RE: Routing and choreography

> -----Original Message-----
> From: Mark Baker [mailto:[email protected]]
> Sent: Wednesday, August 28, 2002 11:30 PM
> To: Champion, Mike
> Cc: [email protected]
> Subject: Re: Routing and choreography
> 

> Now let's say you want to
> modify this flow, perhaps to decouple the immediate invoicing from the
> order submission by introducing a "confirmation receipt" 
> step.  This can
> obviously be done by modifying the resource which declared the invoice
> transition such that the new transition is to the receipt.  
> But another
> way to do it is to use a specialized intermediary (a reverse proxy in
> this case, as WS-Referral or HTTP's 305 response code enables) that
> recognizes the output from the order processor, and basically 
> intercepts
> the invoice link and replaces it with a receipt link - and of course,
> also updates the receipt to point to the invoice.

OK, that's a RESTful mechanism for implementing the kinds of things that
WSCI and BPEL4WS talk about, as best I understand them.  But the point of
"web services choreography" broadly defined is to define a non-procedural
language for describing these links and message flows, not to prescribe a
mechanism for implementing them.   Ideally a standard choreography language
would describe the flows and let one modify them without ripping up a bunch
of software; someone like you could implement them RESTfully, VS.NET users
could implement them RPC-ishly [RP-sheep-ishly ? maybe you can use that as a
comeback when we call you RESTifarians <grin>], and may the best approach
win.