Just recently, we reported on Nuxeo’s (news, site) steady progress with Apache Chemistry, a Java implementation of the CMIS spec.

The newest development on this front is OpenCMIS (a project led by Alfresco, SAP and Open Text) that is adding their collection of libraries, frameworks and tools around CMIS to Apache Chemistry.

No, it is *not* an attack against Chemistry, but more of a friendly merger.

Recap on Apache Chemistry

Initiated by Day Software (see our interview with CTO David Nuescheler), Sourcesense and Nuxeo (see our interview with head of R&D Florent Guillaume), Apache Chemistry started as a proposal for a new sandbox called ‘jcr-cmis’ in Apache Jackrabbit. Chemistry entered Apache incubation in April 2009.

Java-centric Apache Chemistry includes:

  • a high level API
  • a low level SPI
  • generic implementations of clients and servers for AtomPub and SOAP bindings
  • sample backends to serve data from repositories

Chemistry now targets CMIS 1.0 CD 05 draft, soon to be 06. Read more on Chemistry here and check the latest status here.

What is OpenCMIS and How the Two Come Together

OpenCMIS (dating back to summer 2009) is a community of folks employed by Alfresco, SAP and Open Text with the usual suspects as initial committers:

  • Florian Mueller (Open Text)
  • Jens Huebel (Open Text)
  • David Caruana (Alfresco)
  • David Ward (Alfresco)
  • Martin Hermes (SAP)
  • Stephan Klevenz (SAP)
  • Paul Goetz (SAP)

The goal of this CMIS implementation is to provide an enterprise-ready client library for Java that was missing in the existing CMIS prototypes, according to Open Text’s Florian Mueller.

Mueller describes the OpenCMIS architecture as follows, pointing out some differentiators between OpenCMIS and Chemistry:

  • There are two layers in OpenCMIS: the provider layer and the client layer.
  • The provider layer implements CMIS bindings. The opencmis-provider-api maps the CMIS domain model, handles immutable data objects (while chemistry-api follows an object-oriented approach)
  • The client layer, being on top of the provider layer, is a Java-like interface with all the classes and methods expected in an object-oriented interface
  • Chemistry uses Abdera to communicate with the server, and OpenCMIS is based on JAX-B and some CMIS-specific XML coding
  • OpenCMIS has a caching infrastructure that is specific to CMIS and OpenCMIS

As Muller notes, “The overall architecture and principals below the API are very, very different. Bringing both together would require philosophy changes on both sides. I'm not saying that this isn't possible, but it's a lengthy process.

Later on and more optimistically, Day’s Paolo Mottadelli describes in his blog OpenCMIS as “the last blast for Chemistry; the other big thing of the beginning of 2010,” as OpenCMIS joins Apache Chemistry with a request to merge the two codebases on the Apache Maven infrastructure. OpenCMIS, by the way, also uses other Apache products, such as Commons Codec and Commons Logging.

This merge is definitely an advancement in open source CMIS efforts on server and client sides, and covers different areas of the project, including:

  • Low level CMIS client library with support for AtomPub and Web Services bindings
  • High level CMIS client library sitting on top of the low level client with Java API (still in development)
  • CMIS server handling CMIS bindings on the server side and mapping them to a common set of Java interfaces
  • InMemory test repository for the CMIS server. A file system based test repository is under development and should be available soon
  • CMIS browser (currently, AtomPub only) for access to CMIS-enabled repositories

Nuescheler referred to OpenCMIS as “well architected and already very mature in its code base.” Even though CMIS is not even an official standard yet (the second round of public review ending today), and these two projects come from different backgrounds, this joint venture looks like a good approach to collaboration, improving the code and helping spring CMIS adoption into the masses.