RE: Requirements: Decision Points Requirement Proposals

JJ
 
The choreography instance id problem is one that was also discussed by
ebXML. The issues, as you say were:
1. The need to have an identifier shared between the roles (ebXML called
them parties) in the choreography so that, when a message arrives, or is
sent, the correct context could be set by the sender and identified by the
recipient.
2. The problem that the an identifier created by the sender may not serve as
a useful identifier at the recipient as their system separately controls the
identifier used by correlation.
 
I recall that there were several different approaches to solving this
considered, including:
1. Each role setting their own choreography instance id
2. The sender of the first message setting the choreography instance id
3. Concatenating a sender and receivers choreography instance ids to give a
unique, shared id.
 
However, the ended up choosing the second and recognizing that it would mean
that, for some implementations, mapping tables between the "public" and
private id's might be needed.
 
David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Monday, June 09, 2003 11:28 AM
To: 'Burdett, David'; 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor
Public'
Subject: RE: Requirements: Decision Points Requirement Proposals



Typically, what you will have is an architecture where the "choreography
interface", i.e. the component in charge of sending and receiving messages
is interacting with a process engine (e.g. possibly based on BPEL) which
would dispatch these messages to the correct application. Typically, the
process engine will deal with this correlation as you probably don't want to
propagate the choreography 'IDs" into the applications and force the
application to understand how a choreography works and what is a
choreography instance.  What I think we agree on, is that we don't want to
expose correlation to the level of choreography definition since it does not
need to be part of the "shared knowledge". It can be actually quite
confusing in a MCP as each party could have its way to "correlate" a message
to a choreography instance.

 

JJ- 

 

 

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com] 
Sent: Montag, 9. Juni 2003 14:08
To: 'Jean-Jacques Dubray'; Burdett, David; 'Yaron Y. Goland'; 'WS Chor
Public'
Subject: RE: Requirements: Decision Points Requirement Proposals

 

JJ

 

I agree with you that correlation is not a topic we have discussed. I, like
you prefer a choreography instance id as it simplifies the choreography
definition and is indpendent of the detail of the message content. However
it does mean that there can then be inconsistencies between the choreography
instance id and some id inside the message content e.g. an order no.

 

David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Monday, June 09, 2003 2:22 AM
To: 'Burdett, David'; 'Yaron Y. Goland'; 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals

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

[JJ] I would treat the "query/admin" problem as an independent problem like
you seem to suggest in the following points. However, I can see the
advantages of your proposal above in Multi-party-collaborations. This will
save us from complex correlation schemes.

This is another area of requirements that I think we did not touch:
correlation. There are two possible approaches: an explicit correlation
mechanism based on the document contents, and a choreography protocol which
envelope contains a choreography instance ID. I personally favor the
choreography protocol as it works in all cases and simplifies the
choreography definition.  

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