Skip to main content

When to Use WSIT Reliable Messaging

Posted by mikeg on February 25, 2007 at 3:56 PM PST

Reliable messaging is a feature of WSIT, which will be delivered through Glassfish V2. Here is a link to the Milestone 3 build of WSIT.

When the Reliable Messaging feature is used, it does its work automatically with almost no effort from application developers. This means that there is little to say about how to use the feature. It is important, though, to understand when to use the feature.

The first thing to know is that an client application programmer does not get to choose whether to use Reliable Messaging. If a Web Service endpoint uses it, it advertises the fact in a WS-Policy Assertion its WSDL. A WSIT client invoking the endpoint will always use Reliable Messaging when the Policy assertion is present. There are a few client-side Reliable Messaging configuration settings, but they are fine-grained ones. The default values work fine in almost every case. This means that the only special attention a client application programmer needs to pay to Reliable Messaging is the mechanism for closing a connection described here. In most cases, a client programmer does not need to know that Reliable Messaging is being used.

The developer of a WSIT endpoint only needs to choose whether to enable Reliable Messaging, and if it is enabled, must decide whether to enable the ordered delivery feature. The decisions are reflected in Policy assertions in the WSDL of the endpoint. These assertions can be edited using the NetBeans 5.5.1 IDE. To make the decisions, it is important to understand some of the benefits and disadvantages of Reliable Messaging.

Benefits

Let's start with some benefits. Reliable Messaging allows the WSIT Session support to work, but that is the subject of another article. The benefits discussed here involve the delivery assurances that Reliable Messaging is designed to provide.

At least once delivery

If Reliable Messaging is enabled, the client runtime will resend any messages that are lost in the network. This saves the client application programmer the effort of doing this in application logic. Arguably, this is mainly a service to the client, but there might be business reasons for offering the service.

At most once delivery

Some distributed applications will not work correctly without this delivery assurance. Consider a banking application with a payTo() method. Suppose that this is a client program:


BankService service = new BankService();
CheckingAccount account = service.getCheckingAccountPort();

received = false;
while (!received) {
     try {
	account.payTo(“lucky recipient”, 1000.00);
        received = true;
     } catch (SocketTimeoutException e){}
}

Suppose that the request message for the call to payTo is received and processed, but the HTTP response is delayed and the connection times out. In this case, the request will be resent and the payee will get a lucky windfall if the endpoint does not prevent the resent request from being processed by the business logic.

On the other hand, duplicate detection is not always as important. Consider the code:


StockQuoteService service = new StockQuoteService();
StockQuotePort port = service.getStockQuotePort();
float price = port.getQuote(“SUNW”);

If the request message for the call to getQuote is processed several times, it will have no obvious ill effects.

Ordered delivery

Let's add a deposit() method to the CheckingAccount interface. Consider the code:


BankService service = new BankService();
CheckingAccount account = service.getCheckingAccountPort();

account.deposit(500.00);
account.payTo(“possibly angry recipient”, 1000.00);

If the request messages for the invocations of the deposit and payTo methods are processed out-of-order, the check will bounce if the initial balance was less than $500.00. Since the messages might cross paths in the network, the application needs a way to ensure that they are processed in the order in which they were sent in order to work correctly.

In contrast, the StockQuote service in the example above will not malfunction if request messages for two quotes are processed out-of-order.

In summary, the cases where the Reliable Messaging delivery assurances are crucial to an endpoint application are ones where request messages to the endpoint have side-effects and different orderings or cardinalities of the messages leave the system in different (and possibly unpredictable) states. On the other hand, for stateless services where invoking the operations has no side-effects, the benefits of the delivery assurances are not as compelling.

Disadvantages

There are disadvantages to enabling Reliable Messaging. Otherwise, it would be reasonable to enable it even in cases where there is no clear benefit.

Performance

This is the most frequently-mentioned disadvantage,but might not really matter that much to many users. The Reliable Messaging protocol sends its own messages and adds protocol headers to application messages, so both the number of messages and their sizes are increased if Reliable Messaging is enabled. This increases processing times and decreases the number of requests that can be processed by a given endpoint.

Interoperability

This might be the main disadvantage. Not all vendors of Web Services stacks support Reliable Messaging. The implementations of vendors who do support it might not even interoperate well, because of the looseness of the WS-RM Specification. (The specification is being standardized and tightened by The OASIS WS-RX Technical Committee.) WSIT Reliable Messaging endpoints are designed to work with WSIT and WCF Reliable Messaging clients, but may not work as well with clients using other software stacks. Therefore, enabling Reliable Messaging for a WSIT endpoint might limit the number of clients that are able to consume the service.

Summary

Using Reliable Messaging has real benefits. Indeed, some Web Service applications will not work correctly without the delivery assurances it provides. Not every application benefits from it however, and there are costs. A WSIT developer should weigh the advantages against the disadvantages for each application before enabling the feature.

Related Topics >>