Building a Services Layer for Alfresco – When CMIS is Not Enough

We’ve had a number of clients, especially those migrating from a legacy ECM platform, ask us about how to go about building a services layer for Alfresco.  Typically these clients have existing applications that use either a legacy API or proprietary services layer for the old platform.  One question that comes up is: “should we use CMIS”?  For this post, lets talk about what CMIS is and when it may not provide enough tools for your applications.

What is CMIS?

At it’s core, The Content Management Interoperability Services, known as CMIS, provide for a generic API layer that can be used against many different ECM systems.  From the CMIS 1.1 spec:

The Content Management Interoperability Services (CMIS) standard defines a domain model and Web Services, Restful AtomPub and browser (JSON) bindings that can be used by applications to work with one or more Content Management repositories/systems.

The CMIS interface is designed to be layered on top of existing Content Management systems and their existing programmatic interfaces. It is not intended to prescribe how specific features should be implemented within those CM systems, nor to exhaustively expose all of the CM system’s capabilities through the CMIS interfaces. Rather, it is intended to define a generic/universal set of capabilities provided by a CM system and a set of services for working with those capabilities.

CMIS Limitations

Since CMIS is an API that must be able to span many different ECM platforms, it becomes necessary to only support basic functionality common across each repository.  CMIS attempts to go beyond the very basic CRUD (Create Read Update Delete) commands, but there are still ECM features that do not exist.  When CMIS was first introduced, there were high hopes in 2010-2013 that “this was just the beginning” and that CMIS would commoditize the ECM industry.  For example, see this article from AIIM in late 2010.  The 1.1 spec was released in 2012, but as of early 2017 there have been no further CMIS spec releases.  CMIS has also been criticized as being more focused on Document Mangement vs. the whole of what clients use ECM platforms for.  Some examples:

• Workflow – CMIS does not provide support for BPM / workflow functionality
• Lifecycle – CMIS does not provide support for document lifecycles.  See this article for a detailed discussion of Alfresco versus Documentum as it relates to version, security and lifecycle.
• Audit Trail – CMIS does not provide APIs to access the repository query audit trail.  We’ve also seen clients request custom audit entries as part of an application implementation as well.  CMIS does not provide APIs to place an audit trail item.
• Rendition Creation – clients typically configure the ECM repository to automatically rendition documents into PDF when placed into the repository for easy view-ability in browser based applications.  This is typically an automatic action at the ECM server level, so it makes sense that there are no CMIS APIs related to creating a rendition.  However, we have had clients request functionality related to a user requesting a re-rendition of a document or providing a PDF rendition as a document upload.
•  Version to Version Associations – as discussed in this post, Alfresco does not support version-to-version associations.  Therefore, if you require document annotations to stick on a particular version, or more complex controlled document versioning and security requirements, a CMIS-only approach will not work with Alfresco
• Non-core ECM API functionality – we’ve seen clients request features that don’t necessarily fall into the CMIS realm; however, it is nice to have a single API to handle these types of items.  While we wouldn’t expect CMIS to support these requirements, many clients want functionality like:
  • PDF to Image transformations – for display of PDF pages for annotation, as in our OpenAnnotate product.
  • PDF Manipulation – give users the ability to split, merge, and rotate PDFs.
  • Checkout to Cloud – when checking out a document, place the document in the cloud (Ex: OneDrive or Google Drive) for easy web-based editing.
  • Download Multiple documents as a zip file.  For example – this could be from a list of documents, or exporting an entire folder as a zip.
• High Performance – while performance concerns may be negligible for user-based applications, it could be noticeable in large batch scenarios like a document migration.  A 100 millisecond slowdown  won’t be noticeable when dealing with one document, but can become a big problem when working with millions.

Luckily, Alfresco has many APIs available, CMIS just being one of them.  TSG has been building our Rest-based OpenContent services layer since 2007 to satisfy client requirements around ECM repository functionality.  For clients that would like to go beyond the ECM basics with an Alfresco application, we’ve had a lot of success with our clients utilizing OpenContent or the other Alfresco APIs.