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.
This is the time of the year when we start seeing the “what’s going to be hot in Java this year” posts. Actually, I might be a little late. Anyways, there seems to be two kinds. The ones that focus on the very latest buzzwords (the bad) and the ones that focus on what is beginning to take hold or mature (the good). It is sort of like how I prefer to attend JavaOne every other year. One year is full of specifications, standards, and new frameworks. The next year is specification implementations and the maturing of the previous year’s frameworks. I’m hoping this will be a good one. I am trying to focus on technologies that are not necessarily new, but that are beginning to take hold. And to add a little spice, I’m not just listing the emerging technologies. I’m also listing those that I think will be in decline.
I’m surprised I didn’t come across this earlier. JBoss has a released a new federated repository system: DNA.
I’ve caught up with the getting started document and the reference guide, and I quite like what I see. First things first, DNA is itself not a JCR implementation (yet). Rather, it unifies one or more repositories and provides a single point of access via the JCR API. The repositories themselves may be JCR compliant, but do not have to be. DNA comes with a variety of connectors such as the JCR, JDBC, and SVN connectors.
I find this to be quite practical. I worked with a number of clients who had multiple repositories whether they be JCR or simple databases. I’ve seen an environment with FileNet, Day Communique, Alfresco, and a number or Oracle databases. I’ve seen another with Magnolia, Day CQ, and a number of Oracle databases. I could cetainly make use of a unified repository in these environments.
I like that DNA is not simply an application, but an extensible framework for developers. It takes advantage of a very modular/pluggable architecture that allows you to write your own connectors (to connect to various repositories), sequencers (to extract metadata from repository content), and more.
Lastly, I thought there were two particular JIRA tasks that I found interesting.
https://jira.jboss.org/jira/browse/DNA-55 (RESTful API)
https://jira.jboss.org/jira/browse/DNA-46 (JCR Implementation)
Those two should have a significant impact on just how practical DNA is.
So until next time, good fight, good night.
Here is a brief tutorial on how to setup and object content mapping with Jackrabbit (1.5) and Spring.
First things first, download this zip and import the source into your project. As mentioned in this post support for Jackrabbit OCM in Spring still hasn’t found a home. Thus you have to download the zip from the JIRA.
The source includes an updated JackrabbitSessionFactory that we are going to reference in our Spring configuration.
This week I integrated CQ with Amazon S3 via the JCR observation API and Mule.
First, the business need. The client was making extensive use of the CQ media library, and that is just fine. As media library assets are requested, they are cached on the web server(s). The issue at hand is file size and bandwidth. The client wanted to push the larger files to S3 to save on bandwidth, they also wanted to continue using the CQ authoring interface to manage media assets. Absolutely nothing wrong with that.
I’ve updated JC-Rest to include a few new services and have updated a few others. In addition to be able to return properties for a node, the nodes services can now return attributes (is locked, is checked out, etc) too. I’ve also added a few services for creating nodes, properties, and what not. Finally, I added a service to return the repository attributes.
The result is an updated JCR browser that displays the following:
I’m happy to announce the initial release of JC-Rest. This is an application that provides a set of RESTful services for accessing content in a JCR repository. These services can return XML, JSON, ATOM, or even HTML via custom FreeMarker templates.
http://code.google.com/p/jc-rest/
Back in June I wrote a post that talked about building RESTful services using CXF (JAX-RS), Spring, Spring Modules (JCR), and the JCR API. To sum it up, I was working with a client who was using CQ. It didn’t take long before several other applications all required access to the CQ content. Since CQ doesn’t provide an easy means to do this, I wrote a set of highly customized services to return the content. The services were written to meet the requirements of each individual client application that required specific content.
When all was said and done, I realized there was quite a bit of redundancy. Not only technically, but logically as well. I came to the conclusion that it would have been better to build a smaller set of abstract, generalized services. And then perhaps allow for some customization on top them. That is what led me to build JC-Rest.
So, I’ve been working on a RESTful application to expose content in CRX added by authors in CQ to other applications.
I’ve been using the SQL syntax. I suppose this is because my background includes data architecture and modeling. Yes, I have a black belt SQL Kung Fu. Now we are considering using the XPath syntax instead. I noticed that the JCR specification suggests that database backed repositories are limited in the number of efficient XPath queries they can support. The key word there for me was ‘efficient’. It also notes that, for database backed repositories, XPath queries are translated to SQL queries. So that got me thinking. Should I continue to use the SQL syntax and database backed repositories, or not? Actually, for maintenance purposes, I’ve already suggested that we move to the Tar persistence manager. I suppose I’ll switch to the XPath syntax then.
What do you think?
So until next time, good fight, good night.
I’ve been working with CQ for the last few years. I’ve been working directly with JCR API for the last several months. Finally, I decided to read the JCR specification. I was surprised (well maybe not too much) to see that CQ discards quite a few JCR features in favor of implementing them within the application logic. Personally, I’m not too happy about that. If a feature is supported by the repository, why reinvent the wheel in your application?
Let’s get right into it.
I’m often asked what is the best way to go about building a WCM enabled application. I’ve learned over the past few years that there is actually a large number of options here. I’m not just talking about products, but rather architectural approaches.
I think the first question to ask is, ‘Do you need a WCM enabled application or do you simply need a content driven application?’. If you don’t need a ’site builder’, or the ability to have business users build out the site, then you can likely do with just a content driven application.
What I’m starting to see now as that instead of complete WCM enabled applications, we can get away with simple content driven applications. I came across a requirement the other day where the client merely wanted the ability to change text on a page without redeploying the application. Well, you don’t necessarily need an enterprise grade WCM application for that. You just need to pull the text from a repository. This is no different than pulling product information from a database. However, there are cases where a complete WCM enabled application is required.
Here are the options I typically consider.
| 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 | |||