An SOA registry-repository is increasingly becoming an important infrastructure middleware solution for managing the rising complexities and meeting new requirements related to SOA.
Many different information artifacts describe a service component or relate it to other service components and information artifacts, such as:
- Multiple WSDL files may describe the various interfaces and protocol bindings of these interfaces for the service component.
- XML schema files may describe the documents exchanged by messages in the service protocol.
- Business process orchestration for the service component may be described by artifacts such as BPEL descriptions, and ebXML business process specification schemas.
- Metadata may describe the assembly structure and subcomponents of a composites ervice.
- XSLT stylesheets may be used as adapters between service components to handle impedance mismatch due to service version differences.
- WSRP descriptions may describe how service components are used by portals.
- Organizational policies, business rules, and procedures may define how service components and service information artifacts may be defined and used.
Governance is defined as the policies, rules, and regulations under which an organization functions as well as the processes that are put in place to ensure compliance with those policies, rules, and regulations.
It is required to have a point of control within the SOA infrastructure that provides governance of service components and artifacts by enforcing the organizational policies that govern them.
The need for a point of control and governance within the SOA deployment demands that service information artifacts be stored and managed in a consistent manner that allows enforcement of organizational policies.
This is precisely the role served by a registry-repository service within an SOA deployment.
The following example describes a registry-repository using a common metaphor:
- A registry-repository is like your local library.
- It has a repository that contains all types of electronic assets, much like the library book shelves contain all types of published content including books, magazines, videos, and so on.
- It has a registry that contains metadata describing the electronic artifacts, much like the library’s card catalog contains information describing the published content on its book shelves.
- The registry and repository are administered jointly. Within a library, the card catalog information and books in the shelves are administered jointly.
- Any number of registry-repositories should be able to work together to offer a unified service, much like multiple libraries can participate in a cooperative network and offer a unified service.
A registry can only store links or pointers to service information artifacts.
The actual artifacts must reside outside the registry.
A registry-repository provides an integrated solution able to store metadata such as links or pointers to artifacts, as well as the actual artifacts.
An SOA registry-repository should provide governance capabilities that enable organizations to define and enforce organizational policies governing the content and usage of the artifacts throughout their life cycles.
Since organizational policies vary, an SOA registry-repository should enable organizations to enforce custom policies for the governance of any type of service information artifact throughout its life cycle.
A registry-repository should allow business rules to be enforced at the time of publishing. It should also allow such business rules to be defined by the organization and specialized for the types of artifacts. If an artifact fails publish-time validation checking, the registry-repository should either reject the artifact, or accept it as invalid and automatically notify responsible parties.
Federated information management allows multiple registry-repositories to federate together and appear as a single, virtual registry-repository, while allowing individual organizations to retain local control over their own registry-repositories.
Governance requires enforcement of organization policies that are described in a machine-processable syntax, typically XML.
An SOA registry-repository will be used to manage and govern policies in much the same manner as other SOA artifacts.
The ebXML Registry standard supports federated policy management of access control policies expressed in the XML syntax defined by the OASIS Extensible Access Control Markup Language (XACML) standard.
A registry-repository should also support federated identity management features such as single sign-on, and integrate with identity and access management services using open standards such as Security Assertions Markup Language (SAML) and Liberty.
A registry-repository contains all service-related artifacts for service components available within an SOA deployment.
A registry-repository should provide discovery capabilities that are extensible and can accommodate the simplest to the most complex domain-specific discovery queries. Specifically, its discovery queries should not all be predefined.
Here are some examples of service artifact discovery queries expressed in plain English:
- Find all WSDL documents that use a specified namespace pattern
- Find all Service Bindings or Services that have a certain text pattern in their documentation
- Find all Service Bindings that are SOAP bindings AND use DOC Literal style AND do not use HTTP as transport
- Find all WSDLs with Service implementations that use specified implementation platform (for example, Java™ 2 Platform,Enterprise Edition or J2EE™, .Net, and so on)
- Find all WSDLs with Service implementations that use specified platform resources (such as database, Java Message Service or JMS, Java API for XML Registries or JAXR, and so on)
Cataloging of artifacts improves their discoverablity and is essential in supporting the kind of artifact-specific queries.
With cataloging information is automatically converted to metadata at the time it is published.
For example, an organization may define cataloging policies for WSDL artifacts such that when a WSDL document is published, it is cataloged in a WSDL-specific manner to generate metadata that includes information on:
- The documents imported by the WSDL document (such as other WSDL documents and XML schema documents)
- The name spaces used by the WSDL document and documents imported by it
- The name and description of the bindings, interfaces, and types used by the WSDL document
Such metadata can then be used in WSDL-specific discovery queries.
As more and more service components are reused within other service components, the task of tracking the network of dependencies between service components becomes more challenging and significant. A registry-repository should provide a set of standard relationship types, but also allow an organization to define additional relationship types based on its specific requirements.
Service components are deployed in phases. During each phase, organizational access control policies (ACPs) determine the controlled community of users which has access to the service.
A registry-repository should allow ACPs to be defined and enforced for service information artifacts. Since ACPs tend to be fairly specific to organizational needs, the registry-repository should allow for fine-grained access control policies that can accommodate specific needs.
Service components evolve over time for a variety of reasons, such as the need to fulfill new requirements. A service’s evolution may involve changes in its implementation and/or public interface.
A registry-repository should provide versioning capabilities that enable automatic version control of any type of service information artifact
When a service evolves, it is important to notify its consumers of the changes to the service.
A registry-repository should provide a change notification capability that allows interested parties, such as system administrators, to create subscriptions to events within the registry-repository that may be of interest to them.
As IT organizations evaluate which registry-repository to deploy as part of their SOA infrastructures, the choices often fall into the following categories:
1. Proprietary registry-repository
2. UDDI registry without a repository
3. UDDI registry with a proprietary repository
4. ebXML registry-repository
5. Combination of UDDI registry and ebXML registry-repository
A UDDI registry offers a subset of capabilities offered by an ebXML Registry.
In particular, it provides only a registry and no repository.
What gets published in a UDDI registry are pointers to service artifacts such as WSDL.
What gets published to the ebXML Registry are not just pointers to service artifacts, but also the actual artifact themselves.
Thus, an ebXML registry-repository can be used for governance of any type of service artifacts throughout their life cycles.
Further, at the end, the white paper also provides a Registry Standards Comparison Matrix which compares UDDI and ebXML Registry 3.0 standards in various categories.