ECM Standards War: Bye Bye JSR170, Hello CMIS!

I've been wanting to talk about this for a while... but I was under a NDA... but now I can FINALLY tap-dance on the grave of that awful JSR170 standard... and only mere months after Oracle released their adapter. Sorry Dave...

CMS Watch is now reporting the on yet another ECM standard, this one named the Content Management Interoperability Services specification, or CMIS for short. Oracle is a member of the community that is helping design this spec, and I have high hopes for it... unlike the prior ones.

I never liked the JCR specs (JSR 170 and JSR 283). Firstly, the world doesn't need a Java based content management spec. That's just plain stupid. Any spec that by design omits SharePoint will be a non-starter. Also, the whole JCR stuff is an API spec. We don't need an API spec: we need a protocol spec.

That's where CMIS comes it. Its a REST-ful protocol for getting at your data, and changing individual resources... but it also comes with JSON and SOAP fused in there a bit... cuz frankly, we need the extra oomph.

At its heart is the Atom Publishing Protocol. Now... I have some issues with this, because I feel APP isn't robust enough for large scale syndication. There simply is no guarantee of quality of service when you're using "feeds", and polling-based architectures simply don't scale to thousands of enterprise applications. That's the dirty little secret that ReST fanboys don't want you to find out...

Many folks in the open source community have already noticed this, and advocate using the instant messaging protocol XMPP (aka Jabber) to "wrap" restful web services in a bundle. That's the best of both worlds: a simple protocol that's easy to understand, but with a wrapper that can guarantee your published document actually got to where it was supposed to go... Others advocate that enterprises should use a more proven general-purpose messaging protocol like Apache ActiveMQ, instead of the IM-centric Jabber one.

In any case, the CMIS standard is only at version 0.5. Early adopters will notice issues, and the spec will have to evolve to meet the performance and quality concerns... CMIS alone would be great for making lightweight mashups... but I anticipate the ActiveMQ qrapper will become a standard best-practice for heavy duty publishing and syndication.

I promise to have more on this stuff later...

comments

CMIS is trying to cover all bases

I think inclusion of both REST/ATOM/JSON and WS/SOAP is complementary. RESTful part of the specification represents design for consumption while SOAP/WS* part is integration/process centric. In other words, if you are concerned with things like quality of service or reliable deliver just use WS/SOAP instead of trying to tweak REST. If your focus is on consumption and ease of use REST is the way to go and ATOM/JSON are you data format options.

CMIS vs. JCR, and Atom

Nice blog. Thanks for referencing my writeup at CMS Watch. I agree with most of what you're saying here. However, I think concerns over "polling" are orthogonal. Atom Publishing Protocol (not Atom Syndication) is being used in CMIS strictly in a content-interchange-semantics context. There is no notion of creating feeds. The CMIS specs aren't about feeds any more than JSR 170 is. Apache Sling could have used APP for REST enablement, but didn't. No matter. It wouldn't have led to polling there either. ;^)

So, no big disagreement with you (in fact, if CMIS+APP is going to be used in a way that causes polling, I'm on your side totally). I just think there's really no connection between how CMIS leverages APP, and "feeds" per se. This is not about feeds and polling, I don't think. I sure hope not.

CMIS/REST and Polling

Good post. The CMIS/REST binding and the way the services are currently defined always return an answer if the TCP/IP protocol does not break on you for some reason. As such, CMIS does not have enable or encourage the pattern of polling.

Now, if a CMIS client wants to continually poll a folder or the results of a query, that could lead to performance issues on the server. That is the clients design (unfortunately).

Good post, though and I agree completely with the protocol message. Its why we focused on protocols instead of languages.

Andrei, you hit it right on the head. Use SOAP WS if you need what it provides. Use REST for ease of use, combining apps on the glass.

I do think there is a place for JCR for those that want to use it, and JCR and CMIS should be complimentary as some of the use cases over lap and it is easy to see how a subset of the JCR api could be on top of CMIS transport if desired.

client polling is kind of the problem...

like Al said... supporting APP means supporting "stupid clients" that might keep polling a folder, re-running a query, looking for content.

For ease of use, APP is a great idea. I just think that if people use this for "real" enterprise-wide content management, you're talking about thousands, maybe hundreds of thousands of clients. I'm not just thinking web portals or enterprise applications, but also direct syndication to people's desktops.

You don't want to do that with a synchronous protocol...

Backend Feature

JSR/JCR does limit us to using java for the most part. I have not really played with this that much yet but the mere fact of this implementation being platform agnostic is either not the whole story or certainly not winning me over. Web services already granted us this feature for the most part. The fact that these implementations act like interfaces allowing us to switch out backend solutions with little to no code changes makes the solution different from the platform independence granted by web services.

So I guess my question is: does CMIS offer us anything to allow us to access content management platform unique features? Obviously making use of content management platform special features more or less means we have lost the ability to switch out backend platforms with little to no changes. However, most of us will still need to use some of these platform specific features. I mean we probably bought that platform because of the feature differentiation selling performed by the vendor. I bought it because it can do feature and feature versus other solutions. If CMIS does not provide an avenue to access platform specific features I will be stuck using something like web services integration again. So now I will be using two methods to talk to my content server. This does not seem to be heading in the right direction. Again, my ignorance about CMIS may be showing.

re: Backend Feature

Generic protocols and APIs are, by definition, designed to abstract away platform dependencies, so you shouldn't expect JCR or CMIS or Sling to address "platform unique features" -- that's out of scope. I think that from a client-empowerment point of view, things like JCR and CMIS are intended to address the 80-percent case: basic CRUD and Query. (To say nothing of versioning and some of the other things JCR addresses.) I don't think JCR or CMIS are *intended* to enable the highly specific sorts of functionality that comprise the value-adds that let big vendors charge big bucks. Although: I hasten to add that over time, I strongly suspect the authors of CMIS will build out the spec to cover more and more surface area, possibly to include platform extensions and esoteric functionalities of various kinds.

Standards for a purpose

Every standard is design with a set of objectives and constraints in mind. JCR is still relevant for it's intended use and audience.
One thing I observe is that open source ECM vendors are building in more ways to access their repository. I can see that open source ECM vendors will support various standard ways of accessing the repository.

re: Backend Feature, Standards for a purpose

I agree with Kas and Hoi.

What I would like to add to this thread is that JCR comes from Java, and as such focuses on the language (I mean API) aspect. EMC is an entity that focuses on ECM per se, so it is much more appropriate for it/them to devise a protocol spec. Both are complimentary, not contradictory.

nice article.

Very nice article.
thanks

Try a live CMIS pilot

Good point. We work with .NET, and we would not have ever thought to implement the JSR170 or any other JAVA standard. Making a standard without Microsoft, no matter if you like them or not, is "plain stupid". But a protocol with which .NET apps can work seamlessly, is more than welcome, it is badly needed. But CMIS came, and our coders wanted to do it, they worked through the weekend to come up with a draft implementation, a pilot that works and can be shown around. If this CMIS becomes a reality, and companies implement it, we clould finally work with Sharepoint and other CMS-es. And it is very easy to implement, at least the basic get and list functions are trivial. If you want to try a real working implementation, go to my blog and follow the link.

great post

"We don't need an API spec: we need a protocol spec." Absolutely right!

-Eugene

Recent comments