W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

RE: REST, Conversations and Reliability

From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
Date: Wed, 7 Aug 2002 08:27:49 -0700
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E2EAE76@bocnte2k3.boc.chevrontexaco.net>
To: "'Paul Prescod'" <paul@prescod.net>, "David Orchard" <dorchard@bea.com>, www-ws-arch@w3.org

Yes, but there is a HUGE community that wants to put business processes
through web services but sees the main inhibiting factors as lack of
consensus as to security mechanisms and reliable messaging mechanisms, both
of which are probably best done if pretty much everybody is agreeing on the
specifics of how they are implemented.  I think that this is, technically
speaking, a much more modest goal than making distributed applications.  I
remind you again that there is plenty of practical experience in how to do
this kind of thing in the EDI world, where competetion has historically been
limited by the constraints of using proprietary messaging systems instead of
the web.  We would like very much to see a standards-based EDI-like
situation where "everybody can play".

-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net] 
Sent: Wednesday, August 07, 2002 12:01 AM
To: David Orchard; www-ws-arch@w3.org
Subject: Re: REST, Conversations and Reliability

David Orchard wrote:
> I understand the point you are making, which is about the scalability 
> of reliability solutions that span trust domains.

And just when we were having so much fun dealing with specific proposals. ;)

> But I'll decline the challenge to show proof of something that I'm 
> hoping we're going to create.  I understand that you think we've tried 
> and failed,

I want to make the point that the Waldo paper that Mark cites later is
interesting in that it claims that every few years a new set of developers
tries to tackle these intractable problems. 

"Every ten years (approximately),
members of the language camp notice that the number of distributed
applications is relatively small. They look at the programming interfaces
and decide that the problem is that the programming model is not close
enough to whatever programming model is currently in vogue (messages in the
1970s [7], [8], procedure calls in the 1980s [9], [10], [11], and objects in
the 1990s [1], [2]). A furious bout of language and protocol design takes
place and a new distributed computing paradigm is announced that is
compliant with the latest programming model. After several years, the
percentage of distributed applications is discovered not to have increased
significantly, and the cycle begins anew."

You may not feel that you are in the "language camp" but when you talk about
separating networking and reliability logic from application logic it sounds
to me like you are. In network-based applications, networking and
reliability issues are central to your application's logic.

I also feel that the paper offers compelling evidence that applications
*cannot be agnostic* about reliability issues. Reliability must be worked
into the fabric of the application logic:

"The limitations on the reliability and robustness of NFS have nothing to do
with the implementation of the parts of that system. There is no "quality of
service" that can be improved to eliminate the need for hard mounting NFS
volumes. The problem can be traced to the interface upon which NFS is built,
an interface that was designed for non-distributed computing where partial
failure was not possible. The reliability of 
NFS cannot be changed without achange to that interface [used by
programmer's to construct the application logic], a change that will reflect
the distributed nature of the application."

In other words, the programmer's interface and application logic must be
changed: reliability cannot be outsourced.

> but I think we have some new technology - like the web URIs, XML, 
> SOAP, WSDL - as well as past experience that will help us.  And I 
> think we can use these technologies in ways that loosely couple 
> reliability to application semantics.

Every past attempt to solve this problem has built on technologies that were
isomorphic to URIs, XML, SOAP and WSDL. But there is no need arguing
specifics. You believe things are much different this time around. I do not.
XML, Web Services Architecture, REST Architectural Style Consulting,
training, programming: http://www.constantrevolution.com Come discuss XML
and REST web services at the Extreme Markup Conference
Received on Wednesday, 7 August 2002 11:29:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:58 UTC