The Challenge of CMIS

I started this to talk about some of the things out there, but there is sooo much that I am drawing the line. Kas is writing some good things on CMIS as he attempts to grok it.  Others, like Jon Marks, are grappling with CMIS as well. They raise some excellent points that probably deserve posts unto themselves. I find myself, today, focusing on the more immediate and of the more “outside-the-box” thoughts.

Updates and Announcements

First, in case you missed it, the 0.61c version of CMIS is currently out.  A lot of little things, but some solid progress.  I haven’t dived in very deeply, but some changes include:

  • [CMIS-18] – Rename REST-Bindings to “AtomPub Bindings” or “AtomPub Extensions”: Now called “ReSTful AtomPub Binding”.  Solid change as ReST is an architectural style, not a protocol.
  • [CMIS-45] – “base type” vs “root type”: Base type is the answer. Was some confusion between some of the implementations as the spec used both terms.
  • [CMIS-48] – Replace cardinality:enumCardinality with multiValued:boolean: Minor but not something to be overlooked.
  • [CMIS-54] – Content Stream MIME type: mandatory or not?: Was some confusion between documentation and the schema. The answer is “YesNo” [See Florent’s comment below.]
  • [CMIS-85] – enumPropertiesDocument does not contain a string value for “Name”: Love typos.
  • [CMIS-86] – Provide a new service that will allow search crawlers to efficiently navigate a CMIS repository.: Cool.

Second, if you think you missed my presentation on CMIS with Alfresco, you are wrong.  There were audio problems and we are making a second go of it this week, April 22nd at Noon12:30pm EDT.  I am hoping for a strong Q&A portion of the webinar, so come with your questions on CMIS and the AIIM iECM Demo. If I say that I’ll have to get back to you on something, then it is a great question.

Finally, I have been invited to co-present at EMC World on CMIS. Not the best time-slot, 10am on Thursday, aka get-away day. If you show, I promise to make it worth your while.  More details as I get them.

CMIS, The Right Choice?

Saw a bunch of posts stream out from Stéphane Croisier about CMIS. They offer a fresh perspective, but I’m not sure that he fully gets it, yet. He doesn’t appear to have been living ECM for ages, but has a strong WCM/web viewpoint, and he likes CMIS so I am inclined to like him. They are good viewpoints to read though because, agree with them or not, he represents part of the audience for CMIS.  One post talks about CMIS being disruptive.  I don’t think it will be for ECM, but possibly for WCM and portals.  I think the Drupal/Alfesco integration using CMIS is just the first example of how things might change in the WCM world.  Disruptive is a strong word, but it could be that big to WCM.

Think of the impact to other content-focused applications.  Take SharePoint.  The next version, SharePoint 2010, will be out in the first half of next year with the tech preview in Q3 2009.  As they already have CMIS examples with the current version, I see great things in the future. If you can tie SharePoint into a back-end repository with CMIS, the scalability concerns are almost gone.  Who needs RBS or EBS?  Disruption is almost the opposite of what may happen with SharePoint support, which may not be a bad thing.

Then there is the whole CMIS versus the old guard, WebDAV, JSR-283, and ODMA. All have their uses, but none are ideal or do what CMIS does.  Let’s take this in reverse order.

When ODMA became fully supported in Office 97, I danced the happy dance.  Less than a year later, all my clients wanted web interfaces with no FAT clients deployed.  ODMA kind of requires a FAT client, so it withered.  Some repositories still lean on it, and it is awesome.  It is user application to repository standard, not system-to-system.

JSR-283 requires a Java interface. Not everyone, vendors and clients, use Java, so it fails. Even some of those that do, *cough* Documentum, don’t support it.  Nice concept, but limited in full practicality.

Then there is WebDAV.  If you look strictly at the AtomPub binding of CMIS, you get confused as to what the point may be.  Remember, this is not just for applications to save and update content in a repository.  CMIS has advanced queries and, as a whole, is able to function as a standard interface in a Service-Oriented Architecture.  WebDAV does not have object typing, schema, folder navigation, or querying.  WebDAV is a useful way to save content from your desktop applications to an ECM repository, but it won’t link-up to your ESB or serve as the basis for an integration like the aforementioned Drupal/Alfresco blending.

Yes, CMIS is missing a lot of things. Transactions is one thing that we need badly. I am depending on the statements of the TC, the people, that say this is going to be version 1.0 of several versions.  If this is true, then life is good. It isn’t even at 1.0 yet, so small changes can occur (though Kas, I think the “folder” object is a neutral and broad term).  Policies are interesting and could be great depending on how each vendor unitizes the object.  We’ll see.

It is spring, so it is a time of hope. After all, who would have seen Microsoft, IBM, and EMC band together to create it, much less invite Alfresco, Oracle, SAP, and Open Text to play? I plan on dating, seriously, CMIS 1.0.  When version 2.0 comes out, I’ll know that CMIS is serious and I can truly commit.

18 thoughts on “The Challenge of CMIS”

    • I heard policies were in flux. I like them as a concept and don’t want them to get too weak if it can be avoided. I need to research more and post on the topic directly. I also need a time machine so that I can complete my to-do list, but that is apparently still a few years away.

      I posted the 0.61c draft to EDN today, which still only had 0.5 posted. You gotta get on your guys to keep up with that. 😉

      Like

  2. Hello Pie,

    First of all let me say that I am in favour CMIS and or any other initiatives which will try to promote content interoperability. Similar to Thomas Kas “I’m slowly but surely coming to grips with CMIS”.

    As you mentionned it WCM is for the moment out of scope for v.1.0 of CMIS. However while ECM2ECM is important, more and more of our customers also want better integration between their back-end ECM and their front-end WCM (or Social software or Portals). So even if custom Web Content issues are currently not adressed, WCM and other front-end systems will at least have to rapidly act as CMIS consumers.

    Then when you mention the Alfrescal demonstration I do not see anything really new in there. It looks like exactly similar kind of integration have already been done through WebDAV for years (e.g: http://download.microsoft.com/download/5/7/f/57f1490e-8a8d-497b-bbae-ec2a44b3799f/SWCWebCast.pdf – courtesy of Julien Reschke). So perhaps CMIS is bringing a bit more of this or that in term of API. But for the moment prototypes or demonstrations we are seing (e.g: CMIS Content Explorer;…) are not bringing much more than WebDAV+DeltaV+DASL.

    As mentionned by Julien WebDAV clients look like being feature frozen. This could be a problem and opens the door for a kind of “WebDAV fork”. But then in order to succeed everybody needs to be sure that it is more or less aligned and compliant with other content standards. When Julien is saying: “First of all, the CMIS data model really is different from the one used in JCR and WebDAV. For instance, the containment model (files do not have local name) differs drastically, and I currently do not see how a mapping from/to JCR will work beyond read-only access” (Read more: http://scroisier.posterous.com/fmis-or-cmis#ixzz0DIL0LdIi&B), this could firghten more than one company especially smaller ones.

    Perhaps large organisations (and then including Microsoft Sharepoint or Documentum) will have the opportunity to invest time and money on JCR, WebDAV and CMIS (+ some other Restful or Web Services oriented custom API) but this still make a quite complex entry barrier for newcomers and I am not sure this is the main goal of improving content interoperability. Will applications have to choose between WebDAV or CMIS or JCR in a near future?

    So as a product owner more than as a developer I am just looking for a crystal clear and simple user story. And for the moment I am not getting it. Let’s hope fog will disappear in the next months.

    Like

    • Stephane, Thanks for your comment. The story needs to be better explained. For me, the ECM-to-ECM is actually the secondary use-case. I see it more as you want it, Content applications with ECM back-ends. It isn’t just WCM though, Case Management systems and providing ECM as infrastructure to the Enterprise are essential. This requires more advanced features. The Alfrescal does not leverage all of CMIS, and maybe it is better done with WebDAV. On the other hand, it could just be at the first iteration and more advanced features will require the more advanced CMIS features.

      I know, from experience, that a CMIS application needs to be able to query the object model so that subtle differences in the “same” model can be determined from repository to repository. Alternatively, querying the repository for details may tell you what fields to map. Afrescal is a one-to-one. Taking it and making it one-to-many, just that one step, may require CMIS over WebDAV.

      As for a better example, hop onto the Alfresco Webcast tomorrow, link in the post. The AIIM iECM committee wrote a Search Federator using CMIS, Web Services Binding, to conduct searches against Alfresco, EMC, and Nuxeo.

      Like

      • Yes, I agree with you (and still again with Kas: CMIS in search of scenarios: http://asserttrue.blogspot.com/2009/04/cmis-standard-in-search-of-scenarios.html): CMIS looks like being driven by techies for techies. As a product owner and not a code architect guru I am rather trying to envision possible impacts and consequences on features and on possible customers expectations. But everybody agrees on the scope of v1.0: it should be as minimalistic as possible and rapidly out. But if you also want some massive adoption, user stories and possible conflicts of interests with other existing specifications should be clarified first. Else Content Applications Providers will start gambling and betting on what is the best standards, which one they should implement, how each standard is or is not compliant with the others, etc… And this is usually the beginning of the end.

        Regarding federated search (and content federation in general) CMIS is raising a lot of interesting questions. Federated Search Vendors are currently the most advanced in term of management of cross-content repositories issues. Vendors such as Autonomy are already packaging 400 custom CR connectors. It will be interesting to see the impact of CMIS on them. If I analyzed correctly your unified search prototype it is based on multiple search queries executed against each mounted CMIS connector. This is exactly what a vendor such as Autonomy is not recommending to do (cf: http://www.autonomy.com/content/Technology/autonomys-technology-limitations-of-other-approaches-federation/index.en.html). So it will be interesting to see how CMIS will help solve (or not) certain issues in this area. At lease it will help commoditize the content connector industry. Quite a shame that neither Interwoven nor Autonomy are member of the CMIS TC (excepted Exalead there are not a lot of other search vendors in there).

        Finally always in term of content federation I envision a lot of issues as soon as some standard “meanings” could not be shared and reused in between each CR silo. Rendering or querying some remote documents is one thing, trying to use heteregenous compound documents split over multiple CR will be another one (nothing about your AIIM demonstration, it was great. Just some long term oriented toughts). I wrote something about it (http://scroisier.posterous.com/considering-cmis-as-another-plug-to-the-seman) and it would be interesting to see if CMIS will become the missing link between 1/ ontologists still mainly driven by Semantic Web oriented technologies (RDF; OWL; SPARQL;…) and 2/ classical CM vendors (JCR; CMIS; WebDAV…). But here again, at a certain point in time, things will have to better fit all together in the big picture of a unified content world. I bet on Tim Barnes-Lee for the long term story 😉

        Like

  3. Julian Reschke says:

    Then there is WebDAV. If you look strictly at the AtomPub binding of CMIS, you get confused as to what the point may be. Remember, this is not just for applications to save and update content in a repository. CMIS has advanced queries and, as a whole, is able to function as a standard interface in a Service-Oriented Architecture. WebDAV does not have object typing, schema, folder navigation, or querying. WebDAV is a useful way to save content from your desktop applications to an ECM repository, but it won’t link-up to your ESB or serve as the basis for an integration like the aforementioned Drupal/Alfresco blending.

    AtomPub doesn’t have object typing or “schema” either. That is what extensibility is for.

    AtomPub doesn’t have folder navigation, but WebDAV does.

    AtomPub doesn’t have query, but WebDAV does (RFC 5323).

    It seems to me that the people who dismissed WebDAV as protocol binding early on didn’t really understand the WebDAV feature set and its extensibility model. The text about WebDAV in version 0.50 of the draft kind of proves that.

    Like

    • Julian, thanks for your comment. I’ll have to get back to you with a detailed response, but I wanted to share your thoughts with others now. Note that I think WebDAV has been, and should continue to be, an important part of the entire solution.

      I will say that my excitement over the standard centers on the Web Services binding. I see the AtomPub Binding more as a way to stop a WS-* v ReST war from breaking out in the committee. I wasn’t involved in the discussions, so I can only guess.

      As for extensibility…some things, not going to argue which ones at this time, should be standard and not extensions. Extensibility is important, critical even, but not everything should be an extension.

      Like

      • Julian Reschke says:

        As for extensibility…some things, not going to argue which ones at this time, should be standard and not extensions. Extensibility is important, critical even, but not everything should be an extension.

        I didn’t say that everything should be an extension.

        Also, just because something is an extension doesn’t mean it can’t be a standard. For instance, both AtomPub and WebDAV (Proposed Standards) extend HTTP/1.1 (Draft Standard). Also, WebDAV Versioning and WevDAV ACL extend WebDAV.

        So, an extension to WebDAV that would defined a document type model would be an extension to WebDAV (using one or more of WebDAV’s extensibility points), but could become itself a standard.

        More clearer now?

        Like

      • Thanks for the clarification, but I stand by my statement. Not everything should be an extension. Not ready to start making any determinations at this point though. I just want CMIS 1.0 out the door.

        Like

  4. Thank you for the interesting sum up on CMIS. I think that it is interesting, mostly by the industry momentum that it has but I think that again Microsoft will make it or break it. With such a stronghold on the desktop and content production, it is their commitment to this standard that will make the difference to the previous approaches in this area (thinking of previous iECM standards). For me the real test for CMIS will be to be able to integrate on “lightweight” platforms, such as Javascript clients and legacy servers. If this technology can stretch this far this would be a real disruptive technology, otherwise it would just become another difficult-to-implement and less used standard.

    One of the nicer ideas in the JCR (JSR-283) standards, early on was the idea of having “levels” of compliance. This offered a way to still adhere to the standard, at least in the most important aspects, and be able to gradually integrate the more complex parts. CMIS has some similarities in this approach but they still would need refining.

    Anyway, it is promising to say the least, and will be very interesting to develop with.

    Like

    • I agree with your assessment on Microsoft. I talked about Vendor Support in more detail back in September, and the importance of SharePoint to CMIS in February.

      Levels of compliance is good and I would understand if vendors supported one binding only. I would prefer it be the Web Services binding though as that is where the larger gap in the IT infrastructure is located.

      Like

  5. Thanks for the update!

    I haven’t been as active as I’d like in the whole CMIS analysis space… so I’m glad you have been!

    Like

  6. Regarding CMIS-54, the actual resolution is that the MIME type is optional. The reason for this is that some existing repositories (or simply filesystems) don’t have a way of knowing a MIME type for the files they store, and the HTTP spec (for one) is very clear that it’s a no-no to invent a MIME type for a file if you don’t know it. Better serve it without any MIME type than invent one.

    Regarding transactions, they can be supported by the SOAP protocol, using WS-Transaction. No need to add them to the domain model.

    For policies, I’d rather have some actual interoperability using simple ACLs than no interoperability using vague policies. Policies are so abstract anyway that every vendor exposing them would have to provide extensions. That’s not interoperability really.

    Also I wish people stopped pitting WebDAV *against* CMIS. One is a wire protocol extending HTTP, the other one is a domain model with several protocols to implement it. If WebDAV folks want to provide the required spec to implement the CMIS model, they’re actually very welcome, the CMIS TC will support them, and maybe WebDAV will be a third available protocol in CMIS 2.

    Finally, having several levels of compliance is something the CMIS TC really wants to avoid if possible, as it would to lead to lots of headache for implementors (especially clients). Levels of compliance means that consensus was not reached on what’s the common ground between vendors. We may end up with having 3 levels for ACLs, as a necessity, but having them for the core domain model would be a step backwards.

    Like

    • Florent, thanks for the comments. My thoughts on the levels is specific to binding support. I’d rather have the entire binding or none of the binding. As mentioned before, my Policy thoughts will have to come later after I ponder it in more detail.

      As for WS-Transactions, the support needs to be provided by the CMIS implementation. The CMIS standard could just say that they need to be supported and that would be a good step. I have two scenarios for Transactions which I’ll be sharing shortly. All this client work keeps distracting me.

      Like

      • Actually some of the “core” vendors have repositories that cannot support transactions, and they objected to having them put in the standard… In the spirit of “common ground”, transactions are therefore not there.

        If the standard says that they SHOULD be supported but doesn’t not specify how, I’m not sure it’ll help. It’s all up to the protocols implementations.

        Like

      • This is something that I feel is more 2.0 anyway. I am waiting for CMIS 1.0 before I start railing for Transactions.

        I have situations that need Transactions, but I understand that it is an more complicated feature. It is more focused on the situation when you are linking into a repository from a system, like a Case Management system, where several actions have to take place and if any of them fail, roll them back.

        Like

  7. Walter says:

    From reading the reviewer’s notes in the 0.6 Word doc, it looks like policies are going to be struck from the spec (every time policy is mentioned, there’s a note that says something like “TODO: remove this when we remove/kill policies”). Unless maybe that’s just one anti-policy reviewer’s wishful thinking/hinting.

    Like

Comments are closed.