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

RE: Abstract Bindable Choreography

From: Martin Chapman <martin.chapman@oracle.com>
Date: Fri, 4 Apr 2003 13:13:27 -0800
To: "'Ricky Ho'" <riho@cisco.com>, "'Burdett, David'" <david.burdett@commerceone.com>, "'WS Choreography \(E-mail\)'" <public-ws-chor@w3.org>
Message-ID: <005501c2faef$092a2580$6501a8c0@us.oracle.com>

can you please stop using the word orchestration!
We have no clear defintion of it and it use is banned from this group
until its obvious that we need it:-)

Martin.

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Ricky Ho
> Sent: Friday, April 04, 2003 12:44 PM
> To: Burdett, David; WS Choreography (E-mail)
> 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".
> 
> 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
> 
> 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).  The state can be derivable from the message exchanges 
> between these 
> two roles.
> 
> Every arc has exactly one source state and exactly one target state.
> 
> There is exactly one incoming arc into the "outbound border 
> state".  The 
> source of this incoming arc MUST be an "inner state" of the same role.
> 
> 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.
> 
> An inner state can have (0..n) incoming arcs and (0..1) 
> outgoing arcs.  It 
> is called a "start state" if it has 0 incoming arc.  It is 
> called an "end 
> state" if it has 0 outgoing arc.
> 
> 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".
> 
> 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".
> 
> 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" ?
> 
> 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 Friday, 4 April 2003 16:13:56 UTC

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