Latest Posts

Archives [+]

Déjà-vu: JCR vs. Atom? JCR loves Atom.

There has been a bit of discussion about JCR and Atom in the blogosphere this week. Things got started by Adrian Sutton's post "Atom Is The New JCR", then there was Dan Diephouse ("Atom has not replaced JCR it has supplemented it"), then Sam Ruby wrote (1 line) about it.

These posts reminded me of the time 5 years ago. Back then, people started just about every discussion around JCR with the question "We have WebDAV, why do we need JCR?"to the point where I would include the slides onthe relationship between JCR and WebDAV to preemptthe questioning. Luckily it worked, after a coupleof months the whole debate was gone...

...the good news is, what applied to the relationbetween JCR and WebDAV also applies to the relationbetween JCR and Atom. And I get to recycle my slides ;)

I should mention that I see Atom Publishing Protocol (which I will refer to as "Atom" throughout this post) as a simplified version (probably for the right reasons) of WebDAV & related specifications (which I will refer to as "WebDAV" throughout this post).

So, let's look at some aspects of how Atom and JCR are related:

1. Master of the obvious.

  1. JCR is an API, Atom is a protocol.
    We need both an API and a protocol. Nobody would argue the needfor the Servlet API, on the basis of the existence of the HTTP protocol.
  2. Functional goals.
    As mentioned I think that Atom is can be compared to WebDAV.Both are protocols, both are REST-ish XML over HTTP.
    However from a functional perspective WebDAV is much broaderthan Atom and JCR goes even beyond that.

    Features Atom WebDAV JCR
    Read x x x
    Write x x x
    Query   x x
    Fulltext Search   x x
    Access Control   x x
    Workspace Mgmt   x x
    Versioning   x x
    Locking   x x
    Observation     x
    Transactions     x
    Retention & RM     x

The above table doesn't mean that Atom is inferior to JCR - they just have different goals and scopes. The simplicity of Atom is great, and itsextensibility prevents you from being too constrained when exchanging content. But JCR has a different focus, and so does WebDAV.

2. "Content Silos" and Integration

JCR provides standards based integration, that allowsto implement a minimal (sub)set of features and still covera large set of applications. JCR calls this "Level 1 compliance".

In the JCR expert group we had a long discussion on what featuresshould go into "Level 1" to be able to enable as manysmall and simple applications as possible, and we choseRead & Search.

I am convinced that if you are integrating into a thirdparty repository search is very important. I completelyunderstand why search is not specified in Atom. It isa very painful process to get various vendors to agree on query syntax and semantics.

3. Content Repositories are Application Development Infrastructure.

JCR also provides infrastructure for application developersthat need features like access control, full-fledged versioning, fulltext search or just simply be able to deal efficiently with large streamed binaries or an arbitrarily sized hierarchy of information.

I personally tend to compare Content Repositories to RelationalDatabases or Filesystems.

4. Atom + JCR.

Apache Jackrabbit for a long time exposed a WebDAV server. A general purpose Filesystem based WebDAV access anda complete remoting of the JCR API through WebDAV.Judging on the great deal of interest in broader Jackrabbit community I am convinced that it will be a matter of weeks until we see an Atom layer on top of JCR.

The fact that people already built a backing store for Apache Abdera (Apache's Atom "Server") using JCR (Apache Jackrabbit)very much shows that clearly it is JCR + Atom not JCR vs. Atom.

I think Atom and JCR are a very natural fit and a Atom over JCR implementationmakes a lot of sense as part of an Apache Project, be it a partof Abdera, Jackrabbit or even Sling

 

COMMENTS

  • By Michael Marth - 11:17 AM on Jan 19, 2008   Reply
    Just saw Adrian Sutton has also <a href=""http://www.symphonious.net/2008/01/18/how-atom-and-jcr-work-together/>posted on the topic again</a>.
  • By David Nuescheler - 4:38 PM on Jan 22, 2008   Reply
    And James Snell's comment:
    <a href="http://www.snellspace.com/wp/?p=859">http://www.snellspace.com/wp/?p=859</a>
  • By Jacco van Weert - 8:21 AM on Jan 23, 2008   Reply
    The JeCARS project (http://jecars.sourceforge.net) uses Jackrabbit as JCR backend to create a Atom/APP (GData) compatible server.<br/>

  • By Adrian Sutton - 10:53 PM on Jan 26, 2008   Reply
    I love the interest this discussion has spurred. Some really good thoughts here and in other posts about why the variety of APIs and protocols is a good thing. As my second topic more clearly highlights, I think there is a lot of value in both JCR and Atom. The elevator pitch I'd use to differentiate them would be "JCR for local storage, Atom is remote access". My original post was really just an off the cuff observation so I'm very glad others have filled in the details.<br/>
    It's interesting to add WebDAV into the mix. Looking back, I suppose JCR was the new WebDAV when it first came out. What Atom particularly needs to avoid is keeping the momentum going and having compatible implementations for pretty much everything. The real problem with JCR and WebDAV isn't to do with the standards themselves, but the actual level of real, compatible support they've received.
  • By David Nuescheler - 3:23 PM on Jan 30, 2008   Reply
    Hi Adrian,<br/><br/><br/>
    Thanks a lot for commenting. I am very excited about all the good discussions that have been triggered by your initial blog post.<br/>
    <br/>
    I certainly agree that Atom offers a great way to access collections remotely through its features as an http protocol.<br/>
    <br />
    I also agree that JCR offers the ability to work locally (in the same process). JCR as an API though in my mind does not specify a remoting layer or a transport protocol. This is similar to let's say JDBC.<br/><br />

    My take on "X is the new Y", would be "Atom is the new WebDAV" ;)<br /><br />

    I am quite happy with the <a href="http://dev.day.com/microsling/content/blogs/main/jcr-consolidation.html">Adoption of JCR and also with the consolidation it drives</a> and I see that momentum around JCR is steadily growing<br /><br />

    I think that one of the notable features of JCR is that if you are in the process of building a Content Application like a CMS or DMS (or an Atom Server ;)) choosing a JCR backend like <a href="http://jackrabbit.apache.org">Jackrabbit</a> or <a href="http://www.day.com/crx">CRX</a> provides you with all the features that your application may need.<br>
    I think this is what you eluded to in one of your posts as "JCR being the implementation".<br/><br/>

    I fully agree, that Atom is a great lightweight way to exchange information between different applications over HTTP, and particularly in cases where only read and write of simple collections is required it is the perfect candidate, no doubt.<br><br>
    Thanks again, for kickstarting all the discussions.<br>

  • By Jacco van Weert - 9:17 AM on Feb 11, 2008   Reply
    Hello David,<br/><br/><br/><br/>We keep an eye on Abdera, we are now considering solutions for a JeCARS Java client library. There are a number of off the shelf solutions, Abdera, GData-client and Rome.<br/><br/><br/><br/>We use Atom/GData just as specification to work with (for Abdere Atom is a goal), our primary goal for JeCARS is to become integrator for "normal" Java applications.<br/><br/><br/><br/>Large file transfers are an issue not well handled in Atom/APP.<br/><br/><br/><br/>
  • By Jacco van Weert - 9:45 AM on Feb 11, 2008   Reply
    <br/><br/>>...and what do you think of this >discussion?<br/><br/><br/><br/>About this discussion (the mapping of JCR properties directly on Atom items).<br/><br/><br/><br/>In JeCARS every node is a jecars:root node;<br/><br/><br/><br/>[jecars:root] > nt:hierarchyNode<br/><br/>- jecars:Published (Date)<br/><br/>- jecars:Modified (Date)<br/><br/>- jecars:ExpireDate (Date)<br/><br/>- jecars:LastAccessed (Date)<br/><br/>- jecars:Title (String)<br/><br/>- jecars:Body (String)<br/><br/>- jecars:Id (Long)<br/><br/>+ * (jecars:permissionable)<br/><br/><br/><br/>The mapping of the properties is done in code... e.g.;<br/><br/><br/><br/>For the "atom publishing date" the "jecars:Published" is used if this property is not filled in the "jcr:created" is checked.<br/><br/><br/><br/>You are right that that we needed to use the mixin's... in fact I think that (more extreme) we only have mixin's, and nodetypes are constructed using the mixin's.<br/><br/>However there is a conflict with with the "Relational" DB world.<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>