What's new in WebSphere Enterprise Service Bus V7

This article describes new and enhanced features in WebSphere ESB V7 and its associated tooling, WebSphere Integration Developer, including transport protocol bindings, mediation primitives, and policy control.


Callum Jackson (callumj@uk.ibm.com), Software Engineer, IBM

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.

05 May 2010 (First published 05 May 2010)

Also available in Chinese Russian


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
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
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
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
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
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
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
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
SLA between a client and mediation
Figure 9. SLA between a client and provider
SLA between a client and provider
Figure 10. SLA between a mediation and provider
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
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
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
Fail primitive panel


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
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
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
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
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
Module Browser BusinessSpace widget
Figure 19. Service Browser BusinessSpace widget
Service Browser BusinessSpace widget
Figure 20. Mediation Policy Administration BusinessSpace widget
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
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
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
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
Enabling event sequencing



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=What's new in WebSphere Enterprise Service Bus V7