Friday, November 21, 2003

Choreography - Take 1 Imagine two BPEL processes working hand in hand: Buyer BPEL process 1: a. The buyer BPEL <receive>s PO over a Web service from a client b. The buyer BPEL <invoke>s a supplier BPEL Web service to fulfill the PO c. Later the buyer BPEL <receive>s an invoice from the supplier d. Finally the buyer BPEL sends an invoice back to the client Supplier BPEL process 2 a. The supplier BPEL <receive>'s a PO from the seller b. The supplier creates an invoice c.  The supplier <invoke>'s the seller with the invoice Pretty simple scenario ... right?  Modelling each BPEL independently is pretty straightforward ... you as a buyer know exactly the steps you would like to execute - receive PO from customer, invoke supplier, receive invoice, invoke customer.  As the supplier - receive PO from buyer, create invoice, invoke buyer with invoice. Modelling them together and making sure that for every invoke you have a matching receive and vice versa, is another story.  If it is one organization you can coordinate.  But if it really is two separate organizations, how do you document for both parties what the expected behaviour is going to be ... "Will you send an acknowledgement once I send you a PO?"  "What should be sent if the supplier doesn't have inventory - an error or partial fulfillment?"  "Should I block until I have satisfactory inventory?" and so on. This problem is often called choreography - rather than  thinking about a business process from the perspective of a single participant - often called orchestration - modelling the conversation that happens across multiple participants independent of perspective, for example multiple independent business processes. Another way to think about choreography is that it documents the observable set of messages passed between participants in a business conversation (e.g supply chain) but each participant might have long running private business processes independent of the public exchange. Once you know what the exchange of public messages is going to be, you have a roadmap of what the you can do to process those messages - i.e. you have a meta or framework of your  BPEL process which you can then flesh out with all the error checking and internal manipulation you need to do to handle the message exchange. comment [] 11:56:08 PM