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 16:24:18 UTC