Re: Setting the state of the trout pond vs invoking the CleanTroutPon d method (was RE: Dead trout)

On Wed, Feb 19, 2003 at 09:28:13AM -0500, Champion, Mike wrote:
> > This is so meta. 8-)
> 
> I don't think so.

I was just referring to the fact that we're talking about a trout pond.
8-)

>  This is the essence of the SOA "vs" REST debate that has
> gone on for more that a year.

I've been at it for about five years!

> > How about this;
> > 
> > DELETE http://example.org/pond/trout/?status=dead
> 
> Uhh, there's an impedance mismatch between the physical trout pond and the
> Web representation of it.  That DELETE request will surely time out in the
> time it takes Joe to scoop out the dead fish!  In this particular case, it
> probably DOES make more sense to model the interaction between the "Trout
> Pond Manager Client" and the physical trout pond via requests to perform an
> action ("methods") rather than exchanging state representations.  

DELETE just means "remove all representations".  It's not an attempt to
actually delete the resource, which could be something physical as you
say.  I know, poor name.  "FLUSH" or "CLEAR" would have been better.

> > But before anybody jumps on that with "Aha!  Web services are 
> > for those cases!", I'd point out that it's very uncommon to 
> > find such an action in practice.
> 
> I beg to differ.  You've been on the Web too long, son :-)

Indeed.  8-) It's all that experience that lead me to this conclusion.

> Bottom line: at least SOME (a large class of interesting examples!) Web
> services use cases involve "services" that are performed out in the real
> world.  It is probably possible to model all these RESTfully, e.g. instead
> of DELETEing the virtual dead fish PUT-ing the state of the trout pond to
> "CleanupInProgress" and Joe will set it to  "Clean" when he's done.  (Not
> sure whether we need a God to set it to "Unclean" when the next fish dies or
> what).  But I've seen no plausible argument that "CleanTroutPond(Joe)" is
> not a good way to model this class of problems.

It's that a priori issue again; that the REST approach works in the
context of an already deployed coordination language, while typical Web
services construct per-service coordination languages.  Coordination
languages are *extremely* expensive to deploy (and extremely difficult
to design, for that matter).  That's why, during a typical day, I use
perhaps three of them (HTTP, SMTP, POP).  Web services suggests that
we'll have a new one for each service I might want to use.

For example, here's a coordination language for coordinating the sending
and receiving of faxes;

http://www.interfax.cc/webservice/dfs.asmx?WSDL

and here's one for doing public key operations;

http://ntg.webs.innerhost.com/RSAFunctions/RSAFuncs.asmx?WSDL

and here's one for sending and managing SMS messages;

http://www.abctext.com/webservices/SMS.asmx?WSDL

You get the idea ...

Anyhow, I've got a fair bit of empirical evidence backing me up on these
claims.  In all my time studying successful Internet scale systems, I've
yet to see one that wasn't built around a single, general coordination
language.  To suggest that there's no important difference in the
ability for coordination language based systems, and non-coordination
language based systems to be deployed on the Internet, flies in the face
of this evidence.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis