RE: Abstract Bindable Choreography

What about adopting a non normative notation to help us define and
communicate the use cases (internal to the ws-chor working group). Once
we make progress on the language specification and build this notation
overtime (to communicate more and more refined semantics), we could then
decide towards the end, whether it is feasible/valuable to create a
normative notation.

Looking at the work of BPMN, this looks like a big project. We can
assume tool vendors will use all their creativity to represent ws-chor
definitions specified in the ws-chor language. 

Now specifically responding to Assaf, yes it is true in a way that the
control flow of ws-chor could be common with the one of BPEL or BPML
since after all we are just sequencing "things" in parallel or in
series. However when a "thing" is a message exchange or a unit of work
(e.g. "invoke create part in PLM 1") the representations are different.
A message exchange is between parties/roles, with a direction, while a
unit of work is always invoked on a particular system. Representing
roles and message exchange direction (maybe including signals) may
interfere with the traditional parallel/series constructs. There are
also specific aspects to the message exchange choreography: very often
you want to specify that a given message exchange can happen any number
of times for a certain duration or until another message exchange
happens... So I would not assume that a notation for ws-chor would
necessarily be that similar to the one of a process language. AFAIK,
BPMN was never applied to WSCI?

JJ- 
 
 

>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]
>>On Behalf Of Burdett, David
>>Sent: Sunday, April 06, 2003 5:58 PM
>>To: 'Ricky Ho '; Burdett, David; 'WS Choreography (E-mail) '
>>Subject: RE: Abstract Bindable Choreography
>>
>>
>> Ricky
>>
>>See comments inline
>>
>>David
>>Apologies, again for the delay, I've had PC problems.
>>
>>-----Original Message-----
>>From: Ricky Ho
>>To: Burdett, David; WS Choreography (E-mail)
>>Sent: 4/4/2003 12:44 PM
>>Subject: Re: Abstract Bindable Choreography
>>
>>David,  there are some "rules" that I guess by reading your model.
Can
>>you confirm my following understanding of these rules ?
>>
>>"Process" is where each party (who wants to play a role of the
>>choreography) plug-in their private implementation.  In other words,
>>"process" is the hook between "choreography" and "orchestration".
>><DB>Yes, but we must call it "private implementation" ;). Also, a
single
>>"private implementation" defined using BPEL4WS or WSCI could provide
>>support
>>for multiple processes in multiple choreographies.</DB>
>>
>>I categorize the states into various types
>>a) Border state - states sitting at the dotted line
>>     - Outbound border state - source state of an "interaction"
>>     - Inbound border state - target state of an "interaction"
>>b) Inner state - States within the swimlane
>><DB>Good definitions.</DB>
>>
>>All states are "public" in the sense that it is known by at least 2
>>roles (assume multi-role is allowed) at any given point in time
(logical
>>time).
>><DB>Yes they are public and multi-role is allowed.</DB>
>>
>>The state can be derivable from the message exchanges between
>>these two roles.
>><DB>Not completely, when a message is received, for example the order
>>message, the state of the receiver some time later could be any of
"Order
>>Received" or any of the states that result from the "Check Order"
process.
>>The buyer will only know when he receives the next message.</DB>
>>
>>Every arc has exactly one source state and exactly one target state.
>><DB>Yes</DB>
>>
>>There is exactly one incoming arc into the "outbound border state".
>><DB>Often, but not always, for example you could have a combination of
>>inner
>>states that must exist before the outbound state can be realized. For
>>example, in a three role choreography you might want to wait for two
inner
>>states to occur, e.g. before a seller can provide shipping details for
an
>>order they must a) have received and checked the order, and b)
received
>>details about the pick up from the buyer's shipper.</DB>
>>
>>The source of this incoming arc MUST be an "inner state" of the same
role.
>><DB>Yes except that there can be more than one "inner state".</DB>
>>
>>There is exactly one outgoing arc from the "inbound border state".
The
>>target of this incoming arc MUST be a "process" of the same role.
>><DB>Intuitively I think this is good practice, although in theory,
there
>>is
>>no reason why you cannot have more than one process occur upon the
arrival
>>of a message although I can't think of a good example.</DB>
>>
>>An inner state can have (0..n) incoming arcs and (0..1) outgoing arcs.
>><DB>No. An inner state can have (0..n) outgoing arcs. For example a
seller
>>in a multi-role choreography might need to notify the buyer and the
>>shipper
>>if the goods can't be picked up at the expected time. I didn't include
>>this
>>type of situation in the example to keep it simple ;)</DB>
>>
>>It is called a "start state" if it has 0 incoming arc.
>><DB>Yes</DB>
>>It is called an "end state" if it has 0 outgoing arc.
>><DB>Yes, although the behavior of other roles can mean that some of
the
>>other states are "conditional end states" in that, depending on the
>>processing, it may be the "final" state that the role reaches. For
example,
>>the "Accept Order Sent" state will be the end state for the Seller if
the
>>Buyer detects no errors in the Accept Order Message.</DB>
>>
>>Direct connection between inner state is disallowed.
>>In other words, if an inner state has 1 outgoing arc,
>>the arc must connect to an "outbound border
>>state".  Similarly, if an inner state has an incoming
>>arc, it must come from a "process".
>><DB>Often, but not necessarily. For example, to handle a timeout, you
>>could
>>have the "Order Sent" state going to another process which also had an
>>"Order timeout" state as an input. </DB>
>>
>>A process has (1..n) incoming arcs and (1..n) outgoing arcs.  Each
>>incoming arc must be coming from an "inbound border state".  Each
outgoing
>>arc must go to an inner state.  At most one of the outgoing arc can
>>connect
>>to an "end state".
>><DB>Often, but you can also get other states (e.g. timeout states)
that do
>>not come from a border state and go directly to a process. On the
other
>>hand
>>the output of a process should always be one ore more states.
>>Generally, the only real restriction is that a boolean combination of
>>states
>>represent a condition that trigger a process or an interaction, where
the
>>states in the condition are states that exist within that role.
>></DB>
>>
>>It is not mentioned in your diagram and xml, but I consider the
>>"process" should have a timeout concept so that
>>it will be automatically triggered after certain time.  For example,
in
>>the
>>buyer side process "check accept
>>order", how can the seller conclude whether the buyer-side state
"accept
>>order checked OK" or state "accept order checked error" ?
>><DB>I think of a timeout as just another inner state that occurs which
>>then
>>results in messages being sent. Again, for simplicity, I did not
include
>>this in the example.
>>To handle, your specific query, the Seller would only get information
if
>>there was problem i.e. "Accept Order Checked". In practice, I don't
think
>>this is an issue if reliable messaging is being used as:
>>1. The Seller will know that the Accept Order was delivered
>>2. The Seller will know, if there was a problem, that the Accept Order
>>Error
>>was delivered.
>>This means that, for the Seller, no news is good news. Although this
is an
>>optimistic strategy, it should work, especially when any initial
teething
>>problems in an implementation have been ironed out.
>></DB>
>>
>>
>>Best regards,
>>Ricky
>>
>>At 11:08 AM 4/3/2003 -0800, Burdett, David wrote:
>>>There has been some discussion around the idea of an abstract
bindable
>>>choreography so I thought I would provide an example in the form of a
>>>diagram (PDF) which shows the flow associated with the placement of
an
>>order
>>>and an XML representation of the same in a declarative style. I
>>strongly
>>>suggest you look at the diagram first.
>>>
>>>Comments welcome ;-)
>>>
>>>David
>>>  <<PlaceOrderChoreography.pdf>>
>>>  <<PlaceOrderChoreography.xml>>
>>>
>>>Director, Product Management, Web Services
>>>Commerce One
>>>4440 Rosewood Drive, Pleasanton, CA 94588, USA
>>>Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
>>>mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>>>
>>>

Received on Monday, 7 April 2003 09:57:31 UTC