Re: Abstract Bindable Choreography

I would have to agree with Ricky that the timeout is a transition not
the state itself.  In addition, many concurrent business processes and
their inter-relationships are messy, but they do exist (particularly in
larger enterprises or hubs - reference my simple use case that
acknowledges interactivity of business processes, exceptions, etc. that
affect processing and outcomes).  We may also need to look at this
heirarchically where you and have pre- and post-conditions that are
inputs to other processes.

Yes, messy.

Monica J. Martin
Sun Microsystems

"Burdett, David" wrote:

>
>
> Ricky
>
> See comments in line, marked with <DB2></DB2>
>
> David
>
> -----Original Message-----
> From: Ricky Ho [mailto:riho@cisco.com]
> Sent: Monday, April 07, 2003 10:08 AM
> To: Burdett, David
> Cc: public-ws-chor@w3.org
> Subject: RE: Abstract Bindable Choreography
>
> David, I'm thinking about bi-party scenarios when I read your diagram
> (although I know multi-roles is possible)..  Now I focus in
> multi-party
> scenario.  See inline...
>
> >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).
> ><DB>Yes they are public and multi-role is allowed.</DB>
>
> <RH>
> I'm thinking you can use different color of "border state" to
> represent
> multi-role scenario.  e.g. The buyer/seller interactions are using a
> set of
> "green" border states while the seller/shipper interactions use a set
> of
> "blue" border states.
> I also think there can only be "ONE start state" across all roles.  In
> your
> example, only the buyer has a "start state".
> </RH>
> <DB2>I'm not sure why you want to use colors although I think they can
> make easier to view.
> I would generalize "ONE start state" to "ONE set of conditions" where
> a condition is a boolean expression of states. For example you could
> have an order recovery choreography that had a "pre-condition" of
> "OrderSent AND OrderTimeout" where "OrderSent" and "OrderTimeout" are
> individual states.
>
> </DB2>
>
> >There is exactly one incoming arc into the "outbound border state".
> ><DB>Often, but not always, for example you could have a combination
> of inner
> >states that must exist before the outbound state can be realized. For
>
> >example, in a three role choreography you might want to wait for two
> inner
> >states to occur, e.g. before a seller can provide shipping details
> for an
> >order they must a) have received and checked the order, and b)
> received
> >details about the pick up from the buyer's shipper.</DB>
> <RH>
> When there are multiple "inner states" connected to one "outbound
> border
> state", what is the triggering condition ?  Anyone state, or All
> states ?
>
> For There are 2 alternatives that I can think of
>
> 1) Allow multiple inbound border state (as long as they are different
> color) connect their outgoing arc to a process.  A guard condition is
> associated with the process and determines the execution
> pre-conditions.
>
> OR
>
> 2) Allow multiple inner states to connect their outgoing arc to an
> outbound
> border state. A guard condition is associated with the process and
> determines the interaction pre-conditions.
> </RH>
> <DB2>As illustrated in the previous comment, I think that the
> condition can be a boolean expresion that combines states together.
> For example if you wanted to send a "ChangeOrder" message then the
> precondition would be something like "ChangeOrderCreated AND
> (OrderSent OR ChangeOrderSent)" </DB2>
>
> >The source of this incoming arc MUST be an "inner state" of the same
> role.
> ><DB>Yes except that there can be more than one "inner state".</DB>
>
> <RH>
> Same as alternative 2 that I suggested above ?
> </RH>
>
> >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.
> ><DB>Intuitively I think this is good practice, although in theory,
> there is
> >no reason why you cannot have more than one process occur upon the
> arrival
> >of a message although I can't think of a good example.</DB>
>
> <RH>
> I think allowing multiple simultaneous processing is very complex.
> Same as
> all issues associated with multi-threading.  We should avoid this
> until we
> have a good use case to break this.  Agree ?
> </RH>
> <DB2>Although it is complex, sometimes business processes can be
> complex. The real question is do we want to prohibit it. I don't think
> so.</DB2>
>
> >An inner state can have (0..n) incoming arcs and (0..1) outgoing
> arcs.
> ><DB>No. An inner state can have (0..n) outgoing arcs. For example a
> seller
> >in a multi-role choreography might need to notify the buyer and the
> shipper
> >if the goods can't be picked up at the expected time. I didn't
> include this
> >type of situation in the example to keep it simple ;)</DB>
>
> <RH>
> Agreed.  But all outgoing arcs must be in DIFFERENT colors, right ?
> </RH>
> <DB2>OK but colors only apply to the diagrams and not to the XML right
> ;) I also didn't think we were developing a diagramming
> convention.</DB2>
>
> >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".
> ><DB>Often, but not necessarily. For example, to handle a timeout, you
> could
> >have the "Order Sent" state going to another process which also had
> an
> >"Order timeout" state as an input. </DB>
>
> <RH>
> There are two aspects of timeout we need to handle ..
>
> On the sender side, each "outbound border state" should optionally has
> an
> outgoing "timeout" arc connecting to a process of the same role.  This
>
> presence of such "timeout" arc indicates the outbound border state has
> a
> timeout value so that if there is no message received from the same
> partner
> (ie: no message received from any inbound border node who has the same
>
> color of this outbound node), then the process will be started.
>
> On the receiver side, he should indicate an upper bound it takes to
> transit
> to the next state (and send his message).  This is important for the
> sender
> to set his corresponding timeout value on the other side.
> </RH>
> <DB2>This would work, but I don't see how this is really any different
> from anything else as you have a set of conditions made up out of a
> combination of states that determine whether or not a timeout has
> occurred and if so, what, if anything you do. In principle I don't
> like "special cases" (i.e. for timeouts) as they tend to introduce
> unnecessary complexity.
>
> Also, determining a timeout condition is totally within the *control*
> of the sender of the message. Although the sender should take into
> account the processing time of the receiver of the message you cannot
> force the sender to do this as there is no-one in overall control of
> the complete choreography.
>
> I also think that the timeout *values* to use (i.e how long you wait)
> is implementation dependent and therefore should be in the binding of
> the choreography to the implementation.
>
> Perhaps what we need to do is provide guidelines on how to handle
> timeouts. Does this make sense.
> </DB2>
>
> >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".
> ><DB>Often, but you can also get other states (e.g. timeout states)
> that do
> >not come from a border state and go directly to a process. On the
> other hand
> >the output of a process should always be one ore more states.
> >Generally, the only real restriction is that a boolean combination of
> states
> >represent a condition that trigger a process or an interaction, where
> the
> >states in the condition are states that exist within that role.
> ></DB>
>
> <RH>
> In my description above, there is NO such thing called "timeout
> states".  It is being modeled as a "timeout arc" from an outbound
> border state.
> </RH>
>
> >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" ?
> ><DB>I think of a timeout as just another inner state that occurs
> which then
> >results in messages being sent. Again, for simplicity, I did not
> include
> >this in the example.
> >To handle, your specific query, the Seller would only get information
> if
> >there was problem i.e. "Accept Order Checked". In practice, I don't
> think
> >this is an issue if reliable messaging is being used as:
> >1. The Seller will know that the Accept Order was delivered
> >2. The Seller will know, if there was a problem, that the Accept
> Order Error
> >was delivered.
> >This means that, for the Seller, no news is good news. Although this
> is an
> >optimistic strategy, it should work, especially when any initial
> teething
> >problems in an implementation have been ironed out.
> ></DB>
>
> <RH>
> In this example, the seller can never conclude "accept order checked
> OK"
> (even though he can assume that) unless a timeout is attached.  (the
> timeout says, if I don't receive the accept order send error within 2
> hours, then both of us agree "accept order checked OK").
> </RH>
> <DB2>I think an example of how timeouts could work in a diagram and in
> XML will be useful. I will work on it.</DB2>
>
> Rgds, Ricky