RE: Abstract Bindable Choreography

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