- From: Christopher B Ferris <chrisfer@us.ibm.com>
- Date: Fri, 9 Aug 2002 11:15:14 -0400
- To: www-ws-arch@w3.org
Paul's analysis doesn't take into account the fact that there are real
business
issues to be considered w/r/t the order of things that need to be
understood
*and agreed upon*, a priori to beginning an exchange of messages.
There are some things that you just can't leave to chance.
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.
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.
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.
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?
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.
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.
Cheers,
Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624
Mark Baker
<distobj@acm.org> To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
Sent by: cc: www-ws-arch@w3.org
www-ws-arch-reque Subject: Choreography and REST
st@w3.org
08/09/2002 07:32
AM
For a REST perspective on choreography, Paul wrote this up recently.
IMO, it captures the essence of the problem perfectly;
http://www.ai.mit.edu/~gregs/ll1-discuss-archive-html/msg01848.html
When you move from an architecture with its own implicit state model
(REST has hypermedia as the engine of state change) to one without one
(the Web services architecture, as currently practiced - each object
has its own), you have these sorts of issues.
It's amazing how big an impact one little missing architectural
constraint can have. 8-)
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 11:18:25 UTC