RE: Dead trout

David Burdett wrote:
> My focus is on how to make "web services" work in an B2B or EAI
environment
> where the semantics of what you are asking the recipient of a message
to do
> are not a simple request to change the state of an object. For
instance take
> the very simple idea of sending an order to a supplier and asking them
to
> send a response back. At the supplier end, this can involve:
> 1. Checking that buyer is known and has a good credit rating
> 2. Checking that the products ordered are in stock
> 3. Scheduling manufacturing or out-sourcing of out of stock items, or
> placing them on back order
> 4. Checking if delivery can be made when requested
> 5. Scheduling one or more deliveries
> 6. Providing a response back to the buyer with information that
totally
> depends on the outcome of the previous steps.

> I really don't think that a simple REST interface is ideal in these
> circumstances as you are not doing a PUT of the order to the supplier
you
> are really requesting an action that will result in a process being
executed
> that will return a set of information that reflects the results of
that
> process.

Let's think about what is actually happening here
in business semantic terms.

The most common business protocol for orders is Offer-Acceptance.
In that protocol a Purchase Order is an offer to buy.

A good reference is UNECE Recommendiation 31,
Electronic Commerce Agreement:
http://www.unece.org/cefact/rec/rec31/rec31_2000_00tr257.pdf

UNECE calls a PO an Instrument of Offer.
Could be a Web resource, PUT or POSTED.

The supplier is not obligated to accept the offer.
Whatever steps 1 thru 6 that the supplier takes
in preparation to respond is not necessarily any
of the buyer's business.

Then in UNECE terms, the supplier responds
with either an Instrument of Acceptance or Rejection.
Which could also be a Web resource.

If the supplier accepts, the trading partners have
formed a contract (let's call it an Order) which
could alsu be a Web resource.

So the whole Offer-Acceptance protocol could be
accomplished quite nicely in a REST architecture,
or also in an EDI-mailbox-style SOAP architecture.

-Bob Haugen

Received on Wednesday, 19 February 2003 14:59:05 UTC