Re: Choreography and REST

Christopher B Ferris wrote:
> 
> 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.

No, my analysis does take this into account. It says that when the order
of exchange of things is important than it can be managed *in the data*.

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

In my model they would not exchange the very same set of messages. (each
message is of course constrained by an XML schema)

Business Process A:

1. Client: "Hello, I submit this purchase order for X" 
2. Server: "Let us both call this purchase order http://.../po_uri. Look
there to see where you should pay."
3. Client: "GET /po_URI"
4. Server: "Here is the original PO. To pay, submit credit card
information to /po_uri/payment. To cancel, submit a request to
/po_uri/cancel."
5. Client "PUT /po_uri/payment credit_card_info"
6. Server "Okay, now submit your address to
http://.../po_uri/shipping_address"

The schema for message 4 can *guarantee* that there will be a payment
URI and thus that it will be possible to pay after submitting the
purchase order. If the schema has no place for giving your address then
it is pretty clear that the package won't be shipped until after
payment.

Business process B would have a different set of schemas. They would
enforce the following order:

1. Client: "Hello, I submit this purchase order for X" 
2. Server: "Let us both call this purchase order http://.../po_uri. Look
there to see where you should submit your address and confirmation of
receipt."
3. Client: "GET /po_URI"
4. Server: "Here is the original PO. To get the package, please submit
your address here: /po_uri/shipping_address. Once you've got it, please
submit your confirmation of inspection and credit card number to
/po_uri/confirm or rejection to /po_uri/reject."
5. Client: "PUT /po_uri/shipping_address"
6. Server: "Will ship tomorrow!"
(later)
7. Client: "PUT /po_uri/confirm 'The products are satisfactory. Credit
card number attached.'"
8. Server: "Thank you. Come again."

Obviously there are all kinds of business issues we could argue about as
in when is the right time to collect particular bits of information.
Nevertheless I hope that the model is clear. The XML schemas for the
messages can constrain the ordering of the interactions in a statically
declarable way.

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

Schemas, RDF, DAML(-S) and/or prose text. C, Java and VB programmers do
not "fumble around in the dark" trying to understand how the close
functions and read functions interact. They read the documentation. We
happen to have much more powerful tools available through Schemas, RDF,
DAML(-S) than did the definers of the C API, ... but even if we did not
there would be no crisis of darkness-groping.

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

That's right. That's why I've spent the last year of my life thinking
about how to do it. It is a difficult challenge to adapt REST but no
more difficult than inventing a totally new architecture.

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

This is absolutely true. Nevertheless, nobody has yet presented a
problem solvable by SOAP/WSDL that does not lend itself to a REST
solution (which may or may not use SOAP and WSDL, but certainly would
not use the parts of those specifications that are at odds with REST).
-- 
XML, Web Services Architecture, REST Architectural Style
Consulting, training, programming: http://www.constantrevolution.com
Come discuss XML and REST web services at the Extreme Markup Conference

Received on Saturday, 10 August 2002 05:26:14 UTC