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…

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!

Then a new product: WebSphere Business Events. This will build on IBM’s recent acquisition of AptSoft and its complex event processing technology. With a development team based in Hursley you can expect me to mention this product more in the future.

I have mentioned previously IBM’s support statement for running it’s software products within VMWare. It was therefore interesting to go to Ruth Willenborg’s presentation on Using WebSphere with VMWare. You can see a summary of her thoughts on the subject over on developerWorks and can expect to see more in the near future.

Next up was a lab on ITCAM for SOA, in particular looking at its use with WebSphere Process Server. It didn’t teach me much I didn’t know already but I was still left wanting to know more. The day ended with a Birds of a Feather session around WebSphere Service Registry and Repository. If nothing else it was an opportunity to put faces to some of the voices I have heard on our weekly Community of Practice calls.

This evening the UK contingent headed out to Cafe Ba Ba Reeba. The tapas was good but the mains left a little to be desired. It was a slight shame that I ended up on a table most occupied by my department as there were plenty of faces elsewhere in the group that I don’t know.

The other option is the WebSphere Service Registry and Repository Eclipse Plug-in. This is available as SupportPac SA02 and can be used with any Eclipse runtime at Version 3.0.2 or above. This includes products such as Rational Application Developer, WebSphere Integration Developer and the WebSphere Message Broker Toolkit. Whereas the Enterprise Service Discovery wizard uses the web services API for the registry, the Eclipse plugin uses the EJB API. This means you need to ensure that you are running Eclipse with an IBM JRE so that the plugin can use the IBM ORB. A couple of times after installing the plugin in to WebSphere Integration Developer I have had problems with my Business Integration perspective disappearing or a broken Business Integration view. Closing the workspace, deleting the eclipse/configuration directory and then restarting seems to fix the problem.

And why would I want to add the Eclipse plugin to WebSphere Integration Developer? The key benefit is that the plugin not only allows you to query the registry and import artifacts, but also enables you to publish new artifacts up to the repository simply by right-clicking on them in the Resource perspective and selecting Service Registry > Publish Document. If you want to publish multiple dependent artifacts (for example a WSDL and the schema that it imports) then you either need to ensure that you publish the documents in the correct order so that the repository can always resolve dependencies (e.g. schema then WSDL) or publish them together as a new concept.

One topic that the WebSphere ESB chapter covers is how to connect the endpoint lookup mediation primitive to WebSphere Service Registry and Repository via SSL. This doesn’t currently work out of the box. You will need to apply APAR IC51354 to WebSphere ESB and then follow the instructions in the book or corresponding technote.

One possible usage is to modify the behaviour of clients depending on the current system status. For example, by using a query to select endpoints which are not currently experiencing response time issues. This isn’t currently possible in WebSphere ESB when using the endpoint lookup primitive due to the internal caching that is performed. Unlike WebSphere Message Broker, the primitive does not currently have any mechanism to invalidate the cache when service definitions are modified.

I was presenting “Connection Enterprise Systems to WebSphere Application Server” in the next slot and had a good sized audience. The presentation itself was a bit of a random mix covering integration options from Java libraries and HTTP to JMS, Web services and JCA. The focus of the presentation was really JCA though and I continued on to look at the WebSphere Adapters.

After lunch I attended Ann Black’s presentation on what’s coming in WebSphere XD Version 6.1. Sadly it isn’t yet announced so I can’t say any more but this product continues to offer some exciting technologies.

I was back on again for the last session of the day, filling in for a colleague with a pitch on WebSphere Service Registry and Repository.

• Added support for WebSphere Application Server ND.
• Install improvements to allow manual database creation.
• Install improvements to allow remote database.
• Ontology API now includes access via Web Services.
• Performance improvements when making large datagraphs governable.
• Performance improvements when importing a large data set.
• Retrieval of data objects can be limited to a depth of 0, 1.
• Additional languages now supported