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 V6.2, nor does it describe features in depth. It does provide an introduction to some new features in WebSphere ESB V6.2, 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.
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 V6.2, the support bindings included Web services, WebSphere MQ, Java™ Message Service (JMS), WebSphere MQ JMS, HTTP, or Service Component Architecture (SCA).
In V6.2, the Web service bindings have been enhanced to support Java API for XML Web Services (JAX-WS) and SOAP 1.2. When you select the Web Services export option in the tooling, you will see this full list of options:
Figure 1. Web service export options
The new options include the ability to expose the mediation to service requestors using different protocol specifications. The new bindings support SOAP1.2/HTTP and SOAP1.1/HTTP, which are listed as the first two options in Figure 1. For information on the different specifications, see Resources at the bottom of the article.
Using JAX-WS protocol bindings for exports and imports enables you to specify policy sets to describe the quality of service of the interaction. A policy set is a reusable artifact for the configuration of WS-* standards that you would like to associate with a JAX-WS binding. A default policy set can be defined for exports and imports within the tooling, as shown in Figure 2 below, or along with custom policy sets after deployment though the Integrated Solutions Console.
Figure 2. Applying a default policy set on an export using WebSphere Integration Developer
Enhanced transport protocol support
Prior to WebSphere ESB V6.2, bindings implemented their own transport-dependent data binding parsing logic for a message. If the same code was required by two bindings, then two transport-specific data bindings were required. WebSphere ESB V6.2 introduces Data Handlers to address this issue, and they let you write a single unit of code to process messages received across a number of transports. An example is a comma-delimited data handler that can be used across numerous bindings, such as HTTP, JMS, or MQ. V6.2 includes a number of built-in Data Handlers:
- Atom feed format
- Delimited format
- Fixed width format
- SOAP Data Handler
- WTX Invoker Data Handler
- WTX MapSelection Data Handler
- XML Data Handler
In addition, the fault support within bindings has been enhanced to enable the definition of a Fault Selector that determines if the message is a fault as well as the name of the fault. If the Fault Selector detects a fault, the current message will be processed by a Fault Handler rather than by a Data Handler. Similar to the Data Handler, the Fault Handler lets you create a message parsing capability that can be used across a number of transports.
Failed Event Manager
The Failed Event Manager has been included in WebSphere Process Server since V6.0, and WebSphere ESB V6.2 now includes this capability. When an SCA module is executing asynchronously within WebSphere ESB and the execution cannot complete due to a system failure, component failure, or component unavailability, a failed event is created and moved to the Failed Event Manager, which provides the following capabilities to handle such events:
- Browsing all failed events
- Searching for failed events by specific criteria
- Editing data for certain types of failed events
- Resubmitting failed events
- Deleting failed events
Administrative access to the Failed Event Manager is provided via the WebSphere ESB Administration Console:
Figure 3. Failed Event Manager Administration Console
New and enhanced mediation primitive support
Message logger enhancements
Figure 4. Message logger primitive
Prior to WebSphere ESB V6.2, the message logger mediation primitive logged the SMO to a specified database table schema. New in V6.2 is the ability to provide your own Java logging formatter, handler, and filter, which when passed the information from the mediation primitive can perform complex processing before logging the message to a custom location, such as a flat file or custom database. You can also configure the message logger out-of-the-box to log the message to a file in the system's temporary directory:
Figure 5. Message logger primitive custom handler support
New HeaderSetter mediation primitives
Figure 6. Header Setter primitive
Four new mediation primitives have been introduced in V6.2 to simplify protocol header manipulation within the SMO.
The primitives understand the header structure for the associated transport protocol, and you can use them to create new headers as well as modify the values of the header fields.
An example of using the
SOAPHeaderSetter is shown below, and it creates a SOAP header within the SMO of the following schema type:
Listing 1. Sample schema for a SOAP Header
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://CustomerService" xmlns:bons0="http://CustomerService" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="customerType" type="bons0:CustomerHeaderType"<>/xsd:element> <xsd:complexType name="CustomerHeaderType"> <xsd:sequence> <xsd:element minOccurs="0" name="type" type="xsd:string"<>/xsd:element> </xsd:sequence> </xsd:complexType> </xsd:schema>
You can browse for the element to be used as the SOAP header using the tooling as shown in Figure 7:
Figure 7. SOAP header Add/Edit menu
Figure 8 below shows additional editors that you can use to set the value of any selected element definitions:
Figure 8. Defining the properties of a new SOAP header business object
In addition to creating SOAP headers, this primitive can find headers within the incoming message and modify the value or delete them accordingly. The other three header setter primitives have similar functions.
New TypeFilter mediation primitive
Figure 9. TypeFilter mediation primitive
A number of methods are used to route messages down different paths within a mediation flow. For example, you can configure a
Message Filter mediation primitive
to route messages down one of multiple paths, depending on whether a particular XPath expression holds true. In WebSphere ESB V6.2 you can now route messages depending on the message type
Type Filter mediation primitive.
For example, you may have a message structure that can contain a number of different object types, as shown in Figure 10 below. The
Car business object
contains an element called
carType, which is an XML schema definition of
This element can contain different business objects at runtime, such as
Figure 10. Hierarchical car type structure
TypeFilter can have multiple output terminals that route the message down different paths, depending on whether the message type defined in the tooling matches the type
found at runtime:
Figure 11. TypeFilter mediation primitive branching CarTypes
Enabling and disabling primitives
Prior to WebSphere ESB V6.2, a mediation primitive was implicitly enabled by inclusion within a mediation flow path.
However, in V6.2, the
MessageLogger, EventEmitter and
MessageFilter mediation primitives can be disabled at runtime by promoting
Enabled property and altering the value of this property from
Figure 12. Enable/disable MessageLogger primitive
This feature lets administrators turn logging capabilities on and off at runtime, depending on whether they require messages to be logged or not. Additionally, the ability to enable or disable logging can be controlled via mediation policies, which are described briefly below and will be covered in more detail in Part 3. Mediation policies provide much more flexibility because you can control logging via the message content itself.
Mediation modules and libraries can be versioned so that you can use multiple versions in the same runtime environment. The exports and imports automatically inherit the version of the module, but you can configure imports administratively to use a specific version using the Integration Solutions Console.
Enhanced EndpointLookup mediation primitive
In WebSphere Integration Developer, support has been added to version an SCA module, thus enabling multiple versions of the same module to be deployed to a single WebSphere ESB cell.
As part of these enhancements, the
EndpointLookup primitive has been extended to include an option to return the latest version of an SCA binding,
which provides the ability to dynamically update the callout to the latest available SCA binding without the need to modify the module itself.
To enable this capability, set the
Match Policy in the
EndpointLookup properties panel to
Return endpoint matching latest compatible service version
and fill out the relevant
Figure 13. EndpointLookup mediation primitive
By default, the version number is based on the
<version>.<release>.<modification> convention. If you provide * it will retrieve the latest version available --
thus 1 will retrieve the latest 1.* version, and 1.1 will retrieve the latest 1.1.* version, and so on.
Enhanced aggregation scenarios
FanIn mediation primitives were introduced in WebSphere ESB V6.1, enabling information to be aggregated from numerous services.
In V6.1, invocations of services within an aggregation block were always completed in a thread waiting mode, where any request submitted via a
ServiceInvoke mediation primitive
caused processing in the mediation flow component to be suspended until the response was received. Now in V6.2, you can configure the
FanOut primitive to continue processing
between the request and response invocation steps, and therefore multiple outstanding requests can occur within an aggregation block.
There are two configuration steps required to enable multiple outstanding requests within an aggregation block. First, specify the invocation style of the
within an aggregation block to be
Async, as shown below:
Figure 14. ServiceInvoke mediation primitive
Second, if the aggregation is operating in iterate mode, then by default, the Mediation Flow Component will wait for the responses after each iteration.
To modify this behaviour to allow multiple iterations before retrieving the response, change the value of
Check for asynchronous response after X messages have been fired to 0
FanOut primitive, as shown below:
Figure 15. FanOut mediation primitive configuration
Setting it to 0 causes all possible invocations to occur before processing any response messages. For more information on possible values and the resulting behaviours, see Resources at the bottom of the article.
New DataHandler mediation primitive
Figure 16. DataHandler mediation primitive
This primitive can be used within a flow to convert native data to a business object and vice versa. For example, within a message you may have a String value that contains data that you want to convert to the business object representation of that data. In this example, the primitive converts a comma-delimited string into the Customer Business Object logical form:
Figure 17. Business objects on either side of a DataHandler primitive
DataHandler primitive is particularly useful in message gateway patterns, as described in Part 2.
Enhanced dynamic invocation
Prior to WebSphere ESB V6.2, dynamic invocation using the SMO target element was available for Web service and SCA invocations only. In V6.2 this dynamic invocation has been enhanced to support the following binding types:
Many of these protocols require special quality of service (QoS) parameters to be defined for the invocation, such as enabling security in certain situations. To enable QoS parameters,
use dynamic invocation support, and define an
Import on the Assembly Diagram with the particular QoS required. The Service Message Object (SMO) has two new optional attributes
associated with the
TargetAddressType that lets you reference the
Import name and
TargetAddressType is used to hold the dynamic endpoint URL.
Listing 2. TargetAddressType schema
<complexType name="TargetAddressType"> <sequence> <element name="address" type="anyURI"/> </sequence> <attribute name="import" type="string"/> <attribute name="bindingType" type="smo:BindingTypeType"/> </complexType>
Mediation encapsulation and reuse
In WebSphere ESB V6.1 or earlier, only one mediation flow component (MFC) could be placed inside a mediation module. In V6.2 you can place multiple MFCs inside a mediation module, and you can also place MFCs inside WebSphere Process Server modules, which enables greater flexibility for abstraction and interaction between different components without the need for additional deployable artifacts.
Mediation subflows are also new in WebSphere ESB V6.2. They enable common mediation logic to be reused across multiple mediation flows. The mediation subflows are run within the context of their parent flows. You can also nest subflows as well as promote internal subflow properties to the level of the parent flow, allowing dynamic control of subflow processing.
Service gateway patterns
The typical integration pattern within WebSphere ESB involves a single network addressable endpoint receiving a single type of service request, and a mediation flow component then provides the ability to manipulate the message before forwarding the request onto the service provider at a single addressable endpoint, as shown below:
Figure 18. Typical WebSphere ESB interaction pattern
A Service Gateway pattern differs in that a single network addressable endpoint is exposed that is configured to receive requests from a number of different service consumers, and these requests are for a number of different service providers. This pattern is different from the typical one-to-one mapping of consumer and provider within a Mediation Flow Component, and represents a many-to-many model:
Figure 19. Service Gateway interaction pattern
This new pattern adds many opportunities to simplify implementations where you want to complete some generic processing across all services. Within this generalized pattern are two sub-patterns that the Service Gateway can function in:
- Dynamic – Performs a common function for all the messages without requiring access to the body of the message.
- Static -- Performs a common function for all the messages that require access to the body of the message.
As a tooling accelerator, a new Service Gateway wizard guides you through the building of a new Static or Dynamic Service Gateway, as shown below:
Figure 20. Service Gateway Wizard
Further details on the Service Gateway pattern will be provided in Part 2.
Prior to 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 of the 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. New to WebSphere ESB V6.2 is that 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 during the current invocation of the flow. New to promoted properties in WebSphere ESB V6.2 is the concept of a group, which allows promoted properties that are concerned with a common area of interest to be tagged with a common and descriptive identifier.
Promoted properties can be considered as 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 lets you create a single mediation flow that varies depending on the content on the message being processed. This function will be described in Part 3.
- What's new in WebSphere Enterprise Service Bus V6.2, Part 2: Service gateway support
Part 2 describes the service gateway and policy capabilities.
- What's new in WebSphere Enterprise Service Bus V6.2, Part 3: Mediation policy
Part 3 describes dynamic configuration of mediation flows using mediation policy, including creation, storage, and use of a mediation policy to dynamically configure a mediation flow.
- JAX-RPC 1.1 versus JAX-WS 2.0
This developerWorks article compares these two Java Web services programming models.
- What's new in WebSphere ESB V6.1
This developerWorks article describes the new features in WebSphere ESB V6.1 and its associated tooling, WebSphere Integration Developer, including transport protocol binding, data bindings, and administrative and mediation support.
- 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.
- WebSphere Integration Developer information center
A single Web portal to all WebSphere Integration Developer documentation, with conceptual, task, and reference information on installing, configuring, and using your WebSphere Integration Developer environment.
- WebSphere Integration Developer information roadmap
Roadmap of articles and resources to help you with installation, migration, administration, development, troubleshooting, and understanding the underlying technology.
- WebSphere Integration Developer documentation library
WebSphere Integration Developer product manuals.
- WebSphere Integration Developer support
A searchable database of support problems and their solutions, plus downloads, fixes, problem tracking, and more.
- WebSphere SOA solutions developer resources page
Get technical resources for WebSphere SOA solutions.
- developerWorks SOA and Web services zone
Technical resources for evaluating, planning, designing, and implementing solutions that involve SOA and Web services.
- developerWorks WebSphere application connectivity zone
Access to WebSphere application connectivity (formerly WebSphere business integration) how-to articles, downloads, tutorials, education, product info, and more.
- developerWorks WebSphere business process management zone
Access to WebSphere BPM how-to articles, downloads, tutorials, education, product info, and other resources to help you model, assemble, deploy, and manage business processes.
- WebSphere business process management products page
For both business and technical users, a handy overview of all business process management products.
- WebSphere forums
Product-specific forums where you can get answers to your technical questions and share your expertise with other WebSphere users.
- Most popular WebSphere trial downloads
No-charge trial downloads for key WebSphere products.
- Trial downloads for IBM software products
No-charge trial downloads for selected IBM® DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® products.
- Technical books from IBM Press
Convenient online ordering through Barnes & Noble.
- developerWorks technical events and 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.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.