The JBoss DNA team is proud to announce the release of JBoss DNA 0.2. We’ve added some great new sequencers, and we’ve included some nice improvements and fixed a number of bugs. Plus, we added a (partial) JCR implementation with a few initial connectors, including one that federates information from multiple sources and maintains a local cache (a la JBoss Cache) of the unified content.
Our Getting Started document introduces you to JBoss DNA and walks you through a couple of examples. Our new Reference Guide goes into much more detail and covers JBoss DNA’s different components and how they all work. And of course, our downloads page is where you can find the binaries and source.
But before you dive into the examples, read on for a quick primer on the project…
What is JBoss DNA?
The JBoss DNA project is building a unified metadata repository system that is JCR-compliant and capable of federating information from a variety of back-end systems. To client applications, JBoss DNA looks and behaves like a regular JCR repository that can be searched, navigated, versioned, and monitored for changes. But under the covers, JBoss DNA gets its content by federating multiple back-end systems (like databases, services, other repositories, etc.), allowing those systems to continue “owning” the information while ensuring the unified repository stays up-to-date and in sync. JBoss DNA also sequences the content you put into the repository and automatically turns it into information you can use more effectively.
What is metadata?
A simple but useful definition is that metadata is the information you need to manage something. For example, it’s the information needed to configure an operating system, or the description of the information in an LDAP tree, or the topology of your network. It’s the configuration of an application server or enterprise service bus. Or it’s the steps involved in validating an application before it can go into production. It’s the description of your database schemas, or of your services, or of the messages going in and coming out of a service. JBoss DNA is designed to be a repository for all this … and more.
Interestingly, most metadata is either found in or managed by other systems: databases, applications, file systems, source code management systems, services, content management systems, and even other repositories. This means that getting at the metadata in all these systems is a lot of work, simply because so many different APIs are involved. And although we could pull this information out and duplicate it, keeping multiple copies of the metadata in sync is a huge challenge.
The best way to approach this is with a federated repository. A single, standard API makes it easy to get to all the metadata, regardless of its structure, form, or source. Then, using connectors our repository can We can connect to these back-end systems to dynamically access the content and project it into a single, unified repository. We can also cache it for faster access, as long as the cache can be invalidated based upon time or event. But we also need to maintain a clear picture of where all the bits come from, so users can be sure they’re looking at the right information. And we need to make it as easy as possible to write new connectors, since there are a lot of systems out there that have information we want to federate.
Another characteristic of metadata is that it’s very often represented in files, and there are a lot of different file formats. These include source code, configuration files, web pages, database schemas, XML schemas, service definitions, policies, documents, spreadsheets, presentations, images, audio files, workflow definitions, business rules, and on and on. And so even though information is added to the repository through files like these, the repository should be able to automatically extract the most useful content and place it in the repository where it can be much more easily used, searched, related, and analyzed. This process of extracting content and storing it in the repository is what JBoss DNA calls sequencing, and it’s an important part of a metadata repository.
Metadata rarely stays the same. Different consumers of the information need to see different views of it. Metadata about two similar systems is not always the same. The metadata often needs to be tagged or annotated with additional information. And the things being described often change over time, meaning the metadata has to change, too. As a result, the way in which we store and manage the metadata has to be flexible and able to adapt, and the object model we use to interact with the repository must accommodate these needs. The graph-based nature of a JCR repository provides this flexibility while also giving us the ability to constrain information when it needs to be constrained. A JCR repository can also version the information, and it can notify applications when its content changes.
Why use JBoss DNA?
JBoss DNA metadata repositories are useful in a variety of ways. One of the most obvious applications is in provisioning, where it’s critical to understand and keep track of the metadata for models, database, services, components, applications, clusters, machines, and other systems used in an enterprise. Governance takes that a step farther, by also tracking the policies and expectations against which performance can be verified. In these cases, a repository is an excellent mechanism for managing this complex and highly-varied information. But a JBoss DNA repository doesn’t have to be large and complex: it could just manage configuration information for an application, or it could just provide a JCR interface on top of a couple of non-JCR systems.
This is the beauty of JBoss DNA and its connector architecture: a unified metadata repository that federates and sequences information so that it’s easy to view, manage, and leverage. Plus, JBoss DNA is built on top of several best-of-breed open source Java libraries from JBoss.org, including JBoss Cache and JBoss Security. And we have plans to use many more, including the Microcontainer, Hibernate, JGroups, and JBoss Transactions.