Re: Tony's nightmare - wake me up please

Tony Fletcher wrote:

> Consider a relationship between two nodes that we wish to describe.  
> The usual way to describe this fully suing state machines is to 
> develop a state machine for each end and see how they interact.  
> Suppose one state machine has N states and the other M (N and M will 
> be close to the same integer value but not necessarily equal).  So we 
> have had to use N + M (approx 2*N) states to describe this 
> relationship precisely.  However, there are altogether N*M (approx N 
> squared) states that the system can be in.  Now depending on the 
> whether each of our state machines are relatively simple and only have 
> entries on the diagonal cells (or nearly so) or a very complicated 
> with entries in most cells the number of valid, reachable states may 
> be near to 2N or to N squared).  The answer is usually a lot more than 
> 2N even if less than the worst case.

Practically speaking, way closer to 2N than N*M for the simple reason 
that the state machine constrains the states by means of transitions, 
thus not all states are reachable from all states. If you're counting 
states you have to factor reachable states (transitions included), not 
just the mere existence of a state.

The "2N" is unescapable since you're describing a distributed system 
whereby, any way you slice and dice it, there are FSM at each end. And 
in perfect alignment with how the business world has shaped to deal with 
asynchronous communication (mail, fax, etc).

> Now it is possible, in principle (I think) to have a single state 
> machine that describes the permitted message sequences for the 
> relationship but this is usually only attempted for very simple cases 
> due to the state 'explosion' described above.  This single state 
> machine has to represent all the valid states which is between N+M and 
> N*M and usually well above N+M for any 'interesting' protocol.
>  
> In the current version of CDL we do not seem to be describing the 
> process at each node then letting these interact with the others, but 
> describing the interactions directly.  My concern is that this 
> approach will suffer from state space explosion when one tries to 
> include every conceivable message sequence that could happen, and that 
> actually the current CDL may be fine for describing message sequence 
> charts in XML (which is useful but not I thought what we were 
> attempting to achieve) which are fine for illustrating message flows, 
> but do not, in general, cover every possible case the protocol 
> designer needs to allow for, but will become unwieldy / impossible to 
> use for a complete description.

I believe the only _interactions_ worth describing are the "interesting" 
ones, the ones that may happen because they're possible in a reachable 
state, not the ones that could happen because a message can be sent or 
received over the wire. The interesting states are a well defined subset 
of all possible message exchange combinations.

An interaction of the form 'purchase order cancel received for purchase 
order that was never started' is technically possible, as is an 
interaction of the form 'purchase order received by a service that 
provides up-to-date traffic reports'. But neither is interesting to 
cover in a protocol.

Since each node has a well defined FSM on its side that can validate the 
messages it sends/receives based on its current state, there is no need 
to specifically care for interactions not allowed by valid reachable 
states. If both X and Y are in respective state where X is not allowed 
to send message Q, then there is no onus on Y to receive, process or 
otherwise respond to the receipt of message Q. If X fails its 
specification and does in fact send message Q, and Y ignores it (e.g. by 
returning a generic error or putting it in a DLQ), then Y is acting 
consistent with its specification. And since both systems can be built 
to be constrained by their respective specification, there's no need to 
over-invent to cater for all possible interactions.

Assaf


>  
> I hope the point is clear and that someone can answer it.
>  
> Best Regards     Tony
> A M Fletcher
>  
> Cohesions  (TM)
>  
> Business transaction management software for application 
> coordination       www.choreology.com <http://www.choreology.com/>
>  
> Choreology Ltd., 68 Lombard Street, London EC3V 9LJ     UK
> Tel: +44 (0) 1473 729537   Fax: +44 (0) 870 7390077  Mobile: +44 (0) 
> 7801 948219
> tony.fletcher@choreology.com <mailto:tony.fletcher@choreology.com>     
> (Home: amfletcher@iee.org)
>  



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