W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

RE: Use Cases & Requirements

From: Burdett, David <david.burdett@commerceone.com>
Date: Tue, 20 May 2003 10:08:04 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1AFB@C1plenaexm07.commerceone.com>
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

-----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 -

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.

Received on Tuesday, 20 May 2003 13:08:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:05 UTC