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

Another thing we should consider is that timeout management can work WITHOUT
reliable messaging. The use case is where you want to send a message to
someone with the instructions that "if you don't get this message by the
time specified, then please ignore it" but you don't care either if the
message is actually delivered. You could imagine this being expressed as a
SOAP Feature/Module.

Does this mean we would want one definition of timeout semantics for
Reliable Messaging and another one for when we are not doing Reliable
Messaging?

David

-----Original Message-----
From: Dave Hollander [mailto:dmh@contivo.com]
Sent: Thursday, December 05, 2002 8:59 AM
To: www-ws-arch@w3.org
Subject: RM Roles: RE: "Reliable" web services for Next Big Thing?



Here are a few from Edwin's email. Do we know the real
detail of these roles?

* encapsulating disconnected interactions 
* retries 
* exception 
* timeout management 

DaveH
-----Original Message-----
From: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Thursday, December 05, 2002 9:54 AM
To: 'Mathews, Walden'; 'Champion, Mike'; www-ws-arch@w3.org
Subject: RE: "Reliable" web services for Next Big Thing?



+1. Well said.

We have gone through the same mistakes and learning curve. The
infrastructure that certainly help by encapsulating disconnected
interactions and retries but exception and timeout management has to be
replicated/done at the application level for the reasons highlited by
Walden. Please note that this is true even in the case where you use
SOAP over JMS. We run into this problem in every customer deployment.

Edwin

> The idea that reliability in the infrastructure doesn't scale 
> up well is not peculiar to RESTifarians.  I came gradually to 
> that conclusion over several years working with distributed 
> market data, long before I knew anything about Web or REST.  
> A couple of
> examples:
> 
>     - Our workstation product always had built-in retry protocol
>       at the application level, no matter what substrate it was
>       communicating over, and it's plainly obvious that even if it
>       uses TCP/IP, the eventual loss of connection places the
>       burden of being a good "user agent" back on the application
>       layer in the hypothetical stack.  No way out of that if
>       you want to be nice to your customer.
> 
>     - I made the design mistake of a lifetime when managing
>       ticker plant development.  We needed to arbitrate between
>       redundant feeds, and chose to do it in the infrastructure
>       instead of the application layer.  Woe is me.  We ended up
>       implementing a sliding window protocol, introducing
>       unavoidable latency and still falling short of the full
>       requirement, all because we were focused on a "reliable
>       stream" instead of a "recoverable repository".  Hindsight
>       is 20/20.  Just sticking records in a database and filling
>       the gaps out of band would have been both easier and a 
>       better functioning solution.
> 
> This has little to do with REST, according to my experience, 
> so it might be helpful in a political way to decouple.

Received on Thursday, 5 December 2002 15:47:49 UTC