Re: Choreography and REST

At 03:50 PM 8/9/2002 -0400, Mark Baker wrote:

>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.
On the face of it, this flies in the face of 40 years of programming 
evolution.
Reuse, factoring and composition are based on notions that we can reuse
chunks of code that perform identical tasks, and that we should actively
strive to separate unrelated issues. (e.g. message format/content and state
of conversation.)

This issue become especially cogent in negotiation and flexible choreography
situations. If two or more web services are engaging in a classic negotiation
pattern where they iteratively revise their negotiation stances, I may 
expect to
see sequences where tens, or even hundreds of identical messages are exchanged,
differing only in the increasingly long history that led the services to 
their current
interaction. Likewise, if a pair of services, at some point in relationship 
decide they need
to undertake to follow a mutually understood choreography, I'm somewhat at 
a loss
to see how to approach this.

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


I'll politely observe this is a gross simplification of a rather complex 
problem.


>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.
One way to look at Roy's thesis is to look at it for what it is: A very
coherent and systematic analysis of the constraints which underlie
the successful model of the web as a substrate for hypermedia like
behavior. In particular, it provides a set of constraints, which if
you follow, will ensure that you produce a system with similar
properties. Given the success of the web, being informed by
an analysis of the properties of its success is sensible.

However, there's a key missing step. A skipped precondition, if you
will. Before you can conclude that the REST constraints will
produce a desirable system, you need to determine whether the
properties from which the REST constraints were derived fully
match the properties of the system you need. The further one
diverges from the system that informs the REST model,
the harder it is to make the induction that following the REST
constraints will, without additional analysis, yield a desirable result.
You may well produce a system with the properties that REST
ensures, but that may not be a system that actually meets your
needs.

REST is a powerful tool for thinking about the properties of distributed
systems, but like all tools, it must be used in the proper context. It is
a poor craftsman who complains that his screwdriver makes a poor
hammer. Likewise, while Roy's work can be used to derive powerful
insights about the space in which the WSA will reside,  it is not some magic
all purpose construct. Being guided by the REST approach is sensible,
following it without detailed thought about the context one is working in
is not.

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

I'd suggest a complementary approach. When one finds that a
problem seems to be bending the REST constraints, go back and
try to understand which underlying property is causing the
problem. Roy does a very nice job of laying out the
relationship between the various constraints and the properties
which derive from them. If you can identify the cause of the
tension, one can then attempt a synthesis. Can I preserve
much of the core properties preserved by REST, while relaxing
one or more constraints in order to produce a system that has
many of the desirable properties ensured by REST, but not all.

Note that, in some sense, this is more work, but, at the same time,
you get more payoff. You should at least get a deeper understanding
of what properties of REST are in tension with your design, and you
may even get a model where you can retain many of the desirable
features of a REST informed system, while meeting your own set of
desirable properties more directly.

>Thanks.
>MB

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


- David



David W. Levine
IBM Thomas J. Watson Research Center
Autonomic Computing Tooling and Standards

Received on Saturday, 10 August 2002 01:24:50 UTC