Tag Archives: CMIS

OASIS Content Management Interoperability Services (“see-miss”)

CMIS Interoperability

CMS Wire recently picked up the development of CMIS Explorer by Shane Johnson (@shane_dev) at CityTech. CMIS Explorer (download) is a browser application written in Adobe AIR and Flex that uses the RESTful AtomPub binding of the proposed CMIS standard to interact with CMIS-compliant repositories.

Already early access support for CMIS is available from EMC, IBM and Alfresco. Such support makes it possible for applications like CMIS Explorer to be applied to a variety of content repositories in ways not possible before CMIS.

As fellow OASIS CMIS TC member Florent Guillaume from Nuxeo comments, though, CMIS is not yet a formal (fixed) standard. It is under development and somewhat fluid.

When a content repository vendor provides draft support, don’t assume that such support fully conforms to the current draft specification (e.g. v0.5). If you’re an application developer like Shane, you can know conformance exists by first building against what is specified on the OASIS site for CMIS and then pointing your application at desired content repository or repositories.

For example, you can point CMIS Explorer at a Documentum content repository via EMC CMIS support EA2 to search and to see types.

Searching a Docbase via CMIS Explorer

Reviewing Docbase types via CMIS Explorer

However, while basic interoperability seems OK, something prevents actual browsing functionality in CMIS Explorer from working with Documentum. In its com.citytechinc.cmis.Repository.setFolder() method, CMIS Explorer tries to get folder objects from root children via the following condition:
f.object.properties.propertyString.(@name=='BaseType').value == "folder"
However, draft CMIS specification v0.5 does not define a BaseType property, not does the EMC CMIS support EA2 contain this property. As a result, CMIS Explorer cannot find any folder object in root children, which prevents it from being able to browse a Docbase.

To be fair, my colleague, Norrie Quinn, has already pointed out this matter on Shane’s post, and Shane has replied.

My focus here is simply as follows: It’s important for applications to leverage the currently proposed CMIS bindings from OASIS rather than a particular vendor’s implementation of these bindings in order to promote interoperability.

It will be good to see the emergence of CMIS-based applications that go beyond exploration, navigation and portal-style user experiences. Such applications will help to influence the CMIS roadmap beyond version 1.0.

In the meantime, it’s great to see open source efforts like CMIS Explorer take root today. Thanks, Shane.

P.S. It would be good to see a community form around CMIS-based application development (e.g. shine a light on individual efforts, potentially pool interest and resources, solicit ideas and challenges, etc.). If you’re interested in something like, please leave me a comment. In the meantime, I plan to promote community efforts here as best I can. Thanks.

JIRA Client for OASIS

Thanks to a recent IT change concerning the OASIS JIRA server, I can now leverage ALM Works JIRA Client to work OASIS CMIS TC issues.

JIRA Client for OASIS splash screen

Furthermore, all OASIS Issue Trackers in the single OASIS JIRA server are available to me–or any other OASIS member!

Here is how…

  1. Visit ALM Works and download JIRA Client.
  2. Install JIRA Client and choose “Run JIRA Client” before exiting the installer.
  3. Enter your license key. That is, download deskzilla_oasis.license to your local %USERPROFILE%\.JIRAClient directory (e.g. C:\Documents and Settings\YourUserName\.JIRAClient, on a Windows XP machine), and point your JIRA Client instance to your local license file (i.e. select it).
  4. Verify the following license data is presented upon selection:
          Site license
          Licensed to: open-source community
          Support ID: 4000383
          Supported servers:
            JIRA [http://tools.oasis-open.org/issues]
  5. Restart JIRA Client in order for this license to take effect (i.e. Start | Programs | JIRA Client | JIRA Client).
  6. Configure connection (i.e. enter your OASIS member login credentials).
  7. Connect and select the OASIS issue trackers of interest.
  8. Initialize connection, which may take a short amount of time during first-time initialization.

At this point you should be able to leverage JIRA Client against OASIS issue trackers (e.g. CMIS).


  • A big thank you to ALM Works founder, Igor Sereda, for his support of open source projects and organizations like OASIS.
  • Thanks also go to Mary McRae of OASIS for gently vetting JIRA Client licensing details, since I’m not an OASIS employee.

Just to be clear, this ALM Works software is not being provided by, nor licensed to OASIS as an organization. The JIRA Client license from ALM Works isn’t granted to OASIS, but it’s restricted to access the OASIS JIRA repository. Each person who installs will need to determine whether or not they are able to accept the licensing agreements for their organization.


Consuming CMIS WSDL in Visual Studio

As indicated previously, I’ve uploaded a CMIS v0.5 sample to EDN. This sample works with EMC Documentum CMIS EA2.

This CMIS sample is intentionally similar to a sample produced previously for DFS 6.5 SP1. The intent is to help you compare and contrast one set of service contracts from the other. In doing so, please keep in mind that CMIS is focused on basic library services for content management–common features across supporting repositories–while DFS is focused on the broader richness of the EMC Documentum ECM Platform.

It’s worth noting that in the case of its CMIS Repository service interaction, this sample EXE was also used by IBM during this week’s TC meeting against their P8-based WSDL endpoint–requiring only a binding configuration change (i.e. zero code changes).

I mentioned that the CMIS AtomPub service (introspection) document for EA2 is accessible as follows: <code>http://host:port/resources/cmis</code>. Let’s say your EA2 installation is running at localhost on 8080, then a request for this document will return the following type of response:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:service xmlns="http://www.w3.org/2005/Atom" xmlns:ns2="http://www.cmis.org/2008/05" xmlns:ns3="http://www.w3.org/2007/app">
  <ns3:workspace ns2:id="dfs">
    <title type="text">dfs</title>
    <ns3:collection href="http://localhost:8080/resources/cmis/repositories/dfs/objects/0c00302180000105/children" ns2:collectionType="root-children">
      <title type="text">root-children</title>
    <ns3:collection href="http://localhost:8080/resources/cmis/repositories/dfs/objects/0c00302180000105/descendants" ns2:collectionType="root-descendants">
      <title type="text">root-descendants</title>
    <ns3:collection href="http://localhost:8080/resources/cmis/repositories/dfs/types" ns2:collectionType="types-children">
      <title type="text">types-children</title>
    <ns3:collection href="http://localhost:8080/resources/cmis/repositories/dfs/types" ns2:collectionType="types-descendants">
      <title type="text">types-descendants</title>
    <ns3:collection href="http://localhost:8080/resources/cmis/repositories/dfs/checkedout" ns2:collectionType="checkedout">
      <title type="text">checkedout</title>
    <ns3:collection href="http://localhost:8080/resources/cmis/repositories/dfs/queries" ns2:collectionType="query">
      <title type="text">query</title>

Your repository name and object identifiers will likely differ from the example references above, but hopefully you get the gist of the response payload.

Comparing the RESTful AtomPub binding to the SOAP binding in CMIS, one has to make two service requests to yield the same repository information (i.e. the block of data represented by <code>repositoryInfo</code> above) as follows:

repositories = repositoryService.getRepositories();
foreach (cmisRepositoryEntryType repository in repositories)
  cmisAnyXml repositorySpecificInformation;
  string repositoryId = repository.repositoryID,
  cmisRepositoryCapabilitiesType capabilities;
  XmlAttribute[] AnyAttr;
  XmlElement[] Any;
  repositoryService.getRepositoryInfo(ref repositoryId, out repositoryRelationship,
         out repositoryDescription, out vendorName, out productName,
         out productVersion, out rootFolderId, out capabilities,
         out cmisVersionsSupported, out repositorySpecificInformation,
         out Any, out AnyAttr);
  . . .

Comparing CMIS Repository service WSDL consumption with DFS Search service WSDL consumption, the same DFS-based consumer code is as follows:

Repository[] repositories = searchService.getRepositoryList(null);
foreach (Repository repository in repositories)
  . . .

To be clear, these examples are not provided for me to argue that one approach is better than another but rather to show how approaches differ based on domain model, use cases, etc.

I’ll leave it as an exercise for the reader to perform similar comparisons where query support and object support is concerned between DFS and CMIS. :-)

Perhaps it’s also useful to comment on how WS-Security header information is passed to CMIS WSDL endpoints, since CMIS WSDL doesn’t currently declare headers explicitly in the service contract.

This sample injects WS-Security headers via app.config-based declaration (versus programmatically):

    <add name="usernameToken" type="SecurityMessageInspector.UsernameTokenBehaviorExtensionElement, SecurityMessageInspector, Version=, Culture=neutral, PublicKeyToken=null"/>
    <behavior name="UsernameTokenBehavior">
      <usernameToken username="Administrator" password="emc" passwordType="PasswordText"/>

Right away, understand that this is a sample–you will likely want to take a more secure approach to managing user credentials. Certainly, if you employed this approach, you should employ a secure transport (i.e. SSL). Please see the sample solution’s README file for more details if a more programmatic approach is desired (with or without SSL).

There are other ways to "wire" WS-Security header creation and passing into applications. This particular sample takes a more subtle (less in-your-face) approach to accomplish this concern. Regardless, implicit SOAP headers in a contract require extra coding on the part of a consumer.


Earlier today, John Newton posted a nice summary of what the OASIS CMIS Technical Committee (TC) accomplished this Monday through Wednesday. Anyone interested in the CMIS progress will want to read John’s post.

Earlier this week, EMC released its second Early Access bits that support both bindings in the current draft specification.

It was great to spend time focusing on technical issues and discussing proposals to resolve them. Sometimes there simply isn’t a substitute for working with others in the same room! It was also nice to catch up with prior colleagues–John and Dave Caruana–and establish new report with others in the Enterprise Content Management industry.

In particular, I appreciate the effort made by TC’ers from EMC and IBM to get our bits–both REST and SOAP–interoperating together. We did make demonstrable progress–however difficult the technical environment (i.e. lack of viable network onsite) proved to be. (I’ll post my WCF test client (CMIS WSDL endpoint consumer) separately.)

(By the way, if you ever test MTOM content transfer while outputting messages to a console window, think twice about logging all HTTP traffic. I think that folks in the lobby of building 40 thought my laptop was a bomb when I rushed to leave the TC meeting after I couldn’t get my computer alarm to silence or stop–until a hard power-down action was applied. :-) )

Update 1/31/2009: Thanks to Dennis Hamilton, here is a group photo of those physically present at the TC meeting:

090128 OASIS CMIS TC group photo

EMC Documentum CMIS EA2

Earlier today, the second Early Access (EA2) release of EMC Documentum ECM Platform support for the proposed CMIS standard (i.e. current v0.5 draft) was made publicly available via EDN Labs.

EA2 features support for both bindings in the proposed draft standard: SOAP and AtomPub.

  • CMIS EA2 WSDL endpoints are available as follows:
    (e.g. http://localhost:8080/services/cmis/RepositoryService?wsdl)
  • CMIS EA2 AtomPub service document is available as follows:
  • CMIS EA2 WADL for the AtomPub resources (not covered by the CMIS specification):

You’ll find more deployment details in the associated guide.

EMC is committed to CMIS and the standards process. Just as there was an EA1 before this update, there will be subsequent EA releases in the future. Hopefully by making CMIS support available to you as the proposed standard develops and matures, you will consider exercising the draft bindings and submitting your feedback. Thanks in advance!

Update 1/27/2008: Pie (Laurence Hart) has posted about AIIM’s intention to demonstrate CMIS-based interoperability at its upcoming Expo via a prototype. EMC is looking forward to participating in this effort, which will provide a nice proof point for ECM customers, partners and vendors all.