David Nuescheler has published the slide deck he presented at the CMIS F2F in Redmond. Interesting bits about the relation of AtomPub and CMIS.

Apache Abdera is an Apache Software Foundation project to...

build a functionally-complete, high-performance implementation of the IETF Atom Syndication Format (RFC 4287) and Atom Publishing Protocol (RFC 5023) specifications.

(if reading RFCs is not your cup of tea: IBM developerworks has some good tutorials on AtomPub. Update: Julian Reschke pointed me to these HTML versions of the Publishing and Syndication spec which are quite a bit easier on the eyes).

The project has recently graduated from the incubator and is now a top level project at the ASF. Congratulations!

Since release 0.4 Abdera comes with a JCR adapter (JCR-loves-Atom, remember?). The JCR adapter allows you to run an Abdera AtomPub server and have a Jackrabbit repository be used for storage.

Getting it to run is quite easy: do a checkout of the 0.4 release at http://svn.apache.org/repos/asf/abdera/java/tags/abdera-0.4.0-incubating/ and built with

mvn clean install

This command will also execute the test cases in adapters/jcr/src/test/java/org/apache/abdera/jcr. As part of the test cases a JCR-backed Atom server gets started and some JCR nodes are created through Atom. The main magic happens in the JcrCollectionProvider class that maps the AtomPub elements onto JCR nodes. For example, AtomPub's ID is mapped onto JCR's UUID:

public String getId(Node entry) throws ResponseContextException {
 try {
  return "urn:" + entry.getUUID();
 } catch (RepositoryException e) {
  throw new ResponseContextException(500, e);
 }
}

Getting Abdera to interact with CRX

The primary purpose of the JcrCollectionAdapter class is to equip a stand-alone Atom server with a JCR repository for storage. However, with a bit of tweaking the class can also be used to provide an Atom interface to an existing CRX repository: a simple way to get things running is to leave the existing CRX Quickstart untouched and connect to the repository through RMI. RMI is disabled by default, but on CRX's Knowledge Base is an article how to enable it.

Abdera bundles Jetty which can be used to provide the http server for AtomPub. I have wrapped the JcrCollectionProvider in a little servlet and initialized Jetty with this servlet. The class looks like this:

import org.apache.jackrabbit.rmi.client.ClientRepositoryFactory;
import javax.jcr.Repository;
import javax.jcr.Session;
import javax.jcr.SimpleCredentials;
import javax.servlet.http.HttpServlet;
import org.apache.abdera.protocol.server.Provider;
import org.apache.abdera.protocol.server.impl.DefaultProvider;
import org.apache.abdera.protocol.server.impl.SimpleWorkspaceInfo;
import org.apache.abdera.protocol.server.servlet.AbderaServlet;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.servlet.Context;
import org.mortbay.jetty.servlet.ServletHolder;

public class AppServer {

 public static void main(String... args) throws Exception {
  int port = 9002;
  try {
   port = args.length > 0 ? Integer.parseInt(args[0]) : 9002;
  } catch (Exception e) {
  }
  Server server = new Server(port);
  Context context = new Context(server, "/", Context.SESSIONS);
  ServletHolder servletHolder = new ServletHolder(new
  JcrCollectionServlet());
  context.addServlet(servletHolder, "/*");
  server.start();
  server.join();
 }

 public static final class JcrCollectionServlet extends AbderaServlet {
  protected Provider createProvider() {

   DefaultProvider jcrProvider = new DefaultProvider();

   try {

    ClientRepositoryFactory factory = new ClientRepositoryFactory();
    Repository repository = factory.getRepository("//localhost:1234/crx");

    JcrCollectionAdapter cp = new JcrCollectionAdapter();
    cp.setTitle("My Entries");
    cp.setAuthor("Apache Abdera");
    cp.setCollectionNodePath("entries");
    cp.setRepository(repository);
    cp.setCredentials(new SimpleCredentials("admin", "admin".toCharArray()));
    cp.setHref("feed");
    cp.initialize();

    SimpleWorkspaceInfo wkspc = new SimpleWorkspaceInfo();
    wkspc.setTitle("JCR Workspace");
    wkspc.addCollection(cp);
    jcrProvider.addWorkspace(wkspc);
    jcrProvider.init(getAbdera(), getProperties(getServletConfig()));
   } catch (Exception e) {
    return null;
   }
   return jcrProvider;
  }
 }
}

Please note that the servlet just needs to acquire the JCR and pass a reference to it to the JcrCollectionProvider. Thus, this approach can be used with JNDI or other means of connection as well and is not specific to RMI. Before you run the server you will have to perform a little tweak in the JcrCollectionProvider: when the provider is started it will try to register a new node type. AFAIK this does not work via RMI (I might be wrong, though), so I commented this code in the initialize() method :

//JackrabbitNodeTypeManager jntmgr = (JackrabbitNodeTypeManager) workspace.getNodeTypeManager();
//if (!jntmgr.hasNodeType("abdera:entry")) {
 //InputStream in = getClass().getResourceAsStream("/org/apache/abdera/jcr/nodeTypes.xml");
 //try {
  //jntmgr.registerNodeTypes(in, JackrabbitNodeTypeManager.TEXT_XML);
 //} finally {
  //in.close();
 //}
//}

and manually added the the namespace abdera="http://abdera.apache.org" and the node type "abdera:entry" defined in adapters/jcr/src/main/resources/org/apache/abdera/jcr/nodeTypes.xml to CRX (find a link to the node type manager that provides a UI for registering namespaces and node types at http://localhost:7402/crx). The JcrCollectionProvider will use its specific node type abdera:entry to store and retrieve data.

After you have defined abdera:entry run the AtomPub server main class from above and find your Atom interface at http://localhost:9002/feed (make sure to include the CRX RMI jars from crx-quickstart/server/runtime/0/_crx/WEB-INF/lib on your classpath). You create nodes via curl (see here for an example) or (more or less convenient, depending on your taste) via the AbderaClient class like this code below. It creates a new post with some example data:

import java.util.Date;
import javax.jcr.Repository;
import org.apache.abdera.Abdera;
import org.apache.abdera.factory.Factory;
import org.apache.abdera.i18n.iri.IRI;
import org.apache.abdera.model.Entry;
import org.apache.abdera.protocol.client.AbderaClient;
import org.apache.abdera.protocol.client.RequestOptions;
import org.apache.abdera.protocol.server.impl.DefaultProvider;

// this code is taken from Dan Diephous's
// test classes for the JcrCollectionProvider 
public class AppServerTest {

 private DefaultProvider jcrProvider;
 private Repository repository;

 public static void main(String... args) throws Exception {
  Abdera abdera = new Abdera();
  Factory factory = abdera.getFactory();

  AbderaClient client = new AbderaClient(abdera);

  String base = "http://localhost:9002/";

  // Testing of entry creation
  IRI colUri = new IRI(base).resolve("feed");
  Entry entry = factory.newEntry();
  entry.setTitle("Some Entry");
  entry.setUpdated(new Date());
  entry.addAuthor("Dan Diephouse"); // thanks, for the provider, Dan!
  entry.setId(factory.newUuidUri());
  entry.setSummary("This is my entry.");
  entry.setContent("This is my entry. It's swell.");

  RequestOptions opts = new RequestOptions();
  opts.setContentType("application/atom+xml;type=entry");
  ClientResponse res = client.post(colUri.toString(), entry, opts);
 }
}

(the example is taken from Dan Diephouse's test classes for the JcrCollectionProvider)

This might be your first step if you want to offer an AtomPub interface to your CRX repository. However, it is likely that you will have to tweak the JcrCollectionProvider class a bit more: the crucial part is the mapping between JCR nodes and AtomPub elements. As discussed above the out-of-the-box JcrCollectionProvider can only deal with nodes of type abdera:entry. However, this will not suffice to Atom-enable an existing application, the mapping needs to fit to your specific application's node types.

Somewhat related to AtomPub and JCR: Apache Jackrabbit is expected to support CMIS in the future (which includes an AtomPub binding). Work has started on this and there is some initial code in the sandbox.

Mule Galaxy 1.0 has been released 2 days ago. It is (in their own words)...

an open source governance platform with an integrated registry/repository. It includes versioning, lifecycle management, dependency management and policy enforcement features which enable you to effectively govern your applications and services

Galaxy uses JCR (Apache Jackrabbit) internally and Atom Publishing Protocol for custom integrations. As such it constitutes a nice example for JCR and APP complementing each other.

Another comment that is only slightly related: I just came across Galaxy developer Dan Diephouse's presentations on Effective RESTful services and AtomPub. Excellent stuff (and slide 40 of the first one made me lol).

JBoss has started a new project called DNA. As far as I understand it DNA is a new implementation of the concepts of the MetaMatrix software they bought last year. They describe it as:

a repository and set of tools that make it easy to capture, version, analyze, and understand the fundamental building blocks of information

Take a look at the architecture diagram of DNA. There are a number of interesting aspects on this project:

• DNA uses Java Content Repositories for information storage
  
  

  JBoss DNA manages its information in JCR repositories

  I could not find any information about the actual implementation that is used, though.
• More important, in DNA JCR is also seen as an API to all other sorts of existing content:
  
  

  Integrate multiple JCR repositories. Use relational databases. Access applications and services. JBoss DNA can federate and integration information from multiple JCR repositories, external databases, applications and services - all in real time without having to make copies.

  This is very much in line with the original vision of JSR-170: "JCR the API" is more important than "JCR the implementation". It is also very similar to the"everything is content" vision Day has been sharing for a very long time.
• One last aspect I want to mention is displayed in the upper part of the architecture diagram: access to the repository is possible through HTTP, REST and ATOM (as well as JDBC!). The JCR-ATOM love affair seems to have a new offspring.

It looks to me that this project might produce pieces of infrastructure that are useful far beyond the use case the project currently targets.

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