!!! DRAFT !!!

OpenCMIS Client API

The OpenCMIS client layer provides an object oriented interface for easy consumption of the underlaying CMIS related layers. In additon to the CMIS specification the OpenCMIS client layer introduces a session concept which easily enables applications to get control on the client side cache behaviour.

The client layer consists of a client interface, common interfaces and a runtime implementation. The runtime maps the client interface to the provider layer and implements the session cache. All parts are exposed by following packages:

The following UML diagramm illustrates the main classes of the client API:

• SessionFactory This interface provides the entry point into the client API and is responsible to create a session object. Additionally it gives access to all repository info exposed by a CMIS provider. The runtime provides a default implementation for the SessionFactory interface.
• Session This is the main interface an applicaiton has to work with. A session object is related to a CMIS service provider and is attached to exact one repository. All data that is receiced throug the session interface can be cached in the session object in dependency of the concrete implementation which is behind.
• Repository Wrapper interface for the CMIS RepositoryInfo service.
• CmisObject The CmisObject interface represents the CMIS domain object.
• ObjectType This interface is base for all CMIS domain types like FolderType, DocumentType, PolicyType and RelationType. The derived interfaces are not shown in teh diagram.
• Folder This interface represents the CMIS folder object.
• Document This interface represents the CMIS document object.
• ContentStream this interface wrapps the content stream of a CMIS document.
• Policy This interface represents the CMIS policy object.
• Relation This interface represents the CMIS relation object.

Session and cache concepts

The concrete cache strategy depends on the implementation of the session in the client runtime. There are currently two session implementations in consideration:

1. Persistent Session
2. Transient Session

A Persistent Session implements a read cache only. That means whenever it makes sense the session will avoid secondary calls to the provider and returns cached data instead. An applicaiton can control this behaviour at different granularity. A refresh of the session will release all data kept by the session and ensures most actuallity of the read data afterwards. On the granularity of a method call an application can bypass the cache or avoid caching by parameterizing an optional operation context. The lifetime of the session can be bound to the application. A stateless application can create a new session for each request. The persistent session strategy enables a very performant access to a CMIS enabled DMS infrastructure.

A Transient Session extends the presistent session and implements a buffer for all write operations. With that all single write operations are executed lazy during an explicite session save call. Write operations can be reverted by calling the cancel method on the session object. This strategy is not implemented yet.