On Mon, 20 Feb 2012, Geoffrey Biggs wrote:

> On 20/02/12 02:11, Herman Bruyninckx wrote:
>> If I understand correctly what you mean, my short answer is "yes"! The
>> Coordinator just does the event processing, and most of the events
>> resulting from this will trigger re-configurations of the components that
>> process the data flow. In other words, there is no need for the FSM to do
>> the data flow itself. Take the obvious example of the Board of a company:
>> their decisions are not processing the data in the company itself, but are
>> giving signals to the upper management to change something in the way the
>> whole company deals with its data (or products, for that matter).
>> That's also the reason why a good manager can job-hop to companies with
>> very different activities without much problems: his coordination skills
>> are reusable, even with limited domain knowledge :-)
>
> This is the approach we take. It works well so far, both for "good" and "bad" 
> events. It does have the disadvantage, which Ingo also pointed out, that the 
> components either need to be designed with the method in mind or need to be 
> some form of stateless. In my opinion, however, if you are doing proper loose 
> coupling then it's not *that* special, so components that are not designed 
> like that probably need fixing. ;)

Absolutely! Coordinators can only do their job with components that are
designed to be coordinated by independently developed FSMs :-)

Easier said then done, though... :-(

> Geoff

Herman