2012년 1월 2일 월요일

[DeveloperWorks] What's new in WebSphere Enterprise Service Bus V7.5

What's new in WebSphere Enterprise Service Bus V7.5 

Introduction
IBM® WebSphere® Enterprise Service Bus (hereafter called WebSphere ESB) enables the integration of disparate systems by managing the requests and responses that flow between different services. Mediation modules are authored in IBM Integration Designer and encapsulate the service interaction logic to be deployed within the WebSphere ESB runtime. Within the mediation module, messages can be augmented, transformed, logged, and routed to different service providers depending on one or more mediation primitives, which define the message flow logic. Messages themselves are represented in a logical structure called the Service Message Object (SMO). For more information on the architecture of WebSphere ESB, see Resources at the bottom of the article.
This article describes the new features and enhancements in WebSphere ESB V7.5. It does not attempt to cover every new feature and function, nor does it attempt to describe every area in great depth. Instead, it introduces you to some of the new areas in WebSphere ESB V7.5, starting with the enhancements to the tooling environment IBM Integration Designer, then moving on to the mediation programming model, primitives, and finally performance.
IBM Integration Designer Test Client enhancements
The Generic Service Client provides a single interface for testing services exposed using Web Service, HTTP, JMS, and WebSphere MQ bindings. It is useful for debugging or testing a service when a dedicated client is unavailable. To access it, right-click on a module and select Test Endpoints => Generic Service Client. To access a Web service, add a WSDL file to the Request Library and select a port. This procedure provides a simple way to modify the request message (including attachments), and the transport details (including the protocol, endpoint, and method). To access services using HTTP, JMS, or WebSphere MQ, add an endpoint to the Request Library.

Figure 1. Generic Service Client
Generic Service Client
Transport configuration is accessed via the Transport tab, where multiple configurations can be stored for later access. The MQ transport configuration is shown below:

Figure 2. MQ configuration of the Generic Service Client
MQ configuration of the Generic Service Client
Test suites can be generated automatically for use with IBM Rational® Service Tester or IBM Rational Performance Tester. Test cases for module testing within IBM Integration Designer can now be generated directly from a previously captured execution trace. To access this feature, right-click on an Invoke event in the Integration Test Client and select Create Test Case:

Figure 3. Generating a test case from the Integration Test Client
Generating a test case from the Integration Test Client
A dialog box will open prompting you to specify the test project and test suite for the new test case:

Figure 4. Generating a new test case
Generating a new test case
A new test case is generated containing the configuration used for the original execution. Executing the test case checks whether the result matches the result of the original execution, as shown below:

Figure 5. Results from test suite
Results from test suite
Enhanced transformation: XSLT2
The XSLT mediation primitive has been enhanced to support XSLT2, and you can transform the SMO using the full array of built-in functions in the specification. The Mapping Editor has been enhanced to surface the new functionality once the mediation developer selects Version 2 for the XSLT engine:

Figure 6. XSLT2 support
XSLT2 support
Pattern-based integration: Service Selector and Service Translator
The Patterns Explorer in IBM Integration Designer V7.5 provides two new service virtualization patterns. These patterns enable you to quickly and easily generate new mediation modules with pre-defined mediation flows to accomplish particular tasks.
  • Service Selector pattern -- Enables you to group multiple implementations of the same service interface behind a single proxy service. Each implementation can have a different quality of service or behaviour, and each client request can be matched to a particular service implementation determined by different criteria. You can use this pattern to:
    • Balance loads across multiple implementations or deployments
    • Support higher quality of service for selected clients
    • Route requests to a specific version of a service
    • Partition data; for example, process accounts on a geographical basis through a single logical service interface
    • Translate data for different clients
  • Service Translator pattern -- Enables you to access a given service implementation with a different interface provided on a proxy service. You can select operations to be restricted or restructured on some interfaces, and you can convert and format data for users of specific interfaces. You can use this pattern to:
    • Restrict functionality on an existing interface
    • Predetermine certain parameters according to local business requirements
    • Modify an interface to conform to local business requirements
    • Provide an interface that matches a requesting service's interface
To access the list of patterns, open the Patterns Explorer view in IBM Integration Designer and select one of the patterns to open the Pattern Specification view, which provides more information about the pattern. To create an instance of the pattern, click Create New Pattern:

Figure 7. Creating a new pattern instance
Creating a new pattern instance
When a new pattern instance is created, the Pattern Configuration Editor opens so that you can set the parameters required by the pattern. For the Service Selector pattern, here are the configurable parameters:
  • Service interface – Interface of the service being proxied.
  • Transport protocols – Define the transport protocol that the proxy service provides and the protocols that the provider services support. All standard WebSphere ESB transport protocols are supported.
  • Routing – Defines how the Service Selector proxy service will select one of the service provides at runtime. Three options: use an element from the request message, via your own Java code, or retrieve the selection from a database. All three options change the mediation primitives used in the generated mediation flows.
  • Logging and tracing – Define whether and how logging and tracing occurs when the proxy service is called. Logging can be to a database, via Java custom logging, or as events emitted to a CEI server. Logging and tracing can be switched on or off for the request, response, and modelled fault flows.

Figure 8. Configuring the Service Selector pattern instance
Configuring the Service Selector pattern instance
When the pattern parameters are set, click Generate to create the artifacts required for the Service Selector proxy service, including a pattern summary that details the generated artifacts and linked images of the assembly diagram and mediation flows, as shown below:

Figure 9. Summary of the Service Selector pattern
Summary of the Service Selector pattern
Click on the linked images to go to the appropriate editor page for the artifact. To complete the Service Selector module development, you can edit the Mediation Request flows to select a provider service. A note with the title TODO has been added to any artifacts that require further configuration. In this case, the generated Database Lookup mediation primitive must be configured to retrieve selection information from a database and add it to the SMO, and the generated Message Filter primitive must then be configured to use this information to determine which provider service callout node to route the message to:

Figure 10. Generate flow for the Service Selector pattern
Generate flow for the Service Selector pattern
When the configuration is completed, the generated Mediation Module is ready to be deployed to act as your Service Selector proxy, accepting messages sent to your proxy service, and selecting one of your provider services to send the message on to.
For the Service Translator pattern, here are the configurable parameters:
  • Service interfaces – Select the interfaces of both the provider service and the proxy service being created.
  • Operation and fault mappings – Define how operations on the proxy service interface map to operations on the provider service interface. If a proxy service operation with modelled faults is mapped to a provider service operation with modelled faults, you can also define how the faults map to each other.
  • Transport protocols – Define the transport protocol that the proxy service provides and the protocol that the provider service supports. All standard WebSphere ESB transport protocols are supported.
  • Logging and tracing – Define whether and how logging and tracing occurs when the proxy service is called. Logging can be to a database, via Java custom logging, or as events emitted to a CEI server. Logging and tracing can be switched on or off for the request, response, and modelled fault flows.

Figure 11. Configuring the Service Translator pattern instance
Configuring the Service Translator pattern instance
When the pattern parameters are set, click Generate to create the artifacts required for the Service Translator proxy service, including mediation flows that map the operations on the proxy and provider interfaces as specified in the pattern parameters:

Figure 12. Service Translator operation overview
Service Translator operation overview
As in the Service Selector pattern, a pattern summary is created that details the generated artifacts. Again, to complete the Service Translator module development, you can edit the mediation flows to define any required message type mappings. A note with the title TODO has been added to any artifacts that require further configuration. In this case, the generated XSL Transformation primitives must be edited to define the mapping between the incoming and outgoing messages:

Figure 13. Service Translator flow
Service Translator flow
When the configuration is complete, the generated Mediation Module is ready to be deployed to act as your Service Translator proxy, translating messages sent to your proxy service to those required by your provider service.
Error flows
An error flow is a new type of mediation flow that catches all unhandled errors. A mediation flow generated using IBM Integration Designer V7.5 automatically includes a single error flow within each operation, as shown below. Mediation flows that are migrated to use the text-based mediation flow format will have an empty error flow added to the operation.

Figure 14. Error flow
Error flow
The error flow consists of an Error Input node, the entry point to the flow, an Input Response node for optionally returning a response, and an Input Fault node for each modelled fault, if defined. The flow can contain any combination of mediation primitives and can be used to log errors, handle errors externally through the use of Service Invoke primitive, or end the flow with an unmodelled fault by using a fail primitive. The error flow is invoked when an unwired fail terminal is encountered in a request or response flow, including the fail terminal on the Callout Response node. If an unwired fail terminal is encountered in the error flow itself, or if the error flow is not wired, then the flow will fail with an unmodelled fault. After the processing of the error flow is complete, the request or response flow is abandoned and no further processing occurs. A response or fault returned by the error flow replaces any response previously created by other flows.
Simplified XML flow format
In WebSphere ESB V7.5, the mediation flow component serialized form has been improved to a simple XML format. Mediation flows that are generated using IBM Integration Designer V7.5 will automatically use the new format. Mediation flows that have been created using previous versions of the tooling can be easily converted to the new format.
Previously, flows were serialized using XMI, and the mediation flow component consisted of three separate files: A .mfc file contained the interfaces and references, .medflow contained the component's implementation, and .mfcex was used for tooling extensions such as sticky notes. A change to the mediation flow component could result in all three files being modified.
The new simple XML format uses a single .mfc file to store all required information. The element and attribute tags have meaningful names and structure, so that operations are contained within interfaces and themselves contain request, response, and error flows. All mediation primitives are specified by name, and their property names and values are documented in the information center along with sample XML. Rewiring primitives is a simple case of modifying the targetNode property of a wire element, as shown below. These improvements encourage team-based development by simplifying compare and merge operations.

Figure 15. Comparing two versions of new XML flow format
Comparing two versions of new XML flow format
Service Level Agreement (SLA) Endpoint Lookup mediation primitive
The Governance Enablement Profile within WebSphere Service Registry and Repository provides the framework to model the capabilities (services) and relationship between them within your business. At the high level, each capability within your business can be separated into six core sections:
  • Organization -- Parts of the business,such as Finance or HR who may own capabilities within the business
  • Business capabilities -- The abstract concept of a capability within the business, such as a credit check service
  • Capability version -- A 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 16. 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 represents the providers and consumers within your business. You can then use SLAs to establish formal agreements at a defined level, such as message by day, between the capabilities:

Figure 17. Relationship between a consumer and provider
Relationship between a consumer and provider
Within WebSphere ESB, you can look up the network-addressable endpoint of a service provider based on established SLAs with WebSphere Service Registry and Repository using the SLA Endpoint Lookup mediation primitive:

Figure 18. Properties of SLA Endpoint Lookup mediation primitive
Properties of 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 WebSphere Service Registry and Repository.
Service Invoke mediation primitive enhancements
A new mode of operation called Message Enrichment Mode has been added to the Service Invoke mediation primitive to enable service invoke requests to be constructed from parts of the SMO and responses to be easily merged back into the SMO being processed in the mediation flow. So in this way, the same SMO passes through the Service Invoke and is augmented with information from the response to the service invoke. This process removes the need for additional transformation logic before and after the service invoke primitive, which in previous releases was required to achieve this scenario.
For example, imagine a scenario where a back-end service is used to augment a message with a customer's detailed address information. A single service invoke primitive can now construct a new request message containing the customer id information and send it to a back-end service. It can then merge the completed address in the response back into the SMO at a specific point, and flow the whole message on for further processing in the flow. In this way, the Service Invoke primitive can now be chained together to simply merge input from several services. Transport headers can be optionally propagated from the SMO into the request for the Service Invoke and can be merged back into the SMO from the response.
When the Service Invoke mediation primitive is added to the canvas, a dialog opens to ask you to configure the reference operation to be used to invoke the back-end service. At this point, you can select the new Message Enrichment Mode. This decision will change the configuration required for the Service Invoke primitive and can be reversed later only by deleting and recreating the primitive on the canvas.

Figure 19. Select Message Enrichment Mode when creating a Service Invoke primitive
Select Message Enrichment Mode when creating a Service Invoke primitive
Once Message Enrichment Mode is selected and the Service Invoke primitive is created and wired into the flow, new configuration parameters appear in the Properties panel of the primitive. For each input, output, or fault part of the interface of the reference operation used for the Service Invoke, you must select an XPath expression to identify its mapping to the SMO flowing through the primitive:

Figure 20. Defining the input and output arguments
Defining the input and output arguments
In addition to the parameter mappings, you can choose to propagate headers from the SMO into the request and also to propagate headers from the response back into the SMO.
Conclusion
This article described new features and enhancements in WebSphere ESB V7.5, including enhancements to the IBM Integration Designer tooling, the mediation programming model, primitives, and performance. For more information, see the links below.

Resources
  • IBM Integration Designer resources
  • WebSphere ESB resources
    • WebSphere ESB information center
      A single Web portal to all WebSphere ESB documentation, with conceptual, task, and reference information on installing, configuring, and using WebSphere ESB.
    • WebSphere ESB developer resources page
      Technical resources to help you use WebSphere ESB as a flexible connectivity infrastructure for integrating applications and services to support an SOA.
    • WebSphere ESB product page
      Product descriptions, product news, training information, support information, and more.
    • WebSphere ESB FAQs
      Common questions about WebSphere ESB and its relationship to other ESB products.
    • WebSphere ESB support
      A searchable database of support problems and their solutions, plus downloads, fixes, and problem tracking.
    • WebSphere ESB development guide
      WebSphere ESB development guide manual in PDF format.
    • WebSphere ESB documentation library
      WebSphere ESB product manuals in PDF format.
    • What's new in WebSphere ESB V6.1
      This developerWorks article describes new features in V6.1 and its associated tooling, WebSphere Integration Developer, including transport protocol bindings, data bindings, and administrative and mediation support.
    • What's new in WebSphere ESB V6.2
      This developerWorks article describes new features in V6.2 and its associated tooling, WebSphere Integration Developer, including transport protocol bindings, data bindings, mediation primitives, and declarative flow control.
    • What's new in WebSphere ESB V7
      This developerWorks article describes new features in V7 and its associated tooling, WebSphere Integration Developer, including transport protocol bindings, mediation primitives, and policy control.
  • WebSphere resources
  • developerWorks resources
    • Trial downloads for IBM software products
      No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
    • developerWorks blogs
      Join a conversation with developerWorks users and authors, and IBM editors and developers.
    • developerWorks tech briefings
      Free technical sessions by IBM experts to accelerate your learning curve and help you succeed in your most challenging software projects. Sessions range from one-hour virtual briefings to half-day and full-day live sessions in cities worldwide.
    • developerWorks podcasts
      Listen to interesting and offbeat interviews and discussions with software innovators.
    • developerWorks on Twitter
      Check out recent Twitter messages and URLs.
    • IBM Education Assistant
      A collection of multimedia educational modules that will help you better understand IBM software products and use them more effectively to meet your business requirements.
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.
Philip Norton Philip Norton is a software engineer at IBM Hursley Lab. He works on the WebSphere ESB Development team. His expertise includes Java and JMS for Websphere MQ. He is a certified Java Programmer and he has a degree in Computer Science from Canterbury University.
Alex Wood Alex Wood works at IBM Hursley Lab in England as a Software Developer for the IBM WebSphere Business Integration suite of products. He has extensive experience in development on many of the WebSphere products, including WebSphere MQ, WebSphere Message Broker, WebSphere Enterprise Service Bus, and WebSphere Process Server. He received a BSc in Physics with Astrophysics from Birmingham University in the United
작성자: 시간:
라벨: ,

댓글 없음:

댓글 쓰기

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