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

Re: Events and States (was: timeouts & states

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 11 Apr 2003 11:02:11 -0700
Message-ID: <3E970323.5000705@intalio.com>
To: Ricky Ho <riho@cisco.com>
CC: jdart@tibco.com, Cummins Fred A <fred.cummins@eds.com>, public-ws-chor@w3.org

Ricky Ho wrote:

>
> I understand the "nested state", basically you breakdown a state into 
> finer grain, but this is still mutually exclusive.  You can only be at 
> one of the substate.
>
> In David's example, lets say the seller interact with the manufacturer 
> as well as the credit check.  In the public state diagram, the seller 
> want to express that the purchase order will be confirmed only when 
> the credit check passes as well as the manufacturer have the product 
> in stock.
>
> So, does the seller has two non-exclusive states "credit-pass", 
> "product-available" ?

Practically speaking, also as far as statechart is concerned, the seller 
has two non-exclusive states that are part of the same parent state. 
Although the startchart chart does not depict this, the statechart model 
actually accomodates for that type of state (aka state variables).

There's one thing to demarcate a state. You do something and you enter a 
state in which you can do other things until you leave that state. 
State-transition diagrams talk about these states. Another thing is to 
have a particular state that does not demarcate any activities, e.g. the 
balance in your account.

Let's say you have 6 products to ship as part of a purchase order. At 
some point in time you have already shipped two products, are currently 
preparing to ship two other products and will later ship the last two 
products. What state are you in?

If you think in terms of binary states, you need an endless number of 
combination to account for such scenarios. On the other hand, you can 
have variable states, a state that is defined by a range of values. For 
example: { shipped=2, shipping=2, remaining=2 }. Along side you can also 
have demarcated states, e.g. "in the process of shipping" which is 
contained in "in the process of fulfilling an order".

The state you are in is usually defined in terms of the possible values 
you can have and also the possible activities you can perform.

arkin

>
> or 4 mutually-exclusive states "credit-pass and product-available", 
> "credit-pass and NOT product-available" .....
>
> The latter is easier to understand.
>
> Rgds, Ricky
>
> At 10:15 AM 4/11/2003 -0700, Assaf Arkin wrote:
>
>> Ricky Ho wrote:
>>
>>>
>>> In David's example, "State" is not mutually exclusive.  (Correct me 
>>> if I'm wrong).  A role can have multiple "states" at the same time 
>>> and each of this state can accept different events and transition to 
>>> another states.  Somewhat similar to a multi-thread scenario.  So 
>>> when one thread reaches an end state.  The choreography can still be 
>>> active because of other threads.
>>>
>>> This is quite different from the traditional state chart who try to 
>>> avoid composite states.  Am I totally lost ?
>>
>>
>> Some state transition models have mutually exclusive states.
>>
>> Statechart diagrams have composite states, so they allow for 
>> non-exclusive states and multiple concurrent sub-states as part of 
>> the same parent state.
>>
>> arkin
>>
>>>
>>> Rgds, Ricky
>>
>>
>>
>>


-- 
"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 Friday, 11 April 2003 14:03:42 UTC

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