A REST challenge

I have several use cases that I do not believe fit into the REST style. 
I'd be interested in being enlightened:

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)

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

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)

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

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.


Currently, our best thoughts are that you need two web service centers; 
one belonging to S and one belonging to C. 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. 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.

Received on Tuesday, 16 July 2002 13:56:54 UTC