RE: Requirements: Decision Points Requirement Proposals

Yaron, JJ,
 
Regardless of the maturity of the effort, if I understand the XPath
approach, this sounds like the choreography would be defined in terms of the
structure of the messages.  I think the choreography should be oblivious to
the structure of the messages, which might be XML or something else.  The
determination of what logical document is received can be delegated to the
application that will process it.
 
Fred

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Thursday, July 03, 2003 4:21 PM
To: Jean-Jacques Dubray; 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals


So given that this group is somewhere between 5 to 7 months old (depending
on how you want to count) and we can't even agree on a mission statement
might I suggest that our chances of success would be maximized if we were to
minimize our scope. So let us say that for V1 we will not include an XPATH
and we can re-evaluate providing an extension in V2?

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Wednesday, July 02, 2003 3:43 PM
To: 'Yaron Y. Goland'; 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals



This is exactly how ebXML works. The only thing we added, is that we can
hide an XPath behind a "logical" document, i.e. in BPSS a document = a
physical document + an XPath predicate. If the XPath predicate is null it
works as you say, if it has some value, then it is evaluated to see if this
"logical document" was received. 

 

JJ- 

 

 

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Yaron Y. Goland
Sent: Mittwoch, 2. Juli 2003 13:36
To: 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals

 

I'm proposing something significantly simpler - state transitions should be
triggered by message types. So if you send operation foo from port nippy of
service bar to participant Alpha then the mere fact of receiving
foo/nippy/bar specifies a state transition. E.g.

 

 

Beta (exclusive split)---foo/nippy/bar---->Alpha---baz/back/rack---> Beta

                |

 
--------------furby/nippy/bar-->Alpha-(parallel)---yacky/back/rack--->Beta

                                                                           |

 
----------ippy/back/rack---->Gamma

 

In this choreography the only necessary information is the operation, port
and service. Identification of this triple is provided implicitly by the
WSDL so the choreography doesn't need to use XPATHs.

 

        Yaron

-----Original Message-----
From: Cummins, Fred A [mailto:fred.cummins@eds.com]
Sent: Tuesday, July 01, 2003 2:46 PM
To: Jean-Jacques Dubray; 'Jean-Jacques Dubray'; 'Martin Chapman'; 'Yaron Y.
Goland'; 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals

JJ, 

 

I'm not sure what the appropriate XML expression of state transitions should
be.  Essentially, each

participant must have a number of possible states.  Transitions between the
states must be

specified in terms of the message types sent or received.  Each message has
a sender and

a receiver.  This is not a hierarchichal structure.

 

We may also need to consider that a message sent by participant A to
participant B implies

that participant C is in a particular state, e.g., a seller notifies a buyer
that the product has been

turned over to the carrier.

 

Fred

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Tuesday, July 01, 2003 4:59 PM
To: Cummins, Fred A; 'Jean-Jacques Dubray'; 'Martin Chapman'; 'Yaron Y.
Goland'; 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals

Fred:

 

You are correct, the state of the choreography is immaterial and as you
pointed out the only state that is accessible is the public state of each
participant.

 

What would be wrong if we were to choose XPath predicates to express
conditions that specify the different paths a choreography can take? I am
all for hiding the XPath behind some logical construct like it was suggested
for BPSS that has the notion of a "logical document" behind which either
different physical documents or the same physical document with 2 different
XPath predicates.

 

Could you be more specific on how you would see this kind of logic
expressed?

 

Thanks, 

 

JJ- 

 

 

-----Original Message-----
From: Cummins, Fred A [mailto:fred.cummins@eds.com] 
Sent: Dienstag, 1. Juli 2003 16:07
To: Jean-Jacques Dubray; 'Martin Chapman'; 'Yaron Y. Goland'; 'WS Chor
Public'
Subject: RE: Requirements: Decision Points Requirement Proposals

 

JJ,

 

I think we should avoid talking about the "state of the choreography," and
focus on the public state

of the participants.  By "public state" I mean the state that will be
expressed in the choreography

and that the other participant(s) are expected to know about and understand.

 

The public state of a participant changes when it sends or receives a
message.  The participant must

also keep track of the perceived state of the other participant(s) which is
generally reflected in the last

message received from a participant.  When a participant sends a message,
the participant will typically 

change its state to waiting for a response.  The responses it should be
anticipating are constrained by the 

choreography specification.  When a participant receives a message, its
state should 

reflect that it is processing the message.  If it receives another message,
the choreography should

define what should happen, either explicitly or by default--typically it is
an error but the action could be

specified.

 

When a message is received, the recipient is no longer waiting for a
response, but will be processing the message

to determine its next action.  From a choreography perspective, its next
action is constrained by 

its state and the perceived new state of the sender.  The perceived state of
the sender is determined by the

content/semantics of the message.  How this is determined is an
implementation issue.  The choreography

only needs to define the possible alternatives and the possible responses.  

 

The perceived state of the message sender requires interpretation of the
message.  This could be specified in

the choreography, but then the choreography must become a programming
language in order to process

various formats and potentially interpret the message in the current context
of the exchange.  I do not believe

this is appropriate. The choreograpy should only deal with the result of the
message interpretation.  In other

words, the message is processed by the recipient application, and the result
is the basis for determining 

compliance with the choreography specification as well as the acceptable
subsequent actions. 

 

Thus the choreography says, "Based on your current public state, if you
interpet this message as A, then you can 

respond with M or N, if you interpret it as B, then you must respond with P
or Q."  The choreography constrains

the exchange, but it does not interpret the message.  Similarly, the
choreograpy would define, "if you send a message

type M when you perceive the recipient to be in state G, then you should
expect to get back either X or Y and other responses are not valid."

 

Fred

 

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Tuesday, July 01, 2003 2:13 PM
To: 'Martin Chapman'; 'Yaron Y. Goland'; 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals

Yaron:

 

I don't understand your rationale here, the only way the state of a
choreography can advance is by exchanging a message between two parties. The
only way two parties can agree on the state of the choreography is by
looking at the content of the message(s) (telepathy not being an option here
;-). If there was a piece of information known by only one party that would
advance the state of the choreography, this party would have to send a
message to tell this information to the other party in order for their state
to be aligned. 

 

Incidentally, we are not talking about "routing" messages here but rather
"choreography state". If "this message contains this value" then "the
choreography will continue like this" else "continue like that". Once a
message comes in the choreography definition could not care less where it is
routed. This will typically be a private decision. Of course the line may
blur when we talk about multi-party choreographies.

 

JJ-

 

 

 

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Martin Chapman
Sent: Montag, 30. Juni 2003 17:33
To: Yaron Y. Goland; WS Chor Public
Subject: RE: Requirements: Decision Points Requirement Proposals

 

BPEL duplicates the work of java, c#, c++, ...... but the authors had their
reasons. Therefore I don't   find that to be  a compelling argument. 

Simple parseable if-then-else statements seem a necessity IMHO.

 

Martin.

 

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]On
Behalf Of Yaron Y. Goland
Sent: Monday, June 30, 2003 2:19 PM
To: WS Chor Public
Subject: RE: Requirements: Decision Points Requirement Proposals

I agree with #1 wholeheartedly. In fact I would like to see our priorities
be:

    #1 - Be able to define and validate at runtime a choreography without
reference to any outside facility such as BPEL

    #2 - After we have successfully shipped #1 out the door then we would
worry about how to directly integrate our work with BPEL

 

As for #2, I respectfully disagree. 

 

I believe that including the ability to make machine readable state change
decisions (e.g. decision logic) based on the contents of a message will have
a number of detrimental consequences:

 

    #1 - In real world choreographies it is exceedingly rare that the
decision regarding how to deal with a message is made exclusively based on
the contents of the message itself. Even in the most simplistic scenario, a
message router, there is almost universally a recourse to a routing table
which is fully dynamic. So message control logic expressed exclusively based
on message content (which is the only platform and implementation
independent way of doing it) will always be incomplete and thus of little
utility.

 

    #2 - The only way to define a useful message control mechanism to allow
for routing on message contents will require the introduction of a full
programming language since anything but the most trivial scenario will
require sophisticated data handling capabilities. This quickly takes us down
the course of inventing our own programming language and thus duplicating
the work BPEL is doing.

 

As such I believe that our solution should not specify a machine readable
mechanism for specifying how a routing decision is made in the choreography
graph. Rather the logic should be specified via text. It will then be the
job for a latter group to perhaps specify a mechanism by which one could
point at code (such as BPEL) that could encode the actual decision logic.

 

    Just my two cents,

 

            Yaron

-----Original Message-----
From: Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
Sent: Monday, June 16, 2003 4:45 AM
To: Burdett, David; Yaron Y. Goland; WS Chor Public
Subject: 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 <mailto: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 <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