InfoQ Article: An Introduction to WS-Reliable Messaging
The OASIS WS-RX Technical Committee recently released the Web Services Reliable Messaging 1.1 specification for public review. In an InfoQ article, WSO2's Paul Fremantle, who is one of the two co-chairs of the committee, takes the opportunity to provide an introduction to WSRM and an overview of the specification. After describing the needs covered by WS-RM, Paul shows how the specification approaches them and illustrates how how it might be used in real systems.
Quoting from the article:
Web Services Reliable Messaging (WSRM) is a specification that allows two systems to send messages between each other reliably. The aim of this is to ensure that messages are transferred properly from the sender to the receiver. Reliable Messaging is a complex thing to define, but you can think about WSRM as providing a similar level of guarantee for XML messaging that a JMS system provides in the Java world. There is one key difference though - JMS is a standard API or programming model, with lots of different implementations and wire-protocols underneath it. WSRM is the opposite - a standard wire-protocol with no API or programming model of its own. Instead it composes with existing SOAP-based systems.
Paul's introduction is a great read, whether you are new to WS-RM in general or only interested in finding out what has changed from previous versions.
WS-* versus JMS
Jack van Hoof
And all messaging-infrastructures will understand WS-*, even the network hardware devices like routers and switches. This way the message can - and will - break out of the closed systems and travel freely across heterogeneous infrastructures. Within or outside your company. With your ESB as the company's business events container, representing the real-time state of your business; including all the historical states in a fluent time-line to the past. Imagine it's huge potential...
Jack van Hoof
Re: WS-* versus JMS
You are quite right! The term that is most used is "composable". In other words, you can write a service-based interface and use it. Then when it becomes necessary to add reliability, you can do that without changing code. That is a huge benefit.
In comparing WSRM to JMS there is another interesting aspect - the naming convention. JMS has a complex naming model based on JNDI with Connection Factories as well as Queue or Topic names. This can be complex to setup, and especially when trying to interoperate between different systems (e.g. SOAP/JMS). WSRM just uses the same URI that the SOAP message is going to, making it much simpler and cleaner. Its almost a REST-like argument why a WS-standard is good :-)
This is why god invented tools...
I'm very happy to see WS-RX (featuring RM) out there in the wild now as it makes some of the B2B scenarios much more possible.
One of the bits that seems to be overlooked with Reliable Exchange is that its very simple from a programmatic sense, but very complex from a policy and infrastructure perspective. I'm extremely glad to see that the tools vendors are looking to wrap WS-RX up so we don't all have to read the specification just to send a message reliably.
One question I have is should WS-RX become the default position for all externally facing web services.
Re: WS-* versus JMS
Its almost a REST-like argument why a WS-standard is good :-)
A REST-like argument for WS-*? There can be no such thing :-)
Excellent article, BTW; I learned a lot even though I had closely looked at the earlier versions.
Re: This is why god invented tools...
Certainly we simplified WSRM Policy (to simply say: RM is on, optional). Because it is so simple, it is possible to have only one switch - "RM is on" - and bypass the requirement to have a policy XML.
From an infrastructure perspective, its very simple to make RM completely automatic. For example, WSO2 Tungsten has the ability to turn on fully persistent reliability just by selecting RM from a drop-down box. That's all it takes.
Very nice article! But I remain puzzled about the persistence part: why doesn't the spec say anything about it? Any why doesn WS-RM Policy allow to configure if the communcation should use persistent messaging (queueing)?
This is in my opinion a big hurdle in the adoption of WS-RM and WS-* in general as an alternative for JMS, AS2, RosettaNet and other reliable protcols.
Kind regards, Guy Crets
PS: looking forward to your talk about WS-RM at JavaPolis 2006!
Re: Persistent messaging?
The reason we don't say anything about persistence in the spec is because of two key SOA concepts:
1. Composability. If the RM spec defines transactional/persistent properties then that would overlap with other specs such as WS-AT.
2. Independence from implementation. WS-RM is designed to be a wire-protocol, not an end-to-end protocol, because it is meant to shield the user from the implementation. The wire protocol does not and should not care about issues such as persistence.
I personally would like a WS-Policy assertion that defines reliability, but the OASIS TC preferred to leave this out of the specification as being out-of-scope for the group.
WSRM vs JMS
The question is does your business intend to expose it's SOA services to outside than WSRM may make seance. If your business is looking to quikly turn around data in relible fashion JMS is the best and simplest to implement out there.
RMD vs RD
We have a 'legacy' system that conforms to an earlier version of the Web Services specification (SOAP 1.1 and WSDL 1.1). The legacy system however does not natively conform to the ws-rm specification. We are using BEA Aqualogic as a middleware platform to expose all Web Services within our landscape. BEA does conform to the ws-rm specification.
We will expose these Web Services from the legacy systems as proxies via the ESB. Thus all interested consumers call these Web Services via the proxies. The proxies itself call the native 'legacy' Web Services synchronously over http. This of course is natively unreliable.
If we expose a ws-rm compliant "proxy" via the ESB, representing a native Web Service of the legacy system, does this then become overall reliable?
What I've come to understand thus far is that the scope of ws-rm concerns only the communications between the RMS and RMD.
Now if I take the following remark in your article:
"In RM, there are handlers or agents that sit inside the client's and server's SOAP processing engines and transfer messages, handle retries and do delivery"
.. and considering the scenario I describe above, my understanding is that the RD is actually the "proxy" and not the actual Web Service in the legacy system itself.
Thus any communications between the RMS and the RMD is reliable, so calls to the proxy itself is relaible but what's to be said for the unrelaible communication between the proxy and the actual web service in the underlying system?
My understanding is that the RMD should be an agent that sits "on the other side of the unreliable infrastructure separating it from the RMS" and inside the SOAP processing engine of the legacy system?
Given this then the communication between the proxy and the actual web service remains the "weakest link"... or perhaps I miss something?