When we build out systems and networks, we look at availability in 9s, as in 99.9xx. No one thinks it realistic that software, hardware, or the network will be available 100% of the time. Ironically, one of the key challenges of developing connected systems is connectivity itself.

In practical terms, sometimes this is the result of the network leaving usnetwork connectivity and hardware have temporary or extended outages. Other times, it's a case of us leaving the networkmoving in and out of Wi-Fi coverage areas where we disconnect and reconnect silently behind the scenes.

When disruptions occur, there is an increased likelihood for the unpredictable. If the outage occurs during a multipart operation, the system we're communicating with may be left in an unstable state. Messages may be dropped. Messages may be delivered out of sequence. On restarting, messages may be duplicated.

These disruptions can introduce unplanned variables into the way an application was designed to run, rendering it potentially unreliable as a result. This is not acceptable for the connected systems being developed today.

Regardless of where they originate and why, these temporary losses of connectivity will occur, and your applications need to offset these impacts because they could make the system unreliable.

WS-Reliable Messaging (WS-RM)

The instigating outages are rarely predictable, so applications must be designed to adapt and compensate for these challenges. Fortunately, the problem of reliability has been addressed inside the firewall by a number of middleware vendors for a number of years.

While these solutions have had a number of recurring features in common, they have typically been tied to a particular OS platform or vendor(s) product(s). With the advent of services, it became critical to introduce a standard provided the ability to ensure reliability while being platform and product agnostic.

The industry recognized this and began work on a standard. In doing so, they consciously acknowledged that in a service-oriented world, it was very likely that in addition to being able to being agnostic to platform and product, it also needed the ability to survive multiple hops. Between endpoint A and endpoint B, a number of intermediaries could be used. Also recognized was that if this was also protocol agnostic, it would need to define the standard in such a way that reliability could be added to messaging that utilized unreliable transports as well.

The resulting standard, WS-Reliable Messaging, was put forth by major players in the industry, among them Microsoft, IBM, and Tibco. That specification defines the following reliability features:

  • Guaranteed message delivery, or At-Least-Once delivery semantics

  • Guaranteed message duplicate elimination, or At-Most-Once delivery semantics

  • Guaranteed message delivery and duplicate elimination, or Exactly-Once delivery semantics

  • Guaranteed message ordering for delivery within a group of messages

A number of vendors either have built implementations or have implementations under development. Figure identifies the status of WS-Reliable Messaging development by major companies in the industry, at the time of this writing.

WS-RM Adoption Among Leading Vendors


WS-RM Support

Microsoft WCF


IBM, ETTKAlphaWorks


BEA, WebLogic 9.0


Cape Clear




Blue Titan


Apache Axis 1.3 Sandesha



In Development


In Development

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows