Of registries and repositories
As if we needed more confusion in the SOA world,ZapThink's Ron Schmelzerpoints out in a new piece that "registries" are being confused with "repositories," while the UDDI spec is being confused with a product.
"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," he states. Citing the dictionary, he explains that aregistry "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...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. "
The problem emerges when developers try to determine which assets toregister in a Services registry and which ones to placein a repository."When thinking about SOA, think about what a Service registry does," Schmelzer advises. "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."
He further notes that "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."
The discussion around current confusion dives deeper into what has turned out to be a controversial issue -- namely, the desire of some vendors to package UDDI specs as an actual product.
"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," he concludes. "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, theres no doubt were getting ever closer to the vision of the Service-oriented enterprise."