Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
InfoQ Article: An Introduction to WS-Reliable Messaging
Posted by Stefan Tilkov on Sep 12, 2006
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.
Read An Introduction to Web Services Reliable Messaging
- This article is part of a featured topic series on SOA
- See more SOA content at: http://www.infoq.com/soa
- Other recent content items in this topic
WS-* versus JMS
by
Jack van Hoof
Posted
Re: WS-* versus JMS
by
Paul Fremantle
Posted
Re: WS-* versus JMS
by
Stefan Tilkov
Posted
This is why god invented tools...
by
Steve Jones
Posted
Re: This is why god invented tools...
by
Paul Fremantle
Posted
Persistent messaging?
by
Guy Crets
Posted
Re: Persistent messaging?
by
Paul Fremantle
Posted
WSRM vs JMS
by
Paul Mesh
Posted
RMD vs RD
by
Alfred Deeb
Posted
Re: RMD vs RD
by
Alfred Deeb
Posted
-
One of the big differences with the old world is that we don't have the program tell the messaging-infrastructure how to handle the message (JMS), but we use the message itself to tell the infrastructure how it has to be handled (WS-*). Am I right on that?
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
-
Jack
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 :-) -
And Paul of course.
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. -
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. -
I agree that "tools" or infrastructure are what make RM simple. But as one of the people involved in the spec, I also think that we have built a spec that is inherently much cleaner and more straightforward than most messaging systems. If you think its easy setting MQSeries, you'll find WSRM a doddle!
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.
Paul -
Paul,
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! -
Guy
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.
Paul -
If you think WSRM is simpler than JMS than you are mistaken. And by the way I can use JMS with other clients than JAVA. If you think that JMS provider manages all communications in durable fashion. I do not think HTTP provides durability.
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. -
Hello Paul and Integration enthusiasts
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?
Thank you
Alfred -
Correction on my previous post:
'RD' should read 'AD' (Application Destination) in the following sentence:
.. 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.
10 comments
Watch Thread Reply