There are, however, two relatively new innovations that make this picture more complex. Firstly, WebSphere MQ v7 brings to the distributed platform the browse-mark behaviour that previously existed only on the mainframe. This basically allows the connection consumer to lock messages as it browses the queue thereby ensuring that, when it decides to consume one, it is still available. Secondly, ASF is now old technology with the J2EE Connector Architecture 1.5 specification providing the preferred mechanism for integration between a JMS provider and application server MDBs. In WebSphere Application Server v7 this manifests itself as the WebSphere MQ resource adapter.

The good news is that, if you have a WebSphere MQ v7 queue manager, then the WebSphere MQ v7 JMS provider will automatically use the new browse-mark behaviour for both ASF and the resource adapter. If you are currently using non-ASF, you should therefore switch away from that to one of these two mechanisms when moving to WebSphere Application Server v7. However, if you still have a v6 queue manager and have previously been using non-ASF then you should continue to do and not switch to the resource adapter as this uses the same underlying technology as ASF.

Thanks to Ben Ritchie, Mark Whitlock and Matthew White for providing insight in to the new behaviour.

I started on 5 October 1998, straight out of university (a degree in Engineering and Computer Science from Oxford University). This was a month later than the majority of that year’s graduate intake as I had been otherwise engaged with a leisurely crossing from New York up to Quebec and then across to Vancouver by Greyhound (the coach company that is, not the dog). I began work as a tester on Component Broker, IBM’s CORBA offering and a forerunner for much of what was to become WebSphere Application Server. It was only a few months before I’d managed to wheedle my way across in to the development team, initially fixing defects in the transactions component.

I then had my first brush with the world of messaging working on the MQSeries Application Adapter component. Next up was some work on the common Java client which was to be a sign of things to come. As IBM threw its weight behind Java, Component Broker sank beneath the waves (although I still drink for my CB mug) and WebSphere Application Server became the way forwards. I continued to work on the transactions service and related activity session service before starting to look at the integration of WebSphere MQ with Version 3.5 of the Application Server.

This (along with a part-time MSc in Software Engineering back at Oxford) kept me gainfully employed until someone had the bright idea of writing a new Java messaging provider for the Application Server from the ground up. I was originally slated to work on the mediation component of what was to become known as the Service Integration Bus but somehow that never happened. Instead, having successfully persuaded the powers that be that the J2EE Connector Architecture was the way to integrate the new JMS provider with the Application Server, I found myself owning the resource adapter component.

Once Version 6.0 had safely shipped I felt that, rather than making design decisions in the rarefied atmosphere of Hursley, I needed to get out and meet some customers. This saw me transfer across to the IBM Software Services for WebSphere organisation. I consequently had the dubious pleasure of explaining to customers that, yes, I had designed and coded that particular piece of function in the product and, no, I have no idea at the time how I was expecting people to use it!

My four years in Software Services culminated in a six month assignment to Norway about which you can read more elsewhere on this blog. I was getting travel weary though and, with a young family, sought a little more predictability in my schedule. Consequently I found myself back sitting not very far away from where I had sat when I left development but now working on WebSphere ESB. Two out of the three guys I originally shared a house with when I first joined IBM also work on the same product (the third having left IBM)!

When I joined IBM I had no great plans to still be a part of the company ten years later but I’ve enjoyed the variety of work, the Hursley location and, most importantly, the clever folks that I’ve had the pleasure of interacting with on a day-to-day basis. Who knows where I’ll be in another ten?!

Update: the replay for this webcast is now available.

An immediate stop proceeds as for a normal stop except that there is no quiesce period i.e. in-flight requests are given no time to complete before the server components begin to shutdown. A request to terminate a server effectively kills the server process without any shutdown logic running.

Part of the reason for this investigation was the presence of long-running operations in the particular scenario we were looking at. We were therefore looking for a mechanism to notify those operations when a server quiesce began so that they might perform their own graceful shutdown. I had hoped that this might be achieved via the release method of the CommonJ Work interface however this appears to be called at the end of the quiesce period.

In the end I suggested two possible options. The first, was to use JMX to listen for the “server stopping” notification. Shawn Lauzon’s developerWorks article provides some good example code for achieving this. The second option, was to implement an application startup bean, the stop method of which is called at the start of the quiesce period.

The use of the CommonJ WorkManager API would still provide one potential benefit to the long-running operations. The name of the configured WorkManager is included as part of the thread name. Hence, when the hung thread detection logic output its warning message, it would be possible to tell that, in the case of these threads, it could be safely ignored! (Also note that the timeout for hung thread detection can be modified or, indeed, stopped completely.)

At a high level, what I’m going to suggest is that you use a regular JMS binding defined to use a static destination and then you apply a service integration bus mediation to that destination to perform the dynamic routing. The first issue to resolve is how the mediation module indicates to the service integration bus mediation where the message should be routed. I’m going to use a JMS user property to pass the destination name. The following shows how a custom Java primitive can be used to set a JMS property via the service message object header properties.

smo.getHeaders().setJMSHeader(
    ServiceMessageObjectFactory.eINSTANCE.createJMSHeaderType());
List properties = smo.getHeaders().getProperties();
PropertyType property =
    ServiceMessageObjectFactory.eINSTANCE.createPropertyType();
property.setName("DestinationName");
property.setValue(smo.getString("/body/operation/in/destination"));
property.setPropertyType("java.lang.String");
properties.add(property);

In this example, the destination name is pulled directly out the body of the request but you might, for example, obtain it from a registry lookup. Note that I explicitly create the JMS header although I don’t appear to use it. This is important as it is the presence of this header that causes the header properties to be written out as JMS properties in the message.

I won’t go in to the details of creating the service integration bus mediation – you can read all about that in Dan Murphy’s series of developerWorks articles. The important part is the handler code that retrieves the JMS user property from the message and uses it to reroute the message:

SIMessageContext siMessageContext = (SIMessageContext) messageContext;
SIMessage message = siMessageContext.getSIMessage();
String destinationName =
    (String) message.getUserProperty("DestinationName");
SIDestinationAddress destination = SIDestinationAddressFactory
    .getInstance().createSIDestinationAddress(destinationName, true);
List forwardRoutingPath = message.getForwardRoutingPath();
forwardRoutingPath.add(destination);
message.setForwardRoutingPath(forwardRoutingPath);

The only real thing to note here is that the forward routing path returned from the getter method is a copy of the list so that you need to set it back again once you have added the new destination.

For the simple case, that’s all there is to it. The particular scenario I was interested in though was using publish/subscribe and it was the topic that I wanted to dynamically route to, not the destination. I used the same approach as outlined above, passing the topic name as a JMS user property instead. The code in the mediation handler then looked as follows:

SIMessageContext siMessageContext = (SIMessageContext) messageContext;
SIMessage message = siMessageContext.getSIMessage();
String topicName = (String) message.getUserProperty("TopicName");
message.setDiscriminator(topicName);

The discriminator is what the service integration bus programming model calls the topic name within a topic space. I had the mediation module send the request to a particular topic within the required topic space and then, when applying the service integration bus mediation to that topic space, I specified that topic name as the discriminator. This ensured that the mediation is only driven when a message arrives at that particular topic.

It was at this point that I realized a flaw in this approach. The destination name contained in the JMS message is not altered by the modifications made in the mediation handler. Generally this isn’t a problem as the receiving client either doesn’t care or knows what destination it connected to in order to receive the message. However, in my case the consumer is using a topic wildcard to receive messages and it is important that it knows what topic the message was actually received on as it is then going to republish them to the corresponding topic in another publish/subscribe system. (For the curious, the client is the JMS bridge in MicroBroker.)

At this point I threw away my service integration bus mediation and wrote a message-driven bean to receive the messages from the mediation module and republish them to the required topic. The JMS destination for the send was simply created using Session.createTopic(). In my case I just needed to pass this the topic name but, if you need to redirect to something other than the default topic space, then you need to be aware of the URI syntax outlined in the InfoCenter. Note that, in a point-to-point scenario, this approach might not be appropriate as it results in a change in the message identifier. In publish/subscribe the publisher and subscriber get different identifiers anyway.

Despite being sidelined by the arrival of WebSphere ESB, there are still times when it is useful to use the mediation support in WebSphere’s service integration bus (of which more in another post). It’s obviously a while since I’ve done it though as apparently the mediation handler tooling in Rational Application Developer has been broken since v7 was released. I’m told that the fix will finally make it in to 7.0.0.7.

Next up I sat the IBM WebSphere Process Server V6.0, System Administration certification test. This was a bit of a gamble as, despite being a specialist with WebSphere ESB (for which there is no certification test), I haven’t knowingly opened the admin console for Process Server. With some educated guessing I scraped through – particularly pleasing as, when combined with previous tests, it means I can now claim to be both an IBM Certified Administrator for SOA Solutions – WebSphere Process Server V6.0 and IBM Certified Deployment Professional – WebSphere Process Server V6.0.

After lunch it was another lab: "EJB 3 and Open JPA with RAD 7.5". This was my first hands on experience with the EJB 3 feature pack and with the tooling it really was a pleasure to use. Whilst I’m happy to see unnecessary interfaces removed in EJB3 I’m still skeptical about the use of annotations for ORM and hope many customers will still see the importance of separating the deployment specifics from the application code. The lab was also a chance to finally meet Kevin Sutter face to face – a guy who I’ve worked with closely in the past when he owned the WebSphere JCA component and I the JMS resource adapter but never met in person.

Finishing the lab early gave me a chance to sit another test and add to IBM Certified Advanced System Administrator – WebSphere Application Server Network Deployment V6.1 to my list of titles. I’m glad to say my pass mark was considerably higher than for Process Server. I did, however, have to restrain myself on several occasions from answering "none of the above – the question is badly worded".

Went to see Alasdair Nottingham present his latest updates to the Service Integration Bus Security presentation that we jointly own. Despite having reviewed the changes it was still good to hear Alasdair present it from his perspective.

Actually managed a run before dinner although at that time of day it wasn’t a particularly pleasant experience. I probably would have been better of spending some time by the pool! We had our team meal out at the Ellis Island Casino & Brewery which seemed to have been chosen largely for the price of the beer ($1). At least, it can’t have been for the quality of the food. Stopped off at Nine Fine Irishmen in New York-New York until the early hours.

My contact in development was also able to confirm that, at the moment, although the server-side supports wildcards in topic names, the Dojo client does not, and neither side currently has support for message selection. When combined with the limited support for JMS message types (text and certain specific objects), this means you are unlikely to be able to simply attach a client to an existing topic.

-Xdump:tool:events=user+abort,range=1..0,
    exec=/some/path/cleanup.sh,priority=999

Thanks to Andy Simms and Pete Daly for the research behind this one.