- From: Furniss, Peter <Peter.Furniss@choreology.com>
- Date: Thu, 25 Nov 2004 09:58:37 -0000
- To: "Steve Ross-Talbot" <steve@enigmatec.net>, "WS-Choreography List" <public-ws-chor@w3.org>
- Message-ID: <221369570DEDF346AE42821041345E897D3CB3@imap.choreology.com>
I'm not sure if the pattern of deliberately quoting the orginal PO number on the subsequent messages is covered by one of the suggested solutions. Sort of analoguous to putting "Your reference: ...." on a business letter. There's also the possibility of the distributor-assigned identifier being passed back via the supplier to the buyer on an acknowledgement - which would be like telling the customer the airwaybill number of the shipment. As Perl enthusiasts say, TIMTOWTDI (there's more than one way to do it) Expressing it as soap-ish practicalities, a) the buyer could set up a different url for the returning delivery notices for each purchase, which is passed round the loop b) the buyer could use ws-address/md type additional fields to have a discriminated destination. again passed round the loop c) the parties could use a common header (ws-context style) that it was agreed would be passed everywhere d) the buyer's message could have specific id field that the seller and distributor knew must be copied on, identified as the buyers id e) the seller gets back to the buyer with an id that will be on the distributor->buyer message. Forcing CDL-based protocol design to use a particular pattern doesn't seem right. The question then is whether CDL makes all ways of doing it look the same, which I think comes down to just how much of what kind of information in the concrete is consdiered as covered by the channel variable. If one allows the concrete binding for a channel to include assigning values in the messages themselves, and also allows it refer to any sort of address, then all of a) to d) could be represented by channel passing. (So could e), but the channel is passed the other way round). Having channel id's that mapped to anything from the tcp port number to context-id in a header to //Buyer/POreference would seem to be similar to where bpel correlation sets are heading on their issue 96 (engine-managed correlation sets = http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue96) . Correlation sets are different in that they are usually concerned with tieing together messages between the same parties, but the same mechanisms apply. Of course, saying "it's all in the binding" makes CDL more powerful (one way to represent a lot of things that are similar in abstract) but defers the practical utility. Peter Choreology Anti virus scan completed
Received on Thursday, 25 November 2004 09:59:21 UTC