W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

Re: Abstract Bindable Choreography

From: Assaf Arkin <arkin@intalio.com>
Date: Mon, 07 Apr 2003 11:22:06 -0700
Message-ID: <3E91C1CE.8090506@intalio.com>
To: Jean-Jacques Dubray <jjd@eigner.com>
CC: "'Burdett, David'" <david.burdett@commerceone.com>, "'Ricky Ho '" <riho@cisco.com>, "'WS Choreography (E-mail) '" <public-ws-chor@w3.org>, "'Martin Chapman'" <martin.chapman@oracle.com>

>
>
>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?
>  
>
I have looked at the BPMN specification to determine if it will map well 
to WSCI and allow you to express choreographies, including the ability 
to depict two different parties/roles (separate swimline) exchanging 
messages with a clear notion of direction (who sends what) and state 
(who sends when).  Also ability to express any number of exchanges until 
a certain time-out or another message exchange, do things in parallel, 
etc. BPMN seems to fully support these scenarios and the notation is 
very natural to read.

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.

That's an important aspect if you are using a notation in a 
non-normative fashion to help illustrate examples.

As Stephen said, there is no write up of the mapping from BPMN to WSCI 
due to time/bandwidth. That does not mean they cannot be created. I have 
look at BPMN to determine that it can be done and fairly easily. There's 
nothing new or challanging about these mappings, it's just a matter of 
editing the BPMN document to contain them.

arkin

>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 14:24:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC