Tag Archives: AtomPub

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.

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.

Atom 1.0 is complete

Today Tim Bray reported that Atom is done. This is good news for the Web, and this is an important opportunity for ECM vendors.

I appreciate it when those involved in a standard take the time to share a concise vision for why the standard matters. According to Tim Bray, Atom’s raison d’ĂȘtre is “Publish” Everywhere. (Or, perhaps, publish-and-edit everywhere, reading last night’s IETF announcement.)

Others have already commented on the potentially powerful relationship between REST and ECM. Given APP’s RESTful approach and it’s focus on publishing and editing web resources (e.g. documents, multimedia, metadata), one should expect to see Atom (format and protocol) take hold across the ECM ecosystem.

It would be helpful to see someone like Sam Ruby, who directly participated in both the WebDAV and Atom working groups, would please comment on why WebDAV failed where Atom is seen to succeed. After all, the purpose of WebDAV–Web Distributed Authoring and Versioning–sounds very similar to Atom‘s present purpose. Both protocols rely on HTTP. Etc. Etc. Tim’s candid reply to a relevant IETF working group thread–“I’ve never really studied DAV”–is also unfortunate.

If, indeed, he’s in the majority, then how can a previous WebDAV and potential Atom standard adopter truly know when Atom-WebDAV divergence is intentional and appropriate, and not just accidental or lazy? Those who invested time in adding “checkin” and “checkout” to their authoring software on behalf of their WebDAV embrace, may be reluctant to add shiny new “publish button” supporting Atom, unless it’s clear how history won’t repeat itself (or rhyme, as Mark Twain would instead suggest).

Aside: In general, I find it difficult to talk with others about a standard that has more than one focus (e.g. SAML – (just another) token format or “the universal solvent of identity information,”  Atom – feed format or publishing protocol, etc.). Sounds like Tim has similar concerns with the vague nature of “Atom” (without further qualification). Since “APP” is becoming a fairly common acronym for Atom Publishing Protocol, how about “AFF” for “Atom Feed Format (i.e. RFC 4287)? This could leave “Atom” for all-inclusive conversations (i.e. both APP and AFF).