The Internet’s a dangerous place for a message. Component failures, network connection issues, and other problems can prevent a message from being delivered. Fortunately, there’s WS-ReliableMessaging, which makes sure messages get through. This article explains how to use reliable messaging, why you should use it, and how to use it with WSO2’s Web Services Application Server (WSO2 WSAS) 2.1.

What Is Reliable Messaging?
Reliable messaging may seem like a dull thing. We’re used to being able to rely on the Internet, so why worry so much about increasing the reliability of something that’s already reliable. But is the Internet really that reliable? How many times have you clicked on a hyperlink that didn’t work at first and you had to click it again or hit the refresh button? It’s something that happens so often that we don’t think twice about it. It’s easy to ignore when you have a high-speed connection.

You can’t ignore the unreliable nature of the Internet when building systems that rely on the exchange of data and messages with other systems. You have to deal with this unreliability. That’s where reliable messaging comes in.

When Do You Need It?
How do you overcome the unreliability of the Internet? You could start by paying attention to the HTTP status code you get when you send a message. A status of 200 means the message was delivered. But can you be sure that the message was processed, not just delivered? You need more than just a status code; you need an acknowledgment to be sure your message went through properly.

What happens if you don’t get the acknowledgment? Clearly you have to pick some amount of time to wait and then retry if you don’t get the acknowledgment. Now what happens if the other server was just slow, so your message actually went through, but you sent it again? What if your message is a transaction of some sort? Sending it twice could cause serious problems. You could build logic into your application to deal with this, but wouldn’t it be nice if you didn’t have to?

The WS-ReliableMessaging (WSRM) Protocol
Fortunately there’s a standardized protocol for handling and solving all of the simple scenarios above and even more complicated scenarios. It’s called WS-ReliableMessaging or WSRM for short. It’s important that this not only solves the problem, but that it’s standardized. Even in the simple scenarios described above, there has to be some mutual understanding between the message sender and message receiver for any kind of reliability protocol to work.

Both sides have to understand and implement complementary components of a unified strategy. If you control both sides of a conversation, you can implement any unified strategy that you want. However, there are probably a lot of situations where you control only one side of a conversation. That’s when a standardized solution is needed. It’s the only way to ensure interoperability. It’s the interoperability from standardized solutions that have made Web Service protocols such as SOAP so successful. WSRM is in the same vein.

Numerous infrastructure vendors such as IBM, Microsoft, and Oracle have standardized WSRM. This let’s you use it for either side of a conversation and have confidence that the other side will be able to understand and communicate with you effectively and efficiently. It also means that a lot of people have reviewed the approach to make sure it works properly.