• 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.

One of the other significant points about this fix pack is the move to WebSphere Application Server 7.0.0.11 and, in particular, the fact that this finally has an Installation Manger based install process. This means that you can finally install both the Application Server, ESB and fixes for both, all using the same install technology. Unfortunately you will have to use the old Update Installer to remove any ifixes that you have already installed.

Service Federation Management: I’ve touched on this previously in my post on the product announcement as it is the area on which my efforts have been focussed for this release. The basic thesis is that many enterprises consist of a number of disconnected domains each with their own services. These domains could correspond to lines of business, geographical boundaries, or exist as the result of mergers and aquisitions. What service federation management aims to do is to simplify the sharing of services from one domain to another. A Business Space based console is shipped with the WebSphere Service Registry and Repository Feature Pack. This console allows the definition of multiple domains, each of which has its own registry instance. Existing services in those domains can then be grouped and shared from one domain to another via the console. In addition, a domain may contain one or more connectivity providers (WebSphere Message Broker or WebSphere ESB). When a service group is shared from one domain to another, a proxy can be created in either the provider or consumer domain or both.

Patterns/Proxy Gateway: The existing pattern support in WebSphere Integration Developer has been radically updated. In addition, a new service gateway pattern has been added: proxy gateway. The existing dynamic proxy pattern requires the integration developer to determine what the target service for any given invocation is. The proxy gateway pattern allows back-end services to be defined in an internal registry via a new Business Space widget. Each service is provided with an unique virtual service name that can then be appended to the export endpoint address to identify the target service. A new endpoint lookup primitive is utilized in the flow to retrieve the target service meta-data from the registry. Consequently, a proxy gateway scenario can now be implemented out of the box.

Data Transformation: There have been considerable enhancements to the XML map support. XPath functions can now be accessed directly. “Smart” data type support allows direct mapping between compatible types e.g. date to dateTime conversion. User-defined lookups can be implemented with support for static relationship, CSV, and property file, lookups out of the box. If/else if/else constructs are also now supported. Refactoring support has been added. To name but a few enhancements…

Policy-Driven Mediation: The mediation policy Business Space widget that shipped with the V6.2 Feature Pack is now part of the base product. It is also now possible to attach policies to individual services, service endpoints and operations, in addition to the existing module level policies.

Subflows: Support for subflows (the area I worked on in V6.2) has also be enhanced. It is possible to set the types of the in/out nodes of a subflow to be weakly typed thereby promoting greater reuse. It is also possible to extract part of an existing flow in to a new subflow (although it is then necessary to define the wirings to the in/out nodes explicitly).

Mediation Primitives: No release of the product would be complete without a set of new mediation primitives:

• Message Validator – validates that the message matches the schema
• Trace – prints a trace message to the server log
• SLA Check – ensures that the service requestor has an SLA defined in WSRR
• Flow Order – allows the order of invocation to be defined where a mediation flow branches
• UDDI Endpoint Lookup – enables a service lookup based on business name, service name or find qualifiers
• Gateway Endpoint Lookup – as mentioned previously, allows service endpoint information to be retrieved based on a virtual service name

Mediation Flow Editor: When creating a new mediation flow component implementation you’ll immediately notice a difference to the editor. The operation connections view has gone and, when creating the flow, you are now presented with a set of template options permitting either a one-to-one or one-to-many mapping, or for you just to start with a blank canvas and add callout nodes to references as and when they’re needed. This takes a bit of getting used to for seasoned users but should be more intuitive for the beginner. Then, when editing the flow itself, the request/respones tabs have moved to the top of the editor alongside a new breadcrumb navigation, the combination of which makes it much easier to see which flow you’re currently working on. Another great usability improvement is the ability to click on any terminal in the flow and see the structure of the service message object at that point.

Quality of Service: Event sequencing, previously only supported in WebSphere Process Server, is now available in WebSphere ESB too. There is also a new store and forward qualifier. This can be applied to asynchronous invocations and indicates that, when a given exception occurs (e.g. ServiceUnavailableException), the request messages should be requeued ready to be forwarded at a later point.

Bindings Enhancements: The web service bindings have had support for referenced attachments added. For a JAX-WS binding, it is also possible to modify the response endpoint dynamically within the mediation flow enabling responses to be redirected to a different client application. For the messaging bindings, there is now failed event manager support for all of the binding types. With the move to be based upon WAS V7, the WebSphere MQ related bindings can now also make use of the WebSphere MQ JCA resource adapter. For a JMS import where the response is being sent to a topic, it is also now possible to modify the topic dynamically during the mediation flow. The EJB binding can now be specified on an export as well as an import with support for both EJB 2.1 and 3.0, local and remote interfaces.

WebSphere Service Registry and Repository Integration: In addition to the new SLA check primitive already mentioned above, the existing endpoint lookup primitive has been enhanced. It is now possible to specify the required version dynamically. Lookup for JMS, HTTP and MQ binding types is also now supported. For situations where it is necessary to access WSRR from a custom Java primitive, for example to perform a custom query or to retreive other objects types, it is now possible to use the same client SPI used by the endpoint lookup primitive. This enables custom code to use the same WSRR definitions and caching mechanism used by the provided primitive.

new Service Federation Management across WebSphere Service Registry and Repository and the ESB family to manage service visibility and reuse across the enterprise

Maybe that doesn’t tell you a great deal but I’m not at liberty to say any more at the moment. You could, however, turn to the WSRR announcement which provides a little more detail:

Better manage visibility of service across SOA domains. By using the Service Federation Management console to simplify the process of sharing business services between service domains, you can improve the connections within an organization, and increase reuse of services and information by extending the reach of existing assets across the organization and beyond.

And this might lead you to Greg Flurry and Marc-Thomas Schmidt’s developerWorks article which provides the motivation for this new functionality.

More to come once we reach general availability…

If you’re using a JAX-WS binding then you need to take a different approach. In the server runtime, define a new policy set that contains a HTTP transport policy as described in the Application Server InfoCenter. This policy set has a Connection timeout property (in addition to many other settings). Export the policy set and then import it in to WebSphere Integration Developer (File > Import then Web services > WebSphere Policy Sets). At this point I then had to restart WebSphere Integration Developer to pick up the new policy set. Then select the import on the assembly diagram and on the Properties tab select the Binding > Policy Sets panel. Here you can select the default policy set for the binding.

$AdminTask modifySCAImportHttpBinding -moduleName MyMod -import Import1 -connectionRetries <Import1>3</Import1>

Thankfully the InfoCenter has been recently updated as a result of APAR JR31724 as previously you just had to guess at the syntax! Perhaps I should now try and get them to fix the description of the command which I see states “The modifySCAImportHttpBinding command changes the JNDI name of one or more of the resources associated with an HTTP import binding.”! One suspects someone may have been a little generous on the old cut and paste…

Now that is all very well but it is cumbersome and error prone if you have a large number of properties to modify. I’d also recommend that application deployment, as with any administrative action in anything but a workstation development environment, be performed by scripting. There is no special command for installing mediation modules (they just use the standard AdminApp.install command) so how to specify the module properties? An intial search of the InfoCenter failed to turn up anything useful so I resorted to running the AdminApp.installInteractive command. This showed me the syntax required for specifying the properties on the command line but I still needed to know the name of the corresponding task. I then looked at the wsadmin.traceout file in the profile logs directory where a entry is added showing the generated command. For example:

[20/05/09 16:15:38:000 BST] 0000000a AdminAppClien A   WASX7278I: Generated command line: install 'c:/temp/module.ear' '[ -SIBSCAClientInstall [[, [group1]key1=value1,[group2]key2=value2]]]'

A little bit of massaging and I had the necessary Jython needed to modify properties on application installation:

AdminApp.install('c:/temp/module.ear',[ '-SIBSCAClientInstall', [[', [group1]key1=value1,[group2]key2=value2']]])

It wouldn’t take much to read the property names and values out of a property file to allow the necessary parameterisation for different environments.

The only place I found this task documented was in a very good IBM Education Assistant presentation covering promoted properties. Unfortunately this presentation only covers V6.1 so doesn’t show the syntax required for group names.

Lastly, an alternative approach (although not one that I’d necessarily advocate in terms of following a supported process) would be to have multiple copies of the sca-module-properties.xml file and build a different EAR for each environment. This file contains the default values for each promoted properties in the following format:

<sCAModuleProperty identifier="key1" value="value1" group="group1"/>

1. The syntax of the endpoint URI used for the JMS bindings uses JNDI names to refer to the resources and is therefore not truly dynamic in the sense that JMS destinations need to have been pre-configured for all of the messaging provider destinations to which you might want to send.
2. For a native MQ binding, you can currently only modify the queue dynamically and not the queue manager to which you can connect.