WebSphere ESB 6.2

One of the disadvantages of being back in development is that much of my work is confidential. As the quantity of technical posts on here recently demonstrates – this is not conducive to blogging. Thankfully Version 6.2 of the entire BPM stack became generally available today so the flood gates have opened. developerWorks already has articles covering the new functionality in WebSphere Integration Developer and WebSphere Process Server so, rather than just relisting the features, I’m going to provide a slightly more personal view, focussing on the new content in WebSphere ESB.

The two biggest deliverables from the team here in Hursley are the service gateway and policy support.  The dynamic service gateway support addresses one of the major limitations of the product to date – the fact that the strong typing of SCA interfaces made it very difficult to implement a gateway pattern, particularly for web services. The dynamic gateway implementation provides a very simple interface with two operations: one for request-reply operations and one for one-way operations. The export binding will perform the mapping from the incoming request to one or other of these operations. The general pattern is then to perform some common processing before using a lookup (WSRR or otherwise) to locate the required target provider.

The policy support comes in two parts. A new policy resolution primitive enables the retrieval of policy information relating to a service from WebSphere Service Registry and Repository. The Service Message Object (SMO) has then been enhanced by the addition of a dynamic context. Properties retrieved from the policy are used to populate the dynamic context. These properties then override properties promoted from primitives in the flow. The ability to dynamically modify the behaviour of the flow at runtime, combined with the service gateway support, really opens up the possibilities for creating a meta-data driven ESB with WebSphere ESB.

When you install the runtime you will notice that the Web Services Feature Pack is also installed. The service gateway utilizes the JAX-WS support added by the feature pack and this brings with it support for SOAP 1.2 and WS-ReliableMessaging.

My personal baby is the new concept of mediation subflows. The componentization in SCA already provides for reuse but sometimes this is needed at a much lower level. In many ways, a mediation subflow is just like a regular flow – it consists of a number of mediation primitives wired together. The biggest difference is that, rather than exposing interfaces, the in and out nodes of a subflow specify a message type or may even be left untyped. To promote greater reuse, the subflow can also be defined in a library.

To use a subflow, a new mediation subflow primitive has been added. The input and output terminals of this primitive match the in and out nodes of the subflow with which it is associated and properties promoted from primitives in the subflow become properties of the subflow primitive. A subflow can also contain mediation subflow primitive so nesting is possible. I could say much more about all of this but I’ll save the detail for another day (or a developerWorks article if I get my act together).

While talking about new primitives, there are four additional primitives that allow easy manipulation of MQ, SOAP, HTTP and JMS headers. There is a new primitive that performs filtering based on the type of the message and another that allows a data handler to be used to transform a request to/from the raw wire format. Both of these become particularly useful in the gateway context where multiple different message types may be arriving in a single flow. The message logger primitive has also been enhanced so that it can now be used to perform custom logging (the default being to java.util.logging) rather than just to a database.

On the aggregation front, we now have the ability to perform some asynchronous processing between fan out and fan in nodes. This means that if, for example, the aggregation block contains an asynchronous service invoke, the next leg of the block can start processing whilst waiting for a response.

Two major changes at the module level: a mediation flow component can now be placed in both business and mediation module; and multiple mediation flow components can be placed in the same module. The former means that, if you need to perform pre- and post-processing on, for example, message headers, this can now be done in the same module as the business logic. It is also now possible to specify version numbers for modules and tie this in to service selection.

Lastly on the runtime front, the failed event manager finally comes to WebSphere ESB and has been enhanced to cover many more scenarios such as failures in the bindings.

On the tooling side, I won’t provide quite so much detail but here are some of the new features in WebSphere Integration Developer that I’ve already found useful:

  • Java context assist for BO fields when using the SDO API
  • Improved automatic wiring layout
  • Filtering in the mapping editor
  • Ability to view transaction boundaries within and across modules
  • Insertion of primitives by drag-and-drop on to a wire
  • Wiring unmatched terminal types results in automatic insertion of an XSLT primitive
  • Formatted server logs view with filtering
  • Improvements to the cross component trace including support for the bindings

Whilst this post by no means provides a comprehensive list of the new function, I hope that it provides a good flavour of the significant changes that have gone in to this release. I certainly wish I’d had even half of these features when implementing WebSphere ESB solutions out in the field!

8 Responses to “WebSphere ESB 6.2”

  1. […] “WebSphere ESB 6.2″ this weekend appears to get a tweet from me and a rather more in depth discussion from my colleague David […]

  2. […] ESB v6.2 Available December 16, 2008 — andrewferrier Dave has already beaten me in laying out the details, but it’s worth pointing out that WebSphere ESB 6.2 (together with its tooling environment, […]

  3. Jim Valencia says:

    Thanks a lot! A compressive description of some welcome new features in ESB. I’m downloading the 6.2 version to test it. Good job.

  4. Sivaraman says:

    For quite sometime, I’ve been developing PoC’s in Websphere Business Services Fabric for potential customer engagements. Off late the service implementation has grown up extensively such that I am looking to use a service registry to add flexibility to the endpoints.

    These endpoints represents communication to the various legacy systems(wrapped inside a process/module with a common interface & BO).

    My question is is there any way I can use the Sun service registry or other opensource offerings like JUDDI in the websphere integration developer/Process Server/ESB?

    Your comments are highly appreciated.

    • Dave says:

      Apologies for the delay in responding. There is currently nothing out of the box that is going to help you in these scenarios. I am, however, aware of projects which have implemented a custom mediation primitive that performs for UDDI much the same functionality as the existing EndpointLookup primitive does for WebSphere Service Registry and Repository. It is relatively easy to achieve as, once the primitive has retrieved the necessary endpoint information, it just sets the target address (or alternate targtets) in the SMO header as documented.

  5. remy says:


    I’m working on the definition of an ESB based on Websphere-ESB. My references to do this is the book of David A. Chappell “Enterprise Service Bus”.

    My proposal to do this is to used an external JMS provider that will be the core MOM of the ESB. Mediation components will be used to implement the ESB service container plugged into the JMS-based Core MOM.

    For me, the Bus of the ESB is really different from the internal bus used by the SCA Mediation components.

    What are your opinions , advices about these?

    Thanks a lot,



    • Dave says:

      Hi Rémy,

      You are certainly correct in thinking that the system bus used by the SCA implementation for asynchronous invocations is not the “Bus” in ESB. This is merely implementation detail. The “Bus” is more of a logical concept that combines both connectivity and inter-mediation. In your case, you are choosing to use an external JMS provider to provide the connectivity, which is certainly a valid decision if that provides the necessary means for producers and consumers to connect from their environments. Equally, for other customers, WebSphere’s default messaging provider might suffice.


      • Remy says:


        Thanks a lot for these clarifications. The external JMS provider
        is investigated because
        the ESB will be distributed over the WAN.