- From: Furniss, Peter <Peter.Furniss@choreology.com>
- Date: Mon, 17 Mar 2003 00:45:18 -0000
- To: "Ricky Ho" <riho@cisco.com>, <public-ws-chor@w3.org>
- Message-ID: <221369570DEDF346AE42821041345E890E82A9@exchange1.corp.choreology.com>
I agree with the view that concentrating on the bilateral case will be helpful. One test against the utility of "general" choreography is to consider the case where some of the communication is not web-services (effectively, not usefully represented in wsdl). Take the use case Ricky started with , of buyer - seller -shipper. If the seller-shipper communcations were by phone/fax, or legacy edifact, the buyer-seller and buyer-shipper conversations could well be exactly the same. So the Choreography description as known and used by the buyer need not (and indeed should not) be dependent on how the other two talk to each other. Even the linkage between the conversations involving a single party is rather limited. Much of it is kind of "typed reference" to another service - if the buyer tells the seller the address of the buyers ws that will be used by the shipper, then, if we have good bilateral choreography descriptions, that passed address (uri) might be typed by the appropriate description. And there is likely some data field passed as well, so the buyer knows which incoming shipment corresponds to which order. But again, that's fairly weak linkage. one further comment inline -----Original Message----- From: Ricky Ho [mailto:riho@cisco.com] Sent: 16 March 2003 08:20 To: Burdett, David; public-ws-chor@w3.org Subject: General Choreography and Bi-lateral Choreography David, I agree with everything you say. However, I want to elaborate my view on multi-party choreography. Most real life B2B scenario are multi-party interaction. But "multi-party interaction" is NOT equivalent to "multi-party choreography". For example, a company (or "domain of control") can have an orchestration that span multiple "bi-lateral" choreographies. In other words, "multi-party interaction" can be realized by multiple "bi-lateral" choreographies linked together by orchestration. The only thing lost is the sequence dependencies between message exchanges within choreographies is NOT captured externally. I honestly don't think bi-lateral choreography is sufficient to capture arbitrary public protocol sequence. For example, the well-known 2-phase commit protocol cannot be specified using bi-lateral choreography. So I agree with you that in a generic sense "choreography" should NOT be restricted to 2 parties. prf: on the 2-phase commit comment: I'm not sure if you mean *bi-lateral" isn't sufficient, or "choreography" isn't sufficient. As I said before, I think treating 2-pc as an example "application protocol" - i.e. the subject for a choreography description - can be very instructive. 2-pc can certainly be defined, precisely and fully, involving only two parties. This was done in the OSI Commitment, Concurrency Recovery (CCR) spec [ in fact, because standards politics meant it wasn't allowed to have normative multi-party text, but also was required to have normative semantic definition], and is also (I hope) complete in the BTP specification of the "outcome" protocol (the superior:inferior bit). There are implications for what is going on with other parts of the transaction tree, but the fundamental protocol is in fact two-party. (my diagram with the 3 dumbells and the box, on about my 4th slide was meant to show this, but I fear may not have explained it well] (I mention CCR and BTP because I know them - there may be other specs of similar nature) What you do need, beyond the simple message exchange rules, are statements of the implied semantics of the messages. This is most certainly part of the contract definition between the parties, and we strongly believe any useful choreography specification needs to have ways of stating the contractual implications (at least the software-contractual implications) of the messages. Peter ------------------------------------------ Peter Furniss Chief Scientist, Choreology Ltd Cohesions 1.0 (TM) Business transaction management software for application coordination web: http://www.choreology.com <http://www.choreology.com/> email: peter.furniss@choreology.com phone: +44 20 7670 1679 direct: +44 20 7670 1783 mobile: +44 7951 536168 13 Austin Friars, London EC2N 2JX
Received on Sunday, 16 March 2003 19:45:29 UTC