All CMS vendors have their own definitions of a content model, also called an object model. For example, in Alfresco, there is a folder type (cm:folder), a generic content type (cm:content), associations described as aspects (for example, cm:contains, rn:rendition, and cm:references), and so on. These are available out of the box and are used when you create folders and upload files into the repository. In Alfresco, these types and aspects have properties and they can inherit definitions from other types and aspects. Each property has a datatype and other behavior attributes such as multi-valued and required. When you work with Alfresco in a specific domain, such as legal, it is possible to create domain-specific subtypes that extend the generic types. For example, you could create a legal case type that extends the generic folder type.

Now, as you can imagine, other vendors would not necessarily have the same definitions for their content model. If we take Documentum as an example, its generic content type is named dm_document and not cm:content. Some content management systems also do not have the concept of an aspect.

So what the CMIS Standardization group had to do was come up with an object model that was generic enough for most CMS vendors to be able to implement it. And it had to be specific enough for the implementations to be meaningful and usable. So, the group came up with something called the CMIS domain model.

The CMIS domain model defines a repository as a container and an entry point to all the content items, called objects from now on. All objects are classified by an object type, which describes a common set of properties (such as type ID, parent, and display name). There are five base types of objects: Document, Folder, Relationship, Policy, and Item (CMIS 1.1), and they all inherit from the Object type as shown in the following figure:

Besides these base object types, there are a number of property types that can be used when defining new properties for an object type. They are, as can be seen in the preceding figure, String, Boolean, Decimal, Integer, and DateTime. Besides these property types, there are also the URI, ID, and HTML property types, which are not shown in the preceding figure.

Let's take a closer look at each one of the following base types:

Additional object types can be defined in a repository as custom subtypes of these base types, such as the Legal Case type in the preceding figure. CMIS services are provided for the discovery of object types that are defined in a repository. However, object type management services, such as the creation, modification, and deletion of an object type, are not covered by the CMIS standard.

An object has one primary base object type, such as document or folder, which cannot be changed. An object can also have secondary object types applied to it (CMIS 1.1). A secondary type is a named class that may add properties to an object in addition to the properties defined by the object's primary base object type (if you are familiar with Alfresco, you can think of secondary object types to be the same as aspects; for example, emailed, versionable, published, and more).

Every CMIS object has an opaque and immutable object identity (ID), which is assigned by the repository when the object is created. In the case of Alfresco, a so-called node reference is created, which becomes the object ID. An ID uniquely identifies an object within a repository regardless of the type of the object.

All CMIS objects have a set of named, but not explicitly ordered, properties. Within an object, each property is uniquely identified by its property ID. In addition, a document object can have a content stream, which is then used to hold the actual byte content for the file representing, for example, an image or a Word document. A document can also have one or more renditions associated with it. A rendition can be a thumbnail or an alternate representation of the content stream, such as a different size of an image.

Document or folder objects can have one Access Control List (ACL), which then controls the access to the document or folder. An ACL is made up of a list of ACEs. An Access Control Entry (ACE) in turn represents one or more permissions being granted to a principal, such as a user, group, role, or something similar.

Now, we may ask the questions such as, what does a document object look like?, what properties does it have?, what namespace is used?, and so on. The following figure shows you how the document object and the other objects are defined with properties:

All the objects and properties are defined in the cmis namespace. From now on, we'll refer to the different objects and properties by their fully qualified names, for example, cmis:document or cmis:name.

The CMIS specification also defines the following set of services to access and manage the CMIS objects in the content repository:

As we can see, there are quite a few services at our disposal and we will see how they are used in the upcoming chapters. Note that when working with the different types of protocols and formats that the CMIS standard supports, the preceding method names might not be used. For example, if you wanted to get the children objects for an object, you would use the getChildren method from the navigation service. However, if we are using the AtomPub binding, this method would be referred to as the Folder Children Collection and can be accessed via a URL that looked similar to the following: .../children?id=....

The query method of the discovery service uses a query language that is based on a subset of the well known SQL-92 standard for database queries. It also has some ECM-specific extensions added to it. Each object type is treated as a logical relational table and joins are supported between these, creating a relational view of the CMIS model. The query language supports metadata and/or a full-text search (FTS is optional).

The CMIS object type definitions contain some properties that are related to searching, which are as follows:

The following example selects all properties for all documents but does not include thumbnails (cm:thumbnail):

SELECT * FROM cmis:document

On the other hand, the following example includes cm:thumbnail and any subtypes that are set as includedInSuperType=true:

SELECT * FROM cm:thumbnail

To select specific properties for all documents, use the following query:

SELECT cmis:name, cmis:description FROM cmis:document

To select all documents that have a name containing the text alfresco, we can use the following:

SELECT cmis:name FROM cmis:document WHERE cmis:name LIKE '%alfresco%'

To perform a Full-Text Search (FTS), we need to use the SQL-92 CMIS extension CONTAINS() to look for any document with the text alfresco in it as follows:

SELECT * FROM cmis:document WHERE CONTAINS('alfresco')

The previous query will return all properties (columns) as we have used the wildcard *. There are also some folder-related SQL-92 CMIS extensions to search in a folder (IN_FOLDER) or folder tree (IN_TREE):

SELECT cmis:name FROM cmis:document WHERE IN_FOLDER('folder id')

The preceding query returns all documents in the folder with the identifier folder id. A folder identifier would be the same as a node reference in the Alfresco world. The following query returns all objects beneath the folder with folder id:

SELECT cmis:name FROM cmis:folder WHERE IN_TREE('folder id')

We have covered the object model and the available repository services. We also need to have a look at how we can actually communicate with the repository from a remote client over the wire. This is where protocol bindings come into the picture. There are three of them available: RESTful AtomPub, SOAP Web Services, and RESTful Browser (CMIS 1.1). CMIS-compliant repositories must provide a service endpoint (that is, the starting URL) for each of the bindings. The service URL and an understanding of the CMIS specifications is all that a client needs to discover both the capabilities and content of a repository.