CMIS - the new Lingua Franca of ECM?
Added By Kas Thomas at 10-Sep-2008 | Twitter: @KasThomas |
It's often said that the great thing about industry standards is that there are so many of them. Now we have one more.
A short while ago, three of the biggest behemoths of content management (namely IBM, Microsoft, and EMC) announced a new standard... one that, if it does indeed become an accepted standard, is supposed do for the content-management world what ODBC and SQL did for the database world. (We've heard that one before, but keep reading anyway.)
The Content Management Interoperability Services specification (soon to be submitted to OASIS) is a set of protocols, exposed via REST and Web Services definitions, for platform-independent interchange of repository content. Using CMIS-defined HTTP calls, you will be able to do standard CRUD operations (create, read, update, delete) against any compliant repository, regardless of the underlying repository architecture.
Notably, CMIS leverages the Atom Publishing Protocol in its REST model (and indeed requires compliant repositories to honor APP, although they can optionally honor additional transfer representations, such as JSON). SOAP is written into the spec as well, for what that's worth.
The press releases around CMIS are loud and proud, trumpeting the spec's ability to enable platform-agnostic content mashups, easier cross-silo federation, rapid application development made possible by a common API, cleaner abstraction of content and content services from application logic, and so on.
We've heard these sorts of claims made before, of course. Proponents of the Java Content Repositories spec (originally JSR 170; now JSR 283) pushed JCR using exactly the same selling points. In fact, with just one exception, the originators of CMIS (IBM, EMC, Open Text, Oracle, SAP, Alfresco, and Microsoft) were the proponents of JCR: They were all, except for Microsoft, on the JSR 283 Expert Committee (and still are).
JCR achieved relatively little traction in the WCM and ECM worlds, though. Why should we expect CMIS to fare any better? After all, if JCR (with the same promoters as CMIS) floundered, why won't CMIS?
The answer could turn out to be quite simple. As I noted in an earlier blog, the main impediment to widespread adoption of JCR has always been the 'J': the dependency on Java. The whole world doesn't run on Java; therefore it was never realistic to think the world would embrace JCR. (Certainly Microsoft was never going to advance a Java standard.)
With CMIS (which is superficially quite similar to JCR and Apache Sling), there is no 'J' in the way. Does that mean CMIS will automatically enjoy the sort of uptake JCR never achieved? Of course not. There are many other potential obstacles to adoption, and even if the standard does gain traction, it's always possible for specific implementations to conflict in unexpected ways or be extended in nonstandard directions (as Microsoft tends to do with standards that it initially gets behind, but later hijacks or subverts in some way).
A short while before he posted his official reaction on dev.day.com, I asked JCR Spec Lead David Nuescheler (of Day Software) what he thought about the seeming collision between JCR (and Sling) and CMIS. His response was that just as the HTTP spec doesn't compete with the Java Servlet spec, JCR does not compete with CMIS. He sees no conflict. In fact, he welcomes the arrival of a high-level content protocol that transcends any one programming language. It's a net win for everybody.
I tend to agree. Here's hoping IBM, EMC, Microsoft, and the others will follow Alfresco's early lead and actually implement CMIS rather than (as they did with JCR) just issue press releases about it.
Categories: Kas Thomas, Enterprise Content Management, Web Content Management, Implementation, Industry Standards, Information Architecture, Alfresco ECM, Communique, Documentum , Documentum, Enterprise Content Management Suite 10gR3, FileNet P8 Platform, LiveLink ECM Suite, Microsoft Office SharePoint Server 2007, SAP NetWeaver
