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

I can't help myself... someone stop me before I shoot again...

Mark... please remind me how an autonomous (e.g. no human intervention) 
agent gains 
understanding and capacity to turn off your lightbulb or empty your trout 
pond of floaters without
being a specialized client with all sorts of built-in knowledge?

How is it any different to have intimate knowledge and understanding about 
how/what manipulation of 
state can result in a desired outcome is any different than having 
understanding and built-in knowledge 
of what messages to send to some endpoint? 

I'm not actually expecting a response because I already know the answer. 

There is none.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-ws-arch-request@w3.org wrote on 02/19/2003 10:22:11 AM:

> 
> 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
>