- From: Burdett, David <david.burdett@commerceone.com>
- Date: Tue, 20 May 2003 10:08:04 -0700
- To: "'Yaron Y. Goland'" <ygoland@bea.com>, WS Chor Public <public-ws-chor@w3.org>
Here's my $0.02c on Yaron's paper which I find expresses thoughts generally similar to my own. 1. Introduction: CDl is a set of rules that can be used to validate the correct execution of a choreography instance raising errors if the rules are not followed 2. Requirements: a) a CDl should also be extensible, for example there are multiple different ways of placing an order where each one is gradually more complex than an earlier version [1] b) Components such as reliability and security should be in a separate layer otherwise the choreography is not reusable 3.2 Use Case: Equal Partners a) I can envisage a situation where the same business process could sometimes be implemented reliably and sometimes not. This suggests that identification of reliability to use with a choreography should be contained in a binding of the the base CDl to an implementation. Other things that need to be bound in the same way include: message content, message packaging, use of security and things like business timeouts. 4.5 Segmentation a) If you are hiding part of a choreography, then really the choreography is not a public choreography but is really a private choreography. In this case isn't the CDl really more of a template CPl as the complete definition is under the control of just one participant. b) Similarly if you have segmentation, then it can tend to inhibit reuse as the part of the choreography that is being segmented out could actually be a common choreography that could have been reused elsewhere c) There is also a difference between C, for example, knowing the complete choreography without knowing which organization is B. This would probably be OK from the privacy of information perspective. In fact there can often be multiple different organizations who can be a "B". d) Bottom line, I would view each of the interactions described as probably separate choreographies with their own choreography definitions that have then been assembled for use in a business process owned by A defined using a CPl. 4.7 Annotations a) I agree that signal messages could be useful. However, this really is treading into application territory so needs to be treated with care and it would be wise to leave it to later. So, how about this as the layers that are required: 1. Template Choroegraphy Definition. This is written in a CDl and is something that an organization like RosettaNet could develop, but is not specific on detailed message content (as it varies), or the service instances that are used 2. (Actual) Choreography Definition. This is optionally based (by reference) on a Template Choreography Definition but includes the specific message formats, services, etc that are used. An open question is whether this is single document or, alternatively a Template Choreography Definition with a binding to an instance 3. Segmented Choreography Definition This is a single roles view of a Template (?) Choreography Definition and could be used as the starting point for a business process to support the choreography -----Original Message----- From: Yaron Y. Goland [mailto:ygoland@bea.com] Sent: Friday, May 16, 2003 6:20 PM To: WS Chor Public Subject: Use Cases & Requirements I would like to submit the following use cases and requirements for consideration by the working group - http://lists.w3.org/Archives/Public/www-archive/2003May/att-0029/chor.htm. Besides providing what I personally believe to be critical requirements for the success of the working group I also think they help to outline what I believe to be the fundamental differences between what I think the W3C Choreography WG should be doing and what the BPEL OASIS TC is doing. Of course all opinions on such differences are mine and mine alone, your mileage may vary, objects in mirror are closer than they appear. Yaron
Received on Tuesday, 20 May 2003 13:08:16 UTC