RE: Abstract Bindable Choreography

that's better:-)

> -----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 1:24 PM
> To: Martin Chapman; 'Burdett, David'; 'WS Choreography (E-mail)'
> Subject: RE: Abstract Bindable Choreography
> 
> 
> 
> OK !  Replace that with private implementation.
> 
> Rgds, Ricky
> 
> At 01:13 PM 4/4/2003 -0800, Martin Chapman wrote:
> >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 18:13:42 UTC