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

RE: Abstract Bindable Choreography

From: Burdett, David <david.burdett@commerceone.com>
Date: Thu, 10 Apr 2003 13:00:01 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D196B@C1plenaexm07.commerceone.com>
To: "'Patil, Sanjaykumar'" <sanjay.patil@iona.com>, Assaf Arkin <arkin@intalio.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
I like this idea. It means that you have a state that can be classified into
a number of types which means it has specific semantics associated with it.
For example:
1. "StartState" a state that triggers the initiation of a choreography
2. "EndState" a state that marks the end of a choreography - no further
transitions from this state are valid.
3. "ConditionalEndState" a state that CAN mark the end of the choreography -
there might be more transitions from this state but not necessarily
4. "ErrorState" a state that arises because of abnormal processing of some
kind
5. "TimedOutState" a state that arises because of timeout event of some kind
has occurred.
6. "MessageStartState" a state which causes the sending of a message
7. "MessageReceivedState" a state that is caused by the arrival of a
message.

In practice these should probably be arranged into a hierarchy as ErrorState
is a subtype of EndState. 

Does this make sense?

David


-----Original Message-----
From: Patil, Sanjaykumar [mailto:sanjay.patil@iona.com]
Sent: Thursday, April 10, 2003 12:06 PM
To: Assaf Arkin
Cc: Burdett, David; Monica J. Martin; Ricky Ho; public-ws-chor@w3.org
Subject: RE: Abstract Bindable Choreography



>> 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".

So, you find it useful to tag "both" transition and the state as of type
"time-out". Also, I agree that specifying just time-out will not be greatly
useful and we need to provide for fully defining the time-out constraints,
etc. 

Now, in the choreography language, we could either treat time-out
transitions and states as any other. Or define explicitly in the language
time-out as a type of transition, a type of state, and also define the
bondage that a timeout transition results into a timeout state (I guess we
already assume certain types for the state:- start, end, error, etc and
timed-out become one more! Is that right?)
Received on Thursday, 10 April 2003 16:00:08 UTC

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