It has been a little less than two months since the news of a proposed new enterprise content management standard hit the streets. The Content Management Interoperability Services (CMIS) spec, created jointly by Microsoft, IBM, EMC and a few other Enterprise CMS providers, was the talk of the town -- for better or for worse. But it's been relatively quiet these days and we find that strange considering the importance of a standard like this to the industry. Maybe it's not so important. Maybe it's not all it's cracked up to be. Maybe it's simply a done deal and no one needs to say more...

Quick Recap of CMIS

The Content Management Interoperability Services (CMIS) spec was created by a group of ECM vendors -- specifically, Microsoft, IBM, EMC, Oracle, Alfresco and Open Text. The purpose of the specification is to define a common Web services interface that will allow developers to build applications that can talk uniformly to many different content repositories.
CMIS.jpg

CMIS Service Oriented Architecture

The interface tells developers how to perform basic content management operations that talk to the repository. With every content repository supporting the interface, applications can be developed much easier that combine content from one or more ECM systems. The interface also enables an organization to use more than one ECM in-house, keeping them synchronized. CMIS is designed using a service-oriented architecture (SOA) framework. This means that applications do not have to utilize the entire set of CMIS interfaces. They can pick the ones they need to use. It also means the architecture is loosely coupled -- applications do not have to understand how the interface is implemented inside a particular ECM, they just know it will work. It is important to note that only a basic set of operations used by ECM's have been included in the interface. This "least common denominator approach" is required to ensure that most, if not all, ECM's could easily implement it. There are a number of use cases that have been identified to date for this specification; including portals, collaborative applications, mashups and searching. What this means is that more complicated functions such as records management, Web content management and digital asset management are not a part of this specification.

Components of CMIS Specification

The CMIS specification defines a domain model that includes both a data model and a service model. It then defines specific bindings to two protocols: REST/Atom and SOAP. The domain model defines a set of objects used to manage content in a repository. This model is limited to documents, folders and relationships. The service model defined in the specification includes the following: * Discovery of object type definitions and other repository information * CRUD (Create, Read, Update and Delete) functions * The filing of documents in one or more folders * Navigating and traversing the folder hierarchy * Versioning of documents * Querying a repository (-ies), including full-text searching All ECM's conforming to the specification need to support both the REST and SOAP protocol bindings. SOAP-based Web services are fairly well-known and used in many organizations today. These Web services must also support the WS-Security and WS-I-BP (Web Services Interoperability Basic Profile) standards in their implementation. Both WS-Security and WS-I-BP are standards as defined by the Web Services Interoperability Organization. WS-Security is a standard that outlines how security must be implemented within a web service for both the transport mechanism and the message that's transported. WS-I-BP consists of implementation guidelines describing how a core set of web services specifications must be used together to ensure interoperability. The REST protocol is commonly used in Web 2.0 applications -- particularly, with wikis and blogs. This specific instance of REST is limited to the Atom Pub Protocol (APP) specification. The interfaces are invoked by making HTTP calls. The specification claims that no major redesign of ECM's is required. The specification is designed so that ECM's do not have to make major changes to support it. Some changes may be required, including to existing interfaces. But these changes are not expected to be significant.

Issues with the Specification

While most are positive about the specification and how the REST/Atom and SOAP protocols are implemented, not everyone is thinking happy thoughts. In particular, Roy Fielding has been very outspoken about the specification calling it, "a thin veneer on RDBMS-based data repositories that provides a data model for document-like objects within filesystem-like folders..." Fielding also notes several issues with the specification related primarily to the REST protocol, which he says is not a protocol, but an architectural style and how the HTTP protocol is used. Of course, Fielding knows just a little bit about REST, since he did his dissertation on it: Architectural Styles and the Design of Network-based Software Architectures --which essentially means he created it. He claims there are a lot of unnecessary protocol extensions "that tunnel the Web Services interface through fake-Atom and fake-HTTP". Not a big lover of SOAP-based Web services, Fielding says that, at least, it was created consistent with the design of other SOAP-based services. Others have agreed there may be some issues with the implementation and these have been recognized as potential bugs. Whether or not there are real issues with how the REST binding is implemented should come out when the review process starts for the specification.

Is CMIS Just Another Throw Away Standard?

CMIS is not exactly something new for content management standards. There have been other attempts at defining a standard for this industry. Alan Pelz-Sharpe names a few of them in a KMWorld article: "Take for example DMA, ODMA, DMWare, iECM and JCR 170 -- all great initiatives, but at best adopted half-heartedly, thereby rendering them useless." To be honest, the only one that even sounds remotely familiar is JCR 170 -- and that's because Day Software helped define it as well as it uses it. Pelz-Sharpe goes on to say in that article that the thing that might actually make this standard succeed is that it only covers a basic set of services that everyone agrees on and doesn't try to place standards around more advanced services such as "security protocols, rendering, records management or capture." Those standards may come, but for now we are looking at operations like create, read, update and delete.

Update on the Oasis Standards Process

On October 6, 2008, there was a call for participation in a new technical committee (CMIS TC) whose charter is to define a specification for Web Services and Web 2.0 (like REST) interfaces that "enable information sharing across content management repositories". This specification is to be built upon the proposed draft specification of CMIS (0.5). The role of the TC is not to define how the specific features are to be implemented, but simply to define the domain model and bindings that will be layered on top of the existing ECM's and their current API's. All this to be completed around a universal (or generic) set of capabilities. Specific deliverables and their due dates are: * CMIS Domain model specification (September 2009) * CMIS SOAP-based Web Services binding specification (September 2009) * CMIS REST/Atom-based Web Services binding specification (September 2009) As of November 1, 2008, there has been a lot of support for the work being done, along with support from the interested vendors (Alfresco, Day Software, Microsoft, EMC, IBM, Oracle, FatWire, Open Text, SAP and Nuxeo) and analysts across the industry. Committee members include people from IBM, Microsoft, EMC, Oracle, SAP, Alfresco, Day, Open Text and ACM (Association for Computing Machinery). The first technical committee meeting is expected to take place November 10, 2008, at 12 PM EDT via a conference call. It's interesting that with a couple of exceptions (being Day and ACM), all members of the TC are from the original group that proposed the standard. Does this call into question whether any real issues will be identified and resolved? Does it mean the Specification is going to sail through the OASIS process and very little will change by September of 2009?

CMIS May Not Be Perfect, But It's a Solution

As most already know, many ECM vendors have already developed working prototypes for CMIS. Alfresco, Open Text, EMC and IBM are just some of those that have announced they have done this. Alfresco has even included theirs in their latest enterprise release. This may mean it can't be that complicated. It may also indicate that the entire OASIS review is just a matter of putting the lipstick on an already completed specification and calling it a day (a standard). Is it the perfect solution? Maybe. Maybe not. But the fact that something has been developed that ECMs and other application developers can work with to provide an integrated view of an organization's content is a step in the direction we need to go. We all know the days of a single, in-house ECM system are pretty much over. SharePoint has already taken care of that. We need something to give us hope that our content is manageable -- regardless of where it's located. CMIS does that.