Driving Interoperability with CMIS

Transcription

1 A guide to understanding the impact of the draft Content Management Interoperability Specification (CMIS) on content management repositories This white paper also includes developer resources for creating prototype, future-proof, portable content applications today: Join - The CMIS Community Download CMIS Draft Implementation Trial Learn - Access the CMIS Developer Toolbox ALFRESCO WHITE PAPER SERIES

2 Introduction Content Management Interoperability Services ( ) is a new specification that was recently unveiled and submitted to OASIS for standardization. CMIS defines a common set of interfaces and capabilities for content management repositories. It will allow application developers to access the repositories in both an application-independent and platform-independent way. According to the original CMIS vision statement: The objective of the CMIS standard is to define a common content management Web services interface that can be implemented by content repositories and enable interoperability across repositories. The CMIS specification was created because many organizations, especially large ones, have multiple enterprise content management (ECM) solutions in place and there is no standardization of application programming interfaces (APIs). Each ECM implementation today has a proprietary API, and proprietary query interfaces. Typically, those APIs are language-dependent. This makes it very difficult to work across multiple ECM applications or to make them interoperate. Additionally, its very hard to use an integration or application written against one application to another ECM system. It usually involves rewriting the system from scratch. One of the goals of CMIS is to provide interoperability and the ability to develop write-once run anywhere portable applications that can run against one repository or across many repositories driven by a business process. In addition to being cross-platform, the standard proposal accounts for differences in capabilities between repositories. A typical interaction with a CMIS-compliant repository starts with a getrepositoryinfo call, which returns a document describing which optional capabilities the repository supports. This means there is a well-defined mechanism to communicate the capabilities of a specific repository. This also makes the standard implementation much easier, as it does not force vendors to add capabilities that may be architecturally difficult to implement. Other standards in this area such as JCR 170, WebDAV and Atom Publishing Protocol were designed to address different problems. The JCR 170 standard is specific to one language Java and for many vendors this becomes a challenge. Additionally, JCR is also quite prescriptive in how a particular system should be implemented, which poses additional problems for vendors as it requires them to retrofit their products, rewrite how they store and access content and provide the API. The WebDAV standard doesnt go far enough to address the full spectrum of ECM capabilities. It was designed to provide authoring services over HTTP and has some limitations (such as no concept of content types, relationships, querying, or properties). Lastly, the Atom Publishing Protocol (AtomPub or APP) was created to address the publishing domain, such as updating documents or editing blog posts and wiki pages. However, since AtomPub is extensible, CMIS chose to extend AtomPub for its REST protocol binding so AtomPub clients can be taught to interact with CMIS. Unlike other standards, CMIS is about delivering platform independence, a key enabler in the next wave of growth for the ECM industry similar to the impact of SQL in the database industry. This whitepaper will describe in more detail some of the core concepts of CMIS, focusing on the domain model definition, query language, and defined services. It will review some target use cases of CMIS 2

3 and identify what is not yet addressed in the draft specification. Lastly, it will introduce Alfrescos open source implementation of the CMIS standard and explain why Alfrescos open architecture and service-oriented design is a natural fit for CMIS. Core Concepts of CMIS First and foremost, CMIS defines a common domain model for content management repositories. It covers common types and allows for extending those types with additional properties and creating relationships between the types. The metamodel is just as important as the domain model because it allows for the discovery of defined custom content types. It must be noted CMIS does not specify how to define content - that is repository-specific. With the standardized domain model, there is a standardized query language based on SQL-92. This query language is very powerful because it offers a standard way of finding and querying information which will allow application vendors to run against any CMIS-compliant repository without having to make any changes to their code. Another area CMIS addresses is a common set of content services. CMIS doesnt define all the common services vendors might possibly implement, but it looks at broadly accepted services most content applications require and most content repositories provide, such as check-in/check-out, versioning, and others. Importantly, CMIS also provides a capability to discover which services a particular repository supports. Additionally, CMIS defines a set of protocol bindings to interact with the model. This allows application developers to connect to the model and invoke some of the services. Initial protocol bindings detailed in the specification are REST-style (HTTP and URL interaction) and Web Services using SOAP. The first part of the CMIS specification document is a definition of experience of ECM practice. It defines models and services which interact with domain services and provides a high-level overview of elements included in the model (such as services commonly seen in ECM). The second part of the specification provides mapping of the conceptual model and services to protocol bindings. It provides a mapping to SOAP Web Services, which in turn will allow users to orchestrate content services in an SOA-type environment (such as BPEL and other tools). The second protocol is REST, which is resource-oriented as opposed to service-oriented, and its very well suited to activities such as publishing, mash-ups, and content syndication. 8

4 CMIS Target Use Cases As part of the specification process, a number of use cases were examined that would be good candidates for CMIS. The following use cases were chosen as ones to focus on for CMIS and represent a good spectrum of the requirements that ECM has traditionally addressed. These include: Collaborative Content Creation This requires authentication, check-in/check-out, and version control to manage documents as they move through their lifecycle; Portals Portals allow access to content that is managed inside an ECM system and displayed in a portal interface. It provides the ability to perform actions such as browse throughout a repository, go through folders, examine properties or perform metadata searching; Mash-ups Mash-ups offer the ability to easily pull and mix and match data. By looking at URL addressability and REST-style APIs, users can allow mash-ups to take place. Typical properties for mash-ups include an ability to select content in the context in which its being mashed up; Archival Applications This involves taking content and archiving it so it can be retrieved at a later date, including looking to manage properties to index and searching across that content; Compound Documents There is a critical need to manage relationships between different individual parts that make up a compound document; and, Electronic Legal Discovery It is increasingly important for organizations to be able to easily find out (via features such as version control, properties, indexing and searching) what information was in effect at any point in time in their organization. Features not included in the CMIS Specification For the time being, there are a few elements which will not be included in the CMIS specification. This doesnt mean these cannot be implemented, however, there are no features in the specification designed to specifically address these areas: Records Management (RM) and compliance to manage retention schedules and advanced classification schemes; Digital Asset Management (DAM) to create multiple renditions of digital content and content streaming; Web Content Management (WCM) in order to find or preview content and deploy it later; and, Subscription and notification services. 9

5 CMIS Domain Model The core concepts of the domain model are very familiar. The domain model is, in fact, fairly constrained, and includes four core object types: document, folder, relationship and policy. Central to all of these object types is the metamodel, which allows for description of the content types and relationships between them (see diagram below). 1. The core of the model is a notion of a document. The document has content and metadata,, which are named values that allow users to further describe the document. A document can also be versioned, so the frozen state of that document can be persisted, reverted back to, or kept for historical reasons; 2. Alongside the document, there is the notion of a folder, which is a container which helps organize the documents within a hierarchy. Folders themselves can be inside other folders. Documents can be placed in a folder, in multiple folders (called multi-filing), or not placed in a folder at all (called un-filing). Folders themselves also support metadata or properties; 3. Relationships allow users to create associations or links between documents. Relationships have a source and a target, and there are many types of relationships possible. For example, relationships can represent a notion of a compound document or a translated document, or one document superseding another; and, 4. Finally, there is the notion of a policy, which is an administrative abstraction that can be applied to a folder or document. For example, a policy could be related to access control to restrict access to a certain user or group, or a policy could be based on the retention of a certain document type. 10

6 CMIS Metamodel Object type is the key notion of the metamodel. Every item in the repository can be described by a specific content type and every type can have a unique ID and display name. Hierarchies of types can be created, such as inheritance from one type to another. Therefore, users can have different types of folders or documents. Additionally, types have metadata describing how that type of item can be managed in the repository. There are four basic object types, relating to the four concepts in the domain model. These include: Document Object Type; Folder Object Type; Relationship Object Type; and, Policy Object Type. From these, users can create custom types to extend the types of information they want to maintain in the repository. Types have some other attributes as well. For example, a type can be abstract, so users cannot create an instance of it but, it can be used as a base type. An object type can also be designated as able to request information so users can use a query to find it. A controllable object type can have policies applied to it. 11

7 Object types have one or more property types associated with them. This describes the metadata which is available against that item in the repository. Each property also has a display name, ID, and data type (such as string or date). In addition, a property can be specified by other types of information such as being required or having a default value. CMIS Services Further to the domain model, the first part of the CMIS specification defines a set of standard services for interacting with the four core objects and the metamodel. The available services are: Repository Services to interrogate the metamodel in order to find out more about the capabilities of the repository (such as which types it supports and the definition of the types); Navigation Services to traverse the folder hierarchy; Object Services for Create, Read, Update and Delete (CRUD) operations on the four fundamental objects (objects, folders, relationships and policies) including content stream operations; Discovery Services for querying of objects, including options for whether or not all versions should be searched and other options; Versioning Services S to enable check-in/check-out, retrieving and deleting of versions; Relationship Services to explore relationships between objects; and, Policy Services for applying and removing policies. 12

8 There are three broad categories of actions which these services enable (as detailed in the diagram below): 1. Browse - The first set allows users to browse information in the repository. For example, users can interrogate information about the repository itself such as the vendor and version of repository. Users can interrogate the types of information the repository contains. Users can also traverse the hierarchy to find out which documents are checked out to a particular user, or all users. Additionally, users can find items in the repository by issuing a query. 2. Inspect - After browsing, users can inspect the found items and examine its metadata or contents. Users can determine what kinds of actions are allowed against a document (such as whether or not users can file the document against a particular folder). Users can also inspect the version history and interrogate metadata or content for each version. In compound documents, users can traverse relationships to find out about items inside the compound document. Additionally, users can also determine what kind of policies have been issued against each of the documents inside the repository. 3. Act - Lastly, users can act upon those items. Users can create new objects, documents, folders and relationships. Users can move them around, delete or copy them. Users can also create new versions, check-in /check-out, delete versions and apply or remove policies. 13

9 CMIS Query Language The first part of the CMIS specification also provides a definition of a standard query language for CMIS. The query language is a form of SQL, which means the specification provides a mapping between the domain model and the relational view of the model. This allows the CMIS repository to be exposed as a relational database. Each object that can be queried is mapped as a relational type or a virtual table. The SQL Query Language itself is a subset of SQL -92, with some extensions specific to the content management world. These extensions are based on almost 20 years of experience writing content queries based on SQL by experts with extensive database and content management experience. The most important of those extensions are: ANY - ability to query multi-valued properties common in properties such as keywords; IN_FOLDER() and IN_TREE() - ability to find documents and recursively descend a folder hierarchy; and, CONTAINS() and SCORE() to search text inside the content and relevance ranking of results. These can be combined with traditional attribute search. The query below finds documents containing the text string Caribbean Central America Cruise Tour picking out any DepartureDates (multi-value property) after January 1 st It also sorts it based on relevance of the search. SELECT ObjectId, SCORE() AS Relevance, Destination, DepartureDates FROM TravelBrochure WHERE CONTAINS( CARIBBEAN CENTRAL AMERICA CRUISE TOUR ) AND < ANY DepartureDates ORDER BY Relevance DESC Interestingly, the content stream is not part of the SQL specification and cannot be returned through querying as other services handle retrieving the content. Additionally, there are some optional repository specific capabilities which can be discovered, such as the level of search support, and inner and left outer joins support, among others. 14

10 Alfrescos CMIS Implementation As one of seven participants in the initial CMIS standardization process, and the only open source vendor, Alfresco released the first open source implementation of the CMIS specification as part of its Labs 3 release on the same day that EMC, IBM and Microsoft announced the publication of CMIS. Alfrescos Labs 3 includes the first publicly available and open source implementation of CMIS v0.5 as used in the recent Plugfest where IBM, EMC, Microsoft, Open Text, Oracle, SAP and Alfresco tested the interoperability of their servers and clients via CMIS. Below is an architectural diagram of the CMIS implementation with Alfresco: As a contributing member to the CMIS specification, Alfresco has provided feedback and helped push forward the specification. By building an implementation using the specification, Alfresco has helped to test how feasible it is to map to an existing content repository and to develop test clients supporting the primary use cases. As a result, the draft CMIS implementation in Alfresco Labs 3 provides: Support for the CMIS REST binding allowing client applications to connect to, navigate, read, and create content against the Alfresco content repository. The CMIS REST binding is built 15

11 upon Alfrescos Web Scripts with extensions for Atom / AtomPub, described below; Support for the CMIS SOAP Web Services binding built upon Apache CXF; Support for the CMIS Query Language providing SQL-like querying of the repository, including location, properties, and full-text; and, A CMIS test suite to allow compliance compatibility testing against any CMIS-compliant REST Binding. Throughout the implementation process, the engineers found CMIS was a natural fit for Alfresco. Alfresco is already designed using a service-oriented approach on the backend - and has often been used in content-as-a-service scenarios. With Alfrescos native capabilities for adding SOAP and REST-based Web services, the CMIS implementations were extremely quick and easy to develop. The Web Script architecture was developed on the basis of advanced knowledge of the forthcoming standard, making the transition to CMIS a natural progression. Apache Abdera CMIS Extension Apache Abdera is an implementation of the Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023) specifications. The CMIS REST API binding is an extension of the Atom Publishing Protocol. Therefore, Apache Abdera may be used as a client library to any CMIS REST provider. To support the custom CMIS schema, the Alfresco draft implementation provides a CMIS extension to Apache Abdera. Alfresco Test Harness The Alfresco test harness exercises the CMIS REST API binding. It's available in the following flavors: JUnit test; and, Alfresco Repository hosted Web Page. By default, the test executes against the Alfresco draft CMIS implementation. However, it can be repointed to any CMIS REST API provider by adjusting a few configuration properties. The test harness also doubles as an excellent set of Java CMIS client samples - Test Harness Source Code. 16

12 Conclusion This is just the beginning for CMIS. A draft charter for CMIS has been submitted to OASIS and Alfresco looks forward to the time when it becomes an OASIS standard. In the meantime, it is expected that a cross-section of ECM, Web Service and RESTful expertise will join in this initiative. Alfresco has provided its draft CMIS implementation to foster discussion, to provide a learning tool to gain hands-on experience and to ensure a robust, implemented specification. If the promise of CMIS is fulfilled the ECM industry will have the equivalent of SQL / JDBC for the database industry. Companies will be able to use new standards-based APIs to write applications which are portable and can run against multiple ECM repositories. This should lead to the next wave of growth for the ECM industry as content repositories take their rightful place along with structured database management systems, as a key platform for innovation. Next Steps Alfresco CMIS Developer Toolbox As a contributing member of the draft technical specification, Alfresco is committed to growing the CMIS Community and being the leading Open Source CMIS member, driving development, discussion and adoption of both CMIS and CMIS best practices. In order to encourage developers to learn, explore and prototype CMIS, the Alfresco CMIS Developer Toolbox provides the following resources on and CMIS Trial a download trial of the draft CMIS implementation; CMIS Sample Dashlets demonstrating how to use the CMIS REST API; CMIS Wiki home of all things CMIS, including details of the technical specification CMIS Q&A covering the top ten questions asked about CMIS; CMIS Survey for developers to provide feedback on their experiences with the CMIS; CMIS Forum participate in discussions on the evolution of the standard; CMIS Blog hear from an OASIS CMIS committee member on the progress of the standard and Alfrescos implementation of it; CMIS On-Demand Webinar discover what CMIS means to the ECM user community; and CMIS White Paper understand the impact of CMIS on content management repositories. Alfresco Software Inc. 428 University Avenue, Palo Alto, CA 94301, USA Telephone: Alfresco Software, Park House, Park Street, Maidenhead, Berkshire, SL6 1SL, UK Telephone: Fax: info@alfresco.com WP