This article describes the use of WebSphere Service Registry and Repository (hereafter called Registry and Repository) in an Enterprise Service Bus (ESB) environment, using the WebSphere Message Broker (hereafter called Message Broker) as the ESB implementation. With Registry and Repository, ESB mediations that interact with endpoint services can be more tolerant of changes within the environment. In this interaction, the ESB uses Registry and Repository as a dynamic look-up mechanism that provides information about service endpoints (the service metadata). This means that when changes occur in the service endpoint environment, the associated ESB mediations don't have to change.
The interaction between Message Broker and Registry and Repository is provided by the Message Broker Version 6 Client for WebSphere Service Registry and Repository. See Resources for more information and to download this product extension. The extension includes a set of Message Broker nodes that you can usee when building Message Broker flows. These nodes encapsulate the API calls to Registry and Repository and a caching mechanism to improve the efficiency of the interaction.
This article assumes that you are familiar with the basic concepts of SOA and with WebSphere Message Broker.
SOA offers business agility and resilience through re-use, loose coupling, flexibility, interoperability, integration and governance. In these respects, one of the key enabling features of SOA is the separation of service descriptions from their implementations, and using the descriptive metadata associated with the service description across the service life cycle. Standards-based service metadata artifacts, such as Web Service Definition Language (WSDL), XML schema, policy or Service Component Architecture (SCA) documents capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata can be associated with these artifacts to offer insight to potential users of the service on how and when it can be used, and what purposes it serves.
Message Broker is an ESB implementation that provides powerful message mediation capabilities, including transformation and service endpoint routing. One of the common ESB usage patterns involves mediations that are constructed to act as the exposed (or externally provided) service for an organization. These mediations, or Message Broker flows, process an incoming message and make decisions on the tasks or steps needed to execute the incoming message request. This generally involves delegating the execution of the incoming message to one or more services, referred to as back-end services.
Registry and Repository is the master metadata repository for service interaction endpoint descriptions. This includes traditional Web services that implement WSDL interfaces with SOAP/HTTP bindings, as well as a broad range of SOA services that can be described using WSDL, XSD and policy declarations, but might use a range of protocols and be implemented according to a variety of programming models. As the copy of record for service metadata, Registry and Repository establishes a central point for finding and managing service metadata acquired from a number of sources, including service application deployments and other service metadata and endpoint registries and repositories. It also contains the latest information about service endpoints, which becomes important in the following discussion about integrating the ESB and a service registry.
Using a service registry to improve ESB flexibility
As described above, a common ESB mediation pattern is one where mediations are constructed to act as the exposed (or externally provided) service for an organization, as shown in Figure 1:
Figure 1. Exposed service using an ESB
The back-end services that the mediation will delegate to are generally specified at development time, during message flow development, and usually specify static information about the various service endpoints to be used. As SOA environments become more flexible and responsive, significant numbers of changes can occur within service endpoint definitions (the metadata), making the statically defined mediations brittle. Changing the mediation to accommodate the altered service endpoints raises issues associated with the cost of making a development change, delay in getting these new services deployed, and potential business and operational processes to oversee a mediation change.
As a case in point, consider a mediation that contains the endpoint of the back-end service, such as a Web service, to invoke. This endpoint is expressed using a static URL or other metadata describing a service's binding. This static content makes the mediation brittle when changes are required, such as the deployment of a new Web service, which the mediation now needs to invoke, or deployment of a new back-end service that requires a transformation of the incoming message or that is implemented using a completely different protocol.
You can address the brittleness of the mediation by developing mediations that are no longer reliant on statically defined information about service endpoints. To do this, you need a place to get up-to-date information about service endpoints and a mechanism for efficiently accessing that information. Previous attempts at solving this problem have generally relied on some form of access to a data store, such as a relational database or queue. These mechanisms suffered from their proprietary nature, the performance issues associated with database access from a mediation, and the maintenance issues of working with a hand-crafted solution.
A service registry, such as WebSphere Service Registry and Repository, provides a middleware solution to previously hand-crafted mechanisms. You can access up-to-date information about service metadata from Registry and Repository, making the mediations much more immune to changes in service metadata, like service endpoints. For example, using Registry and Repository, you can ensure that that the latest release of a particular service endpoint is always invoked, or select a particular endpoint service based on some selection criteria in the input message.
A mediation that uses Registry and Repository maintains maximum flexibility because the content of the metadata used in decision-making is externalized, as shown in Figure 2:
Figure 2. Using a service registry with an ESB
ESB and service registry interaction
An ESB uses a service registry to obtain metadata about the services it needs to invoke. This metadata can be specific service endpoints, supported port types, services that meet a certain SLA requirement, or other metadata. In Figure 3, you can see that when a mediation is invoked on the ESB (Message Broker, in this example), the ESB processes the incoming message using specific nodes to access the necessary metadata from the service registry (Registry and Repository). The ESB then uses the retrieved metadata to set the correct endpoints to invoke, determine alternate execution paths, enforce policy, or perform other actions.
Figure 3. Location of Registry and Repository in an ESB
Understanding registry contents
The most elemental building blocks for the Registry and Repository content model are service metadata artifact documents (physical documents), such as XSD or WSDL files. These service metadata documents are stored and managed in Registry and Repository. Any service metadata artifact type can be stored in Registry and Repository; however, Registry and Repository offers advanced functions for the following well-known SOA metadata types: WSDL, XSD, WS-Policy and SCDL. The contents of these types of service metadata documents comprise the logical model of the Registry and Repository. The logical model has entities such as
message related to WSDL files, and
simpleType related to XSD documents. Elements of the logical model have properties and relationships reflecting a subset of their characteristics as defined in the underlying physical document. For example, a
WSDLService element has a
namespace property and a relationship to the ports it contains.
There is one other kind of entity in the Registry and Repository, loosely referred to as a
Concept, which is a generic object that can be used to represent anything that does not have a physical document in the Registry and Repository.
Concepts can be used to represent a reference to content in some other metadata repository such as a portlet in a portlet catalog, an asset in an asset repository, service implementation artifacts kept in a source code library, or information about SOA infrastructure topologies in a configuration management database. They can also be used to group physical artifacts together for ease of retrieval, for example.
In addition to content directly related to service metadata documents, Registry and Repository supports a number of user-defined metadata types that are used to decorate the service metadata to explain their semantics; these are referred to as Service Description Metadata. Registry and Repository supports three types of service semantics metadata types:
Classifiers. Users can associate a property
businessValue with a physical model entity representing a WSDL file, or define a new relationship
makesUseOf between an entity in the logical model representing a
portType and an entity in the physical model representing an XML document; or create a classifier
importantThings and associate it with a
port entity in the logical model and with an entity in the physical model representing a policy document. This enables semantic queries to target individual elements of the service metadata, and meaningful dependency analysis to take place prior to making changes.
The main user interface for Registry and Repository is a Web application deployed with the Registry and Repository runtime. This interface supports a set of anticipated user roles and provides the following capabilities:
- Look-up, browse, and retrieve
- Publish and annotate
- Governance activities, including import/export and impact analysis
The user interface consists of a perspective pane, a navigation tree pane, and a details pane, as shown in Figure 4:
Figure 4. Registry and Repository Web interface
You can use the Web interface to customize the views of the Registry and Repository content. A set of user interface definition files describes the content and layout of the various components that make up the Registry and Repository interface. Role-specific perspectives are also supported.
Message Broker client support for Registry and Repository
The Message Broker client for Registry and Repository provides support for Message Broker runtime access to the service metadata in Registry and Repository through two generic nodes. These nodes allow the Message Broker flows, or mediations, to be more flexible and adapt to changes within an enterprise without the cost of changing, testing, and redeploying the mediations.
The first of the generic Message Broker nodes used to access Registry and Repository accesses the metadata for a specific Web service and sets the proper endpoints and protocol so that the service can be invoked. The icon for this node, called the SRRetrieveITService node, is shown below:
In the Properties dialog for this node, you can specify how the service is retrieved based on a variety of different properties. For instance, a specific service can be retrieved based on its PortType name, namespace, and version. The combination of name, namespace, and version (called a service's tuple or triple) uniquely identifies a specific service. You can also specify a service implementation, or port, be retrieved based on a certain set of criteria, such as matching a specified set of user-defined properties or a specific classification. See Samples for more information.
Figure 5. Properties dialog for SRRetrieveITService node
The other generic node supported by Message Broker for Registry and Repository access is the SRRetrieveEntity. This node is used to obtain the contents of any entity contained in Registry and Repository. It does not establish any environment specifics related to execution, but instead makes the entire contents of the entity available to the mediation. The mediation can then make use of this information as needed. The icon for the SRRetrieveEntity node is shown below:
The SRRetrieveEntity Properties dialog is similar to the previous one, except that this node allows explicit access to any entity in the Registry and Repository, not just a service. This means that the Message Broker flow can obtain the full metadata of the entity, including its contents, and then make use of that metadata or content as necessary. For instance, the Message Broker flow can use this node to access a policy document and use its contents to enforce a specific set of policies. Like the SRRetrieveITService node, the SRRetrieveEntity node allows multiple entities to be returned as specified by its
matchPolicy, which allows the mediation, through a single request to Registry and Repository, to retrieve several documents and use them as needed.
Figure 6. Properties dialog for SRRetrieveEntity node
Sample Message Broker flow to invoke a Web service obtained from Registry and Repository
Let's suppose a mediation needs to listen for a request, retrieve a specific Web service, and then execute that service. The Message Broker flow shown in Figure 7 performs these actions using the built-in HTTP Input node to listen for the request, the SRRetrieveITService node to retrieve a specific Web service from Registry and Repository, and the built-in HTTP Request node to invoke it. If the service is not found, the Message Broker routes the message to a corresponding Failure or NoMatch output terminal.
Figure 7. Sample Message Broker flow using SRRetrieveITService node
During development of this Message Broker flow, the SRRetrieveITService node's Properties dialog is used to specify the criteria to locate a specific Web service to be retrieved and executed at runtime, as shown in Figure 8. In our example, the Properties dialog specifies retrieval of a Web service that has a PortType Name of DemoCustomer and PortType Namespace of http://demo.sr.eis.ibm.com. Furthermore, the retrieved service must also contain the user Properties policy and country with values RM and USA respectively, and must be classified as http://eis.ibm.com/ServiceRegistry/BusinessDomain/GenericObjectTypes#CustomerRelated. Only a service that meets all these criteria will be retrieved. Finally, the dialog specifies a Match Policy of One, which means that only a single service meeting these criteria will be retrieved. If the requested service cannot be found in Registry and Repository, the message is routed to the node's NoMatch terminal and execution is processed by the Post NoMatch Message Broker ComputeNode.
Figure 8. Property dialog for SRRetrieveITService in sample flow
The SRRetrieveITService node's Properties dialog shown above specifies the service that should be retrieved. You can use the Registry and Repository console to validate the service that will be retrieved. To do that, select Service Metadata => PortTypes to display all registered Port types, then select the specified service name (in our case, DemoCustomer). In the detail pane, you can confirm that the name and namespace meet the criteria specified in the Message Broker SRRetrieveITService node properties, as shown in Figure 9:
Figure 9. Registry and Repository detail view of portType used in sample flow
In this example, the Message Broker node's properties also specify retrieval of a service that has specific user properties. You can use the Registry and Repository console to check the port (DemoCustomer, in this example) for these user properties, as shown in Figure 10:
Figure 10. Registry and Repository view of user properties used in sample flow
Finally, you can use the Registry and Repository console to check that the port contains the specified classification, as shown in Figure 11:
Figure 11. Registry and Repository view of calssification used in sample flow
In this example, you've seen how the values specified in the Message Broker node's properties are used to locate and retrieve a service defined in Registry and Repository based on a specific set of criteria. You can identify the actual service (in this case, a Web service) to be invoked using the Registry and Repository console to view the Web service's Location (the SOAP address) as shown in Figure 12:
Figure 12. Registry and Repository view of WebService endpoint for port/portType used in sample flow
If the endpoint for this Web service needs to be changed, the original physical document (for example, the WSDL) will need to be changed. You can then re-import it into Registry and Repository without affecting the Message Broker flow. When the mediation is executed, it will retrieve the updated endpoint from Registry and Repository.
Sample Message Broker flow to access any Registry and Repository entity
In this sample Message Broker flow shown in Figure 13, the SRRetrieveEntity node is used to retrieve all metadata contents for a specific entity. This can be any entity (such as a policy document) contained in Registry and Repository. The sample flow then uses a built-in ComputeNode to display the contents of the retrieved entity (for sample purposes). In a real flow, the flow would use the contents of the entity to perform additional logic or enforce specific policies.
Figure 13. Sample Message Broker flow using SRRetrieveEntity node
As you saw in the preceding example, the node properties (in this case, for the SRRetrieveEntity node) are used to locate and retrieve the entity that matches the specified criteria from Registry and Repository. If those criteria are met, all of the entity's metadata is retrieved and stored in the Message Broker LocalEnvironment. The contents, or any part of the metadata, can then be used by the Message Broker flow. Figure 14 shows sample contents of the Message Broker LocalEnvironment after execution of the SRRetrieveEntity node:
Figure 14. Example of Message Broker LocalEnvironment after execution of SRRetrieveEntity node
As implemented today, an ESB is susceptible to changes in the service metadata with which it interacts. This is because most service endpoint information is statically defined in an ESB mediation at build time. Changes to this metadata can result in a significant cost of time, productivity, and responsiveness for an enterprise. Developers who are keen to exploit the dynamic potential of SOA will find this restrictive and cost-prohibitive. However, using a service registry to retrieve this metadata enables you to build ESB mediations that are more flexible and less brittle, resulting in an overall environment that is less susceptible to change. With WebSphere Message Broker and WebSphere Service Registry and Repository, you can enable your ESB to be more dynamic, more flexible, and more adaptable to the needs of the enterprise. What this means to your business is better responsiveness at a reduced overall cost.
- IBM's SOA Foundation: An architectural introduction and overview (PDF)
- SOA programming model for implementing Web services, Part 1: Introduction to the IBM SOA programming model
- Object Management Group Web site
- An SOA programming model for implementing Web services, Part 10: SOA user roles
- SOA programming model for implementing Web services, Part 1: Introduction to the IBM SOA programming model
- SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus
- WebSphere Business Integration zone
- WebSphere Web services zone
- WebSphere Message Broker 6.0 Information Center
- WebSphere Service Registry and Repository 6.0 Information Center
- Introducing IBM WebSphere Service Registry and Repository, Part 1: A day in the life of WebSphere Service Registry and Repository in the SOA life cycle
- Introducing IBM WebSphere Service Registry and Repository, Part 2: Architecture, APIs, and content
- WebSphere Service Registry and Repository Version 6.0 Quick Start Guide
- Service Oriented Architecture (SOA) Compass, IBM Press, ISBN 0-13-187002-5
- IBM Systems Journal, Service Oriented Architecture, Vol. 44, No. 4, 2005