RE: Requirements: Decision Points Requirement Proposals

Dear Yaron, David and others,
 
Out of this debate I would like re-assurance that we are agreeing to
support the following two 'propositions' :
 
1)  The WS-Choreography language should be usable on its own, as well as
usable in unison with BPEL4WS.
 
Note :use alone and use with BPEL4WS are two separate goals.  Personally
I would be happy if we tried to support them both and I think it makes
sense to try to do so.
 
2)   The next state of a choreography can be determined by some value in
a field of an incoming message.
 
Please refer to the attached slide for a simple example.  Not that how
the supplier determines the accept or reject value for the result field
is hidden.  However, at the buyer side the next step in the Choreography
is determined by the value of this field.  It seems to me that
Choreographies will not be comprehensible (to humans - machines can be
made to accept anything!) with out this sort of facility.
 
Note:  This should be possible both when the WS-Choreography is used
alone, and when used together with BPEL4WS to expand on some (or all) of
the roles.  This is so that the WS-Choreography language can be used on
its own (at least initially) to design choreographies - and as a means
of agreeing a design amongst interested parties.
 
One potential solution to these requirements is to copy some of the
syntax and semantics from BPEL4WS into the WS-Choreography language, but
there may also be other approaches.
 
 
Best Regards     Tony
A M Fletcher
 
Cohesions 1.0 (TM)
 
Business transaction management software for application coordination
 
Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44 (0)
7801 948219
tony.fletcher@choreology.com     (Home: amfletcher@iee.org)

-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Burdett, David
Sent: 07 June 2003 06:31
To: Yaron Y. Goland; WS Chor Public
Subject: RE: Requirements: Decision Points Requirement Proposals



Yaron 

Several detailed comments (with alternative suggested wording) are
included inline below. I would also add another few requirements ...

"The WS-Chor choreography definition MUST provide mechanisms by which
new choreography definitions can be composed out of other choreography
definitions". The use case for this is that you might have a
choreography that defines how to place an order, you also might have
another choreography that defines how to send an invoice. If you then
want to define another choreography that defines how you place an order
that is followed by one to send an invoice, then a composition
capability would allow the original choreographies to be reused. Another
consideration on this is that there a many different functionally
equivalent ways of placing an order. Similarly there are several
functionally equivalent ways of sending an in invoice, so it would
really be useful to be able to compose a choreography that said
something like "Do one of n ways of placing an order, followed by doing
one of n ways of placing an invoice".

"The WS-Chor choreography definition MUST provide mechanisms by which
the execution of one choreography definition is dependent on the
execution of the instance of some other choreography definition". The
use case for this is where you want to execute a choreography that
determines the current state of processing of some earlier choreography.
The "query" choreography can only validly be executed if there is some
earlier instance of the a choreography that can be referenced.

The following couple of requirements are ones that have been discussed
much earlier on the list however I am not sure that we really want to do
them, at least not initially, but I do think they are worth discussing
...

"The WS Choreography specification MUST provide standardized, reusable
choreography definitions that allow one role to determine another roles
state of processing of a choreography instance, no matter what
choreography definition was being followed."

"The WS Choreography specification MUST provide standardized, reusable
choreography definitions that allow one role to request another role to
restart the processing of a "stalled" choreography instance, no matter
what choreography definition was being followed." This could simply be a
request to resend some earlier message that got lost.

The rationale for both of these is that querying the status of a
choreography and re-starting a choreography will be common requirements
for many (but not all) choreographies and therefore having a standard
way of doing these functions will make choreographies easier to design
and develop.

As stated earlier, more comments inline below. 

David 

-----Original Message----- 
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Wednesday, June 04, 2003 4:28 PM 
To: WS Chor Public 
Subject: Requirements: Decision Points Requirement Proposals 



I propose the following requirements be added to the requirements
document: 

The WS-Chor choreography description format MUST provide mechanisms to 
enable a choreography to specify that a process in a particular role
MUST 
send zero, one or more messages from a statically defined set of
messages in 
parallel, serial or any combination of the two. 
<DB> A couple of comments: 
1. I think a role that MUST send zero messages doesn't work as if the
role MUST send zero messages, then why is it in the choreography. 

2. Why do you use the term "description format" instead of the simpler
"definition' because, aren't the properties you seek a characteristic of
the definition rather than the format of the definition.

3. The first sentence is circular as it says ... "The WS-Chor
choreography description format MUST enable a choreography ..." without
specifying what a choreography is. 

4. I think you mean when you say a "statically defined set of messages"
that the actual messages definitions that can be sent are finite in
number and from a proscribed list. There has been a lot of discussion on
the idea of variability in the detailed message content which means that
limiting a choreography to specific message formats will inhibit
choreography reuse. Instead I thinkt that we should refer to "Message
Types" or "Message Families" rather than "messages".

5. This requirement is also very similar to the next so my alternative
is described below 
</DB> 

The WS-Chor choreography description format MUST be able to describe 
decision points where a process in a particular role MAY send zero, one
or 
more messages from a statically defined set of messages in parallel,
serial 
or any combination of the two. 
<DB>So how about the following requirement that combines the previous
two and takes into account the comments I made ...

"The WS-Chor choreography definition MUST provide mechanisms that define
the sequence in which one or more messages types are exchanged between
two or more roles either in parallel, serially or any combination of the
two, together with the conditions that cause those messages to be
sent."</DB>

The WS-Chor choreography description format MUST be able to describe who
is 
to receive a message by referencing their role. 
<DB>I would add the sender to this definition to give ... "The WS
Choreography definition MUST be able to describe who the sender of a
message is and who the receiver should be by referencing their role."
The rationale for this is that what you do with a message may well
depend on the role of the sender ... assuming that the same message can
be sent by different roles.</DB>

The WS-Chor choreography description format MUST make it possible to
specify 
a role's binding to an actual web service instance either statically,
when a 
web service using that choreography is deployed, or dynamically at run
time. 

The WS-Chor choreography description format MUST provide mechanisms to
allow 
messages to be sent to a particular member of a set of web services in
the 
same role. 
[Ed Note: What I'm very inelegantly trying to capture is the idea that
if 
you are running an auction service and you just found out that one of
the 
bidders isn't qualified to bid you need a way to say things like "I'm
now 
going to send out an unsolicited 'get lost you dead beat' message to one
web 
service that is in the role of bidder." This could then trigger a whole
set 
of messages back and forth between the auction service and the dead beat

bidder, the choreography needs some way to capture the fact that you are

still talking to the same member of the role group.] 
<DB>This example introduces the idea of a role group, which I don't
*think* we need. If we take this use case, then you can actually
consider it as an internal "business process" problem, for example:

The auctioneer has a business process that consists of a set of separate
individual identical choreographies between the auctioneer and the
bidder where each choreography instance would take the following form
...

AUCTIONEER       BIDDER 
Bid Invite -------> 
Either ... 
Get Lost ---------> 
... or ... 
<--------------- Bid 
... etc ... 
The fact that there are several bidders involved is something that only
the auctioneer needs to be concerned of. 

This means that this is really a business process (e.g. BPEL ) problem
rather than a choreography problem especially as the auctioneer is in
complete control of what goes on. For example, the auctioneer could
treat all the interactions as being part of one choreography by using
the same identifier for the correlation of all the messages irrespective
of the bidder. 

Now there may be a use case where you really do the need the
variability, but I can't think of one. On the other hand, if we can
avoid this variability, then it will simplify the specification we need
to write significantly.

</DB> 

The WS-Chor choreography description format MUST NOT require that the
logic 
used by a sender in a decision point to decide how to act be exposed in
the 
choreography. 
<DB>There's a corollary, I think, that says something like ... "The
WS-Chor choreography definition MUST enable the results of decisions
made by one role that affect the behavior of another role to be
communicated to the other role." This is really about the transmission
of relevant state information between roles.</DB>

The WS-Chor choreography description format MUST enable the annotation
of 
all actions with human readable descriptions. 
<DB>I agree but would go further and replace the last phrase with "...
with clear semantic definitions." Something might be human readable but
that does not mean it explains the purpose well.</DB>

The WS-Chor choreography description format MUST provide an abstract 
mechanism where by the logic used to make a decision at a decision point
can 
be expressed through reference to a WSBPEL abstract or executable
process or 
similar machine readable logic. 
<DB>I don't have an alternative definition, but this pre-supposes a
binding to WSBPEL that we might (or might not) want to make unless and
until we collectively (i.e. WSBPEL and WSCHOR) work out what the goals
and relationships of each activity will be.</DB>

The WS-Chor choreography description format base specification MUST NOT 
specify bindings for the abstract mechanism used to reference machine 
readable logic, rather extension specifications on top of the base 
specification MUST be used. 
<DB>As a general comment, we could do with developing definitions of
various terms, e.g. "decision point", "base specification" which
although quite intuitive, could be open to miss-interpretation.</DB>

I would appreciate it if objections to these requirements were stated in
the 
form of alternate proposals. It's easy to say why something is wrong,
it's a 
lot harder to spend the time to specify what is right. 

                Yaron