David Currie

Here’s my first post of a series looking at some of the new functionality in WebSphere Application Server Version 6.1 that has come out of the Hursley Development Lab, in particular in the area of the service integration bus.

One of the most of obvious change is the addition of a new persistence mechanism: the file store. In Version 6.0, the messaging engine data store used JDBC to store persistent messages and transactional data (amongst other things) in to a database. There were a couple of issues with this. Firstly, even for non-transactional, non-persistent messaging, it meant configuring a database and, secondly, the out-of-the-box performance with the default Cloudscape database was not great.

In Version 6.1, the default is to use a proprietary flat file in much the same way as WebSphere MQ. Although almost three times faster than using Cloudscape, the best performance can still be obtained by offloading processing to a remote DB2 instance. It may also be preferable to still use a database for other reasons such as high availability and backup and recovery.

Having posted on WebSphere Service Registry and Repository yesterday, I thought it was a little unfair that, despite being out for a while now, I haven’t mentioned Version 6.1 of WebSphere Application Server. Robby Peterson has a developerWorks article providing an overview of the new features so I shan’t list them all here. I will, however, pick out a few that I think are important/interesting and then blog again on some of the new functionality brought to you by my development colleagues in Hursley.

(more…)

I should know better having once worked in the WebSphere Application Server transactions development team but it is easy to assume that JTA maintains consistency throughout the lifetime of a transaction. In reality though, for a distributed transaction it is impossible to ensure that all resource managers commit at precisely the same moment. The result is that, between the first and last commit, the state of the different resources is inconsistent. This can be a particular problem if one of the changes taking place under the transaction is used to trigger further processing.

(more…)

The browser based WebSphere Application Server (WAS) administration console is not an ideal interface for displaying runtime status. In addition, when working with the Service Integration Bus in WAS V6, the resources associated with a bus are spread over numerous panels. For a while now, those of use in IBM have had the pleasure of using an SWT application written by a colleague in development (Gareth Matthews) that provides a single viewpoint of the bus resources defined across multiple cells and their current runtime state. The legal niceties having being resolved, this fantastic tool is now available for all on alphaWorks.

(more…)

I’m often asked by customers, both during engagements and more informally, about the support for connecting to the default messaging provider in WebSphere Application Server V6 from a client environment. Until now, the official line has been that either the client container or thin client from the WebSphere Application Client installation should be used. However, installing a 100Mb from a CD isn’t usually what most folks have in mind when talking about a thin client (at which point they start copying files from a server installation). Fortunately, a much more palatable option is now available from alphaWorks in the shape of the “Client for JMS on J2SE with IBM WebSphere Application Server”.

(more…)