Adapting Content Management Interoperability Services for Web Content Management Systems DENNIS NKANGI

Adapting Content Management Interoperability Services for Web Content Management Systems DENNIS NKANGI Master of Science Thesis Stockholm, Sweden 2010

Adapting Content Management Interoperability Services for Web Content Management Systems DENNIS NKANGI Master s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2010 Supervisor at CSC was Kjell Lindqvist Examiner was Stefan Arnborg TRITA-CSC-E 2010:173 ISRN-KTH/CSC/E--10/173--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc

Standards are like parachutes: they work best when they re open. Mary P. McRae, Director, Standards Development, OASIS

Abstract Adapting Content Management Interoperability Services for Web Content Management Systems Content Management Interoperability Services (CMIS) is a standard aiming at solving the problem of managing dispersed content repositories. The objectives of this thesis were to evaluate the standard from a.net-based Web Content Management System s perspective, using EPiServer CMS as a platform for proof of concept. CMIS version 1.0 is a document centric standard, which provides value mostly to content management systems with a focus on document management. It may be applied to web content management systems with the reservation that the developers must themselves define and implement the mapping of web content to custom CMIS data types. Some of the CMIS design principles do not correlate with the.net design principles and Windows Communication Foundation (WCF). The standards is strict on the issue concerning XML serialization and format, where the principles of WCF is towards abstracting those issue from the programmer, letting the framework handle serialization and format. CMIS does solve the problem of dispersed content repositories for.net based web content management systems, if they are limited to document management and if developers are willing to adapt to the CMIS design principles and thereby depart from some of the features in.net and WCF. The standard needs to address the issue of web content in order for it to be useful within web content management, in a broader perspective.

Sammanfattning Appliceringen av standarden Content Management Interoperability Services på webbpubliceringssystem Content Management Interoperability Services (CMIS) är en standard, vars mål är att lösa problemet med spridda content repositories. Syftet med denna avhandling har varit att utvärdera standarden CMIS från perspektivet av ett.net-baserat webbpubliceringssystem. Och att i denna process använda EPiServer CMS som en plattform för att utveckla prototyper och påvisa slutsatser. CMIS version 1.0 är en dokumentcentrerad standard, som tillför ett värde främst till publiceringssystem som fokuserar på dokumenthantering. Standarden kan även appliceras på webbcentrerade publiceringssystem, med förbihållet att utvecklarna själva måste definiera och implementera kopplingen mellan webbinnehåll och dess anpassade CMIS-datatyper. Vissa av CMIS:s designprinciper sammanfaller inte med.net:s eller Windows Communication Foundations (WCF) designprinciper. Standarden är strikt i hanteringen av XML-serialisering och -format, medan WCF:s linje är att abstrahera dessa delar från programmeraren. CMIS löser problemet med spridda content repositories för.net-baserade webbpubliceringssystem, förutsatt att dessa är begränsade till dokumenthantering och att utvecklarna är villiga att anpassa sig till CMIS:s designprinciper och därmed frångå vissa funktioner i.net och WCF. Standarden behöver anpassas för hantering av webbinnehåll för att vara användbar inom webbpublicering i ett bredare sammanhang.

Acknowledgements I would like to thank all the people who assisted me throughout my work. My sincere thanks to: Kjell Lindqvist, my supervisor at CSC, for his for his excellent guidance throughout this project. Per Bjurström, senior developer and architect and my supervisor at EPiServer, for his excellent guidance and for sharing his eminent expertise within.net development. Pelle Niklasson, development manager at EPiServer, for taking me in at EPiServer, and for his encouragements and support throughout this project. Fredric Rylander, for all the interesting discussions on program development and design patterns, for proofreading the early drafts of my degree report and for his many valuable comments and tips. Simon Nkangi, for his help with graphics for my prototypes and for proofreading my degree report. Johanne Wilkens, for her honest support and for proofreading my degree report. Finally, my sincere encomiums to the people at EPiServer for letting me work at their office through the period of my degree project and for offering their expertise.

Contents 1 Terminology... 1 2 Background... 2 2.1 EPiServer... 2 2.2 The CMIS Specification... 2 2.2.1 Scenarios and Restrictions... 3 2.2.2 Domain Model... 3 2.2.3 Document Object... 4 2.2.4 Folder Object... 4 2.2.5 Relationship Object... 4 2.2.6 Policy Object... 4 2.2.7 Meta Model... 4 2.2.8 Service Model... 5 2.3 Service Oriented Architecture... 8 3 Related Standards... 9 3.1 JCR... 9 3.1.1 Issues with JCR... 9 3.2 WebDAV... 9 3.2.1 Issues with WebDAV... 9 4 Related Implementations of CMIS... 11 4.1 Alfresco CMIS AtomPub TCK... 11 4.2 CMIS Spaces... 12 4.3 CMIS Explorer... 13 5 Goal and Objectives... 14 6 Limitations and Constraints... 15 7 Conclusions... 16 7.1 Is there a need for CMIS?... 16 7.2 Is CMIS adaptable to WCM? (Q1)... 17 7.3 Is CMIS implementable into EPiServer CMS? (Q2)... 17 7.4 Are the available CMIS applications compatible? (Q3)... 18 8 Recommendations... 20 8.1 CMIS Version... 20 8.2 Content Targeting... 20

8.3 Use Case Targeting... 20 8.4 Implementation Technique... 20 8.5 Plug-in Point... 21 9 Method... 22 10 Results... 23 10.1 Implementing CMIS within a Microsoft.NET-based Web CM system (Q1)... 23 10.1.1 Single Restful AtomPub Service Class... 23 10.1.2 XML Serialization... 23 10.1.3 REST Starter Kit... 23 10.1.4 Target Use Case... 24 10.2 Implementing CMIS into EPiServer CMS (Q2)... 24 10.2.1 Type Mapping... 24 10.2.2 Checked Out Documents... 24 10.2.3 Virtual Path Provider... 25 10.3 Compatibility with other CMIS implementations (Q3)... 25 10.3.1 Be Forgiving... 25 11 Analysis... 26 11.1.NET Web Services Types... 26 11.2 CMIS Services... 26 11.2.1 XML Serialization... 27 11.3 Use Cases... 28 11.3.1 Repository-to-Repository... 28 11.3.2 Application-to-Repository... 29 11.3.3 Federated Repositories... 29 11.3.4 Repository Migration... 29 11.4.NET Content Management Interoperability Services... 29 11.4.1 Object Model... 31 11.5 Restful AtomPub Binding... 32 11.5.1 Client Interaction... 32 11.5.2 Single Service... 32 11.5.3 XML Serialization... 33 11.5.4 XML Declaration... 33 11.5.5 Optional Query String Parameters... 33 11.5.6 Stream Parameter... 33

11.5.7 Validate Request... 34 11.6 WS Binding... 34 11.7 EPiServer CMIS Producer... 34 11.7.1 Client Interaction... 34 11.7.2 getcheckedoutdocs... 34 11.8 EPiServer CMIS Consumer... 35 12 Bibliography... 36 Appendix A 38 Appendix B 39 Appendix C 41 Appendix D 53

1 Terminology This chapter describes reoccurring terms, used throughout this paper. A Content Management (CM) system is a computer system used to store and handle data such as, electronic documents, images, web content and metadata. The concept of a Content Management includes among others Enterprise Content Management (ECM) and Web Content Management (WCM). ECM refers to the management of content that has a relation to the information process of an organization. Document Management (DM) is a component of ECM, and refers to the management of document content. WCM refers to the management of web content, including creation, review, approval and publishing of web content. (AIIM, 2008) The term Content repository refers to the storage facility of a CM system. It may expose mechanisms such as read, write and delete content, versioning of content, querying content and access control. CMS is an alternative notation for CM System. In this paper both the terms, CMS and CM system, are used. The term resource is used in a general sense for whatever might be identified by a URI. (Jacobs & Walsh, 2004) The terms Uniform Resource Identifier (URI) and Uniform Resource Locator (URL) refer to an address to something on the Web. Further URL is a subset of URI; thereby every URL is also a URI and can be substituted without any loss of meaning. (Richardson & Ruby, 2007) In this paper, the term URI is used consistently. The Atom Publishing Protocol (AtomPub) is an HTTP based protocol for managing resources. It is based on the Atom Syndication Format (Atom), which is an XML dialect used for syndication of web feeds. AtomPub can also be abbreviated as APP. In this paper the term AtomPub is used consistently. The concept Representational State Transfer (REST) is an architectural style for distributed software systems. When an application or system confirms to the constraints set up by REST, the particular software is referred to as being Restful. (Wikipedia, 2009) The concept WS-* (pronounced WS-Star) refers to the collection of web services specifications, which all have the prefix WS-, such as Web Services Interoperability (WS-I) or WS-Security. A standard is an accepted conformance, to which multiple independent organizations have agreed. A standards effort is a standards proposal that is actively being handled by a standards developing organization. (Fielding R. T., 2008) During the time of writing this paper CMIS was still a standards effort, not yet reached the status of standard. CMIS was officially announced as an approved standard by OASIS on May 4, 2010. (Geyer, 2010) 1

2 Background This chapter provides a background to the Content Management Interoperability Services (CMIS), which is the core subject of this paper. It also provides a description of EPiServer AB, the provider organization of my degree project. 2.1 EPiServer EPiServer AB is a privately owned Swedish product company, founded in 1994, active within Content Management and portal solutions through the platform EPiServer. EPiServer AB works primarily with Microsoft technologies and the EPiServer platform requires Microsoft.NET Framework. The EPiServer platform holds a number of products of which the Web Content Management System is EPiServer CMS. 2.2 The CMIS Specification CMIS is a technical standard. Its purpose is to allow the sharing of information among dispersed Content Management repositories. It defines a domain model and a service model based on two service bindings: the Web Services (WS) Binding using SOAP Remote Procedure Call (RPC) as its communication medium and the Restful AtomPub Binding using Representational State Transfer (REST) combined with AtomPub as its communication medium. Each of these two bindings exposes all the services of CMIS. CMIS REST Client CMIS WS Client CMIS Restful AtomPub Binding CMIS WS Binding CMIS Compliant Repository Figure 1 Client s perspective The CMIS proposal was submitted to the Organization for the Advancement of Structured Information Standards (OASIS) in fall 2008 by Microsoft, IBM and EMC. Since then OASIS has assigned it a technical committee (TC) to develop the technical standards specification. 2

CHAPTER 2 BACKGROUND Figure 2 The CMIS Logotype The CMIS proposal has undergone two public review processes, in which the OASIS CMIS TC inquired for public input on the current proposal. The first public review period was between October 23 and December 23, 2009. The second public review period was between January 28 and February 12, 2010. (Cover, 2010) 2.2.1 Scenarios and Restrictions The aim of CMIS version 1.0 is to support the following scenarios: Collaboration systems Portals leveraging Content Management repositories Mashup system, merging information from several different sources Federated search, searching one or several content repository. Each of the above scenarios is contained by a use case, described in 11.2.1. The following scenarios are not a part of CMIS version 1.0: Records Management (RM) and Compliance Digital Asset Management (DAM) Web Content Management (WCM) Subscription and Notification Services. (Cover, 2010) Even though these scenarios are not a part of the OASIS CMIS TCs scope of work for CMIS version 1.0, there are no restrictions as to using CMIS for these scenarios. Some of these are therefore also included in the use cases described in 11.2.1. 2.2.2 Domain Model The domain model defines a number of entities for describing and handling the content: Repository, Document, Folder, Relationship, Property and Access Control List (ACL). CMIS does not allow the creation of new base objects. Any repository specific objects must derive from one of the four base objects: Document, Folder, Relationship or Policy. 3

CHAPTER 2 BACKGROUND Document Content Metadata Version History Folder Container Hierarchy/Filing Metadata Meta Model (Property, ACL) Relationship Source Target Policy Target Figure 3 CMIS Domain Model 2.2.3 Document Object The document object represents a document in the repository. It can hold binary content and metadata. It can be versionable and CMIS supports controlling its version history. (Choy, Gur- Esh, McVeigh, & Müller, 2009) 2.2.4 Folder Object The folder object represents a folder in the repository. A folder holds metadata and is a container for objects, including other folders, defining a hierarchy of folders. Objects can be filed and unfiled into folders. (Choy, Gur-Esh, McVeigh, & Müller, 2009) 2.2.5 Relationship Object The relationship object represents a binary, directional and typed relationship between a source object and a target object. Both the source and target objects must be independent objects, such as a document, a folder or a policy. The relationship object is non-invasive, meaning that deleting the relationship object should not modify source nor target object. (Choy, Gur-Esh, McVeigh, & Müller, 2009) 2.2.6 Policy Object The policy object represents an administrative policy, for instance a retention management policy. A policy objects holds a repository specific text string identifying the policy. The support for policies is optional. A repository that does not support policies should not return the policy type from any service call requesting the available repository types. (Choy, Gur-Esh, McVeigh, & Müller, 2009) 2.2.7 Meta Model The meta model contains metadata for the repository and access control. The metadata for objects is represented by object-type definitions. Each object-type definition contains a set of property definitions, which describe and define each property. 4

CHAPTER 2 BACKGROUND The access control of a repository is represented by Access Control Lists (ACLs). An ACL consist of a list of Access Control Entries (ACEs). Each ACE holds a principal, representing a user management object such as a user or a role one or more strings containing the names of the permissions and a Boolean flag indicating whether the ACE is assigned directly to the object. The permission supported by a repository may be the set of permissions defined by CMIS, a set of repository specific permissions, or a combination of both. The permissions defined by CMIS are: cmis:read indicates permission to read properties and content cmis:write indicates permission to write properties and content cmis:all indicates all the permissions of a repository. (Choy, Gur-Esh, McVeigh, & Müller, 2009) 2.2.8 Service Model The service model defines: The discovery of object type definitions and other repository information Create, Read, Update and Delete (CRUD) operations Filing documents into folders Versioning of documents Querying a repository, including full-text searching 2.2.8.1 Web Services Binding The Web Services binding provides a service based interface. The binding maps many service methods to a single URI. The format for messages is SOAP and the communication protocol can be any protocol allowed for SOAP based services. Endpoints Client Service Class Proxy WCF WCF Host Process Host Process Figure 4 Client Service communication using proxy, service class exposing endpoints When implemented in WCF a Web Services Binding architecture will consist of a service and a client. The client generates a set of proxy classes from the WDSL exposed by the client and the programmer of the client may then use the proxy classes to communicate with the service classes. The communication procedure is encapsulated by the proxy and service classes. The programmer will handle.net native languages and the configuration of the service and client. 5

CHAPTER 2 BACKGROUND 2.2.8.2 Restful AtomPub Binding The Restful AtomPub binding provides a resource based interface. The binding maps each service method to a resource combined with an HTTP method. REST is an architectural style, for distributed web systems, which was first introduced in a dissertation by Dr. Roy Thomas Fielding. (Fielding R. T., 2000) Dr. Fielding has criticized the Restful AtomPub binding specification (of the standards proposal CMIS version 0.5) for not following the REST definition. He argues that the Restful AtomPub binding violates the constraints of REST by translating SOAP into HTTP method calls and calling it REST. (Fielding R. T., 2008) The discussion of whether the Restful AtomPub Binding truly follows the REST definition or not, is out of scope for this essay. I will confine with concluding that there are objections to the binding being referred to as Restful. The architecture of the Restful AtomPub Binding maps the architecture of AtomPub. Figure 5 shows the elements of AtomPub (left tree) and the corresponding elements of the CMIS Restful AtomPub Binding (right tree). Service Repository Server Workspace Repository Collection Root Folder Children Type Definitions Checked Out Entry Media Resource Folder/Document Content Type Working Copy Parents/Associated Version History Allowable Actions Queries Figure 5 The elements of AtomPub and the Restful AtomPub Binding The Restful AtomPub Binding elements Parents/Associated, Version History, Allowable Actions and Queries do not have a corresponding element in AtomPub. 2.2.8.3 CMIS AtomPub AtomPub is an HTTP based technique for managing resources. It is designed fundamentally around the idea of using the basic operations provided by the HTTP protocol (such as GET, 6

CHAPTER 2 BACKGROUND PUT, and DELETE) to pass around instances of Atom 1.0 Feed and Entry documents / / (Snell, 2006) A central concept to AtomPub is the collections of editable resources, represented by Atom Feeds. All interaction is done with the HTTP methods GET, POST, PUT and DELETE, to the URI of a resource. CMIS extends AtomPub with CMIS specific elements. The Restful AtomPub binding exposes three types of resources: AtomPub Service Document Atom Feed Atom Entry 2.2.8.4 Service Document The service document consists of the following entities: Collections o Checked Out Collection o Query Collection o Root children Collection o Type children Collection o Unfiled Collection Links o Type Descendants Feed Link o Folder Tree Feed Link o Root Descendants Feed Link o Changes Feed Link RepositoryInfo Object (Properties and Capabilities) UriTemplates 7

CHAPTER 2 BACKGROUND Repository Info Properties Capabilities Collections Links Checked Out Collection Type Descendants Feed Link Query Collection Folder Tree Feed Link Root children Collection Root Descendants Feed Link Type children Collection Changes Feed Link Unfiled Collection URI Templates Figure 6 CMIS REST/AtomPub Service Document Structure 2.2.8.5 Representation Formats Valid representation formats are Atom and JSON. 2.3 Service Oriented Architecture Service Oriented Architecture (SOA) is a computer system architecture, which consists of a set of services that communicate with each other. The communication can enfold exchange of data or more complex interaction, such as remote method calls. Services may be connected to one another. (Barry, 2009) A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. (Barry, 2009) 8

3 Related Standards This chapter describes a few related standards aiming at the same goal as CMIS. This chapter also addresses issues with each standard, with respect to content interoperability. 3.1 JCR Content Repository API for Java (JCR) is a Java specification for uniform access to content repositories. (Popescu & Ottinger, 2006) The specification uses the Java Community Process (JCP) and is formalized as two instances of the Java Specification Request (JSR); JSR-170 (version 1.0) (Nuescheler, 2006) and JSR-283 (version 2.0) (Neuscheler, 2009). JCR models an abstraction of a content repository, which may be based on a database, a file system or any other storage facility that is appropriate. A JCR repository provides four basic operations: read, write, query and delete. These operations are directly related to the CRUD operations of CMIS. 3.1.1 Issues with JCR The following issues concern JCR. JCR is: Only applicable to Java, making it restricted to a specific programming language and environment. Not backed by the major ECM vendors. To prescriptive, in that it requires changes to core ECM capabilities in order to support specific features. Not service oriented, meaning it requires consistent connections, which makes it inappropriate for mashup applications. (Columbro, 2009) 3.2 WebDAV Web Distributed Authoring and Versioning (WebDAV) is an extension to the Hypertext Transfer Protocol (HTTP). (Dusseault, 2007) WebDAV allows collaborative editing and managing of files on remote web servers, aiming at making the Web a readable and writeable medium. Through WebDAV a user can create, read and change documents on a remote server. The operations of WebDAV are directly related to the CRUD operations of CMIS. WebDAV exposes the features: Properties (the ability to query and manage information on web pages), Collections (the ability to manage resources), Locking (the ability to assign a unique editor of a document at any one time), and Namespace Operations (the ability to map resources to URIs). (Dusseault, 2007) 3.2.1 Issues with WebDAV The following issue concern WebDAV. WebDAV has: No types and properties, making it unfit for handling documents. No support for query, making it unsearchable. 9

CHAPTER 3 RELATED STANDARDS No relationships, making it unable to relate objects to each other. A strong connection to HTTP, which does not allow the use of WS-* techniques. (Columbro, 2009) 10

4 Related Implementations of CMIS This section describes related implementations of the CMIS standards proposal available at the time of writing this paper. Related implementation of CMIS are implementations that implement CMIS in some extent, and which have been used for interoperability testing with the NCMIS prototype. A full list of current implementations is available in Appendix D. 4.1 Alfresco CMIS AtomPub TCK The Alfresco CMI AtomPub Test Compatibility Kit (TCK) is a web-based client for testing the compatibility of Alfresco s implementation of CMIS with any other implementation available as a public Restful AtomPub service. Figure 7 Alfresco CMIS AtomPub TCK 11

CHAPTER 4 RELATED IMPLEMENTATIONS OF CMIS 4.2 CMIS Spaces CMIS Spaces is developed by Steve Reiner, as an open source project available for download from Google Code. It features a desktop application, running in the Adobe Air runtime environment. It supports both the SOAP and Restful Atom bindings of CMIS. Figure 8 CMIS Spaces 12

CHAPTER 4 RELATED IMPLEMENTATIONS OF CMIS 4.3 CMIS Explorer CMIS Explorer is developed by Shane Johnson, as an open source project available for download from Google code. It features a desktop application, running in the Adobe Air runtime environment. It supports the WS binding; there is no support for the Restful AtomPub binding. Figure 9 CMIS Explorer 1 1 Image from http://blogs.alfresco.com/wp/cmis/files/2009/02/cmis_explorer_browser.png 13

5 Goal and Objectives The main objective is to evaluate the draft CMIS specification and formulate a suggestion of how to integrate the CMIS standard with a Web CM system, specifically the EPiServer CMS. A prototype consumer and producer shall be implemented using the CMIS specification (Choy, Gur-Esh, McVeigh, & Müller, 2009), Microsoft.NET Framework and EPiServer CMS. All code shall be written using Microsoft Visual Studio 2008 and C#. Parts of the code/project shall be made available as open-source on the CodePlex.NET Content Management Interoperability Services (NCMIS) library 2. The following questions should be answered: Q1. How can one implement the CMIS standard within a Microsoft.NET-based Web CM system? Which technology is best to use for such an implementation? This includes defining business classes and enumerators for all CMIS entities: Repository, Document, Folder, Policy, Relationship, and Property. Also the implementation of protocol handlers for the Restful AtomPub Binding and the WS Binding as defined in the CMIS specification. Q2. What would be the best method for implementing the CMIS into EPiServer CMS? This includes the implementation of a prototype CMIS producer for EPiServer CMS, and defining which parts of EPiServer CMS could be used in CMIS. Also the implementation of a prototype CMIS consumer using Microsoft.NET Framework Windows Presentation Foundation (WPF). Q3. How well does the suggested CMIS implementation communicate with other available CMIS implementations? This includes the testing of the above implementation with other available implementations of CMIS. 2 The NCMIS-project is a vendor independent open source project initiated by EPiServer in order to produce a general framework for CMIS with.net. http://ncmis.codeplex.com/ 14

6 Limitations and Constraints This paper addresses the CMIS standard version 1.0 Community Draft 4 (CD04). Earlier (or later) versions of the CMIS specification have not been considered in this paper. A majority of the issues addressed in this paper can however also be applied to CMIS version 1.0 Community Draft 7 (CD07), which is the final draft, submitted as a candidate for CMIS version 1.0. Further, this paper focuses on how to apply CMIS to web CM systems (despite that the targeted CMIS specification does not include WCM). I focus on how CMIS can be adapted to web CM systems, using the EPiServer CMS as a platform for proof of concept, and only briefly mention other divisions of CM systems. The concepts of Windows Communication Foundation (WCF) are merely explained in brief, since it would take up too much of this paper to discuss WCF and its techniques more thorough. I assume the technical readers of this paper have basic knowledge of WCF. When referring to the EPiServer CMS this implicitly refers to the EPiServer CMS version 6. Earlier (or later) versions of the EPiServer CMS have not been considered in this paper. Finally, the reader of this paper is assumed to have a basic understanding of programming and software development principles and terminology. 15

7 Conclusions This chapter describes the conclusions drawn from the study. Where possible the conclusions are matched to the questions (Q1, Q2 and Q3) from section 5 Goal and Objectives. 7.1 Is there a need for CMIS? A standard for content management systems data exchange would mean that different content management vendors could more easily exchange data and develop applications allowing the use of dispersed data repositories. Taking in account that there are others standards that attempt to achieve the same goal as CMIS there is clearly and industry need for a standard. Table 1 Comparison of CMIS and JCR Programming Language Restrictions ECM Vendor Involvement Integration Service Oriented Architecture CMIS No restrictions Several of the major vendors, such as Microsoft, IBM and EMC are involved Is implemented as a layer on top of an existing ECM solution Service Oriented JCR Only applicable to Java solutions Only vendors developing for the Java platform will have any interest in the standard Requires changes to core ECM capabilities in order to support specific features Not Service Oriented, requires consistent connections Table 2 Comparison of CMIS and WebDAV Types and properties Queries Relationships Communication Protocol CMIS Exposes and extendable set of types and properties Supports a custom query language Exposes a relationship object for relating CMIS objects to one another Allows the communication through HTTP or any protocol allowed by the WS-* techniques WebDAV No support for types and properties No support for queries No support for relationships Is tightly tied to HTTP The standards JCR and WebDAV partially offer the same features as CMIS. The main difference is that JCR requires Java and WebDAV requires HTTP. These two limitations are the primary advantage of using CMIS over JCR or WebDAV. A JCR compliant repository will not be able to 16

CHAPTER 7 CONCLUSIONS communicate with a repository not implemented in Java. And a WebDAV repository will not be able to communicate with a repository that does not use HTTP as its communication protocol. CMIS can handle both of these cases. CMIS overcomes some of the weaknesses found in JCR and WebDAV, as shown in Table 1 and Table 2. 7.2 Is CMIS adaptable to WCM? (Q1) CMIS features a document model, represented by the base types Document, Folder, Policy and Relationship. While these objects could also be applied to web content, CMIS lacks the modeling architecture of web content. If the Web CMS allows to store and control document or binary content the object types have the same mapping as within a document centered repository. For being able to model web content CMIS would need web content types, such as a Webpage type, with properties characteristic for a web page. In order to implement CMIS within a Microsoft.NET-based Web CM system, the use of WCF speeds up and simplifies the developing process. The REST Starter Kit likewise speeds up and simplifies the developing process of the Restful AtomPub Binding of CMIS. The drawback lies within the data contract and the DataContractSerializer. The DataContractSerializer offers no control over how an object graph is serialized, other than the element names and order. (Rigsby, 2008) The CMIS standard requires the exchanged XML to conform to a specific format. This leads to that you can either chose to use the XmlSerializer which allows more features, such as serialization of XML attributes or manually specify the serialization and deserialization process, for instance using the LINQ classes XElement and XAttribute. 7.3 Is CMIS implementable into EPiServer CMS? (Q2) Since CMIS targets document management, and adding custom web CM features would require a substantial amount of work, the most natural way of using CMIS in EPiServer CMS is within the document features. There are two directions in which CMIS may be implemented into EPiServer CMS; as a content producer and as a content consumer. A producer will produce content, which is exposed as a CMIS service. A consumer will consume content from an existent CMIS service and expose it as content in EPiServer CMS. A content producer will be implemented as a part of the CMS, communicating directly with the service layer, as shown in Figure 10. A producer service requires the development of a set of service classes that translates the internal structures of EPiServer CMS into valid CMIS XML for the WS Binding and the Restful AtomPub Binding. Some of the optional services specified by CMIS have no natural application in EPiServer CMS. E.g. the getcheckedoutdocs service, described in 11.7.2 getcheckedoutdocs, would require the traversing of all the available folders and documents, i.e. files, in order to get a list of all checked out documents. This operation is, although possible, presumably very time consuming and not an effective operation in practice. 17

CHAPTER 7 CONCLUSIONS CMIS Client XML Service CLR Types Producer CMS Figure 10 Content Producer Provider in context of a CMS For a consumer architecture, an EPiServer VPP is a possible plug-in point. The data source for the VPP will be any valid CMIS service, as shown in Figure 11. Arbitrary CMS CMIS Service CMIS VPP EPiServer CMS Figure 11 Content Consumer Provider in context of a CMS Since CMIS focuses on document centric use cases a VPP consuming a CMIS service is a potential use case. 7.4 Are the available CMIS applications compatible? (Q3) The developed prototype applications have been tested for interoperability with Alfresco AtomPub TCK repository and web-based client and CMIS Spaces desktop client. All of the developed applications are, during the time of writing this report, in an early stage of maturity. There is still little error handling implemented, making it hard to pinpoint the exact reason to why to applications are not compatible. The foremost reason is that the output XML of 18

CHAPTER 7 CONCLUSIONS the producing application is not compatible with the expected input XML by the consuming application. The services which were implemented, at the time of writing this report, were in general compatible with the tested applications. These services are however limited to basic operations such as retrieving CMIS objects, retrieving content streams, moving, editing and deleting CMIS objects. When the applications grow more complex and use real data instead of test data new situations will most probably occur, which have not been tested for. The most prominent issue with comparing compatibility within live web applications is that they may change, which is the case with Alfresco AtomPub TCK repository. 19

8 Recommendations This chapter gives recommendations on adopting the CMIS standard to the EPiServer CMS. These recommendations do not take into consideration the issue whether EPiServer CMS should or should not implement CMIS. 8.1 CMIS Version The current version, CMIS 1.0 is the standard most likely to be used by other applications implementing CMIS, at the time of writing this paper. Therefore CMIS version 1.0 should be used. CMIS version 1.0 is also the only version not in draft status. 8.2 Content Targeting Focusing on the document management aspects of EPiServer CMS requires less tweaking of the standard then trying to adapt CMIS 1.0 to WCM. It is also more likely that users of CMIS are more interested in using EPiServer CMS in conjunction with a document repository than another CMS, since the latter would require a considerable amount of work to configure CMIS for web content exchange between two different CM systems. A scenario that will most likely be interesting for users is to use SharePoint as a document repository producer and EPiServer CMS as a consumer of that content. This, assumedly that SharePoint will support CMIS. During the time of writing this report it is not clear when SharePoint will support the CMIS standard. Targeting web content at this point will require a substantial amount of work in order to translate web content, i.e. web pages into CMIS objects. And even if that work would to be done, other vendors would have to translate their content to CMIS as well for this application scenario to be of any practical use. 8.3 Use Case Targeting The strength of EPiServer CMS is its ease of use and presentation capabilities. The strongest use cases for including CMIS functionality is the Repository-to-Repository and Application-to- Repository use cases, described in 11.3 Use Cases. These two use cases allow scenarios where EPiServer functions as presentation and control layer for a document centric repository. For instance a user could use SharePoint as a document repository and EPiServer CMS as a presentation and control tier that allows showing and editing the documents inside the SharePoint repository. There is no restriction to only use.net-based backend repositories. The repository can be on any platform as long as it supports CMIS. The drawbacks may be lack of speed, due to information having to be sent over a network, or slow serialization and deserialization process. The discussion of these issues is beyond the scope of this report. 8.4 Implementation Technique The preferred way to implement the CMIS standard is as a consumer of CMIS services, described in 11.8 EPiServer CMIS Consumer. For ease of development and speed the NCMIS library should be used, along with the WCF service templates for the producer services. 20

CHAPTER 8 RECOMMENDATIONS 8.5 Plug-in Point The producer can use the suggested architecture of NCMIS, using the CMIS Provider to expose EPiServer document content as a CMIS service. The consumer can be implemented as an EPiServer VPP, which may consume a specified CMIS service either through the WS Binding or the Restful AtomPub Binding. 21

9 Method The results have been derived from studies of the CMIS Specification and from implementing a service library, a prototype service for EPiServer CMS and a client prototype for CMIS services. All implementation is in Microsoft.NET Framework, C#, to match the programming framework of the EPiServer CMS. The CMIS specification itself is programming language agnostic, and all the above implementations are agnostic to the platform and internal implementations of their communication counterparts. The service bindings are developed with Windows Communication Foundation (WCF), which is a Microsoft technology unifying service oriented development. 22

10 Results This chapter addresses the results of the study, and offers answers to question one (Q1) through three (Q3) from section 5. 10.1 Implementing CMIS within a Microsoft.NET-based Web CM system (Q1) It is more efficient to use WCF Services, over the ASP.NET Web Services. WCF handles much of the code which needs to be written for services, and also offers a way of exposing a service through various bindings without having to change the code. In the case of CMIS, there still exists a need to create a set of WS services and a separate set of Restful AtomPub services, due to that each binding has its specific communication interface. 10.1.1 Single Restful AtomPub Service Class The Restful AtomPub service implementation should be implemented as a single service class. Separating the service into its logical components, such as a Repository service class, a Navigation service class, an Object Service class, etc, results in that methods addressing the same resource will have different URIs. For instance, the GET method of the Checked Out Collection resource is in the Navigation service, while the POST method is in the Versioning service. In order for these two methods to share URI in WCF, without using URL rewriting or routing, both of the service methods need to be in the same service class. 10.1.2 XML Serialization Some of the CMIS specified constructs cannot be serialized using data contracts, since the data contracts cannot define all types of XML. For instance data contracts do not allow for properties to be serialized as XML attributes. Also a construct where a parent collection holds child objects of different types (of a common base type), the data contract serialization does not allow for each child element to have its unique name. For instance, if the properties object is a collection of property type descendants, such as property id and property string, a data contract cannot serialize the properties object into the following XML construct: <object> <properties> <propertyid name= cmis:objecttypeid > <propertystring name= cmis:name > </properties> </object>. The DataContractSerializer is preferred for use with WCF services, for speed and ease of development. The XmlSerializer may be used when the output XML needs to adapt to a specific format. The NetDataContract serializer may be used when the services involved in the messaging uses the same CLR types. 10.1.3 REST Starter Kit Microsoft has released a set of classes for development of REST services, called the REST Starter Kit. These classes should be used in order to speed up development and also since they feature already tested code. However, they should be modified and extended to match the CMIS XML 23

CHAPTER 10 RESULTS format. CMIS specifies a few required namespaces and prefixes for the serialized XML. These should be included explicitly to the output types. 10.1.4 Target Use Case The most probable use scenarios for a web CMS implementing CMIS is the Repository-to- Repository use case and the Application-to-Repository use case, described in 11.3.1 Repositoryto-Repository. This can be exemplified by using a document centric repository as a backend repository and a web CMS as a frontend application. The strength of a web CMS is its presentational features and its use of the web media. 10.2 Implementing CMIS into EPiServer CMS (Q2) Implementing CMIS into EPiServer CMS requires the translation of CMIS object types into EPiServer object types and vice versa. One issue that needs to be solved is where to plug CMIS into EPiServer CMS. Should an EPiServer CMS provider expose only documents or also web content? Since the CMIS targets Document Management, but not Web Content Management, there is no natural translation of web content into CMIS objects or vice versa. The most natural connecting point would therefore be the EPiServer CMS Global files directory, which corresponds to the CMIS root folder. 10.2.1 Type Mapping The CMIS base types Folder and Document can be used in the EPiServer provider. There are no appropriate mappings for the base types policy or relationship. Each of the two base types has two EPiServer specific child types. The Folder descendants are UnifiedDirectory and VersioningDirectory. The Document descendants are UnifiedFile and VersioningFile. Folder Document UnifiedDirectory VersioningDirectory UnifiedFile VersioningFile Figure 12 CMIS type mapping to EPiServer types The Folder and Document types are abstract types, which do not exists as types in EPiServer CMS. The descendants of Folder and Document map concrete types in the EPiServer CMS. 10.2.2 Checked Out Documents The get service for checked out documents requires getting a list of all checked out documents that the current user has access to. In EPiServer CMS this requires the get method to loop through every available folder and check each document whether it is checked out. In a scenario 24

CHAPTER 10 RESULTS where there are many files and folders in the repository this operation may be notably time consuming for the user. 10.2.3 Virtual Path Provider A Virtual Path Provider (VPP) is an ASP.NET construct that allows the extension of ASP.NET to serve virtual content. This content may be stored in a file system, but may also have a different source, e.g. a database or a content repository. (Agarwal, 2007) EPiServer allows the use of VPPs to serve static files, which matches the use of CMIS. 10.3 Compatibility with other CMIS implementations (Q3) CMIS Spaces can browse an NCMIS service. Alfresco AtomPub TCK can browse an NCMIS service, and also make POST requests. Some POST request fail due to that the TCK specifies text inside the Atom XML element Author. This is not allowed and triggers an exception in the serializing WCF classes used by NCMIS. The correct format requires the Author element to contain only other XML elements, such as Name or Email. CMIS Explorer cannot connect to a NCMIS service, due to that the prototype does not define a WS binding. The NCMIS client can browse an Alfresco repository. 10.3.1 Be Forgiving When parsing the XML from other CMIS implementations situations might occur when you receive XML that differs from the XML expected. This might be because the implementation breaks the standard, the standard is not clear about a specific implementation issue, there is a bug in your own code, you have implemented different versions of the standard, or any other reason. For your implementation to be compatible with as many other implementations as possible you need to be forgiving when parsing the XML, and not require that the input XML strictly matches your expectation. Some expectations must be uphold, those explicitly stated in the CMIS specification. 25

11 Analysis This chapter provides an analysis of the results and explains how they were achieved. The analysis is expressed in a binding agnostic fashion. Exceptions, where the analysis is derived with respect to a specific binding are explicitly stated. 11.1.NET Web Services Types There are two types of services available in.net, the ASP.NET services and the WCF services. The WCF services is a newer technique and has more features as how to communicate. WCF services can mimic the behavior of ASP.NET services, by using the ASP.NET compatibility mode. WCF services may also use the ASP.NET services file extension,.asmx, rather than the default,.svc. A WCF service is provided through an endpoint, which specifies the address of the service, how to communicate with it (binding) and its available operations (service contract). A service contract may be exposed though multiple endpoints, meaning it can reside on multiple addresses and allow access through a multiple amount of protocols. This feature does not exist for the ASP.NET services. (Microsoft, 2008) ASP.NET services return unhandled exceptions as SOAP faults to the client. WCF services hide the unhandled exceptions, in order to prevent sensitive information to be exposed in the error message. There is a configuration setting for allowing unhandled exceptions to be returned to the client for the purpose of debugging. Table 3 shows a comparison of the features in the two techniques. Table 3 Comparison of ASP.NET Services to WCF Services ASP.NET Services WCF Services File Extension.asmx.wcf Serializer XmlSerializer XmlSerializer, DataContractSerializer Unhandled Exceptions SOAP faults Hidden for security The WCF services are thereby preferred to ASP.NET services as in the result in 10.1 Implementing CMIS within a Microsoft.NET-based Web CM system (Q1). 11.2 CMIS Services CMIS defines nine distinct groupings of services. (For a complete list of services see Appendix B.) When implemented in WCF each service set corresponds to a WCF service class and each service corresponds to a WCF service method. 26

CHAPTER 11 ANALYSIS Table 4 CMIS Services Service Group Repository Services Navigation Services Object Services Multi-Filing Services Discovery Services Versioning Services Relationship Services Policy Services ACL Services Description Allows the discovery of information about the repository and its object types. Allows the navigation of the folder hierarchy of a repository and the localization of checked out documents. Allows ID-based CRUD operations on objects in a repository. Allows the filing and unfiling of objects into and from folders. These services are supported only if the repository supports the multifiling or unfiling optional capabilities. Allows a repository to be searched for queryable objects. Allows the navigation and updatability of document version series. Allows the retrieval of the dependant relationships objects associated with an independent object. Allows the application and removal of policies to an object. Allows the application and removal of ACLs to an object. The entry point for the Restful AtomPub binding is the GetServiceDocument method which encloses the getrepositories and getrepositoryinfo services of Repository Services. The Restful AtomPub binding requires some of the services located in dispersed service groups to use the same URI template. Since WCF always includes the service class name in the service URI all the services must be located in a single service class. In NCMIS I solved this by implementing partial service classes into a single service class. This solution allows for the service classes to have a logical structure of being dispersed classes, for the developer, but will be compiled into a single class. Another solution would be to use routing or URL rewriting or reroute the client request to the appropriate service. This leads to the result in 10.1.1 Single Restful AtomPub Service Class. 11.2.1 XML Serialization There are three XML serializers available in WCF, the XmlSerializer, the DataContractSerializer and the NetDataContractSerializer. The key difference between the DataContractSerializer and the NetDataContractSerializer is that the NetDataContractSerializer includes CLR type information in the serialized XML. (Rigsby, 2008) This means it is only useful if the communicating services share the same set of CLR types. Since the particular feature is not interesting from the point of this discussion, it will from here on be treated as subset of the DataContractSerializer. 27

CHAPTER 11 ANALYSIS The XmlSerializer was introduced with.net 1.0 and can be used to serialize any object graph to XML. The DataContractSerializer was introduced in.net 3.0 and is the default serializer for WCF. It was designed for contract first development. (Rigsby, 2008) The DataContractSerializer uses an opt-in approach. This means that the developer must specify explicitly which properties and fields are to be serialized by marking them with a DataMember attribute. The XmlSerializer uses an opt-out approach, meaning it will serialize everything not marked as to being left out. The DataContractSerializer serializes data about ten percent faster than the XmlSerializer. (Rigsby, 2008) Table 5 XmlSerializer and DataContractSerializer comparison XmlSerializer Features Opt-out Can serialize properties, but not fields Slower than DataContractSerializer Allows much control over how the XML looks Cannot understand the DataContract attribute DataContractSerializer Features Opt-in Can serialize properties and fields Faster than XmlSerializer Allows little control over how the XML looks Understands the Serializable attribute This leads to the result in 10.1.2 XML Serialization. 11.3 Use Cases There are a number of use cases for the application of CMIS. These are Repository-to-Repository (R2R), Application-to-Repository (A2R), Federated Repositories and Repository Migration. They explain and exemplify how CMIS can be used in business situation. The two most usable use cases, for a web CMS, are the Repository-to-Repository and the Application-to-Repository use cases. These two allow the web CMS to function as a user interface using a document repository as a backend source. The federate repositories use case will most probably mostly feature mashup systems. The repository migration use case requires the full content of the source repository to match the content model of the target repository. In the case that the repositories are of different types this will most probably require a substantial amount of work. If the repositories are of the same type content migration through CMIS is most probably not necessary. These issues lead to the result in 10.1.4 Target Use Case. 11.3.1 Repository-to-Repository The R2R use case is the situation where repositories communicate directly to each other. This use case includes: Federated Records Management, i.e. a central managing of records that are stored in other repositories. 28

CHAPTER 11 ANALYSIS The publishing of content from one repository to another, e.g. publishing content from an ECM system directly into a WCM system for publication to the Internet. (Hart, 2009) 11.3.2 Application-to-Repository The A2R use case is the situation where an application that uses content is connected to a repository that handles the content services. This use case includes: Collaboration systems. Use a repository as backend for collaboration applications, e.g. use EPiServer CMS as frontend for a repository Enterprise Software Applications Content Enabled Vertical Applications (CEVAs) Productivity Applications, link a desktop application, such as e.g. Word or Excel, to a CMIS repository. 11.3.3 Federated Repositories Federated Repositories use case illustrates where an application communicates with many different repositories providing a single user interface. This use case includes: Mashup systems, merging information from several different sources Federated search, i.e. a single interface for a search in many repositories Federation instead of migration. 11.3.4 Repository Migration The Repository Migration use case illustrates the situation of migrating content from one repository to another. This use case includes: Repository migration tools and applications. Migration instead of federation. 11.4.NET Content Management Interoperability Services I have implemented a prototype CMIS library for the.net Framework,.NET Content Management Interoperability Services (NCMIS). NCMIS defines the middle layer between a CMIS client and a CMIS service, allowing any CMIS capable client to communicate with any.net capable repository. Figure 13 NCMIS logotype 29

CHAPTER 11 ANALYSIS CMIS REST Client CMIS WS Client CMIS REST API CMIS Web Services NCMIS Repository Figure 14 NCMIS Overview The namespaces of NCMIS are illustrated in Table 6. Table 6 Namespaces of NCMIS Namespace Ncmis.AccessControl Ncmis.ObjectModel Ncmis.ObjectModel.MetaData Ncmis.ObjectModel.Rest Ncmis.Produce Ncmis.Provider Ncmis.Provider.SampleProvider Ncmis.ServiceModel Ncmis.ServiceModel.Ra Ncmis.ServiceModel.Syndication Description Exposes the ACL and ACE classes. Exposes the core object classes that carry the data, such as the document and folder object. Exposes the core object meta-data. Exposes classes that are specific to the Restful AtomPub Binding. Exposes classes that are used specifically to produce content. Exposes extendable classes for creating a CMIS provider according to the.net provider model. Exposes a sample provider that implements the extendable classes of the CMIS provider. Exposes the service layer architecture. Exposes classes of the service layer architecture that are specific to the Restful AtomPub Binding. Exposes classes for syndication of the data, i.e. serializing and de-serializing of the XML according to the CMIS Atom format. NCMIS uses WCF for communicating through services both for the Restful AtomPub binding and the WS binding. The NCMIS business objects define the object types, as.net CL types, defined in the CMIS specification. Each of the service interfaces for REST and Web Services are 30

CHAPTER 11 ANALYSIS responsible to serialize NCMIS objects to valid CMIS XML as well as deserialize incoming CMIS XML into NCMIS business objects. The NCMIS Repository provider is an interface, following the.net provider model, which is implemented for a specific repository, e.g. an EPiServer CMS repository provider or a SharePoint Repository provider. It is up to the provider to communicate with the repository and covert the NCMIS business objects to and from repository specific CL types. The underlying repository must be.net compliant. CMIS REST API CMIS Web Services WCF REST Service Interface WCF Web Services Interface NCMIS Business Objects NCMIS Repository Provider.NET Compliant Repository Figure 15 NCMIS Structure The ideal structure would be to have a single WCF service interface, which communicates with REST as well as Web Service clients. In this scenario the endpoints would be configured to communicate either with a REST client or a Web Service client. Due to the specific XML format, and that the Restful AtomPub binding exposes its XML as Atom, which is not valid in the WS binding, the single service interface is not possible. A.NET implementation of CMIS requires two separate interfaces. 11.4.1 Object Model The object model defines the business classes for CMIS. The object type is the parent type for the four base object types: document, folder, relationship and policy. NCMIS simply implements a CmisObject class, which can hold instances of any of the four types. Some CMIS services returns more than a list of objects, why NCMIS defines a set of object container classes. The container classes are: CmisObjectList, PathedCmisObject, PathedCmisObjectContainer, PathedCmisObjectList, CmisObjectParents and TokenedCmisObjectList. There are a few types that are closely associated with the CMIS object type. These are: CmisProperties, ContentStream and Rendition. 31

CHAPTER 11 ANALYSIS Figure 16 CmisObject and its containers. 11.5 Restful AtomPub Binding The Restful AtomPub binding communicates using REST principles. 11.5.1 Client Interaction 1) The client requests the service document (by the URI provided by the vendor) 2) The client chooses a CMIS repository to interact with from the initial service document (each repository is mapped to a single app:workspace element) 3) The client follows the link references in the initial service document to access a specific repository 11.5.2 Single Service The service contains a single service interface IService, and single service class Service. The reason of having a single class is that the different collections and feeds require the same URI template for methods to use web methods upon, e.g. if one access a specific feed with GET and another method access the same feed with POST, both methods must be able to access an identical URI. In WCF the name of the service class will be a part of the URI, e.g. Service.svc will be included in path portion of the query string, meaning that if the services would have been distributed among several service classes they would not have the same URI. In order to logically group the service methods, I chose to implement partial interfaces and classes, which is a.net technique allowing the developer to declare a class among dispersed files, which are assembled into a single class file during compilation. Each service method defines one of the HTTP methods: GET, POST, PUT or DELETE. 32

CHAPTER 11 ANALYSIS 11.5.3 XML Serialization For XML serialization and deserialization I have chosen to use the WCF REST Starter Kit, which provides classes for serialization to and from Atom format. The formatting of the XML is handled by one of the three formatting classes: Atom10FeedFormatter, Atom10Itemformatter and AtomPub1010ServiceDocumentFormatter. 11.5.4 XML Declaration WCF REST services do not by default include an XML declaration. CMIS 1.0 specifies the declaration: <?xml version="1.0" encoding="utf-8"?>. The declaration tells the client that XML version 1.0 and the 8-bit Unicode Transformation Format (UTF-8) is used. This needs to be included manually for each service method that returns a value. I have chosen to implement an operation behavior as a.net attribute, IncludeXmlDeclarationAttribute, which hooks into the serialization process and adds an XML declaration at the beginning of the XML output. An alternative would be to implement a service behavior that performs the same result on service level. The advantage of this alternative is that removed the need to specify an attribute for every method of a service, presumed all methods needs the attribute, and the disadvantage is that you cannot control the serialization of individual service methods with a service behavior. 11.5.5 Optional Query String Parameters The URI templates of NCMIS do not define any optional query string parameters. E.g. the URI template for method getchildren, using optional query string parameters would be defined as following. /{repositoryid}/children/{folderid}?maxitems={maxitems}&skipcount= {skipcount}&orderby={orderby}&filter={filter}&includerelationships= {includerelationships}&renditionfilter={renditionfilter}& includeallowableactions={includeallowableactions}&includepathsegment= {includepathsegment} Without any optional query string parameters the same URI template is defined as following. /{repositoryid}/children/{folderid} Here only the parameters that are a part of the path, and that are mandatory, are defined. All optional parameters are requested using the collection WebOperartionContext.Current.IncommingRequest.UriTemplateMatch.QueryParameters. The reason for choosing this solution is that WCF has a bug where the optional query string parameters will cease being optional when both methods of the same service class implement the same URI template both for the WebGetAttribute and the WebInvokeAttribute. (O'Brien, 2009) 11.5.6 Stream Parameter When receiving an atom entry as a post, the receiving service method must be able to receive the whole entry as a single entity. An alternative to accepting a System.Stream parameter is to accept a System.Xml.Linq.XElement parameter. 33

CHAPTER 11 ANALYSIS 11.5.7 Validate Request When hosting the WCF Service in IIS, the problem occurs of passing illegal characters in the query string. The base object types in CMIS have specific names, such as cmis:folder, and this value must at some time be passed through the query string as an mandatory input parameter to a service method. The colon character (:) is however not allowed in the query string as it is counted as a potentially dangerous character. The solution I have chosen in NCMIS is to use the allowed underscore character (_) in the query string and then translating it to a colon once received by the service method. Another solution would be to turn off the request validation. This solution however opens the application for potential hijacks or other dangerous requests. 11.6 WS Binding The WS binding communicates using SOAP messages. No implementation was done using the WS binding. The binding structure is identical to the Restful AtomPub binding and is expected to generate the same issues as the former binding, with exception of any SOAP specific issues. 11.7 EPiServer CMIS Producer This section describes the results from the EPiServer CMIS Producer. 11.7.1 Client Interaction 1) The client uses the CMIS Get Repositories service (getrepositories) to obtain a list of available repositories at this endpoint. 2) The client chooses a repository to interact with, using the Repository ID. 11.7.2 getcheckedoutdocs There is no appropriate way of implementing getcheckedoutdocs service into EPiServer CMS. The service requires to get all checked out documents available for the current user. This, in turn, requires the CMS to be able to return a list of all checked out documents. EPiServer CMS does not have any such method, requiring the CMIS provider to loop through all documents, checking if that particular document is checked out or not. This can be done either through an exhaustive search, for instance Breadth-First Search (BFS) or Depth-First Search (DFS). If is the total number of edges and total number of nodes in the tree, the time for running these algorithms is. (Kleinberg & Tardos, 2006) Since the running time is polynomial it is efficient. An hypothetic case with a three of 1000 nodes and 2000 has a running time of. If inspecting one node or edge takes 1 ms, inspecting all 3000 nodes and edges takes 3 seconds. 34

CHAPTER 11 ANALYSIS 11.8 EPiServer CMIS Consumer The prototype CMIS consumer is developed as a VPP, using the Restful AtomPub binding. Arbitrary CMS CMIS Service CMIS VPP EPiServer CMS Figure 17 EPiServer CMIS Consumer as a Virtual Path Provider A consumer using the WS Binding would function in the same way, with the difference of communication binding. 35

12 Bibliography Agarwal, P. (2007). How to use virtual path providers to dynamically load and compile content from virtual paths in ASP.NET 2.0. Retrieved February 22, 2010, from http://support.microsoft.com/kb/910441 AIIM. (2008). What is ECM? Retrieved November 2, 2009, from http://www.aiim.org/what-is- ECM-Enterprise-Content-Management.aspx Barry, D. K. (2009). Service-oriented architecture (SOA) definition. Retrieved April 23, 2009, from http://www.service-architecture.com/web-services/articles/serviceoriented_architecture_soa_definition.html Choy, D., Gur-Esh, E., McVeigh, R., & Müller, F. (2009). Content Management Interoperability Services (CMIS) Version 1.0. Retrieved November 9, 2009, from http://docs.oasisopen.org/cmis/cmis/v1.0/cd04/cmis-spec-v1.0.pdf Columbro, G. (2009). Cmis Virtual Training Webinar 24 Nov09. Retrieved January 31, 2010, from http://www.slideshare.net/alfresco/cmis-virtual-training-webinar-24-nov09 Cover, R. (2010). Cover Pages: Content Management Interoperability Services (CMIS). Retrieved February 7, 2010, from http://xml.coverpages.org/cmis.html Dusseault, L. (2007). HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). Retrieved November 2, 2009, from http://tools.ietf.org/html/rfc4918 Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures. Retrieved September 24, 2009, from http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm Fielding, R. T. (2008). No REST in CMIS. Retrieved November 9, 2009, from http://roy.gbiv.com/untangled/2008/no-rest-in-cmis Geyer, C. (2010). OASIS Members Approve CMIS Standard. Retrieved May 5, 2010, from http://www.oasis-open.org/apps/group_public/email/cmis//201005/msg00008.html Hart, L. (den 17 August 2009). Three Fundamental CMIS Use Cases. Hämtat från http://wordofpie.com/2009/08/17/three-fundamental-cmis-use-cases/ den 31 January 2010 Jacobs, I., & Walsh, N. (2004). Architecture of the World Wide Web, Volume One. Retrieved November 9, 2009, from http://www.w3.org/tr/2004/rec-webarch-20041215 Kleinberg, J., & Tardos, É. (2006). Algorithm Design. Addison Wesley. Microsoft. (2008). Comparing ASP.NET Web Services to WCF Based on Development. Retrieved February 23, 2010, from http://msdn.microsoft.com/en-us/library/aa738737.aspx Neuscheler, D. (2009). JSR 170: Content Repository for JavaTM technology API Version 2.0. Retrieved November 2, 2009, from http://www.jcp.org/en/jsr/detail?id=283 36

CHAPTER 12 BIBLIOGRAPHY Nuescheler, D. (2006). JSR 170: Content Repository for JavaTM technology API. Retrieved November 2, 2009, from http://www.jcp.org/en/jsr/detail?id=170 O'Brien, M. (2009). REST/WCF UriTemplate Optional Querystring Parameters. Retrieved January 19, 2010, from https://connect.microsoft.com/visualstudio/feedback/viewfeedback.aspx?feedbackid=4512 96&wa=wsignin1.0 Popescu, A., & Ottinger, J. (2006). JCR: A Practitioners Perspective. Retrieved November 2, 2009, from http://www.theserverside.com/tt/articles/article.tss?l=jcrpract Reiner, S. (2009). Cmisspaces. Retrieved November 9, 2009, from http://code.google.com/p/cmisspaces/ Richardson, L., & Ruby, S. (2007). RESTful Web Services. O'Reilly Media. Rigsby, D. (2008). XmlSerializer vs DataContractSerializer: Serialization in Wcf. Retrieved February 2, 2010, from http://www.danrigsby.com/blog/index.php/2008/03/07/xmlserializer-vsdatacontractserializer-serialization-in-wcf/ Snell, J. (2006). Getting to know the Atom Publishing Protocol. Retrieved November 16, 2009, from http://www.ibm.com/developerworks/library/x-atompp1/ Wikipedia. (2009). Representational State Transfer. Retrieved February 1, 2010, from http://en.wikipedia.org/wiki/representational_state_transfer 37

Appendix A Abbreviation ACL API AtomPub CMIS CRUD DAM ECM HTTP JCP JCR JSON JSR REST RM RPC TC URI URL VPP WCF WCM WebDAV WPF Abbreviations Concept Access Control List Application Programming Interface Atom Publishing Protocol Content Management Interoperability Services Create, Read, Update, Delete Digital Asset Management Enterprise Content Management Hypertext Transport Protocol Java Community Process Content Repository for Java JavaScript Object Notation Java Specification Request Representational State Transfer Records Management Remote Procedure Call Technical Committee Uniform Resource Identifier Uniform Resource Locator Virtual Path Provider Windows Communication Foundation Web Content Management Web Distributed Authoring and Versioning Windows Presentation Foundation 38

39 Appendix B CMIS Services Repository Services getrepositories getrepositoryinfo gettypechildren gettypedescendants gettypedefinition Navigation Services getchildren getdescendants getfoldertree getfolderparent getobjectparents getcheckedoutdocs Object Services createdocument createdocumentfromsource createfolder createrelationship createpolicy getallowableactions getobject getproperties getobjectbypath getcontentstream getrenditions updateproperties moveobject deleteobject deletetree setcontentstream deletecontentstream Multi-filing Services addobjecttofolder removeobjectfromfolder

APPENDIX B CMIS SERVICES Discovery Services query getcontentchanges Versioning Services checkout cancelcheckout checkin getobjectoflatestversion getpropertiesoflatestversion getallversions Relationship Services getobjectrelationships Policy Services applypolicy removepolicy getappliedpolicies ACL Services getacl applyacl 40

Appendix C NCMIS Classes Namespace Ncmis.AccessControl Name AccessControlEntry AccessControlList AccessControlPrincipal Ace Principal Description Represents an Access Control Entry (ACE). Represents and Access Control List (ACL), which is a list of Acess Control Entries (ACEs). May hold zero or more ACEs. Represents an Access Control Principal, representing a user management object, e.g. a user, group, or role. Represents a collection of Access Control Entries (ACEs). Represents a principal in the CMS. Namespace Ncmis.Client Name CmisDocument CmisFolder CmisWebRequest PropertyFactory Description Handles CMIS document objects in client application. Handles CMIS folder objects in client applications. Handles the HTTP requests in client applications. Utility class for creating CMIS property objects. Namespace Ncmis.ObjectModel Name ChangeEvent CmisObject CmisObjectList CmisObjects CmisProperties Description Represents a CMIS change event. Represents the CMIS Object type. Represents a list of CMIS objects. Rendition collection wrapper, for XML serialization of a CMIS object array. Represents a collection of CMIS properties. 41

APPENDIX C NCMIS CLASSES Namespace Ncmis.ObjectModel Name CmisProperty CmisPropertyBoolean CmisPropertyDateTime CmisPropertyDecimal CmisPropertyHtml CmisPropertyId CmisPropertyInteger CmisPropertyString CmisPropertyUri ContentStream CopyFlaggedDocumentId Document Folder ListOfIds PathedCmisObject Description Represents a property of a CMIS object. A property holds zero or more typed data values. A property may be single-valued or multi-valued. A single-valued property contains a single data value, whereas a multi-valued property contains an ordered list of data values of the same type. Represents a CMIS object property of type System.Boolean. Represents a CMIS object property of type System.DateTime. Represents a CMIS object property of type System.Decimal. Represents a CMIS object property of type System.String. Represents a CMIS object property of type System.String. Represents a CMIS object property of type System.Integer. Represents a CMIS object property of type System.String. Represents a CMIS object property of type System.String. Represents the content stream for a document (cmiscontentstreamtype). Represents a document id with the Content Copied flag. Represents a CMIS document object. Represents a CMIS folder object. Represents a list of object identifiers. Represents a CMIS object with a relative path segment. 42

APPENDIX C NCMIS CLASSES Namespace Ncmis.ObjectModel Name PathedCmisObjectContainer PathedCmisObjectList Policy Relationship Rendition Renditions TokenedCmisObjectId TokenedCmisObjectList TokenedDocumentId Description Represents a CMIS object with the relative path segment and an array of children objects. Represents an array of Ncmis.ObjectModel.PathedCmisObject objects. Represents a CMIS policy object. Represents a CMIS relationship object. Provides an alternative representation of a document. Alternative representations could be a preview of a document, enabling clients to preview a document without downloading the full content. Rendition collection wrapper, for XML serialization of a Ncmis.ObjectModel.Rendition array. Represents a CMIS object identifier with the changelog token property. Represents a Ncmis.Objectmodel.CmisObjectList with Changelog token property. Represents a CMIS document object identifier with the changelog token property. Namespace Ncmis.ObjectModel.MetaData Name AllowableActions AllowableActionsKey Cardinality Description Models the CMIS AllowableActions mechanism, which allows an application to discover the set of service operations that can currently be performed on a particular object, without having to actually invoke the service. Identifies a specific allowable action, used to map a permission. Represents a property s cardinality, indicating whether the property can have "zero or one" or zero or more values. 43

APPENDIX C NCMIS CLASSES Namespace Ncmis.ObjectModel.MetaData Name CmisChangeEvent CmisChoice CmisChoiceBoolean CmisChoiceDateTime CmisChoiceDecimal CmisChoiceHtml CmisChoiceId CmicChoiceInteger CmisChoiceString CmisChoiceUri CmisNs CmisPropertyDefinitionId CmisPropertyType ContentStreamAllowed DecimalPrecision PermissionDefinition Description Represents a single action that occured to an object in the repository that affected the persisted state of the object. Base class for CMIS choice types. Represents a CMIS choice of type System.Boolean. Represents a CMIS choice of type System.DateTime. Represents a CMIS choice of type System.Decimal. Represents a CMIS choice of type System.String. Represents a CMIS choice of type System.String. Represents a CMIS choice of type System.Integer. Represents a CMIS choice of type System.String. Represents a CMIS choice of type System.String. Defines CMIS namespace references. Holds object-type Property Definition ID references. Defines the type of a CMIS property, as specified by the W3C Recommendation 28 October 2004, http://www.w3.org/tr/xmlschema-2/, along with CMIS-specific extensions. Specifies if a content stream is allowed. Defines the precision, in bits, supported by the decimal object-type property. Represents a permission name and description. 44

APPENDIX C NCMIS CLASSES Namespace Ncmis.ObjectModel.MetaData Name PermissionMapping PropertyBooleanDefinition PropertyDateTimeDefinition PropertyDecimalDefinition PropertyDefinition PropertyHtmlDefinition PropertyIdDefinition PropertyIntegerDefinition PropertyStringDefinition PropertyUriDefinition RelationshipDirection TypeContainer TypeDefinition TypeDefinitionList Description Represents the permission mappings to allowable actions, mapping one allowable action to many permissions. Since an allowable action may require permissions on more than one object for example, moving a document from one folder to another may require permissions on the document and each of the folders the mapping table is defined in terms of permission "keys", where each key combines the name of the allowable action as the object for which the principal needs the required permission. Represents a boolean object-type property definition. Represents a datetime object-type property definition. Represents a decimal object-type property definition. Represents property definitions for an object-type. Represents a HTML object-type property definition. Represents a ID object-type property definition. Represents an integer object-type property definition. Represents a string object-type property definition. Represents a URI object-type property definition. Specifies whether the Repository MUST return relationships where the specified Object is the source of the relationship, the target of the relationship, or both. Represents a hierarchy of object-types, with a base type and its children types. Represents the type definition base type, that describes an object types attribute values and property definitions. Represents a list of instances of Ncmis.ObjectModel.MetaData.TypeDefinition. Namespace Ncmis.ObjectModel.MetaData 45

APPENDIX C NCMIS CLASSES Name TypeDocumentDefinition TypeFolderDefinition TypeOfChanges TypePolicyDefinition TypeRelationshipDefinition UnfileObjects Updatability VersioningState Description Represents the document object-type definition, which describes a folder object s types attribute values and property definitions. Represents the folder object-type definition, which describes a folder object s types attribute values and property definitions. Defines the changes made to a CMIS object. Represents the policy object-type definition, which describes a folder object s types attribute values and property definitions. Represents the relationship object-type definition, which describes a folder object s types attribute values and property definitions. Specifies how the repository must process file-able child- or descendant-objects. Represents a property's allowed updatability, i.e. indicates under what circumstances the value of a property may be updated. Specifies what the versioning state of the newlycreated object must be. Namespace Ncmis.Produce Name AclCapability AclPropagation BaseObjectTypeId CapabilityAcl Description Represents the ACL capabilities of a repository. Use combined with the RepositoryCapabilities class If the RepositoryCapabilities.Propagation property is none, ACLs are not supported by the repository. If capabilityacl is discover or manage, additional information about the repositories permission model and how changes to ACL are specified by instances of this class. Specifies how non-direct ACEs can be handled by the repository. Represents the ids of the base object types. Specifies the repositories level of support for ACLs. 46

APPENDIX C NCMIS CLASSES Namespace Ncmis.Produce Name CapabilityChanges CapabilityContentStreamUpdates CapabilityJoin CapabilityQuery CapabilityRendition Fault Query Rendition RepositoryCapabilities RepositoryEntry RepositoryInfo ServiceExceptionType Description Indicates what level of changes (if any) the repository exposes via the change log service. Indicates the support a repository has for updating a document s content stream. Indicates the types of JOIN keywords that the Repository can fulfill in queries. Indicates the types of queries that the Repository has the ability to fulfill. Indicates whether or not the repository exposes renditions of document objects. Represents an exception that a repository may return in response to a CMIS service method call Represents a CMIS Query. Represents an alternative rendition of a document. Represents the capabilities of a repository. Each boolean class member represents an optional capability, meaning the repository does not need to support the specific capability to be compliant with CMIS. Represents a CMIS repository. Represents the set of information available on a CMIS repository, including the optional capabilities and access control information. Speicifies the exception types that a repository may return in response to a CMIS service method call. Namespace Ncmis.Provider Name AclProviderBase Description Provides the base implementation for the ACL Provider for the ACL Services. 47

APPENDIX C NCMIS CLASSES Namespace Ncmis.Provider Name AclProviderCollection AclProviderConfiguration AclProviderManager DiscoveryProviderBase DiscoveryProviderCollection DiscoveryProviderConfiguration DiscoveryProviderManager MultiFilingProviderBase MultiFilingProviderCollection MultiFilingProviderConfiguration MultiFilingProviderManager NavigationProviderBase NavigationProviderCollection NavigationProviderConfiguration Description Represents a collection of ACL Provider objects that inherit from NCMIS.Provider.AclProviderBase. Represents the AclProvider section within the application s configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Provides the base implementation for the Discovery Provider for the Discovery Services. Represents a collection of Discovery Provider objects that inherit from NCMIS.Provider.DiscoveryProviderBase. Represents the DiscoveryProvider section within the application's configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Provides the base implementation for the Multi- Filing Provider for the Multi-Filing Services. Represents a collection of Multi-Filing Provider objects that inherit from NCMIS.Provider.MultiFilingProviderBase. Represents the AclProvider section within the application s configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Provides the base implementation for the Navigation Provider for the Navigation Services. The navigation services are used to traverse the folder hierarchy in a CMIS Repository, and to locate Documents that are checked out. Represents a collection of Navigation Provider objects that inherit from NCMIS.Provider.NavigationProviderBase. Represents the NavigationProvider section within the application s configuration file. 48

APPENDIX C NCMIS CLASSES Namespace Ncmis.Provider Name NavigationProviderManager ObjectProviderBase ObjectProviderCollection ObjectProviderConfiguration ObjectProviderManager PolicyProviderBase PolicyProviderCollection PolicyProviderConfiguration PolicyProviderManager RelationshipProviderBase RelationshipProviderCollection RelationshipProviderConfiguration RelationshipProviderManager Description Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Provides the base implementation for the ACL Provider for the ACL Services. Represents a collection of Object Provider objects that inherit from NCMIS.Provider.ObjectProviderBase. Represents the ObjectProvider section within the application s configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Provides the base implementation for the Policy Provider for the Policy Services. Represents a collection of Policy Provider objects that inherit from NCMIS.Provider.PolicyProviderBase. Represents the ObjectProvider section within the application s configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Provides the base implementation for the Relationships Provider for the Relationships Services. Represents a collection of Relationship Provider objects that inherit from NCMIS.Provider.RelationshipProviderBase. Represents the ObjectProvider section within the application s configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. 49

APPENDIX C NCMIS CLASSES Namespace Ncmis.Provider Name RepositoryProviderBase RepositoryProviderCollection RepositoryProviderConfiguration RepositoryProviderManager VersioningProviderBase VersioningProviderCollection VersioningProviderConfiguration VersioningProviderManager Description Provides the base implementation for the Repository Provider for the repository services. The repository services allow the discovery of information about a repository and the objecttypes defined in it. Represents a collection of Repository Provider objects that inherit from NCMIS.Provider.RepositoryProviderBase. Represents the RepositoryProvider section within the application s configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Provides the base implementation for the Versioning Provider for the Versioning Services. Represents a collection of Versioning Provider objects that inherit from NCMIS.Provider.VersioningProviderBase. Represents the VersioningProvider section within the application s configuration file. Represents the single instance of the Provider Manager that initializes the default provider and the provider collection. Namespace Ncmis.Provider.SampleProvider Name SampleAclProvider SampleDiscoveryProvider SampleFactory SampleMultiFilingProvider Description Provides sample implementation for the ACL services. Provides sample implementation for the Discovery services. Provides factory/creation methods for sample objects. Provides sample implementation for the Multi- Filing services. 50

APPENDIX C NCMIS CLASSES Namespace Ncmis.Provider.SampleProvider Name SampleNavigationProvider SampleObjectProvider SamplePolicyProvider SampleRelationshipProvider SampleRepositoryProvider SampleVersioningProvider Description Provides sample implementation for the Navigation services. Provides sample implementation for the Object services. Provides sample implementation for the Policy services. Provides sample implementation for the Relationship services. Provides sample implementation for the Repository services. Provides sample implementation for the Versioning services. Namespace Ncmis.ServiceModel.Ra Name IncludeXmlDeclarationAttribute RequestParameter Service XmlDeclarationMessage XmlDeclarationMessageFormatter Description Represents a Operation Behavior Attribute, that includes the XML Declaration in a service response of the called operation. Handles Request parameters from the current incoming web request. Provides the services for the REST/Atom binding. Represents a System.ServiceModel.Channels.Message that supports emitting XML Declaration (default WCF behavior of Message class does not support the emitting of XML Declaration). Represents a System.ServiceModel.Dispatcher.IDispatchMessageFormatter that deserialize request messages and serialize response messages in a service application using the NCMIS.ServiceModel.Ra.XmlDeclarationMessage message class. 51

APPENDIX C NCMIS CLASSES Namespace Ncmis.ServiceModel.Ra Name CmisAuthor CmisChildren CmisContentTypeMapper CmisEntry CmisServiceDocument CmisSyndicationFeed CmisSyndicationItem CmisWorkspace ServiceDocumentExtensions SyndicationItemExtensions Description Represents a syndication author element. Represents a CMIS children element. Specifies the message format to which the content type of an incoming message is mapped. Overrides the default mapping for CMIS/Atom specific content types. Represents a CMIS Atom entry. Represents a CMIS service document. Represents a CMIS Atom feed item, extended with Atom Extensions for CMIS. Represents a CMIS feed item, extended with Atom Extensions for CMIS. Represents a CMIS workspace element, extended with Atom Extensions for CMIS, within a CMIS service document. Holds extensions for the service document class. Holds extensions for the syndication item class. 52

Appendix D Other Implementations of CMIS CMIS Repositories Alfresco (http://cmis.alfresco.com/) KnowledgeTree (http://wiki.knowledgetree.com/cmis) Nuxeo (http://www.nuxeo.org/xwiki/bin/view/main/cmis) CMIS Clients Alfresco (http://cmis.alfresco.com/) CMIS Explorer (http://code.google.com/p/cmis-explorer/) CMIS Spaces (http://code.google.com/p/cmisspaces/) (Reiner, 2009) cmislib (http://code.google.com/p/cmislib/) 53

TRITA-CSC-E 2010:173 ISRN-KTH/CSC/E--10/173-SE ISSN-1653-5715 www.kth.se