RE: "Reliable" web services for Next Big Thing?

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Thursday, December 05, 2002 12:41 PM
> To: www-ws-arch@w3.org
> Subject: RE: "Reliable" web services for Next Big Thing? (was 
> RE: Agenda
> for 5 December WSA telcon)
> 
> 
> 
> <snip/>
> 
> >
> > Can we just focus on "reliable messaging" (AFAIK, a guarantee that
> > a SOAP message will arrive either 0 or 1 times at its destination,
> > and the sender will be unambiguously informed which it was), or
> > is the larger architectural question of "reliability" something
> > we can dig into?
> >
> 
> I think that a simple acknowledgement protocol in soap 
> headers would be very
> useful and hit an 80/20 point.  We've consistently heard from 
> customers and
> partners that reliable messaging is very important to them.  
> I support the
> discussion and architectural description of reliable messaging in this
> forum.
> 
> And saying that reliable messaging protocols don't make sense 
> is akin to
> saying that we don't need tcp as ip already exists.

As long as no applications developers are fooled into thinking
this means they have less work to do in building reliable applications.
80/20 is a fallacy in this context, because in the first place,
it's a counterexample of what people mean when they say "reliable",
and in the second place, because of the "special" economics of
software, the effort to develop the mitigation for the 20% rivals
if not equals an effort to mitigate the problem from scratch,
100%.  That's why the workstation in my previous story was written
the way it was, unavoidably.  That's the point.

TCP is helpful, but it's not enough.  By analogy, if you employ
a financial advisor, consider the wisdom of not reviewing his/her
decisions w.r.t. your portfolio.  It's a question of ultimate
accountability.

Respectfully,

Walden

Received on Thursday, 5 December 2002 12:57:17 UTC