Don't worry, this post won't be nearly as ominous as the title indicates. Actually, I'm rather optimistic about the future of this space. Hopefully this Thursday at SAP in Palo Alto really will be the beginning of the end of the competing reliable messaging specifications, and we, and more importantly our customers, can begin to enjoy the benefits of a single, interoperable reliable messaging specification.
What is reliable messaging, and why is it so important?
The concept of reliable messaging is, simply put, the act of moving one or more messages from a sender to a receiver in a manner that guarantees a level of assurance that the message(s) will, in fact, be moved from the sender to the receiver. This guarantee is necessary so that business logic can be implemented on top of the messaging layer without worrying about all the ugly details of how this actually occurs, and instead simply be satisfied with the fact that it will occur in the manner specified.
The web services world has long awaited such a mechanism, especially as web services themselves have been used to address increasingly complex problems. It is almost a fact of life that the more complicated business services become, the more important that the reliable delivery of the messages exchanged among such services will be. It may suffice to say that the lack of any widely adopted reliable messaging specification is therefore not due to the lack of demand. So the question arises - what has been taking so long?
A brief history
I am relatively new to the standards game, and therefore the history of these specifications is not something that I took part in personally. I have, however, spent a fair amount of time trying to understand the developments so that I can ultimately achieve my goal, a goal that is desirable to many (if not all) of SAP's customers: The emergence of a single, widely adopted, interoperable web services specification that provides for the reliable delivery of messages.
As far as I can tell, around the year 2002 it became quite obvious in the industry that a specification describing an interoperable way of reliably exchanging messages was necessary. Until that point in time, the world had primarily focused on simple services, and accomplished this by exchanging SOAP messages over HTTP. This was fine for simple interactions, but not at all sufficient for business critical interactions between enterprises over an unreliable medium such as the web. When the industry began to realize the power of the web services architecture and companies started increasingly relying on web services for their core business processes, the need to make the message exchanges between these services reliable became glaringly apparent.
A spec divided
It seems, however, that even though the need for web services reliable messaging was apparent to everyone, there was a difference of opinions as to what the process for solving the problem should be. The first group decided to follow more or less the standard route to a standard. They first formed a technical committee under OASIS, a standards body, and then worked together to produce the final specification that would become known as WS-Reliability. On the other hand, the second group whose resulting work was called WS-ReliableMessaging, followed a different approach, in which they first published the specification under a royalty free license, then conducted interop workshops, and only after a certain milestone was reached would they consider submitting the specification to a standards body.
The two competing methodologies and the resulting competing specifications have left a bad taste in the mouth of the industry. Chris Ferris made this presentation, which resulted in this response from Bob Freund, and ultimately this rebuttal from the WS-RM group as a whole. Both sides naturally don't want to see their work go to waste, but the industry at a whole would benefit greatly from a single specification. Where will the madness end?
Unification? One spec to rule them all...
Well, hopefully it will at least begin to end on Thursday. It seems that the WS-ReliableMessaging specifications will now be submitted to the newly formed OASIS WS-ReliableExchange TC (WS-RM was already taken by WS-Reliability). It should be noted that many of the original members of the existing WS-Reliability TC have signed up to be a part of this new TC, which leads many to be optimistic that the problem of competing specifications can now be resolved in the new TC.
The first face to face meeting of the WS ReliableExchange TC is occurring this Thursday and Friday in Palo Alto and will be hosted by SAP. Given the broad support from both the competing efforts as well as from general OASIS membership, this meeting should be quite an interesting one, if not historic. Hopefully this TC will not become a battle ground but can instead be used to unite the two efforts to arrive at a single standard for Web Services reliable messaging that will be widely adopted throughout the industry. Only in this manner will enterprise web services be able to take a great leap forward, and only in this manner will SAP be able to provide the most value to its customers.
A quick timeline
- January 9, 2002: The WS-Reliability specification was published by Fujitsu, Hitachi, Oracle, NEC, Sonic Software and Sun Microsystems.
- February 13, 2003: The formation of a new OASIS Technical Committee was announced. The Web Services Reliable Messaging (WS-RM) TC was formed by a number of large industry companies, though IBM and Microsoft were notably absent from the list.
- March 13, 2003: One month after the formation of the TC, IBM, Microsoft, BEA, and TIBCO published the royalty free but proprietary WS-ReliableMessaging specification, which would compete directly with WS-Reliability.
- November 15, 2004: WS-Reliability was ratified as an OASIS standard.
- April 19, 2005: The latest version of WS-ReliableMessaging was submitted to OASIS as the basis for the WS-ReliableExchange TC.
- June 23, 2005: The WS-RX TC is scheduled to convene at SAP in Palo Alto.
References & Further Reading
