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.
- 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. - 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
http://www.snellspace.com/wp/?p=859
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.
Thanks a lot for commenting. I am very excited about all the good discussions that have been triggered by your initial blog post.
I certainly agree that Atom offers a great way to access collections remotely through its features as an http protocol.
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.
My take on "X is the new Y", would be "Atom is the new WebDAV" ;)
I am quite happy with the Adoption of JCR and also with the consolidation it drives and I see that momentum around JCR is steadily growing
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 Jackrabbit or CRX provides you with all the features that your application may need.
I think this is what you eluded to in one of your posts as "JCR being the implementation".
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.
Thanks again, for kickstarting all the discussions.
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.
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.
Large file transfers are an issue not well handled in Atom/APP.
>...and what do you think of this >discussion?
About this discussion (the mapping of JCR properties directly on Atom items).
In JeCARS every node is a jecars:root node;
[jecars:root] > nt:hierarchyNode
- jecars:Published (Date)
- jecars:Modified (Date)
- jecars:ExpireDate (Date)
- jecars:LastAccessed (Date)
- jecars:Title (String)
- jecars:Body (String)
- jecars:Id (Long)
+ * (jecars:permissionable)
The mapping of the properties is done in code... e.g.;
For the "atom publishing date" the "jecars:Published" is used if this property is not filled in the "jcr:created" is checked.
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.
However there is a conflict with with the "Relational" DB world.
thanks for the update, this all sounds excellent.
Have you seen the additional properties defined in public review of jsr-283? Do you think it might make sense to use those... I am somewhat torn between using standard properties for better interop and using app:prefixed properties to make it more homogeneous for the app developer... what do you think?
thanks for the update, this all sounds excellent.
Have you seen the additional properties defined in public review of jsr-283? Do you think it might make sense to use those... I am somewhat torn between using standard properties for better interop and using app:prefixed properties to make it more homogeneous for the app developer... what do you think?