- From: Yaron Y. Goland <ygoland@bea.com>
- Date: Thu, 3 Jul 2003 14:06:02 -0700
- To: "'WS Chor Public'" <public-ws-chor@w3.org>
- Message-ID: <GMEOJGJFKALPDCNPFMDOOECGDFAA.ygoland@bea.com>
MessageIf we are to harbor any hope of shipping any time soon I would
suggest we follow the rule that 'the spec is ready to ship when there is
nothing left to cut'. We can clearly cut XPATH and still have an enormously
useful spec. We can also layer XPATH support in on a future release so our
choice does not permanently cut off us. Therefore I would propose leaving
off XPATH.
-----Original Message-----
From: Cummins, Fred A [mailto:fred.cummins@eds.com]
Sent: Thursday, July 03, 2003 1:56 PM
To: Yaron Y. Goland; Jean-Jacques Dubray; 'WS Chor Public'
Subject: 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)---yac
ky/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 (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
Received on Thursday, 3 July 2003 17:06:07 UTC