RE: A REST challenge

Mark,

Conceptually speaking, in this example, what is the "resource" whose URI
is being sent from C to S and whose state is changed each time S calls
back C?

Edwin

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Mark Baker
Sent: Tuesday, July 16, 2002 10:30 AM
To: Francis McCabe
Cc: www-ws-arch@w3.org
Subject: Re: A REST challenge



On Tue, Jul 16, 2002 at 10:56:52AM -0700, Francis McCabe wrote:
> Use case 1 (The conventional business cycle)
> 
> A supplier S and a customer C:
> 
> C places an order with S (which may involve many too-ing and fro-ing,
> but let us stipulate for the moment that it can be modeled as a series

> of invocations of web services)

An order document is transferred over POST, which includes a URI to
which further correspondance should be sent.

> Sometime later, at a time determined by S, S sends a delivery note to 
> C
> noting (sic) that the product has been shipped

S POSTs delivery note to aforementioned URI, if it's an HTTP URI. Could
use SMTP to transfer the order if the URI is mailto:.  etc.. But
logically, either way it's a POST.

> Sometime later still, also at a time determined by S, S sends an
> invoice. (BTW its not reasonable to assume that C has any motivation
to 
> poll S for the invoice)

S POSTs invoice to URI

> Later still, S sends an aged balance statement. Again, C has no
> motivation to poll S for this.

Ditto.

> Eventually, C sends a remittance advice note to S. Again, S is too 
> busy
> to poll C for it, and C being a large corporation and S being a  mom'n

> pop shop would not look too kindly on all this polling.

No problem-o.

> Currently, our best thoughts are that you need two web service 
> centers;
> one belonging to S and one belonging to C.

Like a web server, sure.

> In addition you need two user
> agents.  However, you now have a massive coordination and identity 
> problem since, at the level of business relationships, the web 
> service/user agent pairs are implementation artifacts that obscure the

> fact that there is a single entity behind each.

How so?  One could certainly implement it to give themselves these
problems, but the architecture doesn't require it.

> This architecture also
> obscures the interrupt-driven style of the use case -- what method on
a 
> customer server is being invoked when a supplier delivers its age 
> balanced statement?

POST.

> The other use case is even more entertaining, which I'll leave for
> another challenge.

Hit me! 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 Tuesday, 16 July 2002 14:41:54 UTC