WebSphere ESB 7.5 Preview

As announced about a month ago, WebSphere ESB 7.5 is due to be available at the end of this week. Having presented on the subject at Impact, I felt I should provide a little more background to some of the new features described in the announce letter. Time permitting, I’ll cover some of the topics in further details once the product has been released.

  • WebSphere ESB Registry Edition 7.5 – Not a new feature but worth highlighting all the same – there will be a new version of Registry Edition which will bundle the 7.5 versions of WebSphere ESB and WSRR providing a single product for SOA governance and runtime enforcement.
  • Simple XML mediation flow format – Prior to 7.5, the mediation flow was written out to a couple of files (.mfc and .medflow) in a serialized XMI format which, to say the least, is not easy to comprehend. In 7.5, the default behaviour will be to serialize the flow to a single file in a simple XML format. There are a couple of major benefits to this new format. Firstly, it has been explicitly designed to simplify the process of doing a compare/merge on two copies of a mediation flow. This makes possible the concurrent development of mediation flows in a team-based environment. Secondly, the format will, for the first time, be documented in the Information Center. This opens up the possibility that the flow definition is created with something other than IBM Integration Designer (the new name for WebSphere Integration Developer), for example as part of an automated pattern generation.
  • Operation level error handling – In the mediation flow editor, you will now see that, in addition to the request and (optional) response flows for each operation, there is an error flow. The error flow is driven when a message hits an unwired fail terminal (a scenario that would normally result in a rollback of the flow and an unmodeled fault). On the right-hand of the error flow are the same nodes you’d see on the response flow. This allows you to either recover from the error and return a normal response, return a modelled fault, or simply perform some common action before failing the flow as before. All of this without having to complicate the main logic in the mediation flow with lots of failure paths.
  • Message enrichment mode for service invocation – If using the service invoke mediation primitive to retrieve additional content from an external service to enrich the content of the message, it has previously been necessary to surround the primitive with a pair of transformations. Before the invocation, it was necessary to copy the message to the transient context and construct the request message to send to the service. Then, after the invocation, another transform was required to merge the response with the original request. In 7.5, a new message enrichment mode has been added to the service invoke mediation primitive which allows an XPath from the request to be used to form the service request and then the response is placed back to an another XPath location.
  • Data transformation enhancements – Version 7.5 adds support for XPath 2 and XSLT 2. On the XPath side this means that developers have access to a raft of new XPath functions out of the box, particularly in the area of date/time operations. The auto map support in the mapping editor has also been improved to make it much easier when, for example, mapping between schemas that only differ in namespace. Other additions to the editor include support for join transforms, supplemental inputs, nillable and empty element assignment policy, data mapping overlay for copying complex objects and overriding individual fields, and variable support. On the runtime side, XPath queries and XSLT transforms are now pre-compiled during application installation (at least outside of a development environment) which reduces the latency on first invocation of the flows containing them.
  • Bindings enhancements – There are a few minor enhancements in the bindings area. There is a new policy set that simplifies the use of basic auth with username token on the JAX-WS web service binding. For the JMS bindings, it is now possible to give an initial state for the activation specification, something that previously was only possible when using listener ports with the MQ bindings. Finally, to aid with problem determination, cross-component trace has now been enabled across all of the bindings.
  • Business Object lazy parsing mode – We released an ifix on 7.0.0.3 last year that added support for something called business object lazy parsing mode. This utilizes a new parsing technology that gives significant performance benefits, particularly for large message sizes and where the mediation flow does not touch all of the message and/or contains a mix of primitive types. This work has continued with Version 7.5 bringing further performance benefits. For 7.5, in a new workspace, new modules will be created with lazy parsing mode enabled by default.
  • WSRR integration – A new mediation primitive has been added in 7.5 that effectively combines the capabilities of the SLA check mediation and the endpoint lookup mediation primitive. So, for example, it is possible to retrieve the endpoints for which the consumer has an active SLA, that are online, and that are classified as in production. The existing endpoint lookup and policy resolution mediation primitives were also extended so that they now support all of the binding types including manual endpoints.

Comments are closed.