Re: Choreography and REST

Chris,

On Fri, Aug 09, 2002 at 11:15:14AM -0400, Christopher B Ferris wrote:
> Consider two businesses with different business models. One requires
> that payment be made before shipping, and the other requires that the
> items shipped be received, inspected, and acknowledged before it will
> consider
> payment.

Good example.

> They may start out with the same state (new PO), exchange the very same set
> of
> messages, but the process "choreography" would be vastly different.

But in the REST model, the messages would not be the same if the
choreography were different.  The way in which the resources are
navigated (aka the way in which state changes are done) would be
different, resulting in different messages, even if the resulting state
of the system was identical in each case.

> The two businesses need to understand up front whether they can agree on
> the
> business process model that will be used. Quite often, there's a legal
> contract
> (TPA) that accompanies this agreement, signed in blood by both parties,
> notarized, enforacble in a court of law, and whatnot.

Right.  In the REST model, either side could detect a change in the
process, if one was declared to be in use.

> There are more than technical considerations at play when engaging in
> e-business (once you start doing things slightly more interesting than
> getStockQuote). Clearly, e-business is one of the uses that many have in
> mind
> for Web services.
> 
> Then there's the practical issue of having no well defined way of
> communicating
> some of the constraints that Paul simply dismisses with so much hand waving
> (e.g. calling file.close() before file.read() and dismissing that faux pas
> by saying
> the file.read() just throws an exception). Writing software should not have
> to be
> a trial and error process of feeling around in the dark. How does one
> communicate
> externally that there's a constraint on a given class of resource such that
> the read() operation
> can only be performed when the resource is in the 'open' state such that
> the person
> writing the software that interacts with the resource can internalize this
> constraint
> in her code?

If we RESTify this example, we could have a resource that represents a
file.  One way in which the constraint on the open state could be
reflected, is that the programmer would not discover the file URI until
after it was in the open state, as determined by the container resource
which creates file resources.  So once it was discovered, they could
always invoke GET.

To handle the closed state, a GET could return 410 (Gone).  Obviously
you can't hide it once you've released it. 8-)

> Quoting Roy's thesis:
> 
>       "Unlike the distributed object style [31], where all data is
> encapsulated within and hidden
>       by the processing components, the nature and state of an
> architecture's data elements is a
>       key aspect of REST. The rationale for this design can be seen in the
> nature of distributed
>       hypermedia. When a link is selected, information needs to be moved
> from the location where
>       it is stored to the location where it will be used by, in most cases,
> a human reader. This is
>       unlike many other distributed processing paradigms [6, 50], where it
> is possible, and usually
>       more efficient, to move the "processing agent" (e.g., mobile code,
> stored procedure, search
>       expression, etc.) to the data rather than move the data to the
> processor."
> 
> My point is that REST is an architectural style for distributed hypermedia,
> that is typically "processed"
> by a human. The user agent concerns itself only with rendering the
> representation retrieved and
> performing operations (GET, POST, etc. on selected URIs) at the behest of
> the human sitting in
> front of the browser. A human can reason about the information presented
> and take action
> based on that reasoning with no a priori knowledge of the resource
> represented (usually:).
> Writing a software agent to replace the human in the REST equation is a
> very difficult challenge
> indeed.

Not really.  Anybody who's written any RDF code has already done this.

Roy was simply observing what is currently true today; humans *are* the
principle target of most hypermedia documents out there.  But even
today, machines such as Googlebot extract what information they can from
data formats intended primarily for human consumption, without any help
from a human.  Even HTML's <address> tag permits an HTML-knowledgeable
piece of software to know that it's dealing with an address.  This can
be generalized, which is what RDF does.

> Thus, while I firmly believe that there is MUCH that we can learn from
> REST, and that we should
> incorporate into the WSA, I am not convinced that it is a panacea. There
> are many facets of
> Web services that can, and probably SHOULD, be modeled as distributed
> hypermedia so that
> the advantages of the REST architectural style can be fully leveraged.
> However, as Roy takes
> pains to call out in his thesis, it is not an architectural style that is
> necessarily well suited to all problem
> domains.

That's the problem with his honesty, it so easily allows those that
haven't studied it closely to wave it aside as irrelevant to their
particular problem.

I'd encourage you to take some time to consider exactly how you might
form a solution to this (or any other) problem within the constraints of
REST.  If, after you've done that, you've decided it isn't suitable for
your needs, then by all means don't use it.

Thanks.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Friday, 9 August 2002 15:50:03 UTC