W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

RE: Need info on Reliable Messaging

From: Anne Thomas Manes <anne@manes.net>
Date: Thu, 27 Feb 2003 08:40:00 -0500
To: "Bhanu Challa" <challabp@yahoo.com>, <www-ws-arch@w3.org>


You might want to address these questions to the WS-RM team at OASIS. But
I'll give you my personal opinion. See inline...


-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Bhanu Challa
Sent: Thursday, February 27, 2003 7:51 AM
To: www-ws-arch@w3.org; challabp@yahoo.com
Subject: Need info on Reliable Messaging

Hi All,
       I know very little about the "WS- Reliable Messaging". I need few
clarifications on this topic. You may feel these are very basic questions,
but your valuable responses will definitely help me in understanding
WebServices technology to some extent.
1) Does the WS reliability means providing only reliable messaging across
web services/applications? Or WebServices can be made reliable by any other

WS-RM applies only to SOAP messaging. It is a SOAP extension that conveys
context between the SOAP sender and SOAP receiver so that they cna be
assured that messages are delivery according to a defined quality of service
(e.g., once and only once). Use of WS-RM assumes that the SOAP runtime or
application has the ability to assure the requested quality of service.

2) From WS-Reliability specification, my understanding is, each application
needs the logic to provide reliability? Cant we provide a built-in mechanism
which forces to implement all the reliability stuff into the architecture

WS-RM assumes that the SOAP sender and the SOAP receiver has the ability to
support reliability. Keep in mind that the SOAP runtimes on either side of
the wire play the roles of SOAP sender and SOAP receiver (not the end
application). There's no assumption that the application manages reliability

3) Can any one give pointers on Reliability/Reliable Messaging in the
context of web services without dwelling much into any specific technology
such as MSMQ,MQ Series, JMS??

The whole point of WS-RM is to enable reliability at the SOAP protocol level
rather than at the transport level. Right now most [maybe all] WS platforms
rely on the transport to support reliability. Right now all I can point you
to is the WS-Reliability spec. The WS-RM team will produce more documents
soon. Perhaps the WS-Arch Relability task force can point you to some
preliminary documents.

4) Can any one give pointers on each specific technology(above mentioned)
pros and cons over the another??

I don't think this is the venue to compare product implementations.

5)What are the pros if the architecture itself provides reliability related
stuff instead an application providing the same?

It's the same argument that applies to any middleware extension. You want to
use a standard framework to ensure efficiency, interoperability, and

6)"Reliable" the meaning itself is really ambiguous for me!!! Does it
relates to Fault-tolerance, availability, security!!!?? Can any one help me
in distinguishing whats the meaning of reliability???

See section 1 of the WS-Reliability spec [1]. Reliability refers to a
*predictable* quality of service. It is a separate issue from fault
tolerance, availability, or security. If you send a message, you want to be
sure that it gets delivered properly. If the first send doesn't go through,
then it should be resent. If you send the message more than once, you need
to make sure that it only gets processed once. If for some reason you can't
deliver the message immediately, then perhaps it can be queued and sent
later. If the message can't be delivered within a specified period of time,
the application needs to know that. WS-RM allows you to do that.

[1] http://www.sonicsoftware.com/docs/ws_reliability.pdf

Your valuable suggestion/comments/anwsers would really help me.
Thanks and Regards

Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, and more
Received on Thursday, 27 February 2003 08:40:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:04 UTC