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(    
Related Topics >>