David Currie

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!

This entry was posted on Friday, December 12th, 2008 at 12:38 pm and is filed under WebSphere ESB, WebSphere Process Server, WebSphere Service Registry and Repository. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.