W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

RE: Dead trout

From: bhaugen <linkage@interaccess.com>
Date: Wed, 19 Feb 2003 13:58:11 -0600
To: www-ws-arch@w3.org
Message-id: <003c01c2d851$3d00ac00$b8eafea9@PC1>

David Burdett wrote:
> My focus is on how to make "web services" work in an B2B or EAI
> 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
> 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
> 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
> are really requesting an action that will result in a process being
> that will return a set of information that reflects the results of
> 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:

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:03 UTC