RE: Abstract Bindable Choreography

>>In fact, I think the last point is very important. The notation is
self
>>explanatory so it's easy to understand definitions - including those
>>depicting multi-party choreographies - by just looking at the diagram.
>>Just look at the example that Stephen gave and see if you can easily
>>understand what's going on without having to read the BPMN spec.
>>

Actually, I would content that this is not as true as one would believe,
yes you can clearly see the message exchange in an otherwise forest of
internal activities in each respective party.

My main point of contention with WSCI remains and this is why I don't
like BPMN when applied to choreography as well: the choreography itself
is not represented, it is merely the association of "n" choreography
specifications (one for each partner) that one has to use to understand
(an navigate) the overall behavior of the choreography (this is well
shown by Steven's examples). This creates an unnecessary level of
complexity that would hinder the understanding of a large choreography
(look at what is currently needed to support a few messages between two
parties). Other notations exist which show one single "neutral"
choreography without the use of "internal" activity and business logic.


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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
>>
>>--
>>"Those who can, do; those who can't, make screenshots"
>>
>>----------------------------------------------------------------------
>>Assaf Arkin                                          arkin@intalio.com
>>Intalio Inc.                                           www.intalio.com
>>The Business Process Management Company                 (650) 577 4700
>>
>>
>>This message is intended only for the use of the Addressee and
>>may contain information that is PRIVILEGED and CONFIDENTIAL.
>>If you are not the intended recipient, dissemination of this
>>communication is prohibited. If you have received this communication
>>in error, please erase all copies of the message and its attachments
>>and notify us immediately.

Received on Monday, 7 April 2003 15:09:58 UTC