Re: A REST challenge

On Tuesday, July 16, 2002, at 11:30  AM, Mark Baker wrote:

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

As you might have noticed, this is what happens today. When you place an 
order on the web, only the initial transaction is handled via the 
browser, thereafter its all emails.

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

Think a little about it. You are building a single system that is 
simultaneously maintaining a server presence and acting as a user agent. 
The two facets need to be coordinated; if you want the left hand to know 
what the right hand is doing.

This was the motivation in suggesting that an identity was necessary in 
maintaining a permanent presence in P2P style interactions.

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

Later

>
> 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:31:53 UTC