Re: Abstract Bindable Choreography

Burdett, David wrote:

>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.
>  
>
How about:

1. State - a state.

A "start state" is characterized as a state with no input transition. An 
"end state" is characterized as a state with no output transition. All 
other states are intermediary. An "error state" is a state with input 
transitions occuring as result of error events. A "time-out state" is s 
tate with input transition occuring as a result of time-out events. A 
state may be an error state or a time-out state or a message state or 
both or any combination.

>In practice these should probably be arranged into a hierarchy as ErrorState
>is a subtype of EndState. 
>
I disagree that error necessarily leads to a terminal state.

If someone invited you to their home, you came, knocked on the door and 
there was no one there, do you just give up or leave? Perhaps you should 
try ringing the door bell. Still no answer? Call them on the cell phone. 
You may find that they are back in the garden attending to the roses. 
They may ask you to come around the back instead of entering through the 
front door.

In the majority of cases an error is indeed the end of the choreography. 
You've tried your best but you just can't complete. But in some cases 
you can recover, notify and elect a different path. If you have a vested 
interest in performing the choreography surely you have a vested 
interest in trying to recover and proceed past a point of error.

arkin

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


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Thursday, 10 April 2003 19:17:24 UTC