Registries vs. Repositories and Standards vs. Products

Question: what’s the difference between a bagpipe and an onion? Answer: no one cries when you chop up a bagpipe. If only the difference between registries and repositories were as clear! In the world of SOA, significant confusion surrounds the storage and management of Service metadata that developers need during design time, as well as the metadata that the SOA infrastructure requires to manage Service operation during runtime. In particular, people are confusing the capabilities of registries with those of repositories. Adding to the confusion, people are attributing product features to the UDDI standard. This ZapFlash aims to clarify not only the differences between these various different aspects of metadata management, but also provides a framework for evaluating the roles registries vs. repositories play, and what they can expect from specifications vs. the products they buy.

Registries vs. Repositories

The dictionary definition of “registry” is a place where official records are kept. In the technical sense, a registry is an authoritative store of information that relates to a particular task at hand. For those that are married, engaged, or have friends who are, when you hear the term “registry”, you might instantly think of the kiosk in stores like Crate & Barrel that point you to the goodies that you want to be given, or the gifts that your friends encourage you to purchase. Like a gift registry that provides listings of the items you wish your friends to purchase, or the Windows registry that stores pointers and configuration information for how the operating system should handle the various resources on your machine, registries store metadata that relate to the particular asset you have interest in, without actually containing those assets. The store that actually contains those assets is the repository. A repository, like the gold repository in Fort Knox, stores actual assets and typically controls access to those assets. So, while a registry simply records official information that relates to an asset, the repository stores the assets themselves.

So, here’s where the confusion starts: what assets should you register in a Services registry, and what assets should you place in a repository? The answer depends entirely on the nature of the registry and repository in question. The first realization is that there really is no such thing as a general-purpose registry, since all registries are built for a specific function. The Windows registry is meant to handle the coordination of objects in the operating system, while a Services registry handles interactions among Service consumers and providers. The same is true for repositories: repositories are built for the specific kind of assets they are meant to hold and the modes of interaction they must support. Databases, file systems, and content management systems are all repositories of one sort or another, and they are all tailor-made for their specific requirements.

So, when thinking about SOA, think about what a Service registry does. And then, think about all the assets that are associated and related to those Services. Where do models go? Where do functional specs go? How about policies, schemas, and transformation maps? While a registry might be the right place to store a Service definition and associated policy metadata, it is not the right place to store service artifacts such as models, maps, shared keys, and transformational schemas.

To add to the confusion, developers have different needs for registries at design time than systems require for runtime operation. Design time registries help developers locate assets, make decisions about which ones are best to use among many that might be similarly appropriate or adequate, and understand the various costs involved in their consumption. Runtime registries help systems make automated, policy-based decisions about Service selection. However, there is no such design time vs. runtime delineation for repositories. A repository is simply a repository — to be used at both design time and runtime. Understanding the difference is key to figuring out which assets belong in what type of metadata storage system.

UDDI is a Specification, Not a Product

People also confuse the specifications that govern interaction with registries and the capabilities of those registries themselves. A registry specification does not a registry make! Specifically, developers consistently confuse the UDDI standard with the registry capabilities it is meant to specify. While the original intent for UDDI was as a platform-independent, open framework for describing services, discovering businesses, and integrating business services, as we detail in our UDDI: Straw Man or Ugly Duckling? ZapFlash, the true power of UDDI lies in its role within an operating SOA as a key standard that helps companies realize loose coupling by guiding the location independence of Services, and hence implementing the abstraction layer that the Services represent to SOA. Specifically, UDDI specifies a set of XML-based service descriptors that provide the metadata needed to locate and bind to a given Service. In other words, UDDI specifies a query mechanism to search an XML-based registry.

Registries, however, are not the only kind of entity that should have UDDI-based interactions. Service consumers should be able to communicate with anything exposing a UDDI interface. SOA and Web Services management tools should likewise have UDDI interfaces. In fact, anything that has to do with the publication or discovery of Service assets should either communicate with or expose a UDDI interface.

So, UDDI specifies certain functionality, but the standard itself has no product features, because, after all, it isn’t a product. UDDI doesn’t define the inner workings of registries. An LDAP directory can expose a UDDI interface just as an embedded store in a cell phone can, even though they are very different products with very different functionality. As such, why would anyone expect those two registries to have the same capabilities? Just as one can’t expect any two Services that communicate via SOAP to do the same activities in the same way, users should not assume that any two registries that expose UDDI interfaces will do the same thing. In fact, there’s no such thing as “a UDDI registry” per se — there can only be registries that expose UDDI interfaces.

People often ask ZapThink whether they should use UDDI at design time or runtime. That’s actually the wrong question! UDDI is just a standard, so the question really is, should they use a registry at design time or runtime, and does the UDDI specification support the usage of those registries in both scenarios? Currently, most registry owners use them at design time, and many of those registries support UDDI, so as a consequence, UDDI is mostly applied in a design time capacity. However, as registry use increasingly handles runtime Service discovery, most will do so through UDDI-compliant interfaces.

You should never ask whether or not UDDI can provide the capabilities of a registry at runtime, but rather whether it can support the interoperability needs across all such registries. Standards are for insuring interoperability, after all! Indeed, there are other specifications for registry interaction, and if UDDI can’t support the needs for runtime discovery, surely another such standard will fill that gap. However, there’s no need to replace the registry product — simply the standard you use to interact with it!

The ZapThink Take

Another important reason to separate UDDI from the products that support it is the fact that products can span the capabilities of both registries and repositories. Just because registry and repository product categories contain different feature sets doesn’t mean that there can’t be products on the market that provide the capabilities of both categories. In fact, some companies with UDDI-based registry products now offer more general-purpose asset repository capabilities, and similarly, some asset management repositories on the market now provide UDDI-based registry capabilities.

There’s no reason to pigeonhole companies’ products into the registry or repository product categories, just as there is no reason to identify registries with UDDI. In fact, some registry products support other interchange format specifications than UDDI, like ebXML’s registry/repository specification. Standards like UDDI are only technical guidelines for the interfaces products should have so that they will interoperate with each other; the products themselves must meet the actual customer requirements.

In the final analysis, the key to understanding how to apply these various standards and feature sets is to realize that a Service is an asset that contains both platform-dependent information that governs its functionality as well as metadata that govern its use. Therefore, metadata govern both the asset and its use, establishing the vital role metadata management plays in making an SOA work. SOA governance, for example, is a class of problems that focuses on managing human, rather than system, behavior. Registries and repositories both provide the metadata management that is needed to solve SOA governance issues. As such, as vendors increasingly build products to solve SOA governance issues, their products will span the capabilities of registries and repositories and likewise provide support for specifications that include, but are not limited to UDDI. As end-users work their way through the various options for working with and storing metadata, there’s no doubt we’re getting ever closer to the vision of the Service-oriented enterprise.