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

(1)

Adapting Content Management

Interoperability Services for Web

Content Management Systems

D E N N I S N K A N G I

Master of Science Thesis Stockholm, Sweden 2010

(2)

Adapting Content Management

Interoperability Services for Web

Content Management Systems

D E N N I S N K A N G I 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

(3)

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

(4)

(5)

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.

(6)

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.

(7)

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.

(8)

(9)

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)

(14)

2

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.

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.

CMIS REST Client CMIS WS Client

CMIS Restful AtomPub Binding

CMIS WS Binding

(15)

CHAPTER 2 BACKGROUND

3

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.

(16)

4

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.

Document

• Content • Metadata • Version History

Folder

• Container • Hierarchy/Filing • Metadata

Relationship

• Source • Target

Policy

• Target

Meta Model

(Property, ACL)

(17)

5

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.

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.

Client Endpoints Host Process WCF Host Process WCF Service Class Proxy

(18)

6 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).

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,

Service

Workspace

Collection

Entry Media Resource

Repository Server Repository Root Folder Children Folder/Document Content Type Definitions Type Checked Out Working Copy

(19)

7

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)

(20)

8 Repository Info

 Properties

 Capabilities

Collections

 Checked Out Collection

 Query Collection

 Root children Collection

 Type children Collection

 Unfiled Collection

Links

 Type Descendants Feed Link

 Folder Tree Feed Link

 Root Descendants Feed Link

 Changes Feed Link

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)

(21)

9

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.

(22)

10

 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)

(23)

11

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.

(24)

12

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.

(25)

CHAPTER 4 RELATED IMPLEMENTATIONS OF CMIS

13

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 Explorer1

(26)

14

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) library2_.

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/

(27)

15

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.

(28)

16

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

CMIS JCR

Programming Language

Restrictions No restrictions Only applicable to Java solutions

ECM Vendor Involvement Several of the major vendors,

such as Microsoft, IBM and EMC are involved

Only vendors developing for the Java platform will have any interest in the standard

Integration Is implemented as a layer on top

of an existing ECM solution Requires changes to core ECM capabilities in order to support specific features

Service Oriented

Architecture Service Oriented Not Service Oriented, requires consistent connections

Table 2 Comparison of CMIS and WebDAV

CMIS WebDAV

Types and properties Exposes and extendable set of

types and properties No support for types and properties

Queries Supports a custom query

language No support for queries

Relationships Exposes a relationship object for

relating CMIS objects to one another

No support for relationships

Communication Protocol Allows the communication

through HTTP or any protocol allowed by the WS-* techniques

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

(29)

CHAPTER 7 CONCLUSIONS

17

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.

(30)

18

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.

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

CMIS Client CMS Service Producer XML CLR Types CMIS VPP EPiServer CMS CMIS Service Arbitrary CMS

(31)

CHAPTER 7 CONCLUSIONS

19

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.

(32)

20

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.

(33)

CHAPTER 8 RECOMMENDATIONS

21

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.

(34)

22

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.

(35)

23

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.1Single 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.2XML 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.3REST 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

(36)

24

format. CMIS specifies a few required namespaces and prefixes for the serialized XML. These should be included explicitly to the output types.

10.1.4Target Use Case

The most probable use scenarios for a web CMS implementing CMIS is the to-Repository use case and the Application-to-to-Repository use case, described in 11.3.1 to- Repository-to-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.1Type 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.

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.2Checked 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

Folder

UnifiedDirectory VersioningDirectory

Document

(37)

CHAPTER 10 RESULTS

25

where there are many files and folders in the repository this operation may be notably time consuming for the user.

10.2.3Virtual 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.1Be 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

(38)

26

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.

(39)

CHAPTER 11 ANALYSIS

27

Table 4 CMIS Services

Service Group Description

Repository Services Allows the discovery of information about the repository and its object types.

Navigation Services Allows the navigation of the folder hierarchy of a repository and the localization of checked out documents.

Object Services Allows ID-based CRUD operations on objects in a repository.

Multi-Filing Services 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.

Discovery Services Allows a repository to be searched for queryable objects.

Versioning Services Allows the navigation and updatability of document version series. Relationship Services Allows the retrieval of the dependant relationships objects associated

with an independent object.

Policy Services Allows the application and removal of policies to an object.

ACL Services 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.

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.

(40)

28

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 DataContractSerializer Features

Opt-out Opt-in

Can serialize properties, but not fields Can serialize properties and fields

Slower than DataContractSerializer Faster than XmlSerializer

Allows much control over how the XML looks Allows little control over how the XML looks Cannot understand the DataContract attribute 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.1Repository-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.

(41)

29

 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.2Application-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.3Federated 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.4Repository 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.

(42)

30

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 Description

Ncmis.AccessControl Exposes the ACL and ACE classes.

Ncmis.ObjectModel Exposes the core object classes that carry the data,

such as the document and folder object.

Ncmis.ObjectModel.MetaData Exposes the core object meta-data.

Ncmis.ObjectModel.Rest Exposes classes that are specific to the Restful

AtomPub Binding.

Ncmis.Produce Exposes classes that are used specifically to

produce content.

Ncmis.Provider Exposes extendable classes for creating a CMIS

provider according to the .NET provider model.

Ncmis.Provider.SampleProvider Exposes a sample provider that implements the

extendable classes of the CMIS provider.

Ncmis.ServiceModel Exposes the service layer architecture.

Ncmis.ServiceModel.Ra Exposes classes of the service layer architecture

that are specific to the Restful AtomPub Binding.

Ncmis.ServiceModel.Syndication 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

(43)

31

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.1Object 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.

(44)

32

Figure 16 CmisObject and its containers. 11.5 Restful AtomPub Binding

The Restful AtomPub binding communicates using REST principles.

11.5.1Client 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.2Single 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.

(45)

33

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.4XML 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.5Optional 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.6Stream 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.

(46)

34

11.5.7Validate 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.1Client 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.2getCheckedOutDocs

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

(47)

35

11.8 EPiServer CMIS Consumer

The prototype CMIS consumer is developed as a VPP, using the Restful AtomPub binding.

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.

CMIS Service Arbitrary CMS

CMIS VPP EPiServer CMS

(48)

36

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/service-oriented_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.oasis-open.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

(49)

CHAPTER 12 BIBLIOGRAPHY

37

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-vs-datacontractserializer-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

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

Adapting Content Management

Interoperability Services for Web

Content Management Systems

Adapting Content Management

Interoperability Services for Web

Content Management Systems

Abstract

Acknowledgements

Contents

1

Terminology

2

Background

Document

Folder

Relationship

Policy

Meta Model

(Property, ACL)

3

Related Standards

4

Related Implementations of CMIS

5

Goal and Objectives

6

Limitations and Constraints

7

Conclusions

8

Recommendations

9

Method

10

Results

11

Analysis

12

Bibliography