- From: Ricky Ho <riho@cisco.com>
- Date: Fri, 04 Apr 2003 13:24:03 -0800
- To: "Martin Chapman" <martin.chapman@oracle.com>, "'Burdett, David'" <david.burdett@commerceone.com>, "'WS Choreography \(E-mail\)'" <public-ws-chor@w3.org>
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