A little while ago(and my last post) I talked a little bit about my surprise discovery of the JCR adapter for Oracle UCM on the documentation site. I received quite a bit of nice feedback about the post and was actually pretty surprised by it as it was one of my more casual entries.
One of the responses though came from a member of the Oracle UCM team and they had some great info that was definitely worth sharing:
- Apparently the answer to the title question, “JCR for UCM when did that happen?” is just before the end of the 4th quarter.
- The API is indeed a wrapper on top of CIS and it implements all of the JSR-170 (Level One) specifications.
- At the time of our email exchange last week, there was a new version coming out. And then later in the week it arrived. You can download it right off of OTN, under the document management section: http://www.oracle.com/technology/software/products/content-management/index.html
- There are a number of nice ADF components that “just work” with UCM. Probably more to come on that. I’m also told that the new JDeveloper version is worth checking out, nothing explicitly in the email about it, but the components might be in there.
There was a semi-cautionary note in the email related to “additional overhead” while using the API. The JCR wrapper from a high level is a lot like a square-peg-to-round-hole connector as it’s making the content server appear as an XML-based content repository. Apparently the extra work required to abstract the repository like that is “sub-optimal”, though it’s unclear whether we are talking about performance or just memory utilization. It’s something to look for though.
Is anyone out there using the JCR yet? I would love to get your feedback on it if you have a chance.
(3 votes, average: 3.00 out of 5)
Loading ...
6 Comments
Sweet. Thanks for the followup info!
Hmmm…something smells fishy about this!
Thanks for the update, tho. I have a client who wants to explore this, so I’ll let you know if I discover anything noteworthy.
David, your recent posts about the JCR specification provided some good background on the spec and highlighted some of the benefits the standard can provide. I’m with a company called First Trace that has taken the JSR-170 specification and used it as one of the core foundations of our software architecture. We provide a family of document management solutions for engineers, called KinnosaONE, that are built on a variety of open industry standards including JSR-170, WebDav, J2EE, Web 2.0 and others.
Both our document management products, Korrigo and Kinnosa, utilize the same JCR (java content repository) for storing and managing critical engineering documents, such as CAD files. Our heritage is in the engineering content management arena where we specialize in providing the highly advanced document management functionality that engineers require to manage complex CAD files, file relationships, and collaborative design processes. We have extended the JSR-170 spec farther than any other software vendor in the Engineering community to create service-oriented architecture (SOA) solutions for engineers. By using a JCR to store and manage files (we call our content repository the Kinnosa JCR) we can provide an open, yet secure, repository for storing files. The JCR has allowed us to challenge the traditional paradigm that documents must be housed in locked, proprietary data vaults. We have developed Add-Ins to the CAD tools our customers use for design work as well as with Microsoft Office, Windows Explorer, and OpenOffice desktop applications. The open Kinnosa JCR can be accessed by these CAD tools, Windows Explorer and common desktop applications so that documents can be managed from the user’s preferred interface.
The JCR approach has really created our opportunity in the Engineering Document Management market. The Kinnosa JCR allows our customers to connect their engineering document repositories with more enterprise-oriented content management (ECM) systems like Documentum, SharePoint, Lotus Notes and others by using connectors, like those described in your posts. Our customers essentially create a “virtual repository” that unifies their data and existing vaults and repositories. Document repositories can be located in different departments, offices or countries but can appear to be all stored locally.
The JCR has allowed us to provide our customers with a truly distributed environment where files can be managed in real-time, without having to resort to inadequate methods such as data replication or data duplication to facilitate collaboration. Additionally, the JCR and virtual repository unifies disparate systems into a single consistent view which eliminates the need to consolidate systems into a centralized corporate repository or conduct painful data migrations projects.
For any of your readers looking to learn more about how we’ve used the JSR-170 spec, here are some hyperlinks to our Website:
First Trace Homepage: http://www.FirstTrace.com
This link provides an overview of our KinnosaONE product family: http://www.firsttrace.com/product-kinnosa-one.jsp
This link provides some information about our software architecture and how we’ve utilized the JSR-170 spec: http://www.firsttrace.com/product-kinnosa-one-architect.jsp
David, I’ve read your recent posts on JCR in Oracle’s UCM with great interest. I’m with Day Software, and we’re very glad that the JCR standard has been embraced more and more by the major enterprise software players. I’ll try to answer some of the questions you posted.
Re: your question “Is anyone out there using the JCR yet?”. You might want to have a look at the post JCR Standardization and Consolidation by the JCR specification lead, Day’s David Nuescheler. It shows, with two nice slides, a sample from the large pool of both JCR-enabled repositories and JCR-enabled applications, which are on the market today (Kyle’s mention of the KinnosaONE above is yet another example
.
Oracle themselves have settled on using JCR standard as the cornerstone of content integration for their enterprise infrastructure, applications, and development tools. The following products from Oracle’s suite have JCR support as of today:
* WebCenter, a major part of the new Oracle 11g suite, is going to have JCR-based content integration (see WebCenter roadmap presentation, Content Integration, slide #14).
* The foundation of the content ingegration, JCR-enabled ADF application framework, has been available for some time in Oracle 10g JDeveloper and Oracle Application server.
* Other known Oracle application products supporting JCR integration (JCR-enabled) are Oracle Portal (see, e.g., this blog) and BEA (now Oracle) WebLogic Portal (via WebLogic JSR 170 Adapter). The list might surely be longer.
* JCR-enabled content repository products, integrating with Oracle’s stack are their own UCM and Oracle ContentDB, as well as EMC Documentum, MS Sharepoint, and IBM Lotus Domino/Notes through additional JCR adapters for these products (see the aforementioned WebCenter roadmap slide).
Re: “JCR wrapper from a high level is a lot like a square-peg-to-round-hole connector”. If one looks at it from the (content) integration perspective, though, it makes a lot of sense as it greatly simplifies integration between various applications and content repositories / providers, and also allows the development tool vendor create fairly generic components working with a variety of content sources (e.g., ADF components from Oracle). Ultimately, it leads to a pluggable architecture, and gives customers more freedom in deploying stuff and reusing/leveraging their existing investments, while working with the new technologies.
Note also that by adding a JCR adapter, UCM’s features can still be leveraged through native user interfaces and APIs, and in addition to that all the applications running on top of WebCenter, ADF, or JCR, can leverage the content managed by UCM without extra effort or cost. The fact that “a number of nice ADF components [...] “just work” with UCM” seems to have been enabled by the JCR standard used in both products.
Hi All,
Great responses..thanks very much for all of them. I think I probably did a poor job of using the term JCR adapter though as I was really referring to just the new Oracle JCR.
The “square-peg” analogy has to do with UCM’s repository vs the JCR XML-based one. From what I’ve heard there is some additional “overhead” with the integration.
Also I was looking for customers using Oracle’s JCR adapter.
All that said, I’ve really enjoyed all the feedback this thread has generated and am working on a Sling example with UCM now. So expect a follow up post soon.
Thanks
David
Do you know if the adapter supports Level (i.e., “write”) JCR compliance, or just Level 1?