Re: About component architectures...

On Thu, 25 Apr 2002, Anthony Mallet <Anthony Mallet wrote:

> Herman Bruyninckx wrote :
> | I am not too happy with a `supervisor' because that is such a general
> | name that covers too many different things we want to separate.
> 
> I think what you really want is an "execution control layer", which can
> be made of several components: 'configurator', 'resource management',
> 'consistency checks' (e.g. checking that you are not doing things with
> the 'functional components' that are not allowed), 'communication
> management' (e.g. some of the functionalities of an ORB), etc...

These are all part of configuration, aren't they? But I agree that
they represent different aspects (`roles') of configuration.

> | - Configurator (what the people in LAAS call ``control flow'' I guess),
> 
> Not really: the control flow is much more general. With our terminology,
> the control flow represents all the service requests that are made to the
> 'functional components'. 
> | - Mediator (``data flow'') that accepts service requests from
> |   the user and divides those into actions for its sub-components.
> 
> [ Services requests are part of the control flow ]

Ok, I understand my misunderstanding.

> Your Mediator is what I called 'communication management' above. And it
> must take care of both the data and the control flow.

Communication is not concrete enough, I think: configuring how
sub-components must communicate is one thing, but deciding how an
incoming service request is to be executed by the available
sub-components is another thing. The latter has to be done for every
incoming request (hence `mediator'); the former only once at
`configuration'.

> Let's say you have a component A that can produce data (A.ouput) and a
> component B that need data (B.input).
> 
> The control flow represents the floowing actions:
> "tell A to start producing A.output"
> "tell B to read B.input from A.output"
> "tell B to start using B.input"

Ok. This is configuration.


> | Should we make separate sub-component for each of these ``roles'' or
> | should we do just that: call it supervisor, and give it different
> | roles (Configurator, Mediator) to play?
> 
> No, I think it's a good idea to make separate sub-components :)

And how do we decide what sub-component will be active when? By
another `supervisor' on top of them....? It looks simpler to me to
give the Configurator the possibility to perform various roles,
instead of branching of a new sub-component for each of these roles.

> But I wouldn't call 'supervisor' the set of the sub-components you are
> talking about. In the literature, the supervisor is the one that makes
> decisions about the services to activate whithin the functional layer.

That depends on which part of the literature you read :-)

> I think we are really talking about the 'execution control layer' of the
> 3 layered architectures.

No, I am talking about the _internals_ of _all_ three layers...
Irrespective of what their functional purposes are. Of course, there
will be differences between the architectures of components with
different functional purposes, but I do think they will have lots of
structure in common; it's this structure I want to specify now...

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480