xCMIS(1): CMIS basics

That is the first post in a series of xCMIS - an Extendable Open Source implementation of OASIS's Content Management Interoperability Services (CMIS) standard. 

Let's start with small introduction of the standard itself, its domain model and some specification internals (really briefly).

Why CMIS?
Over the past decades, mankind has accumulated a huge number of electronic documents, which led to the emergence of a large number of content management systems on the market. All of those systems have proprietary interfaces which creates problems for both smaller and bigger customers. Indeed, small-to-mid ones have to choose between very expensive solutions from big vendors and cheaper solutions with the risk of not finding a provider "alive" tomorrow. While mid-to-big companies with multiple CMS from multiple providers has suffered from limitations of their interoperability.
This situation led to the creation of CM related Open Standards such as WebDAV and then Java Content Repository JCR (with open implementations such as Apache Jackrabbit and eXo JCR).
Later, ECM vendors started discussions about the idea of a standard to make it easier to share and manage content and an Organization for the Advancement of Structured Information Standards (OASIS) technical committee was formed to write a formal specification of a Content Management Interoperability (CMIS) standard.

CMIS Domain Model
Domain model of CMIS is pretty simple and non-restrictive, it defines a Repository as a container and an entry point to the objects.

Repository manages entities called Object. All objects are classified by Object Type which declares that all objects of given type have common set of Properties and Attributes (such as TypeID, Parent, Display Name and others). There are four base types Document, Folder, Relationship, and Policy which inherit Object as it shown on diagram below. In addition you can extend those basic types of modifying a set of their properties.

Fig. CMIS Domain Model

Document is similar to a file, it has properties to hold document metadata, such as the document author and modification date and custom properties. It can also contain a content stream (in many cases that is why it needed) and renditions, such as a thumbnail view of a document.
Folder is self-explained, it is container for other objects. Note, that apart from default hierarchical structure, CMIS is optionally able to store objects in multiple folders or in no folders at all (so called multifiling and unfiling capabilities)
Relationship object defines a relationship between two objects (target and source). An object can have multiple relationships with other objects.
Policy is a way of defining administrative policies to manage objects. For example, you can use a CMIS policy to define which documents are subject to retention policies.


CMIS Services
The CMIS specification also defines a set of services to access and manage the content or repository including:

• Repository Services: are used to discover information about the repository, including information about the repository and the object-types defined for the repository
• Navigation Services: are used to traverse the folder hierarchy in a CMIS Repository, and to locate Documents that are checked out
• Object Services: provides ID-based CRUD (Create, Retrieve, Update, Delete), operations on objects in a Repository
• Multi-filing Services: (optional) make it possible to put object to several filders (multi-filing) or outside folder hierarchy (un-filing)
• Discovery Services: are used to search for query-able objects within the Repository
• Versioning Services: are used to navigate or update a Document Version Series (checkOut, cancelCheckOut, getPropertiesOfLatestVersion, getAllVersions, deleteAllVersions)
• Relationship Services: (optional) are used to retrieve the dependent Relationship objects associated with an independent object
• Policy Services: (optional) are used to apply or remove a policy object to a controllablePolicy object
• ACL Services: are used to manage the Access Control Llist of an object.

As you can see, not that much and a repository might not implement certain optional capabilities, but is still considered CMIS-compliant.
Each of the services has two bindings which defines the way messages will be serialized and wired. Both bindings based on HTTP, one uses the Atom Publishing Protocol, and the other uses Web services based on SOAP. Specification obliges CMIS compatible repositories support both but does not limit to have more (first possible candidates are JSON).

Thats it for the first xCMIS post, I'll continue to talk about CMIS internals/usecases and of course about xCMIS features, so see you later.
Feel free to drop your comment or tweet me @gazarenkov

Resources: 
xCMIS project: http://code.google.com/p/xcmis/
OASIS CMIS specs: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis