When two parties want to communicate reliably using SOAP messaging, the most common option is to select a message queueing system, typically JMS-based. While this provides some portability, is does not create interoperability — which means that reliable communication is restricted to those communication partners who are able and willing to connect to the same middleware. WS-ReliableMessaging 1.1, which has just become an OASIS committe draft, provides an interoperable solution to this problem. It achieves this by implementing the necessary protocol on top of SOAP, which means that even an unreliable communication protocol such as HTTP can be used as the basis for reliable communication. One of the most important scenarios for this is B2B interaction, i.e. communication between distinct companies.
The committee draft status is significant because it marks the end of the most frequently cited Web services standards battle. OASIS has already ratified a standard addressing the same problem, WS-Reliability, originally created by Sun, Fujitsu, Novell, Oracle and Sonic. Proving expectations expressed by many analysts and industry experts correct, it never gained wide-spread adoption because industry heavyweights such Microsoft and IBM, together with BEA and TIBCO, pursued their similar, but distinct specification: WS-ReliableMessaging. Both specifications were originally published in early 2003; WS-Reliability became a standard in November 2004.
WS-ReliableMessaging, which had been updated twice (in 2004 and 2005) was submitted to OASIS in April 2005. The committee draft specification of WS-ReliableMessaging 1.1 has been created with support from many of the companies who were involved in WS-Reliability and the original WS-ReliableMessaging spec. WS-ReliableMessaging is based on WS-Addressing (itself now a W3C recommendation); the accompanying Web Services Reliable Messaging Policy Assertion v1.1, which is based on WS-Policy (also recently submitted to W3C), defines how to express reliability-related messaging capabilities and needs.
The committee draft status is significant because it marks the end of the most frequently cited Web services standards battle. OASIS has already ratified a standard addressing the same problem, WS-Reliability, originally created by Sun, Fujitsu, Novell, Oracle and Sonic. Proving expectations expressed by many analysts and industry experts correct, it never gained wide-spread adoption because industry heavyweights such Microsoft and IBM, together with BEA and TIBCO, pursued their similar, but distinct specification: WS-ReliableMessaging. Both specifications were originally published in early 2003; WS-Reliability became a standard in November 2004.
WS-ReliableMessaging, which had been updated twice (in 2004 and 2005) was submitted to OASIS in April 2005. The committee draft specification of WS-ReliableMessaging 1.1 has been created with support from many of the companies who were involved in WS-Reliability and the original WS-ReliableMessaging spec. WS-ReliableMessaging is based on WS-Addressing (itself now a W3C recommendation); the accompanying Web Services Reliable Messaging Policy Assertion v1.1, which is based on WS-Policy (also recently submitted to W3C), defines how to express reliability-related messaging capabilities and needs.
/filters:no_upscale()/sponsorship/topic/c7a3c369-fdfd-4c13-b1f1-4938dc3bedc5/KalixLightbendLogoRSB2023-1681370636831.jpg)
/articles/how-to-manage-full-stack-java-development-with-hilla/en/smallimage/manage-full-stack-java-development-with-hilla-small-1686055303315.jpg)
/articles/debugging-beneath-trusted-abstraction/en/smallimage/debugging-outside-comfort-zone-diving-beneath-trusted-abstraction-small-1685961994992.jpg)
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
Community comments
Public Review starting
by Paul Fremantle,
Re: Public Review starting
by Stefan Tilkov,
Public Review starting
by Paul Fremantle,
Your message is awaiting moderation. Thank you for participating in the discussion.
Stefan
Good article. I just want to clear up one point. This is slightly more important than just an OASIS Committee Draft. Without going into the whole OASIS process, this is our first public review, and the main chance for interested parties to comment. Based on the feedback we aim to try to get WSRM 1.1 standardised by around the end of the year.
Not only is this an opportunity to provide feedback, this is also a major "stake in the ground" for the technical committee. We have resolved all the major issues we raised as a group, and we believe the spec is in good shape.
Paul Fremantle
Co-chair - OASIS Web Service Reliable exchange TC
Re: Public Review starting
by Stefan Tilkov,
Your message is awaiting moderation. Thank you for participating in the discussion.
Thanks for your comment, Paul. If the news item did not communicate the importance, it was unintentional -- I'm very much aware of the importance for the WS-* community. Congrats for getting it out the door ;-)