As you know, there is a lot of vendors for Enterprise Content Management systems (ECM) and they all have different interfaces. Content Management Interoperability Services (CMIS) is a standard for improving interoperability between Enterprise Content Management systems. The vendor-neutral OASIS Web services interface specification published two versions of CMIS v1.0 and v1.1, then the Technical Committee was closed on 09 May 2017 and is no longer active but the standard is still used by almost all CMS products.
What this means?
In fact, you can write applications targeting Alfresco, Documentum, SharePoint and other ECM systems using CMIS without writing one line of a vendor-specific code, so one source code to interoperate with them all… Compare it with JDBC to connect to any database that provides a JDBC driver 😉
This kind of standardization must survive and be constantly up to date, because it enable applications to target different ECM repositories uniformly with a common interface and I think that is really cool.
At the root of the CMIS model and services is a repository, which is an instance of the content management system and its store of metadata, content, and indexes.
The repository is the end point to which all requests are directed. In the RESTful model, it is the root path of the resources being addressed in CMIS, then it is capable of describing itself and its capabilities.
A CMIS Query is based upon SQL-92. The query is read-only and presents no data manipulation capabilities!
The syntax consists of the following clauses:
- SELECT with a target list.
- FROM with the object types being queried.
- JOIN to perform a join between object types.
- WHERE with the predicate.
- IN and ANY to query multi-value properties.
- CONTAINS to specify a full-text qualification.
- IN_FOLDER and IN_TREE to search within a folder hierarchy.
- ORDERBY to sort the results.
The CMIS query maps the object type into a relational structure where object type approximates a table, the object approximates a row, and the property approximates a column that can be multi-valued.
CMIS provides services that you can access using SOAP or AtomPub, and include the following:
- Repository services let you discover available repositories, get the capabilities of these repositories, and provide basic Data Dictionary information of what types are available in the repository.
- Navigation services let you navigate the repository by accessing the folder tree and traversing the folder/child hierarchy.
- Object services provide the basics (Create, Read, Update, Delete) and Control services on any object, including document, folder, policy, and relationship objects. For document objects, this includes setting and getting of properties, policies, and content streams.
- Object services retrieve objects by path or object ID. Applications may also discover what actions users are allowed to perform.
- Multi-filing services let you establish the hierarchy by adding or removing an object to or from a folder.
- Discovery services provide Query and Change services, and a means of paging the results of the query.
- Change services let you discover what content has changed since the last time checked, as specified by a special token. You can use Change services for external search indexing and replication services.
- Versioning services control concurrent operation of the Object services by providing Check In and Check Out services. Version services also provide version histories for objects that are versioned.
- Relationship services let you create, manage, and access relationships or associations between objects as well as allow an application to traverse those associations.
- Policy services apply policies on document objects. Policies are free-form objects and can be used by implementations for security, record, or control policies.
- ACL services let you create, manage, and access Access Control Lists to control who can perform certain operations on an object.
Web Services (SOAP)
This binding is based on the SOAP protocol All services and operations defined in the CMIS domain model specification are present in the Web Services binding. For example, in Alfresco you can get a summary of the CMIS services from the following URL:
This RESTful binding is based on the Atom Publishing Protocol. Clients communicate with the repository by requesting the service document, which is obtained through a well-known URI. For example, in Alfresco the service document is at:
Personnaly, I used AtomPUB which works very well, and I think is being the most performant and the most popular. But if you’ve ever looked at the XML that comes back from a CMIS AtomPub call you know how verbose it can be!
CMIS v1.0 vs v1.1
CMIS 1.1 has some exciting new features comparing to v1.0. I will not list all v1.1 news, but you can find below the two important news (for me):
The Browser Binding is based on JSON, so the payloads that go between client and server are smaller, making it the fastest of the three bindings.
The original purpose of the Browser Binding was to make it easy for those building “single page” web apps, but I think apps of all types will move to the Browser Binding because it is easier to work with.
This allows CMIS developers to create and update the repository’s content model with code. Sometimes you will need content types to store objects with metadata specific to your solution.
Before CMIS 1.1, you have to ship repository-specific content models and configuration instructions with your app.
With CMIS 1.1, developers can simply write install and config logic as part of the solution that will interrogate the repository to determine if any changes need to be made to the content model to support the solution.
So, for the moment we have CMIS 1.0 and 1.1, which is cool but as you know things are moving fast and the CMIS need to follow… Do you think that we will see a CMIS 2.0 soon?