JCR for UCM…When did that happen?

So I was on the Oracle UCM documentation page the other day looking for the Javadocs for CIS and I ran across something I had not seen before, the “Content Server JCR Repository Adapter” document.

JCR Screen Shot

It was hiding there is plain site for, well I am not sure how long, I guess I just missed the memo on that one.  Very interesting though.  For those of you who are curious about what a JCR is, it stands for Java Content Repository and though it uses the word “Repository” it’s really more of a connector.  The big thing about it is that it’s a Java standard, specifically the JSR-170 standard actually.

BEA(now Oracle) WebLogic as well as WebCenter(the flagship portal of the Oracle fleet) both communicate to content management systems using a JCR.  UCM and before that Stellent have both traditionally not provided a JCR, rather they provided a pretty robust API known as the Content Integration Suite.  From the new document(and of course it’s location) it appears that the JCR is more or less a wrapper on top of CIS.

The Swiss are Clever

The JSR-170 standard has an interesting history.  It was submitted by Day, a CMS vendor out in Switzerland.  Thier content managment system(and I may be messing this up a little) Communique, leverages a proprietary content repository called CRX which of course is a JCR(and most likely the first).  The thing about Day though is that they are Swiss, and so very clever.  While many CMS vendors had interesting and/or creative content repositories, Day not only touted theirs as the best, they also submitted it as a Java standard.

Since then a number of other vendors began supporting the standard.  Apache released Jackrabbit, I think Vignette uses it too, but really when BEA started adopting it in Weblogic, it became quite a bit more credible.  The Day team and of course the standards committee has since updated it, there’s now a new version known as JSR-283, though I have not seen much use yet.

My Somewhat irrational dislike of the JCR standards

I really don’t like the JCR standards and my reasons really aren’t all that good.  There’s nothing technically wrong with them.  I think they are somewhat on the simple side, but honestly for a standard simple is probably better.  My problem really stems from the fact that they are Java based in a multi-language world.  Having a CMS with a standards-based connector that oh-by-the-way only works in Java, doesn’t make a whole lot of sense.  All of your content consumers must then be in Java, and that just really limits the whole “Enterprise” piece of the Enterprise Content Management system.

The unfortunate thing I would see though was that many CMS vendors would market their support of the JCR standard as a sort of money back guarantee for buying their product.  ”Go ahead and buy our CMS and if you don’t like it you can just switch it out with another, we support the JSR-170 standard”.  While of course that was technically true from a 10k foot level, I am sure the reality of the implementation was much different from the sales presentation.  Of course overcoming the “money back guarantee” argument with “the standard should not be Java-specific” never went over very well though.

Things are looking good

Despite my somewhat irrational dislike, I am pretty excited about this new connector.  There are a number of applications that support JCRs(though most of them serve like UCM), including a Spring module.  In addition it looks like there may be some movement on getting a “Service-like” standard for content repositories and actually we would have the JCR to thank for it.  Back in December, BEA filed a patent for a JDBC-like services wrapper for the JCRs.  Though many folks weren’t too crazy about the fact that they filed a patent instead of just releasing a connector, I think this is a pretty positive move.  Oracle obviously owning BEA won’t hurt the future UCM integration either I’m sure.

About David Roe

Thanks for visiting ContentOnContentManagment.com, my name is David Roe and this is my blog. I work for Ironworks Consulting as a technical lead/architect in our enterprise content management group. My primary focus is implementing Oracle Universal Content Server, which was formerly known as Stellent Content Server. Prior to focusing in Stellent, my work centered around .NET integrations with other content managment systems as well as content management systems built on the .NET framework. I plan on keeping this blog mostly technical in nature. I’m not really one for the Coke vs. Pepsi debates, so plan on seeing quite a bit of ”how to” content. Please feel free to download and use any of the code examples available on the site. As you might imagine none of it is supported or warented..do we need a disclaimer? I do ask that you leave any references to me or this site in the comments though.
This entry was posted in BEA, Content Management, ECM, Oracle. Bookmark the permalink.

5 Responses to JCR for UCM…When did that happen?

  1. Jason Stortz says:

    Thanks for pointing this out! Typically we will stick to using the web services (SOAP) integration almost universally as we have the same patterns to deal with whether we choose a client that is based on java, .net or etc. Each technology has a place however and I have always enjoyed the variety of ways the content server product has supplied for integration. This is yet another avenue, and that’s great. I suppose one of the things I liked the most about this post was the dose reality that you sprinkled on as you discussed the approach of swapping backend vendors and mentioned some of the political games involved in the evolution of JSR’s and JCR’s. I really appreciate it when someone tries to lay out both sides of the story and a little history to boot. Thanks so much.

  2. Atul says:

    Interesting post. I was wondering if you could add email subscription in your blog ;-) .

    Thanks anyway for wonderful update on UCM.


  3. Pingback: coreContentOnly - Why I Like The JCR Post Over At contentoncontentmanagement.com

  4. Boris Kraft says:

    Nice write up. I like the title ;-)
    We have been using JCR with Magnolia since its inception, more than 5 years ago. Magnolia allows to plug in different repositories. The benefit here is less that you can replace Magnolia with another system while keeping the data. This would certainly be possible but only as an intermediate step. However, the ability to switch implementations to see what works best for your specific usage pattern is definitely assuring, and something we do regularly when updates are available. To that extend, I do hope to get my fingers on an Oracle Level 2 JCR eventually.

  5. Hi David,
    I work for Day – thanks for mentioning us. Regarding the “JCR-is-all-Java” topic you bring up you might want to have a look at Apache Sling[1] which is a JCR-based web framework. I wrote a post about how Sling makes JCR content available from languages other than Java[2].

    [1] http://incubator.apache.org/sling/site/index.html
    [2] http://dev.day.com/microsling/content/blogs/main/rubycr.html