uri: http://dev.day.com/microsling/content/blogs/main/jcr-loves-atom.html
posted 18 January 2008 by David Nuescheler
filed under jcr jsr-170 jsr-283 atom atompub webdav
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 on the relationship between JCR and WebDAV to preempt the questioning. Luckily it worked, after a couple of months the whole debate was gone...
...the good news is, what applied to the relation between JCR and WebDAV also applies to the relation between 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:
JCR is an API, Atom is a protocol.
We need both an API and a protocol. Nobody would argue the need
for 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 broader
than 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 its extensibility prevents you from being too constrained when exchanging content. But JCR has a different focus, and so does WebDAV.
JCR provides standards based integration, that allows to implement a minimal (sub)set of features and still cover a large set of applications. JCR calls this "Level 1 compliance".
In the JCR expert group we had a long discussion on what features should go into "Level 1" to be able to enable as many small and simple applications as possible, and we chose Read & Search.
I am convinced that if you are integrating into a third party repository search is very important. I completely understand why search is not specified in Atom. It is a very painful process to get various vendors to agree on query syntax and semantics.
JCR also provides infrastructure for application developers that 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 Relational Databases or Filesystems.
Apache Jackrabbit for a long time exposed a WebDAV server. A general purpose Filesystem based WebDAV access and a 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 implementation makes a lot of sense as part of an Apache Project, be it a part of Abdera, Jackrabbit or even Sling