Waiting for the release of Content Management Interoperability (CMIS), a number of articles on options for the use of CMIS appeared in Internet. Early articles, such as Three fundamental CMIS Use Cases, list some CMIS-based application types, classifying them in terms of interaction between the repository and the client application (R2R, A2R, FR). The following articles and presentations offer some concrete CMIS use cases (eg Revisting the CMIS Use Cases, How will CMIS be adopted?).
Wondering "to CMIS or not to CMIS" (see also CMIS basics post) it's worth to recall the meaning of a letter "I" in abbreviation, i.e. about "interoperability". What are the usecases allowing us to feel the content interoperability advantages and, therefore, necessity and importance of CMIS-ability of developed or purchased CM solution?
Let's recall two mutual targets which caused appearance of the specification:
1. Content integration - ensuring of using the content from various repositories, even created by different vendors in a single application, such as the portal, CMS, etc.
2. Access unification - a minimum interface provided by content repository to decouple the content storage from the application's business logic.
In essence, these problems are similar to those which are solved for a more structured data using SQL. That is why CMIS sometimes compared in importance with SQL, which causes mild irritation of people perceive this comparison too literally.
So, let us explain these requirements in more details:
Content integration
The CMIS client (front-end application or middleware) uses generic interface to access one (simple case) or several content repositories.
Use cases:
Access unification
This requirement caused by the needs of various applications to have a universal interface to access content.
Applications of different purposes and different manufacturers can be simply connect to an CMIS-enabled content repository, considerably reducing the cost of business application development. Indeed, a business application's developer can concentrate on application's business logic rather than compatibility or content migration issues.
Moreover, CMIS enabled content management system allows avoid (or at least significantly reduces) vendor lock-in factor.
Wondering "to CMIS or not to CMIS" (see also CMIS basics post) it's worth to recall the meaning of a letter "I" in abbreviation, i.e. about "interoperability". What are the usecases allowing us to feel the content interoperability advantages and, therefore, necessity and importance of CMIS-ability of developed or purchased CM solution?
Let's recall two mutual targets which caused appearance of the specification:
1. Content integration - ensuring of using the content from various repositories, even created by different vendors in a single application, such as the portal, CMS, etc.
2. Access unification - a minimum interface provided by content repository to decouple the content storage from the application's business logic.
In essence, these problems are similar to those which are solved for a more structured data using SQL. That is why CMIS sometimes compared in importance with SQL, which causes mild irritation of people perceive this comparison too literally.
So, let us explain these requirements in more details:
Content integration
The CMIS client (front-end application or middleware) uses generic interface to access one (simple case) or several content repositories.
- Portals - different components (portlets) use different content repositories through unified interface. So, various by the nature and size data can be arranged in different repositories. Nevertheless, the portal will use the same interfaces for content management. For example CMIS Expert application accessible as a Google gadget.
- Mashups - components which use content from various content repositories, similar to the first case, but unlike the portlets, the client application can be located on the client side (such as Open Social Gadget) or on the server side.
- Federated search - using the content from the various repositories in one application, requesting each of the participated CMIS repository and producing consolidated results. For example AIIM Demo application which uses several repositories from different CMIS vendors.
- Content migration from one CMIS repository to another.
Access unification
This requirement caused by the needs of various applications to have a universal interface to access content.
Applications of different purposes and different manufacturers can be simply connect to an CMIS-enabled content repository, considerably reducing the cost of business application development. Indeed, a business application's developer can concentrate on application's business logic rather than compatibility or content migration issues.
Moreover, CMIS enabled content management system allows avoid (or at least significantly reduces) vendor lock-in factor.
Options of the CMIS-ability
- Content management system which supports CMIS out-of-the-box. The content repositories produced by the main content management players such as IBM, Microsoft, eXo Platform, Alfresco, Nuxeo already support CMIS.
- Middleware solutions, providing necessary CMIS bindings and internal, local interfaces which have to be implemented by CMS vendor in order to make the content CMIS allowable (so called SPI). Such a middleware can be used by the companies, produced dedicated software (for instance, for vertical markets) with proprietary CMS as well as by CMS end users.
Beginning from version 1.0 beta2, xCMIS extends its functionality. Now it is able not only to make CMIS representation for eXo JCR repository but also to expose potentially any content repository through CMIS interfaces.
To do that, a software producer must implement xCMIS Storage Provider Interface (SPI). Find more details on xcmis.org.
That's all for the time. In my next posts I'll try to implement simple CMIS-able content storage using xCMIS's SPI. Stay tuned following @gazarenkov on Twitter.
0 comments:
Post a Comment