- From: Monica J. Martin <monica.martin@sun.com>
- Date: Fri, 11 Apr 2003 21:35:01 -0600
- To: "Patil, Sanjaykumar" <sanjay.patil@iona.com>
- CC: "Burdett, David" <david.burdett@commerceone.com>, Ricky Ho <riho@cisco.com>, public-ws-chor@w3.org
Let's put this one in the parking lot as I am not certain that a timeout is indeed a state, in and of itself. Monica Patil, Sanjaykumar wrote: > Understood. There are acks at various levels such as messaging and > process level. Choreography perhaps should limits itself to handling > timeouts of process level acks only. Makes sense. > > I was however commenting on the other the discussion topic, that is, > whether Timeout is a state or a transition. Personally, I did not see > it clearly to be one of these and my inclination is to say that it's > both. This is perhaps a subtle modeling issue and we can move on > without getting a clear answer today. However, if we run into more > such cases where the state and transition are married to each other, > we may consider supporting it as a language feature and solve it once. > That's all. > > > Sanjay Patil > Distinguished Engineer > sanjay.patil@iona.com > ------------------------------------------------------- > IONA Technologies > 2350 Mission College Blvd. Suite 650 > Santa Clara, CA 95054 > Tel: (408) 350 9619 > Fax: (408) 350 9501 > ------------------------------------------------------- > Making Software Work Together TM > > -----Original Message----- > *From:* Burdett, David [mailto:david.burdett@commerceone.com] > *Sent:* Thursday, April 10, 2003 9:56 AM > *To:* Patil, Sanjaykumar; Monica J. Martin; Burdett, David > *Cc:* Ricky Ho; public-ws-chor@w3.org > *Subject:* RE: Abstract Bindable Choreography > > I think that two different types of timeout can occur associated with: > 1. Delivery of an individual message, and > 2. Completion of the processing of a message > > For the first case, you can ask for a *message* acknowledgement > receipt on any message that is sent. If the acknowledgement is > received it does NOT mean that the message has been processed it > only means its been delivered and it SHOULD be processed. This is > what the Reliable Messging specs (note the "s") all do. I don't > think that this type of protocol is within our scope although we > should recognize that they exist, we could even recommend that > they are used. > > In the second case you get a response that is based on processing > the message. In this case it might be just *process* > acknowledgement receipt which means that the message was > successfully processed. For example if you are doing a > subscription to a service then this might be all you need. This > type of acknowledgement receipt is, I think within our scope. > > These two types of receipts also lead to two different types of > timeout: > 1. The reliable messaging timeout which is the time you wait for > the *message* acknowledgement receipt before resending the > message. This is also part of the RM spec. > 2. The process timeout, which is the time you wait for any message > as defined in the choreography to comeback. > > Note you could get a message acknowledgement receipt and still get > a proccess timeout. > > David > > -----Original Message----- > *From:* Patil, Sanjaykumar [mailto:sanjay.patil@iona.com] > *Sent:* Thursday, April 10, 2003 9:35 AM > *To:* Monica J. Martin; Burdett, David > *Cc:* Ricky Ho; public-ws-chor@w3.org > *Subject:* RE: Abstract Bindable Choreography > > > Perhaps it is both. That is, a Timed-out state can only result > if a timeout transition occurs. Similarly a timeout transition > can only lead to a Timed-out state. > > Now a Timed-out state may further lead to a Success or Failure > outcome state based on the the logic for handling the > particular situation. > > As shown in your example, a timeout in receiving an ack for a > response may be less critical and can be perceived as a > success state (with warning being logged). Whereas a timeout > in receiving an ack for a request is a critical failure as the > state change is predicated on the ack in this case. > > > I am not sure if there are other cases where a transition and > the resultant state are tied to each other. In case there are, > we may consider supporting the pattern as a language feature. > > Sanjay Patil > Distinguished Engineer > sanjay.patil@iona.com > ------------------------------------------------------- > IONA Technologies > 2350 Mission College Blvd. Suite 650 > Santa Clara, CA 95054 > Tel: (408) 350 9619 > Fax: (408) 350 9501 > ------------------------------------------------------- > Making Software Work Together TM > > -----Original Message----- > *From:* Monica J. Martin [mailto:monica.martin@sun.com] > *Sent:* Thursday, April 10, 2003 9:01 AM > *To:* Burdett, David > *Cc:* 'Ricky Ho'; public-ws-chor@w3.org > *Subject:* Re: Abstract Bindable Choreography > > I would say that the transition would be a timeout, but > the state would be at a minimum Failure or Success (if the > timeout is not deemed substantive and in actuality a > conclusion is reached). For example, we have seen that a > requestor is asked to send a receipt acknowledgement to > the responder for a response. The requestor does not send > the receipt acknowledgement, but from a business > perspective does not negate the transaction but a warning > is logged. Effectively, although in a different manner, > the interchange concludes in Success. > > I do not think the State is a timeout but the timeout > results in a state. > Thanks. > > > "Burdett, David" wrote: > >> MonicaI think we are basically agreeing. But I tend to >> think of a timeout as a transition that results in the a >> state that indicates a timeout has occurred. If you think >> of timeouts in this way, then the resultant timeout state >> can be used in exactly the same way any other state that >> occurs, for example, because a message has arrived. >> Here's an example: >> Buyer Seller Event/Transition >> State State1. Message:Order ------------> OrderSent OrderReceived... nothing happens, no >> Order Response is sent so the Buyer never reaches the >> "OrderResponseReceived" state, so ...2. >> Timeout:NoOrderResponse OrderTimeout3. If >> (OrderTimeout AND NOT OrderResponseReceived) then >> Message:OrderStatusRequest ------->4. etc ...Does this make any sense?DavidPS. I held off >> responding to your comments on timeouts since I thought >> we might talk about this in our conference call but we >> never got around to it. >> >> -----Original Message----- >> *From:* Monica J. Martin [mailto:monica.martin@sun.com] >> *Sent:* Tuesday, April 08, 2003 10:25 AM >> *To:* Burdett, David >> *Cc:* 'Ricky Ho'; public-ws-chor@w3.org >> *Subject:* 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 >>>
Received on Friday, 11 April 2003 23:29:01 UTC