W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

Re: A REST challenge

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Tue, 16 Jul 2002 11:31:48 -0700
Cc: www-ws-arch@w3.org
To: Mark Baker <distobj@acm.org>
Message-Id: <4A11FA30-98EA-11D6-A3D4-000393A3327C@fla.fujitsu.com>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC