2012년 1월 2일 월요일

[DeveloperWorks] Introduction to WebSphere Enterprise Service Bus Registry Edition V7.5

Introduction to WebSphere Enterprise Service Bus Registry Edition V7.5

Introduction
This article describes the capabilities and usage patterns of IBM® WebSphere® Enterprise Service Bus Registry Edition. For detailed information on the separate products WebSphere Enterprise Service Bus (hereafter called WebSphere ESB) and WebSphere Service Registry and Repository (hereafter called Service Registry), see Resources at the bottom of the article.
WebSphere ESB Registry Edition provides a robust, scalable, and flexible infrastructure for service mediation, hosting, visibility, and control. This article describes the WebSphere ESB Registry Edition capabilities that enable you to leverage existing service enablement, dynamically connect service providers with service consumers, and control your SOA-based mediation policy. WebSphere ESB Registry Edition includes licenses for both WebSphere ESB and WebSphere Service Registry and Repository.
Common usage patterns
Dynamic endpoint resolution
Dynamic endpoint resolution enables you to decouple the logical intent of a mediation to invoke a service provider from the physical, network-addressable endpoint used by the runtime. Often when a mediation is being developed, it is undesirable to hard-code the endpoint of the service provider. One solution has been to provide this binding from the logical to the physical at deployment time, but this method usually requires you to restart the application in order to change an endpoint. In addition, the administrator deploying the mediation may not be the correct person to manage the relationships between service consumers and service providers, because this role involves business decisions rather than deployment decisions. For example, service provider A may be more costly than service provider B, so the business decision is to consume service provider B. Therefore you need a more flexible mechanism to resolve the endpoint location within the ESB, and the solution is to use a registry that looks up the endpoint dynamically, as shown below:

Figure 1. Typical integration between an ESB and registry for endpoint resolution
Typical integration between an ESB and registry for endpoint resolution
In this case, the client invokes the mediation residing on WebSphere ESB. The mediation includes search criteria to resolve the endpoint at runtime instead of hard-coding the address within the deployed module. WebSphere ESB uses this search criteria to query Service Registry, which returns the endpoint address of the provider service. Depending on the scenario, different search criteria are used to resolved the endpoint. This article describes several common approaches used by WebSphere ESB.
Endpoint Lookup mediation primitive
The Endpoint Lookup mediation primitive allows dynamic resolution of service provider endpoints when the endpoint information is stored in Service Registry. Retrieved endpoints (and metadata from Service Registry) are stored in the Service Message Object (SMO) in the SMOHeader Target and AlternateTarget structures and in the EndpointLookupContext structure in the SMO context section.

Figure 2. Endpoint Lookup Context within the SMO
Endpoint Lookup Context within the SMO
When the mediation flow reaches a Service Invoke primitive or Callout node which has "Use dynamic endpoint if" in the message header property set to true (the default setting), then the endpoint specified in the target structure will be called, overriding any endpoint address set on the SCA Import. If the Retry on property is set to Any Fault, Modelled Fault, or Unmodelled Fault, the if the Try alternate endpoints property has been set to true on the Service Invoke primitive or Callout node, and then the call to the Target endpoint fails, WebSphere ESB tries to call each of the list of AlternateTarget endpoints in order:

Figure 3. Enabling dynamic endpoint support
Enabling dynamic endpoint support
The Endpoint Lookup primitive retrieves endpoints from Service Registry by matching the property values set on the primitive with values on the endpoint objects stored in Service Registry. The primary property used to search in Service Registry is the name and namespace of the WSDL PortType that defines the interface of the endpoint. In addition to the WSDL PortType, search results can be further limited by specifying the Binding Type (Web Service, JMS, MQ, SCA, and so on) and the version of the endpoint in the primitive properties. The Match Policy property defines whether to retrieve just the first matching endpoint that is found, retrieve all matching endpoints but not set the Target or AlternateTarget structures (allowing for later processing to set these structures), retrieve all matching endpoints and set the Target and AlternateTarget structures, or finally, retrieve a single endpoint that is the latest compatible version of the service based on SCA Module versioning and wildcard characters in the version property, such as 1.2.*.

Figure 4. Endpoint Lookup mediation primitive
Endpoint Lookup mediation primitive
In the Advanced properties section, you can further refine Service Registry search by setting Classification URIs and User Properties, which are matched against classifications and user properties defined on the endpoint objects in Service Registry. You can set User Properties to a static value, or use an XPath expression to retrieve a value from the SMO at runtime.

Figure 5. Advanced configuration of the Endpoint Lookup mediation primitive
Advanced configuration of the Endpoint Lookup mediation primitive
Service endpoint information stored in Service Registry is set from various sources:
  • For Web services, Service Registry must contain either the appropriate WSDL documents, or SCA modules that contain exports using Web service bindings.
  • For other SCA bindings, Service Registry must contain the appropriate SCA modules.
  • For services that are accessed using MQ, JMS, or HTTP but are not defined in a SCA module, Service Registry must contain an appropriate Manual JMS/HTTP/MQ endpoint with associated Interface Business Object with the endpoint information and associated interface correctly set.
The Endpoint Lookup mediation primitive lets you retrieve information for the following list of service endpoint types:
  • Web services using SOAP/HTTP
  • Web services using SOAP/JMS
  • SCA module exports with Web service bindings, using SOAP/HTTP
  • SCA module exports with Web service bindings, using SOAP/JMS
  • SCA module exports with the default SCA binding
  • SCA module exports with the MQ binding
  • SCA module exports with the MQ JMS binding
  • SCA module exports with the JMS binding
  • SCA module exports with the generic JMS binding
  • SCA module exports with the HTTP binding
  • Manually defined MQ endpoints with associated interfaces
  • Manually defined JMS endpoints with associated interfaces
  • Manually defined HTTP endpoints with associated interfaces
Gateway endpoint resolution
Within a gateway scenario, WebSphere ESB is acting as an entity that handles the requests for multiple typed service consumers and providers, as shown below:

Figure 6. Service gateway pattern
Service gateway pattern
The gateway can provide common functionality across all services, such as security, auditing, and transformations. When a message is received within the gateway, you cannot query Service Registry with the PortType (as with the Endpoint Lookup primitive) to resolve the endpoint information because it may not be available within the runtime. In a Web service gateway, each request has a SOAPAction value specified, and if enabled, will also have a WS-Addressing action value. According to the specification, this value should be: "An identifier that uniquely (and opaquely) identifies the semantics implied by this message." For each message passing through the gateway, this Action value can be used to query Service Registry to find available WSDL ports, which you can do using the Gateway Endpoint Lookup mediation in Action mode:

Figure 7. Gateway Endpoint Lookup
Gateway Endpoint Lookup
The primitive will retrieve the Action value from the SMO header structure and submit it to Service Registry for resolution. However, Service Registry does not natively support SOAPActions and WS-Addressing action information for SOAP 1.2 Web services, and therefore this solution will work only for SOAP 1.1 based services.
Governing and enforcing service level agreements (SLAs) between consumers and providers
The Governance Enablement Profile in Service Registry provides the framework to model the capabilities (services) and the relationship between them within your business. At a high level, each capability in your business can be separated into six core sections:
  • Organization -- Parts of the business, such as Finance or HR, which may own capabilities within the business
  • Business capabilities -- Abstract concept of a capability within the business, such as a credit-check service
  • Capability version -- Particular version of a business capability, such as Version 1.0 of a credit-check service
  • Schema specification -- Describes the interface associated with a particular capability version, such as the WSDL and XSD representing the interface and data structures
  • Service level definition -- Describes a set of properties that represent the non-functional characteristics of the service, such as the number of messages per second that the service can handle
  • Service endpoint -- Network-addressable endpoint where the service version is available
The relationship between these concepts is shown below:

Figure 8. Governance Enablement Profile basic structure
Governance Enablement Profile basic structure
In addition to modelling this information, each part goes through a life cycle. As the model transitions through different states the Governance Policy Validators ensure that life cycle transitions meet pre-defined rules for governance for your enterprise. This model is used to represent the providers and consumers within your business. You can then use SLAs to establish formal agreements to a defined level, such as message by day, between the capabilities:

Figure 9. Relationship between a consumer and provider
Relationship between a consumer and provider
Within WebSphere ESB, it is possible to look up the network addressable endpoint of a service provider based on established SLAs with Service Registry using the SLA Endpoint Lookup mediation primitive:

Figure 10. Properties of the SLA Endpoint Lookup mediation primitive
Properties of the SLA Endpoint Lookup mediation primitive
The primitive is configured with the consumer identifier (specified on the capability version of the consumer), optionally the context ID (specified on the SLA) if multiple SLAs are associated with the same capability version and require further filtering), and the endpoint classification that highlights which life cycle state the service provider is in (such as production or development). Using this information, you can navigate the model to determine the available endpoints. If you need to restrict the query with additional parameters, use the Advanced tab and update the named query in Service Registry.
Runtime caching of communication between WebSphere ESB and Service Registry
To ensure that the dynamic lookup capabilities between WebSphere ESB and Service Registry do not cause performance issues, a configurable cache located in the WebSphere ESB runtime caches the results for a specified time period configured by the WebSphere ESB administrator. In addition to the timeout, you can clear the cache using either a programmatic interface or the Administration Console.
SLA verification
In addition to retrieving endpoints based on SLAs, in WebSphere ESB you can also check that the consumer of a target service has an SLA in place that permits it to use the service. You can enforce this permission using the SLA Check mediation primitive, which ensures that a valid SLA exists in Service Registry:

Figure 11. Properties of the SLA Check mediation primitive
Properties of the SLA Check Mediation primitive
The primitive is configured with a target service endpoint address (specified in Service Registry on the service level definition), optionally a consumer identifier (specified in Service Registry on the capability version of the consumer), and a context ID (specified in Service Registry on the SLA) if multiple SLAs are associated with the same capability version and require further filtering. All three of these properties can be either statically set, or retrieved from the message via an XPath expression.
At runtime, if the SLA Check primitive determines that a valid SLA exists, the accept terminal is fired and processing continues to any primitives wired to the accept terminal; for example, the message may be forwarded to the target service. If no SLA is found, the reject terminal is fired and processing continues to any primitives wired to the reject terminal; for example, a rejection message may be returned to the client.
Mediation policy
The design of a mediation often requires different logic to be executed based on the content of the message, which you can do by using routing and branching logic within the mediation. The example below shows an inbound message that needs to have a language-dependant transformation applied:

Figure 12. Mediation flow implemented with branching logic
Mediation flow implemented with branching logic
To achieve the desired behaviour. a MessageFilter primitive is used to branch the flow, and three pre-configured language-dependant XSLT primitives are used. However, this approach has several disadvantages:
  • When additional languages are supported by the mediation, the module must be modified within the tooling environment.
  • When more languages are added, the branching logic becomes more complex, even in this simple case.
  • Extensive testing is required after modification to ensure that no regressions have occurred.
It would be desirable to simplify the mediation to dynamically retrieve the configuration of the transformation based on the content of the inbound message. WebSphere ESB Registry Edition can do this retrieval by storing metadata regarding the mediation module within Service Registry. The encoding used for this metadata is WS-Policy, as shown in the example below:

Listing 1. Mediation policy document
<?xml version="1.0" encoding="UTF-8" ?> 
<wsp:Policy xmlns:wsrr="http://www.ibm.com/xmlns/prod/serviceregistry/6/2/wspolicy" 
  xmlns:sibx="http://www.ibm.com/wbi/mediation/200812/LanguageTransformer" 
  xmlns:wsp="http://www.w3.org/ns/ws-policy" 
  xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
      oasis-200401-wss-wssecurity-utility-1.0.xsd" 
  wsrr:policyClass="LanguageTransformer_CLASS" wsu:Id="LanguageTransformer_DefaultPolicy" 
  wsrr:policyClassDomain="http://www.ibm.com/wbi/mediation/200812/LanguageTransformer"> 
     <sibx:xsltStyleSheet value="http://mymachine.com/transforms/english.xsl" /> 
</wsp:Policy>

Once the metadata has been stored in Service Registry, you can simplify the logic of the mediation module to:

Figure 13. Mediation flow with policy enabled
Mediation flow with policy enabled
The mediation uses the Policy Resolution primitive that dynamically looks up the available policies associated with the module in Service Registry. Gate conditions can be attached that allow the selection of a particular policy depending on the content of the inbound message. In this example, the message passes the language identification to Service Registry, which returns the corresponding policy document with the configuration for the XSLT primitive, as shown below:

Figure 14. Mediation policy retrieval from Service Registry
Mediation Policy retrieval from Service Registry
For further information on setting up the Policy Resolution primitive, see the links below.
Conclusion
This article has described the key capabilities and usage scenarios for the new WebSphere ESB Registry Edition product. The article has shown how WebSphere ESB Registry Edition lets you leverage existing service enablement, create new services to quickly and dynamically connect service providers with service consumers, and visualize the impact of your SOA efforts to foster reuse and accelerate broad adoption.

Resources
About the authors
Andrew Borley photo Andrew Borley is an IT Specialist at IBM Hursley, UK. He has held various roles including developer, team leader, and project manager and has worked with various technologies in his 7 years at IBM. Since 2001 he has been working with customers on Service-Oriented Architecture projects, and his current role is developing the SCA for C++ implementation within the Apache Tuscany open source SOA project.
Photo of Callum Jackson Callum Jackson is a Software Engineer on the WebSphere ESB team at the IBM Hursley Software Lab in the UK. He has worked on the WebSphere ESB team since 2005, and before that he worked in Software Services on SOA applications for the telecommunications industry. You can contact Callum at callumj@uk.ibm.com.
작성자: 시간:
라벨: ,

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)