Skip to main content

What's new in WebSphere Enterprise Service Bus V6.2, Part 1: Overview

Brian Hulse (brian_hulse@uk.ibm.com), Software Engineer, IBM
Brian Hulse is a Senior Software Engineer on the WebSphere ESB team at the IBM Hursley Software Lab in the UK. He has worked in software development at Hursley for 20 years, the last five of which have been in the SOA arena. You can contact Brian at brian_hulse@uk.ibm.com.
Callum Jackson (callumj@uk.ibm.com), Software Engineer, IBM
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.
Amanda Watkinson (amanda.watkinson@uk.ibm.com), Software Engineer, IBM
Amanda Watkinson is a Software Engineer on the WebSphere ESB team at the IBM Hursley Software Lab in the UK. She has worked on the WebSphere ESB team since 2004, and before that she worked on a number of other WebSphere products. You can contact Amanda at amanda.watkinson@uk.ibm.com.

Summary:  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 binding capabilities, mediation primitives, and declarative flow control.

Date:  27 May 2009
Level:  Intermediate
Activity:  5275 views

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 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
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
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
  • JavaScript Object Notation (JSON) 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
Failed Event Manager Administration Console

New and enhanced mediation primitive support

Message logger enhancements


Figure 4. Message logger primitive
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
Message logger primitive custom handler support

New HeaderSetter mediation primitives


Figure 6. Header Setter primitive
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
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
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
TypeFilter 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 using the 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 anyType. This element can contain different business objects at runtime, such as HondaType or FordType:


Figure 10. Hierarchical car type structure
Hierarchical car type structure

The 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
TypeFilter 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 the Enabled property and altering the value of this property from true to false.


Figure 12. Enable/disable MessageLogger primitive
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.

Versioning

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 Version, Module, and Export fields.


Figure 13. EndpointLookup mediation primitive
EndpointLookup 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

The FanOut and 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 ServiceInvoke primitive within an aggregation block to be Async, as shown below:


Figure 14. ServiceInvoke mediation primitive
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 on the FanOut primitive, as shown below:


Figure 15. FanOut mediation primitive configuration
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
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
Business objects on either side of a DataHandler primitive

The 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:

  • JMS
  • MQ
  • HTTP
  • JCA

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 bindingType. The 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
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
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
Service Gateway Wizard

Further details on the Service Gateway pattern will be provided in Part 2.

Mediation policy

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.


Resources

About the authors

Brian Hulse is a Senior Software Engineer on the WebSphere ESB team at the IBM Hursley Software Lab in the UK. He has worked in software development at Hursley for 20 years, the last five of which have been in the SOA arena. You can contact Brian at brian_hulse@uk.ibm.com.

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.

Amanda Watkinson is a Software Engineer on the WebSphere ESB team at the IBM Hursley Software Lab in the UK. She has worked on the WebSphere ESB team since 2004, and before that she worked on a number of other WebSphere products. You can contact Amanda at amanda.watkinson@uk.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Close [x]

Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Close [x]

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=392401
ArticleTitle=What's new in WebSphere Enterprise Service Bus V6.2, Part 1: Overview
publish-date=05272009
author1-email=brian_hulse@uk.ibm.com
author1-email-cc=flanders@us.ibm.com
author2-email=callumj@uk.ibm.com
author2-email-cc=
author3-email=amanda.watkinson@uk.ibm.com
author3-email-cc=

Table of contents

Next steps from IBM

My developerWorks community

Interact, share, and communicate with developers worldwide.

My developerWorks overview

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

 

Dig deeper into WebSphere on developerWorks

DB2 pureScale

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers

No-cost WebSphere Application Server development

No Charge Code Lotus Domino Designer

SOA experts share best practices for SOA governance

More offers