Ensuring XA Recovery works with a secure bus

I have been responsible for security for the service integration bus for a number of years now and most of the problems I have dealt with over that time have come down to configuration problems. While helping the tenth person to hit a particular problem can be a little frustrating, at least I am not having to explain security flaws. Their are a number of very common problems, such as typing in the wrong userid and password, to not understanding how foreign bus security works. One of the more worrying problems that occurs relates to XA Recovery.

The problem here will be that during normal operation of the environment connections will be made, to a secure bus, authentication will occur and messages sent and received; all is good in the world. Then disaster strikes and for some reason the application server goes down leaving uncommitted work in the bus. The node agent restarts the application server which then connects to the bus and performs recovery. At least that is what should happen. In this case the connection fails with a JMS SecurityException. The original connection was established, but recovery does not work.

So what went wrong here? During normal operation when a connection is made to a transactional resource and a transaction is in effect the connection factory is written into something called the partner log. This contains details of how to connect to all the transactional partners that may be needed during recovery. In this case the connection factory does not contain any information on what security credentials should be used, so no credentials are used, causing this problem.

So if you see this how do we get the transactions resolved? Their are two of options and the first one would be preferable:

1. Grant the special Everyone group access to the bus. Assuming dynamic configuration is enabled this will allow recovery to work quickly.
2. Turn security off for the bus until recovery is complete. We generally advice restarting the whole bus, but a single application server may work on a temporary basis.

So now you have solved the temporary problem and your business is up and running with no in-doubt work, how do you solve it more generally? Every JMS connection factory can have an XA Recovery Alias specified. This should be configured with a user that has bus connector authority (only bus connector authority is required). Once this has been configured save, sync and restart and any new JMS work with the bus will recover with no security problem. At least until the password expires.

In fact the XA Recovery Alias is not JMS specific it exists for all JCA resources, so it can help when using WebSphere MQ and DB2 too.

Did I hear someone say "yuck"? You do not like this? Well to be honest neither did we. One of the themes of the WAS v7 release was to make it more usable (we use the term "consumable", but who'd want to eat WAS?) so we have tried to simplify here. In WAS v7 the XA recovery alias is no longer required; during recovery the application server will use the WAS server identity to perform recovery. Their are a few limitations. The first is that the special Server group needs to have bus connector authority, and the second is that the recovery server must be in the same cell as the bus. Other than that you are good to go. Oh and do not worry, if you already have an XA recovery alias we will continue to use this unless a problem occurs.

Alasdair

WAS V7.0 Cluster Bus Member Wizard

There's a really neat consumability improvement in WAS V7.0 in the shape of the new console wizard that guides you through configuration of a cluster bus member. The new wizard is invoked when you click "Add" to create the bus member for a cluster.

If you've ever added an appserver cluster to a bus, then you'll probably agree that anything other than a simple "HA" setup was pretty hard to configure - if you wanted to create multiple messaging engines to operate in parallel within the cluster then it's likely that you needed to create your own core group policies, and configure their match criteria and properties. If you made a mistake along the way you probably only found out later because the engine wasn't running on the server you expected, or wasn't failing back to a preferred server after recovery. The reason was often that the match criteria contained a typo and the engine was not bound to the policy you intended.

The new cluster bus member wizard in V7.0 spares you from having to worry about any of that, by providing a pattern-based approach to creation of the cluster bus member. On launching the wizard, you can select one of a small number of patterns and the wizard then sets up the messaging engines and core group policies with settings that corresponding to the pattern. The patterns cover the popular uses; you can select "high availability" if you want a single engine that can failover, or you can select "scalability" if you want multiple engines. There's also a pattern that provides both of the above.

The new console wizard makes life really easy by saving you from having to enter the core group policies by hand. It also provides feedback on your curent configuration and provides hints about how to improve it. For example it'll spot that you might have asked for a highly available bus member, but your whole cluster is running on one node. You can do that if you want, but the node is a single-point-of-failure and the wizard will detect it and politely suggest that might want to remove the SPOF.

If your browser supports SVG you even get a visual representation of the cluster showing the nodes and servers and the messaging engines.

The visual aspects of the wizard and the amount of work it saves you make it a pretty useful addition to the console.

Welcome!

This blog is for discussion WebSphere Application Server (WAS) and Messaging.

In particular it will cover the service integration technology included in WAS, which is known as the "SIBus" or just "SIB". SIBus provides the default messaging provider for JMS applications in WAS. It also provides an asynchronous transport used by SCA and the WPS/WESB stack products.

Instead of using the default messaging provider, you can configure JMS Resource for an alternative JMS provider, such as WebSphere MQ (WMQ). WAS V7.0 includes a JCA 1.5 Resource Adapter for WMQ and new panels for configuration of JMS resources.

We hope you find this blog useful - the authors are all folks who work on or with WAS Messaging and have direct practical experience.