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:18:30 UTC