RE: REST, Conversations and Reliability

Paul,

The point is here is not as much about hiding the reliability logic
layer from the application logic layer but to allow the application
logic to delegate reliability.

The difference is that in the second case the application is aware that
it is communicating with a remote service and it decides to "queue" a
message for that services. 

The benefits of a messaging paradigm are reliability but also
scalability in the sense that it allows components that have different
throughput to communicate (my B2B gateway can handle 1000tx/s but my SAP
system can only handle 50tx/s).

Messaging works, it has been deployed for years: There are more MQSeries
deployment than app servers deployments. New technologies and standards
like XML, XML Schema, HTTP, URI could take existing messaging
infrastructure that are priorietary and difficult to deploy and manage
across domains and make then ubiquitous.

Messaging does not means that app logic does not need to handle failure
to connect to messaging or timeout but it encapsulates a big chunk of
the retries, queuing and load balancing. Things that would need to be
otherwise implemented and managed one off as part of each application.

Another proof of that is the adoption of JMS within distributed J2EE
applications.

The conclusion here is that there are ways to allow the application
logic to delegate message delivery to messaging intermediaries, which
are known to developers and can therefore avoid the pitfalls of RPC type
abstractions. 

Although I am not a REST expert, I believe that this can be done while
respecting REST by creating a Queue resource. The only side effect is
that in those cases, where one can also imagine multiple protocols to
access to those queue resources, it might be beneficial to store
operation, correlation, transaction and other context information inside
the SOAP message so that it is transport agnostic...This does not seem
to please everyone.

Cheers,

Edwin


> -----Original Message-----
> From: www-ws-arch-request@w3.org 
> [mailto:www-ws-arch-request@w3.org] On Behalf Of Paul Prescod
> Sent: Tuesday, August 06, 2002 9:01 PM
> 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 03:01:23 UTC