/ciol/media/agency_attachments/c0E28gS06GM3VmrXNw5G.png)
Follow UsThe just announced WS-Reliability (or reliable Web Services messaging) working draft specification by Fujitsu, Hitachi, NEC, Oracle, Sonic Software and Sun Microsystems is best viewed as a table-setter for a final specification yet to come. The reliability of Web Services messaging has been one of the issues preventing more rapid adoption of Web Services.
WS-Reliability hopes to settle this issue by providing a decidedly minimalist (and royalty-free) specification that uses Simple Object Access Protocol (SOAP) 1.1’s extensibility mechanism to address guaranteed delivery, elimination of duplicates and ordered message delivery.
There is no question that WS-Reliability solves a real problem. One strong point in the design is that the specification is at the SOAP protocol level (rather than at the HTTP level like IBM’s HTTPR spec), which allows reliability to be guaranteed no matter what the SOAP messages are ultimately being transmitted over. The ordered message delivery uses the concept of a group ID, which could then be used by a higher level spec to more easily create conversations or choreography. Minimalism is good but WS-Reliability might be too minimalist. For example, it’s easy to imagine that reliability could be rolled into choreography or conversations, especially if doing so helps manage messaging to quality of service objectives. That is exactly the approach taken by ebXML’s ebMS messaging service (from which WS-Reliability heavily borrows), which provides reliability.
While anyone can create a spec, getting traction is another issue. Historically, the Web Services
specifications with the most adoption have been from respected standards organizations (World Wide Web Consortium (W3C) or Organization for the Advancement of Structured Information Standards (OASIS)) or from IBM and Microsoft.
The likelihood of adoption of WS-Reliability spec will be driven by:
- W3C interest (if this spec is submitted to OASIS or Internet Engineering Task Force (IETF), the probability goes way down)
- Ability to get either Microsoft or IBM on board (which we deem unlikely)
- The authors’ ability to get implementations in the hands of developers (ideally through the Apache Foundation in products like Axis), or through Java APIs like JAX-RPC and JAXM
- The cost of implementation and the ease of transition to an alternate spec if one emerges
- The quality of the spec itself (Is it minimally sufficient?)
The likely effect of the WS-Reliability spec will be to exert strong pressure on whatever final spec gets adopted by a standards body and users to ensure that it will be royalty free.
Recommendations
For clients with a strong need for reliable messaging solution now, it’s certainly worth downloading the spec and evaluating whether it will meet architecture’s needs. Using the spec will require implementation support a better choice would be to send SOAP over a reliable transport where possible. Some vendors who provide support for this are IBM, Sonic, TIBCO and Microsoft. For clients that can afford to wait, it will be about six months before standards organization decides to begin standardizing WS-Reliability and IBM/Microsoft announce their own competing spec. The WS-Reliability specification working draft is available royalty free for download from each co-editor’s website, see: