Re: Abstract Bindable Choreography

Patil, Sanjaykumar wrote:

>>>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?)
>  
>
A state is a state is a state.

You may arrive at a state because you received a particular message. You 
may arrive at a state because you failed to receive a particular 
message. It may be another message that you have received (rejected 
instead of accepted) or simply lack to receive any message. Or perhaps 
it is an error on your side that you wish to communicate.

It may be a terminal state. It may be just another state from which you 
transition to another state. A time-out does not necessarily lead you to 
a terminal state. If you did not receive a response in a timely manner 
you may prefer to escalate rather than give up.

You may elect to call a particular state "time-out". You may call it 
"I've given up", or "partner away" or just "not the outcome I would 
like". I can see the difference between a time-out event that is fired 
by some clock and a message event that is recieved from another system. 
But once you respond to that event and transition to some states, all 
states look the same.

A language that has specific transition types and state types depending 
on the event type is needlessly complicated. It contains too many 
constructs. A language can be succinct and still achieve the same result 
by defining one generic type of state/transition model and simply adding 
time related events.

In addition to making the language simpler, it also makes the 
definitions more reusable. You may end up having different events that 
cause a transition to the same state. The state "Not accepted" may be 
reached upon receipt of an "order rejected" message, or after failing to 
receive any response within an accepted time frame.

I can see the rational to create different type of states to account for 
all the possible event types. There's something appealing about creating 
a lot of XML elements and using the XML element name to clarify your 
intention. But it's my opinion that the language would be simpler and 
more effective if we resist this temptation.

arkin

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

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