JBoss DNA, Revisited

I decided to take another look at JBoss DNA the other day, and it turned out to be quite a surprise.

It seems that the focus has been refined, and the vision clarified.

The first time I looked at it, DNA was not a repository. Rather it was something that could federate multiple content stores (e.g. – repository/database/file system). I just wasn’t sure what that something was. I believe that is what led me to question how practical it was.

Now, DNA is a repository. However, with this particular repository you can access multiple content stores via the JCR API.

In my first post on DNA I mentioned two JIRA issues: DNA-55 (RESTful API) and DNA-46 (JCR Implementation). They were supporting features. Now, they are defining features.

The one thing that hasn’t changed is that I still see the value in DNA. I still like the idea of federated repositories. That, and I really like the JCR API.

So, what is the big deal?

First, the ability to access content outside the repository via the JCR API.

Second, the ability to apply JCR functionality (search, versioning, etc.) to content outside the repository.

Third, the ability to federate multiple content stores. Here are a few scenarios where I think this might be practical.

• SVN & File System – The source code may be in a SVN repository, but the build artifacts are on a file system.
• JCR & File System – I’ve worked with a number of clients who maintain their binaries on a file system, but maintain the metadata in a repository (JCR).
• Database (Metadata) & Database (Metadata) – How about comparing the schemas of multiple databases?

There are a few issues though…

According to the reference documentation, DNA is lacking a JCR connector. To me, this is a sore spot. I just described a possible JCR/file system pairing above, but at the moment the repository would have to be a DNA repository.

The database connector is only for metadata, as I just described. That may be a bit limiting. I would like to have added this pairing: Database (Content) & JBoss Cache/Infinispan. Wouldn’t it be nice to compare what is cached with what has been persisted?

The file system/SVN connectors are read-only. A little disappointing. The scenarios I described are now useful only for reporting. It would be nice to be able to use DNA to persist content to the file system and metadata to a repository.

It appears that the JBoss Cache/Infinispan connectors are really just persistence options for DNA repositories. I’m not sure that they can be used to access content that has been cached outside the context of DNA. Though I could be wrong.

Now I’m left wondering, does DNA have any disk based persistence options? Perhaps it is not via a connector. I didn’t see anything in the reference documentation regarding this point.

Also, a number or rather important JCR features are still missing: queries, observation, and locking. That significantly diminishes my second point above (applying JCR functionality to content outside the repository).

Note: If observation is available as part of the Graph API, why is it not yet available as part of the JCR implementation?

That being said, DNA is still in the early stages of development. I suspect some of these issues may be addressed before the 1.0 release. I still think it is pretty neat even with the limited connectors currently available.

There is one aspect that is particularly interesting. The JBoss Cache/Infinispan connectors. I’ve always thought it would be cool to be able to persist a repository to a distributed data grid/cache. As far as I know, there are no such persistence managers for Jackrabbit. I wonder how much emphasis JBoss is going to place on these connectors. Personally, I think they could be defining features.

That brings me to one last concern. How is JBoss going to market DNA?

Part of me wonders if the JCR implementation shouldn’t be separated and treated as its own project. Then place a great deal of emphasis on the fact that the content can be persisted to a distributed data grid/cache. It could now be treated as a direct competitor to Jackrabbit and offer a distinguishing feature. Finally, allow DNA to focus purely on the federation aspect and the ability to use the JCR API to access content outside of repositories.

We’ll just have to see what the 1.0 release bring us. I’m looking forward to it.

So until next time, good fight, good night.