With all the buzz going on about the need for a SOA registry, people are increasingly realizing that another key SOA component is a repository. What is the difference between a registry and a repository? On a recent ZapThink webcast on the topic of registries and repositories, the consensus was that registries hold references to things and repositories hold the things.
The example that ZapThink Analyst Ron Schmelzer gave is the idea of a bridal registry vs. Fort Knox. A bridal registry is a mechanism to see who got the happy couple the Ronco Dial-O-Matic veggie slicer and who got them the George Foreman Grill. Fort Knox, on the other hand, is a repository -- a place where you store things.
Some people would like to suggest that registries hold metadata and repositories hold data. That's a handy difference, but really taxes the semantics. Metadata is just data about data, right? So what is documentation? Well, if it is a Microsoft Word document, that would suggest that it is data right? Not so fast -- because the document describes the service, and so it should be considered metadata. Not only that, but Microsoft has promised to make XML the default format for Microsoft Office documents. The key to take home is that data and metadata are determined by relationship -- and that one person's data is another person's metadata. On a given day, a data set may play the role of data and change to metadata and then back to data.
The permeability of the data/metadata boundary is why the market, as it matures, is increasingly seeing integrated registry/repository solutions.
Several distinctions may be helpful in clarifying the boundaries. One useful distinction is between design-time and runtime. Both registries and repositories have design-time and runtime features. Design-time metadata is mostly focused on description and discovery, while runtime metadata is focused on delivering contract and policy information. Design-time data typically reflects artifacts such as code -- and thus typical design-time repositories use standards such as CVS (Concurrent Versions System). Runtime repositories typically store messages and provide query, audit, logging and a variety of archiving capabilities.
|
Design-time |
Runtime |
| Registry |
Discovery
Description |
Contracts
Policies
Versioning |
| Repository |
Code versions
Documentation |
Queriable message store
Logging
Auditing |
Obviously there are a number of other features, such as governance, federation, subscription and notification, security, identity, reporting, and management, which come with the products in this space.
Infravio has supported an integrated registry/repository model since the beginning of its product (which is called "X-Registry"). The X-Registry platform uses the Java application programming interface (API) for XML Registries (JAXR), which is the Java programmatic API for developing applications on top of standard registries, including Universal Description, Discovery, and Integration (UDDI) and the ebXML RIM, or Registry Information Model.
Sun Microsystems recently validated this approach by releasing a lightweight registry product which integrates registry and repository functionality, based on the FreebXML code base. This supports the JAXR functionality.
Systinet, which based initial products on UDDI registry only, is also changing their tune. The next version of their product, code-named "Blizzard," incorporates runtime repository functionality based on an XQuery interface.
Which brings us to the question — what are the standards around repository?
This question should be addressed with respect to SOA lifecycle, as well as the features needed. In the design-time, standards like CVS are used to store code artifacts. This is one type of repository. When you get to SOA runtime, there is a need for storing message data. Now, if you want message query capability, the logical interface is XQuery. XQuery allows you to query distributed XML data as if it were one single database. However, if you are looking for a richer information model and things like auditable message logs, ebXML Registry has these capabilities.
Increasingly, registry and repository are seen as integrated parts of an SOA "platform." The key questions when selecting registry and repository products should be whether the needs are focused on design-time or runtime. By understanding which functions are needed for the lifecycle of your SOA services, a better selection process can be achieved.
About the Author
Miko Matsumura is vice president of marketing at Infravio, Inc.
