Full RSS Feed
Receive
the Free CMSWire Newsletter
WCM Fields Notes is a regular column written in collaboration with Jon Marks (@McBoof), head of development at LBi. This first issue looks at evolving standards in the content management space and how they might influence you when selecting and implementing a web content management system.
The web is humming with talk of standards at the moment — due mainly to the fact that the Content Management Interoperability Standard (CMIS) version 1.0 is nearing its final state and open for public review.
To celebrate this, I recently drew a picture:
CMIS, JCR and OSGi for Idiots by Jon Marks (full version here)
Now while this picture is undoubtedly the best thing you've ever seen, it may very well make zero sense to you. To address that problem, in this article I shed some light on what the JCR, CMIS and OSGi standards are, and why you should care about them.
Java Content Repository (JCR) Alive and Well
Unlike standards such as WebDAV and the other JCR (the Johnson County Republicans), the Java Content Repository is still in active development.
For the purposes of this article, let's define the JCR as an infrastructure specification for interacting with general purpose content repositories using a Java API. If JCR is a new topic for you, I strongly recommend having a look at JCR In 15 Minutes by Bertrand Delacretaz.
For the rest of us, let's remember that a content repository is a multi-purpose service that combines the best of relational databases and file systems, with a number of useful facilities like versioning and observation. The following diagram — presented by David Nuescheler (@davidnuescheler), JCR Spec Lead,Official JCR/CMIS Liaison and CTO of Day Software, at the recent JBoye conference in Aarhus — provides us with a quick reference for typical content repository services.
Content Repository Concepts by David Nuescheler
The Java Content Repository specification has evolved over a number of years and with the participation of many different software organizations. Three months ago we saw the final release of version 2.0 of the spec. The two versions of the Java Content Repository — JCR 1.0 and JCR 2.0 — are defined by two Java Specification Requests, JSR-170 and JSR-283 respectively.
The following diagram provides a high level view of JCR and the domains of v1.0 versus the v2.0 specification.
JCR from 10,000 Feet — v1.0 versus v2.0
The v2.0 iteration deprecated XPath support and introduced a number of new features, with my personal favorite being Shareable Nodes. The Shareable Nodes feature gives you the ability to implement a content graph, not just a tree. In other words, with v2.0 a content item in the repository can have more than one parent.
Does JCR Need to be in Your RFP?
In the field, I still see the JCR specs mentioned in many content management RFPs. Then again, we know that buzzwords are often included in CMS RFPs just for the sake of it. To this point Matt Hamilton (@HammerToe), Technical Director of Netsight, tweeted this recently:
Got govt tender doc mandating JCR-* standards, which effectively mandates Java. Can a govt body legally mandate a technology in a tender?
Matt raises an interesting question. I don't think we'll ever know if this was put into the RFP to intentionally mandate Java, or was simply cut-and-paste from some other buzzword-rich requirements document.
I often see strange stuff in CMS RFPs. Piero Tintori (@pierotintori), CEO at TERMINALFOUR (news, site) has some funny examples of questions he recently saw. My favorites include "What size are the shipping pallets used for your product?" and "Is your product radioactive?".
You need to understand that mandating JSR-170 and/or JSR-283 in your RFP implies a Java-based CMS. If you include such requirements, know precisely why, have a clear business case supporting your thinking, and don't waste the time of the non-Java vendors by sending the RFP to them.
The New Kid on the Block: CMIS
The Content Management Interoperability Specification (CMIS) is an OASIS project started in 2008 and driven by a number of medium and large content management vendors (i.e., Alfresco, Day, EMC, Fatwire, IBM, Microsoft, Open Text and others).
At this point I'm assuming that most readers have basic familiarity with CMIS. But for those that don't, have a look at the informative JCR loves CMIS presentation by Nuescheler and review the CMSWire coverage here. If you're feeling ambitious, you can take the deep dive on the OASIS project website.
For the purposes of this article, let's define CMIS as an interoperability specification for interacting with document-centric content repositories via HTTP-based protocols.
To keep ourselves on the straight and narrow, focus on the oft overlooked word interoperability in the CMIS acronym. Keep in mind that the aim of CMIS is to allow diverse systems to interoperate.
Further, CMIS is by definition a lowest common denominator specification — it only provides core functionality. And by being simple, it is meant to be easy for vendors to implement. In terms of its place in the standards world, CMIS is intended to complement JCR, not compete with it — JCRs are used as a systems internal repository, where as repositories interacted with via CMIS-compliant interfaces are typically supplementary.
Continue reading this article:
Email It
