In this sequence diagram, we see the Sender needing to send two messages to the Receiver. WSRM lets the Sender specify which is the “last message” so the Receiver knows how many messages there are in the sequence. It just so happens that the first one doesn’t make it but the second one does. The Receiver can see that it only got the second of the two messages that were supposed to be sent. It sends an acknowledgment that it only got Message #2, so the Sender knows to resend Message #1. Once this comes, the Receiver knows that everything has been sent. It sends a final acknowledgment and the conversation ends.

The key here is that both Sender and Receiver use a common protocol to relay metadata back and forth about the conversation. This lets them work together to ensure that the conversation is reliable, i.e., nothing is lost. Let’s take another look at the variant in Figure 2.

In this case there’s no acknowledgment so the Sender gets impatient and resends both messages. The Receiver then sends an acknowledgement for both message #1 and message #2. There are several things to realize here. First, the Receiver is going to ignore the repeat (message #1). The protocol handles ignoring the repeated message, so you don’t have to put anything into your application logic to deal with this scenario. You don’t have to worry about it because WSRM is going to handle it for you. This is known as duplicate elimination.

Next, WSRM is smart enough to send acknowledgments for both message #1 and message #2 in a single acknowledgment message. This is an important optimization. It’s easy to imagine that if the Receiver had to send two separate acknowledgments, the impatient Sender might have resent message #2 in between the acknowledgments. Of course you can imagine if there were N messages in the sequence, not just two.

As you can tell, the WSRM specification addresses a lot of complexity. Imagine trying to deal with this complexity in your application. You might spend more time doing that than developing business logic. WSRM frees you from that by pushing that problem set down to the middleware level, where technology stacks like WSO2 WSAS implement the WSRM specification.

WSRM: Builds on SOAP
So far we’ve mentioned all the great things that WSRM does. We haven’t looked at the underlying WSRM implementations, but we’ll get to that later. First, it’s important to understand how WSRM metadata is sent back and forth between the senders and receivers in a conversation. For example, in the diagrams you see things like “message 1” and “last message.” This metadata is key, but how is it sent?

The answer is SOAP headers. One of the keys of WSRM is that it builds on top of SOAP. WSRM isn’t a reliable messaging solution for any message protocol; it’s designed for SOAP. With that in mind let’s take a look at a SOAP message that includes WSRM metadata, shown in Listing 1.

Notice all the elements with the WSRM namespace? That’s the WSRM metadata. It’s all contained in the header section of our SOAP message.

If you look at the header of this message, or at other SOAP messages, you’ll probably notice other metadata that has nothing to do with WSRM. This metadata is being used as part of various WS-* standards. For example, Listing 1 shows an element in the WSA namespace. This element is being used to pass WS-Addressing metadata. One of the key benefits of WSRM is that it integrates with the other WS-* technologies.

WSRM: Working Together with Other WS-* Technologies
WSRM is an effective solution to the problem of creating reliable messages with SOAP. It works with the other WS-* technologies to solve numerous problems facing systems that rely on the SOAP standard to send messages and data. For example, our reliable messaging solution neglects to deal with another possible cause of messages being lost, namely network security such as firewalls, NAT, etc. You may use HTTP to get your message to a particular gateway, but that’s all that HTTP can provide. WSRM isn’t going to help here, but WS-Addressing will help.

Another WS-* technology that is synergistic to WSRM is WS-Policy, a generalized framework for adding extra policy information to SOAP messages so both sides of a conversation can communicate more effectively. For WSRM, there are a number of policy choices you can make, and with WS-Policy, you can make sure that everyone involved in the conversation knows about these policies. Let’s take a look at some of the policies you can use with WSRM.

WSRM Policies
Table 1 shows the various policies you can set to configure WSRM for your Web Service. As mentioned earlier, all of these can be specified and communicated to partners using WS-Policy.

How Does WSO2 WSAS Implement WSRM?
We’ve seen how powerful and useful WSRM can be. However, at the end of the day, WSRM is just a specification. You need something that implements the specification. The idea behind things like SOAP, WSRM, and other WS-* technologies is to standardize message formats and protocols so that Web Service stacks/middleware can take care of the hard part for us. What’s the Web Service stack that we can use that will give us the power of WSRM?

You don’t have to look too hard. The WSO2 WSAS stack implements SOAP, WSRM, and numerous other WS-* technologies. It’s built on best-of-breed implementations of these various technologies to provide a powerful, easy-to-use solution for Web Service developers and consumers alike. Let’s take a look at the WSRM implementation provided by WSO2 WSAS.