BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News InfoQ Article: An Introduction to WS-Reliable Messaging

InfoQ Article: An Introduction to WS-Reliable Messaging

Bookmarks

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

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • WS-* versus JMS

    by Jack van Hoof,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: WS-* versus JMS

    by Paul Fremantle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 :-)

  • This is why god invented tools...

    by Steve Jones,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: WS-* versus JMS

    by Stefan Tilkov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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...

    by Paul Fremantle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Persistent messaging?

    by Guy Crets,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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!

  • Re: Persistent messaging?

    by Paul Fremantle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • WSRM vs JMS

    by Paul Mesh,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • RMD vs RD

    by Alfred Deeb,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: RMD vs RD

    by Alfred Deeb,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT