Axis 2 is an enterprise solution for an enterprise problem - Service Oriented Architectures. When running Axis 2 over the standard HTTP/S transports it is excellent. However, when running it over JMS, it has a major shortcoming (as of Axis 2 1.3).

The key feature of a system based around messaging is that messages must be 100% guaranteed to reach their destination. In the SOA world, this is handled via the Durable Subscriber enterprise integration pattern. A durable subscription instructs the messaging server to save messages, that are published while a subscriber is inactive. When the subscriber reconnects to the messaging server, the subscriber receives all the messages that it missed while it was inactive. This is a standard JMS feature which is one of the key patterns in enterprise integration systems.

Axis 2 1.3, does not support this, so I had to do some custom modifications to the Axis 2 transport layer so that I could make use of durable subscriptions. This blog is about how to configure your Axis 2 to support durable subscriptions, and contains a downloadable jar that contains the modified JMS transport layer for Axis 2 1.3.

Don't Shoot the Messenger!

axis2.xml

I have modified Axis 2 so that the configuration fits in with the standard JMS transport configuration. The following example JMS transport receiver highlights the two new transport receiver configuration parameters. axis2.xml is generally located in the WEB-INF/conf folder of your Axis 2 server.

1. UseDurableSubscriptions - this speaks for itself.
2. DurableSubscriptionClientIdentifier - this is a unique identifier that the messaging server uses to identify your specific application server instance (for example, your dev tomcat).

Note that the example transport receiver below is configured to work with Web Sphere MQ, so the JNDI parameters should be changed depending on the messaging platform you are using.



services.xml

The final part of your configuration, is to configure your individual web services to be durable. My implementation is such, that you can have multiple web services and can define per web service, whether it is durable, or runs over HTTP or JMS (or both) or any combination.

The only parameter required for your service definition is, DurableSubscriptionName - this parameter identifies your specific web service uniquely to the messaging server so that when your web service connects to it, it knows what messages you have missed. As soon as you deploy your web service, you will see it start to pull all the messages off MQ that it missed!

If your JMS-enabled web service does not require to be durable, then simply leave this parameter out and it will resort to being a plain-old Axis 2 non-durable JMS service. Any of your web services running over standard message queues should be configured this non-durable way, as durability is only for publish-subscribe.

Note that the following services.xml excerpt is for a web service that is available over both HTTP and JMS and is subscribed to the topic MQ.BOOKING.TOPIC.



Note that I have not modified Axis 2 to have the ability to de-register a web service as a durable subscriber. Also note that durable subscriptions only work for publish-subscribe/asynchronous messaging - it does not work for point-point message queues and never will!

To anyone who is interested, I am also working on a major update to the JMS transport for Axis 2 so that it can heal its connections to messaging servers without having to restart the Axis 2 server.

Distribute Me

The jar file attached to this blog (see below) contains the JMS transport classes I fixed up for Axis 2 1.3 only. These either need to be put into the Axis 2 kernel jar so they take the place of the existing ones, or expanded into the WEB-INF/classes folder of your Axis 2, so they override the versions of these classes in the Axis 2 kernel jar file.

Download the jar file here.