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

What's new in WebSphere Enterprise Service Bus V7

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 within WebSphere Integration Developer 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 that 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 does not cover every new feature and function in WebSphere ESB V7, nor does it describe features in depth. It does provide an introduction to some new features in WebSphere ESB V7, including enhancements to transport bindings, mediation primitives, mediation patterns, and policy control. To benefit from this article, you should have some experience with WebSphere ESB and basic technical knowledge of its features and functions. For a summary of the new features in WebSphere ESB V6.2, see What's new in WebSphere ESB V6.2.
New transport protocol support
In WebSphere ESB, you can invoke existing services through imports, while mediation modules are exposed to external applications using exports. Imports and exports can be associated with a transport-specific protocol binding, and prior to V7, the support bindings included Web services, WebSphere MQ, Java™ Message Service (JMS), WebSphere MQ JMS, HTTP, or Service Component Architecture (SCA).
EJB binding
In V7, the EJB binding has been enhanced to provide support for EJB exports as well as the already supported EJB imports. When you select the export and generate the binding, you will see a full list of the options, including the EJB binding:

Figure 1. EJB export bindings

The new option includes the ability to select whether the EJB binding should be EJB 2.1 or EJB 3.0 compliant. In addition, you can decide whether to expose the EJB as local, remote, or both. A wizard guides you through the process, as shown below:

Figure 2. EJB export binding configuration

Messaging binding
There have been a number of improvements to the messaging bindings for JMS and WebSphere MQ:

• Failed Event Manager support -- WebSphere ESB V6.2 introduced the Failed Event Manager, enabling failure messages that were sent asynchronously to be held and managed centrally. In V6.2 the JMS binding supported the Failed Event Manager, and in V7 this support has been enhanced to include WebSphere MQ bindings.
• Dynamic response destination -- The JMS binding has the built-in capability to dynamically generate a new destination queue for receiving the response message, which gives you additional flexibility when deciding which design approach to adopt.
• WebSphere MQ Resource Adapter Support -- The WebSphere MQ binding has been enhanced to include support for the WebSphere MQ Resource Adapter, so that you can take advantage of improved failover and load balancing support.

New and enhanced mediation primitive support
In WebSphere ESB, the core processing of the mediation occurs within the Mediation Flow Component, which is split into a mediation flow for each operation. These flows contain a number of pre-built mediation primitives that are wired together to complete the required processing. This section describes enhancements to the pre-built mediation primitives in WebSphere ESB V7.
Flow Order primitive
The Flow Order primitive has been introduced in V7 to enable deterministic branch firing logic within a mediation flow. Before V7, if you wanted to branch the mediation flow, the order of execution of these branches was nondeterministic. The Flow Order primitive lets you order branching logic by creating separate terminals for each branch and connecting a single wire to each, as shown below:

Figure 3. Flow Order mediation primitive

Gateway Endpoint Lookup primitive
WebSphere ESB V6.2 introduced the Service Gateway capabilities, and as part of a continued drive to provide first-class support for the Service Gateway pattern, a new primitive has been added that is dedicated to routing patterns in a Service Gateway. This primitive is focused on Web service endpoint resolution and has three different modes of operation:

• URL -- Use when the unique identifier is available at the end of the URL to provide the service identification information that can be used as a token to determine the endpoint address to which to forward the message. In this mode of operation, the configuration data is stored within the built-in configuration store (for more information on this pattern, see the Proxy Gateway section below).
• XPath-- Lets you specify an XPath expression that resolves into a unique identifier across all the services the Gateway is being used for. You can then use this identifier as a token to determine the endpoint address to which to forward the message. In this mode of operation, the configuration data is stored within the built-in configuration store (for more information on this pattern, see the Proxy Gateway section below).
• Action-- Every Web service request has a SOAPAction value specified, and if enabled, 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 primitive, the action value is determined from the ServiceMessageObject, and WebSphere Service Registry and Repository is queried to find WSDL ports that have the same Action value. Similar to the Endpoint Lookup primitive, you can specify user defined properties and classifications for this mode of lookup.

Figure 4. Gateway Endpoint Lookup primitive

By default, the primitive is configured in URL mode and no additional configuration is required. However a Proxy Group should usually be specified, as described below. If XPath mode is required, an XPath expression must be included in addition to the Proxy Group configuration. Finally if Action is required, then communication with WebSphere Service Registry and Repository (hereafter called WSRR) is a prerequisite, and therefore the WSRR instance name must be specified if the default value is not acceptable.
In general, action-based routing is used within a Dynamic or Static Service Gateway, while the URL and XPath modes are used only in the new Proxy Gateway pattern, which is described below. Regardless of the lookup method used, the target, alternative addresses, and endpoint lookup context within the ServiceMessageObject will be populated with the results of the lookup.
Message Validator primitive
The Message Validator Primitive lets you validate either the whole or part of the Service Message Object against the schema information. In addition to validation against the interface schema, if any assertions have occurred via primitives such as a SetMessageType primitive, then these assertions will also be validated. In the example in Figure 5, a message is validated before being transformed. If the validation fails, then the flow will be failed to prevent any downstream failures.

Figure 5. Message Validator primitive

Policy Resolution primitive
Before the introduction of mediation policies, a mediation flow could only be controlled using promoted properties. Any property promoted from a mediation flow is visible in the administrative console and can be changed so that the flow configuration is changed. Any such changes to the promoted properties affect all flows that reference the properties, and the change is permanent within the deployed application until the value is once again altered in the administrative console. In WebSphere ESB V6.2, any property that can be promoted is available for dynamic update via mediation policy, but any changes that are affected via policy control only have a lifetime of the current invocation of the flow.
Promoted properties can be considered points of variability within any mediation flow, with the mediation policies used to define what values are used at those points of variability. Mediation policies use the WS-Policy format, and there is a simple mapping between the concepts used in WS-Policy and those defined by WebSphere ESB in promoted properties. The capability allows the creation of a single mediation flow that varies depending on the content on the message being processed.
In WebSphere ESB V6.2, mediation policy documents were attached only to SCA module representations within WSRR. New in WebSphere ESB V7 is the ability to extend this support to attaching mediation policy documents to target services, enabling customization of the mediation flow based on the service to which the request is forwarded. The Policy Resolution primitive now has three modes of operation:

• Module – Default setting and same logic as in V6.2.
• Target Service – The ability to look up mediation policies within WSRR based on the target service information specified within the ServiceMessageObject (automatically populated by the Endpoint Lookup Primitive)
• Intersection of Module and Target Service – this provides the capability to query WSRR for mediation policy information associated with both the Module and Target Service. The query will succeed only if a mediation policy can be found that conforms to both levels, enabling a flow to seek policy conformance from both Module and Target Service.

These options are shown below:

Figure 6. Policy Resolution primitive

For more information on the resolution of mediation policy support for target services and modules, see Resources at the bottom of the article.
SLA Check primitive
In WSRR V7, the Governance Enablement Profile provides the new capability for Service Level Agreements, which enables the creation of agreements between clients, mediations, and services (in WebSphere ESB terminology). The agreement expressions are shown below:

Figure 7. SLA class diagram

• Service Level Definition (SLD) -- Provides a formal specification of the quality of service used to send messages to a service, and references the network addressable endpoints.
• Service Version -- Provides a formal statement of the service capabilities referencing an associated SLD for the functional and non-functional specification. Each Service Version may have a consumer identifier that is used when the service is acting as a client on other services.
• Service Level Agreement (SLA) -- Provides a formal specification of the dependencies that a particular Service Version may have on other defined services. These dependencies are represented as a SLA having dependencies on SLDs. Multiple SLAs may be associated with a single Service Version and therefore a contextId can be associated with each SLA to enable the selection of the desired SLA.

In WebSphere ESB there are three patterns between a client, mediation, and provider. Highlighted in red below is the data sent via the SLA primitive to WSRR:

Figure 8. SLA between a client and mediation


Figure 9. SLA between a client and provider


Figure 10. SLA between a mediation and provider

The SLA mediation primitive lets you define an SLA check expression, which must include an endpoint and optionally a context and/or consumer ID. The final setting is the registry name, which identifies which WSRR should be used to evaluate the SLA check.

Figure 11. SLA Mediation primitive panel

Trace primitive
During the development of a mediation flow, it can be useful to put out a trace message to a file -- either the standard WebSphere ESB SystemOut.log, or a separately specified file. To enable this capability, a new Trace mediation primitive has been added in WebSphere ESB V7. The primitive has a number of properties, as shown below:

Figure 12. Trace Mediation Primitive panel

• Enabled – Similar to other primitives, provides the ability to enable or disable the primitive's functionality. A promotable property.
• Destination -- Specifies the location where the trace statement should be added, either Local Server Log (SystemOut.log), User Trace (UserTrace.log), or File (User-defined).
• File path -- Specifies the location of the trace file when the destination field is specified as File.
• Message -- Defines the message format that should be traced: {0} = time stamp, {1} = Message ID, {2} = Mediation name, {3} = Module name, {4} = Message defined by the root property, {5} = Version of the SMO
• Root path -- XPath expression that identifies what section of the SMO should be serialized into the message. Additional explanatory text can also be included.

It is worth realising this new primitive enhances and simplifies the existing tracing mechanisms available and would not be expected to be used in a production system where the existing MessageLogger or EventEmitter primitives would be more suitable.
UDDI Primitive
Universal Description Discovery and Integration (UDDI) is a standard for publishing and finding service descriptions within a network. Mapping between WSDL and UDDI concepts is explained below in order to clarify the integration provided in WebSphere ESB V7. For further information on UDDI, see Resources at the bottom of the article.

• BusinessEntity – Provides information about the business and contains one or more BusinessServices.
• BusinessService – Contains technical and business descriptions for a Web service and is similar to a WSDL Service.
• BindingTemplate – Similar to the WSDL port.
• tModel – Defines the technical specification for a service. Does not have a direct association with a section of the WSDL, but is derived from its service interface section.

The UDDI primitive provides first-class support for integration with UDDI repositories such as the WebSphere Application Server UDDI. The details section enables configuration of the UDDI registry name and associated query information. If the lookup is successful, the relevant header and context sections of the SMO are updated similar to the Endpoint Lookup Primitive. There are three possible match policies:

• Return first matching endpoint and set routing target -- A target address is populated into the headers section, and any relevant registry information associated with this endpoint is populated into the Endpoint Lookup Context.
• Return all matching endpoints -- All returned endpoint information is populated into the Endpoint Lookup Context, but no target address is populated into the SMO header section.
• Return all matching endpoints and set alternate routing targets -- Similar to the above, but the target and alternative fields of the SMO header are populated.

Fail primitive enhancements
In V7, the Fail primitive has been enhanced to support dynamic message generation in addition to the static field previously available. You can now specify an error message using the following substitutions:

• {0} – Time stamp value
• {1} – SMO Message ID value
• {2} – Mediation name value
• {3} – Module name value
• {4} – Serialized section of the SMO specified within the Root Path field
• {5} – SMO version value

These settings are shown in below:

Figure 13. Fail primitive panel

WSRR Query API
Prior to WebSphere ESB V7, the only two built-in mechanisms to communicate with WSRR were the Endpoint Lookup and Policy Resolution primitives. In WebSphere ESB V7, a new query API has been introduced that lets you create bespoke queries within a custom mediation and submit them to WSRR while taking advantage of the built-in caching mechanism. For a full API guide for interaction with WSRR, see the WebSphere ESB information center.
Endpoint Lookup primitive enhancements
Previously, the Endpoint Lookup primitive supported Web service endpoints and SCA exports. WebSphere ESB V7 adds support for the following protocols:

• MQ endpoints
• JMS (SIB, MQ, and generic) endpoints
• SCA-based endpoints: MQ, JMS, Web services, SCA, and HTTP
• HTTP endpoints

The new support in the primitive lets you querying either a single protocol, all protocols, or the existing behaviour of Web service and SCA endpoints, as show below:

Figure 14. Endpoint Lookup primitive panel

Business Space support for WebSphere ESB
Business Space is a Web-based interface that lets you control and manage the applications installed on the system. Primary users are IT and Solution Administrators who want to manage installed applications. It was introduced to WebSphere ESB V6.2 and let you view deployed SCA modules. In V7, capabilities have been extended to include managing Mediation Policies and Proxy Gateways.
Proxy Gateway support
WebSphere ESB V6.2 supported the creation of Service Gateways, providing great flexibility in creating numerous possible gateway patterns. This flexibility has the side effect of increasing the development time of the solution. WebSphere ESB V7 introduces a new pattern called the Proxy Gateway to provide a quicker out-of-the-box experience. The Proxy Gateway lets you create a WebService Service Gateway with built-in routing, and resolved WSDL that can be used for client generation. Here is a diagram of the new Proxy Gateway concept:

Figure 15. Proxy Gateway

A number of service providers have been identified that will be exposed through a Gateway, and they are logically grouped into a Proxy Group, which is a collection of services. During the development of a Proxy Gateway, a linkage is established to one or more Proxy Groups. For each service within the Proxy Group, a corresponding Virtual Service is exposed on the Proxy Gateway, so that service requests can be automatically routed from the virtual service to the real service, completing any gateway logic within the mediation flow component.
Once the Proxy Gateway has been developed in WebSphere Integration Developer and installed on the runtime, the IT/Solution Administrator can log into Business Space and view the relationships between Proxy Gateway, Proxy Group, and Virtual Services. Figure 16 shows the Proxy Gateway widget that initially on loading shows the Proxy Groups and the associated Proxy Gateways:

Figure 16. Proxy Gateway BusinessSpace widget showing the relationship between Proxy Groups and Proxy Gateways

Clicking on the Proxy Group pencil transforms the widget to display the virtual services associated with the Proxy Group, as shown below:

Figure 17. Proxy Gateway BusinessSpace widget showing virtual services within a Proxy Group

Mediation Policy support
The support for Mediation Policies within Business Space removes the requirement for the creation and deletion of mediation policies via the WSRR console. Business Space has three associated widgets:

• Service Browser – Lets you view the services imported to WSRR. These services can then have mediation policies attached that will later be enforced by the runtime.
• Module Browser – Lets you view the modules that have been installed on the WebSphere ESB system.
• Mediation Policy Administration – Once either a service or module has been selected in the corresponding widget (Module Browser or Service Browser) the associated mediation policies are displayed in the Mediation Policy Administration widget. In addition to viewing mediation policies, you can also create and delete policies.

These new widgets provide a dedicated interface that removes many of the generic WS-Policy steps that were previously required when using the WSRR console. Users of the interface need little understanding of the WS-Policy specification in order to define their mediation policy.

Figure 18. Module Browser BusinessSpace widget


Figure 19. Service Browser BusinessSpace widget


Figure 20. Mediation Policy Administration BusinessSpace widget

Managing and monitoring extensions
This section describes new capabilities in WebSphere ESB V7 to enhance the managing and monitoring features.
Service monitoring with Business Space
The Service monitoring widget within BusinessSpace measures the response time and request throughput for services invoked by and exposed by an SCA module. You choose what operations to monitor on the services exposed to requestors (Exports) and consumed (Imports), and you can optionally define thresholds for response time and throughput, thus providing powerful out-of-the-box monitoring capability for SCA modules. Here is an example of the output provided:

Figure 21. Service Monitor widget within BusinessSpace

In addition, for a complex, multiple SCA module solution, this capability helps you determine which parts of the solution are consuming the majority of the time.
Health and problem determination with Business Space
An integral part of administering a solution is tracking the health of the overall system, as well as the health of the administrative artifacts in a module, such as queues, messaging engines, data sources, servers, and clusters. The Module and System Health widgets provide a single interface to quickly check the status of the solution to verify the following information:

• Which applications are running
• Which servers within the topology are started, stopped, or unavailable
• Defined maximum depth of queues and how close you are to the limit
• Which messaging engine artifacts are running
• Any failed events in the module

Figure 22. System Health widget within BusinessSpace

Cross-Component Trace
Cross-Component Trace lets you track messages through SCA modules and components. It adds standard out trace statements that are parsed by a viewer in WebSphere Integration Developer. New in WebSphere ESB V7 is the ability to track the progress of the message through individual primitives instead of simply at the mediation component level. Here is an example:

Figure 23. Cross-Component Trace

Event sequencing
Before WebSphere ESB V7, event sequencing was limited to WebSphere Process Server runtimes, but in V7 event sequencing is included in the WebSphere ESB V7 runtime. Event sequencing enables WebSphere ESB components to process events from asynchronous invocations in the order in which they are delivered. Event order is maintained throughout the entire scenario. For some implementations, you can require that the target component process events in the same order in which they were sent by the source application; processing them out of order can cause errors or exceptions. In these cases, you can enable the Event Sequence on asynchronous Exports and SCA components to enable the capabilities:

Figure 24. Enabling event sequencing


Resources

• What's new in WebSphere ESB V6.1
  This article describes new and enhanced features in WebSphere ESB 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, Part 1: Overview
  This article series describes new and enhanced features in WebSphere ESB V6.2 and its associated tooling, WebSphere Integration Developer, including transport protocol bindings, data bindings, mediation primitives, and declarative flow control. Part 1 provides an overview of the new features.
  
  
• What's new in WebSphere ESB V6.2, Part 2: Service Gateway patterns
  Part 2 describes the Service Gateway and Service Policy features of WebSphere ESB V6.2.
  
  
• Understanding WSDL in a UDDI registry
  This article describes the different ways you can use WSDL with UDDI registries, depending on the needs of the needs of your application.
  
  
• Using the new WSRR API in WebSphere ESB
  This topic in the WebSphere Integration Developer information center shows you how to query Websphere Service Registry and Repository inside a Custom Mediation primitive.
  
  
• 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 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 documentation library
  WebSphere ESB product manuals.
  
  
• WebSphere ESB FAQs
  Basic questions and answers about the new WebSphere ESB product and its relationship to other WebSphere products.
  
  
• WebSphere ESB support
  A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
  
  
• Redbook: Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB
  Patterns for e-business are a group of proven, reusable assets that can be used to increase the speed of developing and deploying e-business applications. This Redbook shows you how to use WebSphere ESB together with WebSphere Message Broker to implement an ESB within an SOA. Includes scenario to demonstrate design, development, and deployment.
  
  
• WebSphere Integration Developer developer resources page
  Technical resources to help you use the WebSphere Integration Developer IDE to render your existing IT assets as service components, encouraging reuse and efficiency as you build SOA-based integration solutions across WebSphere Process Server, WebSphere ESB, and WebSphere Adapters.
  
  
• WebSphere Integration Developer product page
  Product descriptions, product news, training information, support information, and more.
  
  
• developerWorks WebSphere developer resources
  Technical information and resources for developers who use WebSphere products. developerWorks WebSphere provides product downloads, how-to information, support resources, and a free technical library of more than 2000 technical articles, tutorials, best practices, IBM Redbooks, and online product manuals.
  
  
• developerWorks WebSphere application connectivity developer resources
  How-to articles, downloads, tutorials, education, product info, and other resources to help you build WebSphere application connectivity and business integration solutions.
  
  
• developerWorks WebSphere business process management developer resources
  WebSphere BPM how-to articles, downloads, tutorials, education, product info, and other resources to help you model, assemble, deploy, and manage business processes.
  
  
• developerWorks WebSphere SOA and Web services developer resources
  How-to articles, downloads, tutorials, education, product info, and other resources to help you design and build WebSphere SOA and Web services solutions.
  
  
• Most popular WebSphere trial downloads
  No-charge trial downloads for key WebSphere products.
  
  
• WebSphere forums
  Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
  
  
• WebSphere on-demand demos
  Download, watch, and learn what WebSphere products and WebSphere-related technologies can do for your company.
  
  
• developerWorks WebSphere weekly newsletter
  The developerWorks newsletter gives you the latest articles and information only on those topics that interest you. In addition to WebSphere, you can select from Java, Linux, Open source, Rational, SOA, Web services, and other topics. Subscribe now and design your custom mailing.
  
  
• WebSphere-related books from IBM Press
  Convenient online ordering through Barnes & Noble.
  
  
• WebSphere-related events
  Conferences, trade shows, Webcasts, and other events around the world of interest to WebSphere developers.
  
  
• developerWorks blogs
  Join a conversation with developerWorks users and authors, and IBM editors and developers.
  
  
• developerWorks Webcasts
  Free technical sessions by IBM experts that can accelerate your learning curve and help you succeed in your most difficult software projects. Sessions range from one-hour Webcasts 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.
  

About the author

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.

Close [x]

Report abuse help