W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

Re: Abstract Bindable Choreography

From: Assaf Arkin <arkin@intalio.com>
Date: Thu, 10 Apr 2003 11:01:24 -0700
Message-ID: <3E95B174.5040303@intalio.com>
To: "Patil, Sanjaykumar" <sanjay.patil@iona.com>
CC: "Burdett, David" <david.burdett@commerceone.com>, "Monica J. Martin" <monica.martin@sun.com>, Ricky Ho <riho@cisco.com>, public-ws-chor@w3.org

By itself the term time-out is neither a state nor a transition, it's 
just a generic term, much like failure.

I would generally signify "time constraint" as the condition that leads 
to the transition (e.g. at 5:35), "time-out event" as the actual event 
that leads to the transition (e.g. what happens at 5:35). When the event 
occurs you transition to a new state.

It's easy to say that the transition occureed due to a time constraint 
and label it as a "time-out transition". The state you are in may have 
some meaningful name, like "no response provided" or "time to cancel and 
report error". But generally speaking, if you only get to this state due 
to the time-out event, you may as well characterize it as "time-out state".

But just saying time-out is not very helpful. It does not clarify 
whether you are talking about the transition that occurs at the specific 
time instant, or the state you reach as part of that transition.

arkin


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
>
Received on Thursday, 10 April 2003 14:08:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC