Saturday, June 27, 2020

CMIS - Content Management Interoperability Services


­­­­



An Introduction to CMIS

Content Management Interoperability Services
                                                                                                                                


Table of Contents




Introduction
Multiple content management systems are becoming the norm for customers across the globe. With point-to-point connections, the seams always show. Content management tools have evolved into a diverse mix of applications designed to support different aspects or processes within the enterprise. Connecting these disparate repositories allows the content to be accessed as needed, even blended together in new and interesting ways.
The Content Management Interoperability Services (CMIS) specification is a market-driven response to CM integration challenges. CMIS is being developed under the auspices of OASIS (Organization for the Advancement of Structured Information Standards) by an OASIS Technical Committee (TC). CMIS specifies a standardized content management repository access method, providing a powerful, consistent way of connecting CM systems.
The OASIS CMIS standard enables client applications to work with multiple content management systems by defining a standard domain model and standard set of services and protocol bindings for Web Services, RESTful Atom Publishing Protocol (AtomPub) & JSON (Java Script Object Notation).
The Content Management Interoperability Services (CMIS) standard will define a domain model and set of bindings, such as JSON (Browser Binding), Web Service and REST/Atom 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.            
Business Challenges
Ø  Mergers and acquisitions leading to acquisitions of different CM platforms
Ø  Steady stream of new CM products coming up in the market
Ø  Proliferation of CM systems within a single enterprise: content and data in isolated silos
Ø  Operational inefficiencies due to disjointed processes.
Ø  Expensive and costly application development
Integration Difficulties
Ø  The time and money required to integrate just two systems is burdensome
Ø  Integration challenges caused by systems with proprietary features and methods for communicating and accessing the data stored within.
Ø  Integrations are not reusable.
Ø  Maintenance of integration modules is not easy and a costly affair.
Ø  Content assets cannot be leveraged across the enterprise.
Why CMIS?
The purpose of the Content Management Interoperability Services (CMIS) TC will define a domain model including a data model and abstract capabilities for Content Management (CM) and a set of bindings that can be used by applications to work with one or more Content Management Repositories/systems and that can be implemented by content repositories and enable interoperability across repositories.
The CMIS standard will expose core/common ECM repository capabilities in an intentionally generic way. These will allow for applications to be constructed that can work with content residing in one or more ECM repositories, without having to understand implementation differences between the individual repositories or worrying about interface inconsistencies between the repositories
How CMIS works
The CMIS Object Model provides a standard, unambiguous method for accessing repositories regardless of its computing platform or environment. The CMIS specification defines four common types of objects that can be addressed and managed in a CMIS-ready repository:
Ø  Document objects
Ø  Folder objects
Ø  Relationship objects
Ø  Policy objects.
Ø  Item objects
Ø  Secondary objects
Document and folder objects are defined, as their names indicate, to classify objects stored as documents and folders respectively, similar to the way many file systems and repositories define and manage content. The relationships object is used to define relationships between document objects (including links), but also supporting other means of grouping and relating objects in much the same way relationships are defined in relational databases. Policy objects are used to manage policies for accessing and exposing the content. Item object is an extension point for repositories that want to expose other object types via CMIS that do not fit the definition for document, folder, relationship or policy.  Secondary type defines a set of properties that can be dynamically added to and removed from objects. That is, an object can get and lose additional properties that are not defined by its primary type during its lifetime
The CMIS standard defines Web services, Restful AtomPub and JSON (browser) bindings that can be used by applications to work with one or more content management repositories.
Two access methods are defined in the current CMIS specification:
Ø  A Web Services interface (WSDL or SOAP) and
Ø  An alternative Atom Publishing Protocol (ATOM Pub) method.
Ø  JSON (Added in CMIS 1.1)
The SOAP, AtomPub and JSON bindings defined in the CMIS specification are functionally equivalent and consistent — each protocol only defines the syntax for how methods are invoked and how responses are formatted. All of the same CMIS functionality is exposed regardless of which protocol is used.
Bindings and permissions
The CMIS standard has two concepts of permissions, as follows:
Ø  Basic permissions include read, write, and all. A user with Read permissions can only view data from a repository. A user with Write permissions can contribute to a repository, and a user with all permissions has full control.
Ø  Digest permissions are those that are defined by and expressed by a repository. These permissions do not have an explicitly defined meaning in the CMIS specification. They can be looked up at runtime using CMIS interfaces.
The CMIS specification maps allowable actions to the access control level (ACL) permissions defined for a repository. A client application can discover how the permissions that are exposed by the repository affect what actions a user can perform by way of CMIS. Other factors can affect whether a user can perform an action. For example, to check out an object from the repository, a user may need both the appropriate permission and the item.
Web Services Interface
The Web Services method provides a WSDL (Web Services Definition Language) description of the interface to allow developers to connect systems to it. SOAP/WSDL Web Services have been widely adopted for enterprise applications.

CMIS uses Web services and Web 2.0 interfaces to enable rich information to be shared across Internet protocols in vendor-neutral formats, among document systems, publishers and repositories, within one enterprise and between companies.
For those who are new to Web Services, please refer the Annexure section for a brief introduction to Web services architecture.
ATOM Publishing Protocol
The ATOM publishing method relies on the predefined ATOM specifications and processes.
In this binding, the client interacts with the repository by acquiring the service document. The client will request the service document by the URI provided by the vendor. The client will then choose a CMIS collection, and then start accessing the repository by following the references in the returned documents. 
This binding consists of a service document specifying at least CMIS service collections, atom collections, feeds and entry documents. CMIS extends the Atom and AtomPub documents utilizing the Atom and AtomPub extension mechanism. CMIS also leverages link tags to specify additional resources related to the requested resource.  To know more about ATOM Pub, please refer the Annexure section.
JSON (Java Script Object Notation)
JSON is an open standard language-independent format that uses human readable text to transmit data objects. It was derived from JavaScript, but as of 2017 many programming languages include code to generate and parse JSON-format data.
The CMIS Browser Binding is based upon JSON. This binding is specifically designed to support applications running in a web browser but is not restricted to them. It is based on technologies that developers who build such applications already understand, including HTML, HTML Forms, JavaScript and JSON (Java Script Object Notation). Importantly, it does not require a JavaScript library, but rather takes advantage of capabilities already built into modern browsers. It uses just two verbs, GET and POST, and resources are referenced using simple and predictable URLs
While this binding is optimized for use in browser applications, it can also serve as an easy to use binding in other application models. To know more about JSON, please refer the Annexure section.
An Example of CMIS Implementation using Web Services
The Content Management Interoperability Services (CMIS) connector for Microsoft SharePoint Server 2013 enables SharePoint users to interact with content that is stored in any repository that has implemented the CMIS standard. The connector also makes SharePoint Server 2013 content available to any application that has implemented the CMIS standard. CMIS is designed to support scenarios that enterprises commonly encounter when managing content across multiple content management systems in rich, hybrid environments, including:
  • Data migration to and from content management systems in an enterprise.
  • Graphical user interfaces (GUIs) in apps that read data from multiple content repositories.
  • A SharePoint Web Part that uses CMIS to roll up personnel data from multiple legacy content management systems within an enterprise.
  • A mobile application that can access documents from any ECM system.
  • A photo-editing application that saves files to a CMIS repository with ECM features enabled, such as the ability to check in and check out files.
  • A line-of-business (LOB) system that exports report data to an ECM repository.
  • A contract-approval app that uses SharePoint user interface (UI) elements to manage a central approval process while still enabling the contract to be published to several different systems.
An Example of CMIS Implementation using ATOM
IBM CMIS for FileNet Content Manager is the implementation of the OASIS CMIS standard for IBM FileNet Content Manager. It uses the ATOM /REST method for exposing the IBM CM repository.
The following diagram shows how IBM CMIS for FileNet Content Manager connects to your IBM FileNet P8 system and client application.
The CMIS web application is packaged as a WAR (Web Application Archive) file that can be deployed in WebSphere to support REST services expressed in the CMIS specification. The CMIS Web application translates these services at run time to Java™ API calls to the IBM FileNet and IBM Content Manager repositories. The preview uses the IBM FileNet and IBM Content Manager Java APIs to access the native repository.
It is recommended that you deploy IBM CMIS for FileNet Content Manager to a dedicated application server. In addition, it is recommended that you dedicate a server in your IBM FileNet P8 system to IBM CMIS for FileNet Content Manager. IBM CMIS for FileNet Content Manager communicates with Content Engine by using the Content Engine Client Java API. After you install IBM CMIS for FileNet Content Manager, you must install the Content Engine Client on the machine where IBM CMIS for FileNet Content Manager will be deployed and install the Content Engine Client Java API files in the IBM CMIS for FileNet Content Manager Installation directory.
Also, IBM Content Navigator 2.0.3 uses CMIS to connect with various CMIS compliant repositories i.e. IBM FileNet P8 or IBM Content Manager On Demand.
An Example of CMIS Implementation using JSON
Alfresco fully implements both the CMIS 1.0 and 1.1 standards to allow your application to manage content and metadata in an Alfresco repository or in Alfresco cloud
· For existing CMIS 1.0 applications, the Alfresco OpenCMIS Extension extended OpenCMIS to provide support for Alfresco aspects.
· CMIS 1.1 introduces a number of new concepts that are supported by Alfresco. You can now use the new browser binding (JSON) to simplify flows for web applications, use Alfresco aspects, and use the append data support to manage large items of content.
  • The Browser binding In addition to the existing XML-based AtomPub and Web services bindings, CMIS 1.1 provides a simpler JSON-based binding. The browser binding is designed for web applications and is easy to use just with HTML and JavaScript. It uses just two verbs, GET and POST, and resources are referenced using simple and predictable URLs.
  • Using aspects Alfresco aspects are exposed as secondary types in CMIS 1.1. You can dynamically add aspects to an Alfresco object using the API.
  • Appending content In some applications such as journaling, or when using very large files, you want to upload a file in chunks. You might have large files that time out during an upload, or fail because of a bad connection. You can use the CMIS 1.1 append parameter in these situations
  • cmis:item support You can use cmis:item to query some Alfresco object types and your own custom types that are outside the CMIS definitions of document, folder, relationship, or policy.
Benefits of CMIS
Ø  Specialized skills proprietary to each ECM system not required – Developers with specialized skills required to write connectors for each ECM system will no longer be needed. A single CMIS connector will have the capability to talk to multiple systems at the backend.
Ø  Reduced Development Costs and Schedules - A common interface into repositories will eliminate much of the integration work currently required to create a unified view into disparate systems.
Ø  Reduced Change Impact – The change in one system will have less impact on all the other systems and the amount of development needed to accommodate that change is significantly less with CMIS.
Ø  Leverage Existing Investments - Existing legacy applications can be configured to communicate with the middleware using CMIS, thus extending the life of the legacy system until it is migrated to a CMIS-compliant repository.
Ø  Easy Enabling of New Applications - CMIS eases the effort required to achieve seamless integration, freeing business applications from the constraints of content locked in information silos or propriety data formats. End-users will see optimized processes that combine content from multiple sources in a unified view.
Ø  Enhance Content Discovery - In some environments, content applications can be static with little or no change to the configuration and available data over time. Other content applications are much more dynamic, requiring more frequent “scanning” of existing resources and rapid integration of new content systems. CMIS will shine in these dynamic environments by reducing complexity, cost, and time to add new CMS repositories on the fly and by making that content immediately available in a unified view.
ECM Systems / Vendors that support CMIS
The table below shows the Enterprise Content Management Systems that will support CMIS. It also shows when they are going to support it.
Vendor
Product
Comments
Alfresco
Alfresco 3.3+

EMC
Documentum 6.7/7.0

IBM
Content Manager 8.4.3+

IBM
FileNet P8 5.0+

KnowledgeTree
KnowledgeTree 3.7+

Microsoft
SharePoint Server 2010/2013 (Not available in Foundation version)
CMIS 1.0 is supported out-of-the-box in SharePoint Server 2013. It requires installation of the Administration Toolkit in SharePoint Server 2010. Not available in Foundation version
Nuxeo
Nuxeo DMS 5.5+

Open Text
Open Text
Since ECM Suite 2010. Implemented through a CMIS Connector above Enterprise Library Services 10.2.0
Oracle
Oracle Webcenter Content
Content Management REST Service Developer's Guide.
SAP
SAP HANA Cloud Document Service
SAP HANA Cloud Platform Documentation.

Annexure
More About Web Services
Web Services can convert your application into a Web-application, which can publish its function or message to the rest of the world. The basic Web Services platform is XML + HTTP. The diagram below describes the web services architecture.
The Web Services Architecture is defined in the points below.
Ø  Service Processes: This part of the architecture generally involves more than one Web service. For example, discovery belongs in this part of the architecture, since it allows us to locate one particular service from among a collection of Web services.
Ø  Service Description: One of the most interesting features of Web Services is that they are self-describing. This means that, once you've located a Web Service, you can ask it to 'describe itself' and tell you what operations it supports and how to invoke it. This is handled by the Web Services Description Language (WSDL).
Ø  Service Invocation: Invoking a Web Service (and, in general, any kind of distributed service such as a CORBA object or an Enterprise Java Bean) involves passing messages between the client and the server. SOAP (Simple Object Access Protocol) specifies how we should format requests to the server, and how the server should format its responses. In theory, we could use other service invocation languages (such as XML-RPC, or even some ad hoc XML language). However, SOAP is by far the most popular choice for Web Services.
Ø Transport: Finally, all these messages must be transmitted somehow between the server and the client. The protocol of choice for this part of the architecture is HTTP (HyperText Transfer Protocol), the same protocol used to access conventional web pages on the Internet. Again, in theory we could be able to use other protocols, but HTTP is currently the most used one.
More About ATOMPub
Atom is an XML-based document format that describes lists of related information known as "feeds".  Feeds are composed of a number of items, known as "entries", each with an extensible set of attached   metadata.  For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as weblogs and news headlines to Web sites as well as directly to user agents.
 The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources.  The protocol is based on HTTP transfer of Atom-formatted representations.  The Atom format is documented in the Atom Syndication Format. The protocol supports the creation of Web Resources and provides facilities for:
Ø  Collections: Sets of Resources, which can be retrieved in whole or in part.
Ø  Services: Discovery and description of Collections.
Ø  Editing: Creating, editing, and deleting Resources.
 
 

 

 
Central to the Atom Publishing Protocol is the concept of collections of editable resources that are represented by Atom 1.0 Feed and Entry documents. A collection has a unique URI. Issuing an HTTP GET request to that URI returns an Atom Feed Document. To create new entries in that feed, clients send HTTP POST requests to the collection's URI. Those newly created entries will be assigned their own unique edit URI. To modify those entries, the client simply retrieves the resource from the collection, makes its modifications, and then puts it back. Removing the entry from the feed is a simple matter of issuing an HTTP DELETE request to the appropriate edit URI. All operations are performed using simple HTTP requests and can usually be performed with nothing more than a simple text editor and a command prompt. The diagram above describes the same.
More About JSON
JSON
·         stands for JavaScript Object Notation
·         is a lightweight data-interchange format
·         is "self-describing" and easy to understand
·         is language independent *
It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999.
JSON is text, and we can convert any JavaScript object into JSON, and send JSON to the server.
We can also convert any JSON received from the server into JavaScript objects.
This way we can work with the data as JavaScript objects, with no complicated parsing and translations.
JavaScript has a built in function to convert a string, written in JSON format, into native JavaScript objects:
JSON.parse()
So, if you receive data from a server, in JSON format, you can use it like any other JavaScript object.

Sending Data

var myObj = { "name":"Mayur", "age":36, "city":"Gurgaon" };
var myJSON = JSON.stringify(myObj);
window.location = "demo_json.php?x=" + myJSON;

Receiving Data

Example

var myJSON = '{ "name":" Mayur ", "age":36, "city":" Gurgaon " }';
var myObj = JSON.parse(myJSON);
document.getElementById("demo").innerHTML = myObj.name;

Storing Data

Example

//Storing data:
myObj = { "name":"John", "age":31, "city":"New York" };
myJSON = JSON.stringify(myObj);
localStorage.setItem("testJSON", myJSON);

//Retrieving data:
text = localStorage.getItem("testJSON");
obj = JSON.parse(text);
document.getElementById("demo").innerHTML = obj.name;


HelloCMIS - HelloDocument: Creating Folders and Content

With the release of IBM Content Navigator on Cloud, customers are
embracing the concept of cloud for managing their documents. With IBM,
they know the documents will be secured and hosted in an enterprise
class data center.
In the first article we connected to our Navigator on Cloud instance,
browsed the folder structure, and executed some simple queries. In this
article, we will create a new folder and file a new document from the local
file system into the new folder. Although very simple, this example can
easily be converted to handle content submitted via a web site
Apache Chemistry makes it easy
IBM continues to embrace CMIS and with the Content Navigator 2.0.3
release, the JavaScript browser binding is available as a technology
preview. The Apache Chemistry project (http://chemistry.apache.org/)
leverages the CMIS standard and provides client libraries for Java, PHP,
Python, and others. As with the previous example, this example will use
the OpenCMIS Java library.



Connecting to Navigator on Cloud
OpenCMIS makes heavy use of property Maps as a simple way to collect
named value pairs of parameters for operations and this example uses a
HashMap. Create a session by adding a number of required
SessionParameters into the Map and creating the session as shown
below.
package com.ibm.ecm.usingCMIS;
import java.io.File;
import java.io.FileInputStream;
import java.io.InputStream;
import java.util.*;
import org.apache.chemistry.opencmis.client.api.*;
import org.apache.chemistry.opencmis.client.runtime.*;
import org.apache.chemistry.opencmis.commons.*;
import org.apache.chemistry.opencmis.commons.data.*;
import org.apache.chemistry.opencmis.commons.enums.*;
public class HelloCMIS {
public static void main(String args[]){
// default factory implementation
SessionFactory factory = SessionFactoryImpl.newInstance();
Map<String, String> parameter = new HashMap<String,
String>();
// user credentials



Posted by at
Labels: ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)