Great news for anyone interested in the WS-ReliableMessaging specification — as we are — the spec has been submitted to OASIS and a new technical committee is being proposed to progress it.
Anytime a Web services specification as significant as WS-RM is submitted to OASIS or W3C is cause for celebration – or at least some applause. Especially when submitted (as this specification was) under royalty-free terms and conditions.
InformationWeek and articles highlight the competition between WS-ReliableMessaging and WS-Reliability, which is now an OASIS standard. Yet many vendors, including Sun, Sonic, and IONA support both.
So what is going on?
We (IONA) co-sponsored the creation of the original WS-RM TC at OASIS about two years ago because reliability is a key enabling quality for Web services. Customers consistently have been telling us that certain applications, such as EDI replacement or electronic funds transfer, for example, just could not be considered without it. If WS-ReliableMessaging had been around at the time, and submitted to OASIS, we would have supported that instead.
Two years later, we are supporting the current submission (for more details see Robin Cover’s write up.) We think that WS-ReliableMessaging is a better specification, and because it’s supported by Microsoft and IBM it has better market traction than WS-Reliability. This is also the specification customers are asking us to support. We’ve implemented a subset version in our mobile device platform and plan to offer a complete implementation in an upcoming release of our core ESB product, Artix.
One good question is how one specification is different from the other. This is reflected in some of the discussion around this announcement, for example the statement about how WS-ReliableMessaging fits better into the WS-* stack (which actually brings up another whole discussion around which stack you mean, since there are multiple versions of the stack, and the WS-Reliability specification also composes well with other specifications such as WS-Security and ebXML Messaging).
Another key difference is that WS-Reliability defines reliable semantics including the application level, while WS-ReliableMessaging defines reliability only for the transport level. WS-Reliability defines semantics fo submitting and receiving the message, not simply for transporting the message reliably from point A to point B.
The inclusion of operations, albeit abstract operations (i.e. Submit, Deliver, Respond, and Notify) distinguishes WS-Reliability from WS-ReliableMessaging since these operations define the handshake between the sending application and the receiving application. WS-ReliableMessaging explicitly omits any specification of this handshake.
Otherwise the specifications are remarkably similar, except for terminology, in the way in which they accomplish reliability using a series of acknowledgements for a group of messages. The acknowledgements indicate whether a message was in fact received, or if not, whether one or more messages in a sequence need to be resent.
One other difference in the most recent version of WS-ReliableMessaging is that the RM policies are defined using a separate specification. This is consistent with one of the recommendations we made in our position paper at last October’s W3C Workshop on Constraints and Capabilities for Web Services (aka the Policy Workshop).
Returning to the topic of reliable messaging, however, a couple of final points.
First, it’s strange to have a reliable messaging specification defined at the same level as the other WS-* specifications, which are all designed to be transport independent. For example, one of the major justifications for WS-Addressing is that the addressing information needs to be included in the SOAP envelope so that routing and dispatching the SOAP message is not dependent upon the features of any underlying transport, as was the case with the SOAP 1.1 SOAP Action HTTP header (which has since been deprecated.)
But many popular transports natively include reliability features, including JMS, WebSphere MQ, CORBA Notification, IIOP, RMI-IIOP, DCOM, and .NET Remoting to name a few. Adding any kind of WS-ReliabilityMessaging on top of an already reliable transport doesn’t make much sense. WS-ReliabilityMessaging (if you’ll pardon the shorthand) is really only necessary for unreliable transports, such as HTTP. And of course reliability is one of those extended transport features intentionally left out of HTTP so it would scale.
The primary purpose is to create a reliablity layer for HTTP, which doesn’t have one. However for consistency with other WS-* specs it is still designed to be transport independent. This just seems a little strange overall – but I suppose another good application is to reliably bridge between HTTP and JMS (or any other) transports.
Overall the technical differences between WS-Reliability and WS-ReliableMessaging seem less significant than the marketplace dynamics surrounding them (and thus the news angle of conflict), at the high level they represent the inevitable result of two very different overall approaches. WS-Reliability evolved from ebXML messaging, while WS-ReliableMessaging was developed from the basic SOAP starting point.
Those of us who have been involved in this debate long enough 😉 remember that the ebXML and SOAP stacks originally had very different starting points and assumptions. During the past five years the two camps have drifted closer together, but the original ebXML architecture started with the business process and decomposed to the messaging layer, while SOAP started with a simple messaging layer and proposed a composition model that would extend upwards to the business process.
The current differences between these two very similar specifications remains rooted in that past time during which ebXML and SOAP were strongly competing.
Update May 10 With the original supporters of WS-Reliability joining the new WS-Reliable Exchange (WS-RX) TC, it looks as if the confict is finally over.


Comments are closed.