On the CQ5 tour stop in Milan I had the pleasure to talk about CMIS and JCR for the first time since I am serving as the official JCR / CMIS Liaison.

This brought the opportunity to compare and differentiate the two efforts for with a unique legitimacy. There seems to be a desire to discuss the relationship between CMIS and JCR similar to the desire to discuss JCR and WebDAV or, more recently, JCR and Atom. So far, JCR and CMIS have been compared in what I would call "a less educated fashion" for example in the CMIS v0.5 spec draft. Most of those comparisons have been corrected in the meantime.

Feel free to view the entire slideshow here, but here are the main points:

API vs. Protocol

JCR specifies an API (Application Programming Interface) while CMIS specifies two protocol bindings. Much like the Servlet API in Java and the HTTP protocol are complementary this is also the case for JCR and CMIS. Similar arguments have been made for Atom and WebDAV. JCR and CMIS are complimetary in this aspect.

Focused Model vs. Generally Applicable Model

JCR specifies a very general model based Node and Properties that lends itself to the implementation of specific domain models. On the hand, CMIS specifies such a specific domain model for document management.

The CMIS domain model can easily be implemented in a JCR model (see next point). Some people could say that if one were to implement CMIS from scratch a JCR repository would be the ideal starting point as it provides the perfect infrastructure to do that.

I think it is one of the most important assets of CMIS that it exposes the domain model of document management. It will be helpful in further standard discussions to have an established consensus on the domain model amongst the document management vendors.

Every JCR repository is a CMIS repository

Based on this type of compatibility between CMIS and JCR Apache Chemistry (currently in incubation) implements CMIS on top of JCR (amongst other things). This turns every JCR compliant repository into a CMIS compliant repository without any development effort. Even better news are that Chemistry gets bootstrapped with numerous existing JCR repositories and connectors. These repositories can thus expose CMIS right from the start.

Interop vs. Infrastructure

Something that I learned during the years of specifying JCR: There is always a tension in a specification to address both "interop" and "infrastructure" needs. Interop enables different repositories to be compatible on some level, whereas infrastructure provides users with a platform to build upon.

There were tendencies in the JCR expert group to support users of the API in a way that they could build real-life applications. Hence, the infrastructure aspect was always a very important aspect. Because of that, the least common denominator aspects that come with "interop" were only a part of the equation.

For CMIS, offering general purpose infrastructure is a stated non-goal. CMIS is only concerned with "interop".

Consequently, JCR is very successful with the number of users and applications built on top of JCR, while I believe that it is the goal of CMIS to be very successful with number of implementations.

In terms of perception I think CMIS reduces the expectation on JCR to be a least common denominator interop spec. I welcome that because both specification efforts will be able to evolve in a more agile fashion when they focus on "interop" and "infrastructure" needs respectively.

In summary, I am very excited to have a specification both on the protocol and on the API level addressing the needs of a more open standards based content management landscape.

You might be aware that we are running a public instance of CRX (Day's JSR-170 compliant repository) at http://jcr.day.com (the login is admin/admin). As of today there is also the CMIS interface (Atom binding) to that repository publicly available at http://cmis.day.com. The underlying code is the version from the CMIS plugfest, but expect frequent updates. Feedback is appreciated (either as a comment on this post or to mmarth (at) day (dot) com).

Bringing Back the Fun - Reloaded

Apache Sling brings back the fun to Java developers and makes the life of a web developer much easier. It combines current state of the art technologies and methods like OSGi, REST, scripting, and JCR.

The main focus of Sling deals with the important task of bringing your content into the web and providing a plattform to manage/update the content in a REST style.

Sling is built into OSGi bundles and therefore benefits from all advantages of OSGi. On the development side a scripting layer (using Apache BSF) allows to use any scripting language with Sling (of course you can use plain old Java, too). And on top of this, Sling helps in developing an application in a RESTful way.

As the first web framework dedicated to JSR-170 Java Content Repositories, Sling makes it very simple to implement simple applications, while providing an enterprise-level framework for more complex applications. Underneath the covers Apache Jackrabbit is used for the repository implementation.

Download the new release, Apache Sling 5, today and give it a try!

Apache Sling currently comes in four flavors:

• A standalone application (a jar containing everything to get started with Sling)
• A web application (just drop this into your favorite web container)
• The full source package (interested in reading the source?)
• Maven Artifacts (available through the Apache Incubator Repository)

For more information, please visit the Apache Sling web site at http://incubator.apache.org/sling
or go directly to the download site at
http://incubator.apache.org/sling/site/downloads.cgi

The Apache Sling Community

Two noteworthy new items in the blogosphere:

1. The Jackalope project (a JCR implementation for PHP) I mentioned previously is now up to three team members - see their announcement and the enhanced project description on the Liip blog.
2. Aaron Zeckoski of the Sakai project has written a beginner's introduction to Apache Sling that takes a different approach than usual - rather than the RAD aspects of Sling it focuses on OSGi.

Along the way of implementing a Trackback feature on Apache Sling I stumbled across a few details that I would like to share. Maybe, it saves other Sling dabblers a minute or two.

Trackback is a specification developed by SixApart for pings commenting or referring across different websites. Wikipedia defines it like this:

Trackbacks are used primarily to facilitate communication between blogs; if a blogger writes a new entry commenting on, or referring to, an entry found at another blog, and both blogging tools support the TrackBack protocol, then the commenting blogger can notify the other blog with a "TrackBack ping"; the receiving blog will typically display summaries of, and links to, all the commenting entries below the original entry. This allows for conversations spanning several blogs that readers can easily follow.

Trackbacks work via http POSTs and require a specific response. For the latter reason Sling's DefaultPostServlet cannot be used, but a custom servlet must be implemented (this has the implicit benefit that further custom logic like sping detection can easily be placed in the servlet).

A good starting point for looking up how to implement your own Sling servlet is the test servlets in the Launchpad. The Maven plugin and annotation make it easy to specify for which node types, selectors, or extensions the servlet shall be invoked, e.g.:

/** Example/test Sling Servlet registered with two selectors
 * 
 * @scr.component immediate="true" metatype="no"
 * @scr.service interface="javax.servlet.Servlet"
 * 
 * @scr.property name="service.description" value="Default Query Servlet"
 * @scr.property name="service.vendor" value="The Apache Software Foundation"
 * 
 * Register this servlet for the default resource type and two selectors:
 * @scr.property name="sling.servlet.resourceTypes"
 *               value="sling/servlet/default"
 *               
 * @scr.property name="sling.servlet.selectors"
 *               values.1 = "TEST_SEL_1"
 *               values.2 = "TEST_SEL_2"
 *                
 * @scr.property name="sling.servlet.extensions"
 *               value = "txt"
*/

So, that is the easy part. However, here are the above-mentioned gotchas you should be aware of:

• For registering the servlet for the node type nt:unstrutured the corresponding annotation's value must be nt/unstructured (well, this is obvious from the example above, but I did not see it right away).
• When the method is POST extensions are ignored. Selectors work though.
• However, POSTs to mynode.myselector will not work. You need to POST to mynode.myselector.html (no matter what mime type you return). Therefore, you might want make sure that you explicitly set the response type: e.g. response.setContentType("text/xml")
• Last, if the Sling instance you happen to use is a CQ5 author system be aware that the default ACLs do not grant read access for anonymous users. Therefore, you need to add credentials to your POST in that case.

Just a quick announcement: I have added the mailing list of the Apache Chemistry project to the dev.day.com discussion groups (there is also the CMIS technical committee list). The Chemistry project proposal can be read here.

Here's a post-weekend round-up of content-centric news:

David Nuescheler has been awarded as "Star Spec Lead" for his work JSR-170 and JSR-283. He joins this year's other two Star Spec leads Ed Burns of Sun and Mike Milikich of Motorola.

The JBoss DNA project has released version 0.4. I wrote a bit about DNA before, but was not aware that they are implementing their own (level 2 compliant) JCR implementation. Moreover, the federated approach they take looks interesting to me.

Julian Wraith has posted experimental code to hook up the Tridion CMS with Day's CRX - essentially making it possible to use JCR as another storage option in Tridion next to file system and RDBMS.

More on last week's CMIS plugfest: Serge Huber, CTO of Jahia, has shared his impressions on day 1 and day 2 as well as posted videos of the CMIS client presentations.