RE: [RTF] AC019 proposal to WSA WG

Having just read this thread, I find my position, I think, midway between
Mark's perspective and everyone else.

Firstly I think I am safe saying that everyone wants web services to work
reliably ... at least when they need to.

Secondly, web services working reliably I think is split into several parts
including:
1. The sender of a request working reliably - if you can't get the message
out onto the network infrastructure then you're not reliable
2. Delivery of the message over the network infrastructure to the
destination web service reliably - i.e. it gets to where it needs to go
3. The receiving web service actually works reliably and does not fail and
so produces the response that is required.

Now I believe that 1 and 3 are completely out of scope as they are reliant
on the design, architecture and implementation of the application software
at each end. This leaves us with "2" which is all about delivering messages
reliably, or, dare I say it, "Reliable Messaging".

However, as Mark points out there are several ways in which "reliable
delivery of a message to its destination" can be implemented including:
1. The initial sending application resending a message if it does not get
the reply it needs - this is fine IF this is what an implementer wants to do
although the logic required to do this reliably is non-trivial
2. The underlying communication technology is reliable. This is perhaps a
bit far fetched, but you could imagine a private network which, because of
redundancy and failure recovery software, was able to "guarantee" delivery
or, if I'm accurate, "reduce the probability of failure to such a low level
that the user of the technology views the cost of applying other
"reliability" techniques uneconomic" - after all there is really no such
thing as "guaranteed", or
3.  Using infrastructure that sits between the sending application and the
receiving application that provides reliable sending of a message over
unreliable networks, e.g. the Internet. This has the major benefit of
removing the need for applications at each end to worry about making sure
that a message is delivered.

Now I think that 1 and 2 above are out of scope, since, if an application
designer wants to resend a message then they can and if you have
super-reliable infrastructure then there's no need to do anything else. 

However I think that "3" is very useful, and this is what I think of as
reliable messaging. However it does not mean that the sending application
can just "fire and forget" whatever message they are sending, as, even if
the most reliable infrastructure is used for delivering messages, they can
still fail to get through, for example if the receiving web service has
fallen over because the data center has gone up in smoke and there is no hot
(or even warm) backup - then the probability of the original message ever
being delivered in a sensible timeframe is pretty low.

However it does mean that if a "well designed" infrastructure level reliable
messaging solution has been used, it probably means that there is no point
in the application trying to resend the message as it would almost certainly
be unsuccessful.

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.

Finally, as I am, obviously, fairly new to this list, I apologize if I have
already covered topics that have been covered before.

David


-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Wednesday, July 10, 2002 7:35 AM
To: Champion, Mike
Cc: www-ws-arch@w3.org
Subject: Re: [RTF] AC019 proposal to WSA WG



On Wed, Jul 10, 2002 at 08:42:58AM -0400, Champion, Mike wrote:
> > There's a cost to making it reliable.  If it isn't required, as with
> > idempotent methods such as GET and PUT, then that's an enormous cost.
> 
> Sure ... I can buy an unreliable car that will *probably* get me to work
> for $1000.  If it breaks down, I can simply buy another ....It's not
> REQUIRED to have a reliable car, but awfully inconvenient not to.
> 
> Or I can buy a reliable car for $10,000.  Which strategy do most people
who
> can afford it take?   

I wish it were as easy as assigning a dollar figure!  No, what I meant
was that there's a cost in the brittleness of any system built to an
architecture that implements reliable messaging, due to the reasons
discussed in the Waldo paper.

> > Maybe you can answer me this; why is it important that HTTP GET or PUT
> > messages be reliably delivered? 
> 
> Because lots and lots of developers say that this is an issue, and many
> member companies proprietary web services architectures have or propose a
> solution to the reliability issue, and because if reliability isn't
covered
> in the WSA the developers will use incompatible proprietary solutions, and
> the absence of a solution to a commonly cited problem in the WSA will
> seriously undermine its credibility in the industry.  

I agree with most of that, but you appear to be associating
"reliability" with "reliable messaging", so I can understand your
concern.  But I'm not ruling out reliability (that would be quite
daft!), I'm just saying that there are ways of addressing it that don't
invole requiring that every message arrive at its destination, and that
it is primarily a function of the architectural style in use as to which
solution is the most appropriate.

Thanks.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 10 July 2002 11:19:30 UTC