The Unreliable Internet
When you need reliable messaging and how to use it
By: Michael Galpin
Sep. 3, 2008 04:50 AM
Sandesha + Axis2
Axis2 provides a great pluggable architecture that lets you add modules that implement extra behavior on top of SOAP. In the case of Sandesha, extra metadata and processing is done at the exit of outbound messages and at the entrance of inbound messages. This lets Sandesha implement the WSRM specification transparently to the rest of the Axis2 stack and thus transparently to the clients and servers that rely on the Axis2 stack to send or receive SOAP messages.
Besides being a full implementation of WSRM and specifically designed for Axis2, Sandesha has an impressive feature list. It has a pluggable persistence mechanism (see the section on Persistence). It provides a listener mechanism to allow customized logic to handle events such as when a sequence times out. It has a powerful reporting feature that gives you instant information on the Sandesha subsystem and any ongoing deliver sequences. Its configuration from both the server and client perspective is a snap. Let’s take a look at how you’d configure both Web Services and Web Service clients to use WSRM with WSO2 WSAS.
Configuring a Service for WSRM
The first way to enable WSRM uses Axis2’s Web Service descriptor. This is the services.xml for your Web Service. An example of a WSRM-enabled Web Service descriptor is shown in Listing 2.
Most of this is just normal Axis2 elements and configuration options. The only thing we did to enable WSRM was to add the sandesha2 module. We didn’t have to do anything else.
That’s pretty easy, but WSO2 WSAS makes it even easier. WSAS’s Management Console is a powerful graphical interface for managing Web Services. You can use it to enable WSRM for any Web Service. Just log in and go to Services -> <Your Service> -> Manage Module Engagements. You can then select sandesha2 as shown in Figure 3.
After you select sandesha2 and click the Engage button, the UI will be refreshed to show that sandesha2 has been engaged and so WSRM has been enabled, as shown in Figure 4.
With just a few clicks we enabled WSRM on any Web Service deployed on WSO2 WSAS. Now let’s take a look at creating a Web Service client that will use WSRM to send reliable messages to a WSRM-enabled Web Service.
Configuring a Client for WSRM
This code is just like any other Axis2 client code you would write, but with a couple of notable exceptions. The class org.apache.axis2.client.Options let’s us set Axis2 options on our org.apache.axis2.client.ServiceClient instance that we use to send SOAP messages to the WSRM-enabled Web Service. We use this class to enable WSRM by using the engageModule API. That’s all it takes on the client to enable WSRM.
There’s one other thing you might notice in Listing 3. In the code, two messages are sent. After the first one is sent, we add another option. This is the “last message” option that tells Sandesha to add this metadata to the SOAP header on our message, as seen in Listing 1.
WSAS Extensions to WSRM: Persistence
WSAS contains an extension to WSRM, adding persistence to messages. There are two kinds of persistence or storage. The default is in-memory storage. This is just what it sounds like. A WSAS service will keep track of which messages have been received, along with acknowledgments, etc., in memory. This is very fast, but obviously there could be problems in case of a crash. An acknowledgment might not be sent out, for instance. An alternative is permanent storage, which is typically storage in a database. This allows for the recovery of state after a crash.
How do you configure storage? Luckily the WS-Policy standard is made for extensibility, so it can be leveraged to add things like storage. Listing 4 shows a policy specifying the in-memory and permanent StorageManagers.
Of course you can use different StorageManager implementations rather than the default ones shown here. To enable permanent storage on your Web Service, simply add a line of XML to your service.xml descriptor, as shown here:
That’s all you need to do to enable persistence on top of reliable messaging with WSAS.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week