W3C home > Mailing lists > Public > public-ws-chor@w3.org > July 2003

Re: RM

From: Assaf Arkin <arkin@intalio.com>
Date: Mon, 21 Jul 2003 13:02:52 -0700
Message-ID: <3F1C46EC.6070901@intalio.com>
To: jdart@tibco.com
CC: Ugo Corda <UCorda@SeeBeyond.com>, Burdett David <david.burdett@commerceone.com>, public-ws-chor@w3.org

Jon Dart wrote:

> I haven't followed the TC discussion, but as I've said before, 
> Reliable messaging != MEPs, IMO. Adding acknowledgement traffic to the 
> message descriptions at the WSDL layer just complicates and obscures 
> the data traffic (e.g. SOAP payload). RM is a QOS for message 
> delivery; it's not a pattern of message exchange, nor should it be, at 
> the WSDL layer.
> This is the tack taken so far by the WS-ReliableMessaging spec (which 
> does consider WSDL). WS-Reliability is also at least considering this
> approach (see e.g. the proposal in 
> http://lists.oasis-open.org/archives/wsrm/200307/msg00002.html to
> "leave WSRM MEP information out of the WSDL").
> The idea of sending acks "out of band" to a separate set of endpoints 
> is interesting but hasn't been considered so far for RM, AFAIK.

Come to think of it, it doesn't have to be a separate endpoint in the 
sense of a SOAP address, but a separate endpoint in the sense of a 
separate channel. You don't want to override each interface with 
RM-specific operations just so you can use RM with that interface. Doing 
so would not allow you to select protocols independently of the 
interface definition.

But you can expect the same SOAP address to receive different messages 
targeting different operations in different interfaces. So one address 
may represent two different endpoints, one for business-level operations 
and one for RM operations (and even more for coordination, security, 
etc). But if we define service to be address+interface, then even though 
two services use the same address they are still two separate endpoints 
(or some other more applicable term).


> --Jon
Received on Monday, 21 July 2003 16:03:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:00 UTC