JBoss DNA, Revisited
Wednesday, October 14th, 2009
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. The file system connector is read/write. While the SVN connector is currently read-only, work is currently in progress to add write capabilities. It would should 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.
One Response to “JBoss DNA, Revisited”
Leave a Reply
Pages
Calendar
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Oct | ||||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | |||
Shane:
Thanks for taking a look at JBoss DNA and publishing your thoughts. One thing to keep in mind is that JBoss DNA is not yet 1.0, because (as you mention) we’re still implementing the JCR features. We’re not far from releasing 0.7, which will have L1 & L2 support + queries + observation + locking. And the optional versioning feature will be the driver for the following release.
JBoss DNA is primarily a JCR implementation on top of a single connector. It’s just that you get to choose which connector to use. We’ve provided several (hopefully) useful connectors out of the box, including: one that federates using other connectors; a file system connector; an SVN connector; a transient in-memory connector; and three connectors that persist any content. Those last connectors don’t access existing content but instead act like a regular persistence store that stores any content in an Infinispan data grid, a JBoss Cache instance, or a JDBC database (using JPA/Hibernate). Oh, and despite the documentation, the file system connector actually is writable. (We’ll get those docs fixed soon!)
We do have plans for a JCR connector, and we’re working to make the SVN connector read+write. We’re always interested in new community members to help us with features and help write more connectors. But we hope it’s easy for any Java developer to write custom connectors, even if they don’t want to share them with others.
You’re also not the first to wonder about a connector to access content (and metadata) from existing databases. We’d love to see that as well, and it’s absolutely possible. The only question is whether that is always custom or whether we can come up with a reusable design that just works.
So, if you want, DNA can be used exactly like other siloed JCR repositories. Just configure one of the persisting connectors, and you’re good to go. Or, configure the file system or SVN connector, and use JCR to access your files. But, if you want your JCR repository to federate/unify content from multiple places, then configure connectors to all those sources plus a federated connector.