I agree that TCP/IP provides the reliability described below. I don't think
that TCP/IP can, given current web architecture with transport protocols
running on top, do it effectively in a web services environment. So I would
probably add a couple of more definitions, i.e.
3. Where a Message can be, but does not have to be, a SOAP Message
4. Which can implemented in an application neutral way with any existing
popular transport protocol, e.g. HTTP and SMTP.
Item "3" is needed because delivery of the WHOLE message is important - not
just bits of it which TCP/IP does
Item "4" is probably not absolutely necessary but is, I think, highly
practical as SOAP Messages use these protocols at the moment.
David
-----Original Message-----
From: Walden Mathews [mailto:waldenm@ilx.com]
Sent: Wednesday, July 10, 2002 8:32 AM
To: 'Burdett, David'; 'Mark Baker'; Champion, Mike
Cc: www-ws-arch@w3.org
Subject: RE: [RTF] AC019 proposal to WSA WG
> So the conclusion I think I would draw from this is as follows:
> 1. We need a well designed "reliable messaging" support within the
> architecture that can enable very high probabilities of
> successful delivery
> of a message.
> 2. The reliable messaging support must provide a mechanism of
> notifying an
> application that the message could not be delivered, so that
> the application
> can take a compensating action if they want, and
> 3. Reliable Messaging should be optional - you don't have to
> use it if you
> don't want to - as Mark points out, there are other ways of
> realizing this
> requirement.
As far as I can tell, all the tension in this argument about RM is
between RM and "protocol independence", because all of the above described
reliability is provided by TCP/IP.
If we want web services to have "reliability", where reliability is
defined in reasonable terms as above, then it sounds simply like a
transport protocol choice.
Please tell me what nuances I am missing.
Walden Mathews