avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject [Phoenix] Design issue about wiring
Date Thu, 26 Jun 2003 07:11:07 GMT

Hi,

I have a conflict in my design strategy, that I wish to get some feedback on.

Use-case (I take the smallest understandable case I have, so it may seem too 
simple to become a component, but the others are not for sure);

An EnergyMeter receives events from some external source (unknown at design 
time). It computes various values (Power, Accumulated kWh) and handles life 
cycles of physical EnergyMeters (service, calibration and replacements).
It also produces events for activities going on, such as "High Power Limit 
reached" and dozens of others.

I package this as an Avalon Block. There will be dozens or more of these 
(similar) blocks in an application. Each of these blocks will have several 
event sources wired to them, making the number of event sources to 100s.

The event source should be wired by the Deployer.

The event sources are often very small and simple, and I don't think it is 
suitable to be Components, although that is possible. I am instead looking 
towards ServiceSelector, and simple JavaBeans events.

For the EnergyMeter code, it would mean something like;

ServiceSelector ss = (ServiceSelector) servicemanager.lookup( "IOsystem" );
Channel ch = (Channel) ss.select( "virtual:///EnergySource" );
ch.addChannelListener( this );

But the hardcoded select() statement won't work if there are a lot of 
EnergyMeters present. That could be solved by involving the name of the 
EnergyMeter used in the Configuration.
Also, the ServiceSelector must have a configuration where it binds the 
available Channel instances to the requested virtual channel names.

To me it doesn't look "clean" IoC, as the client is very much involved in the 
"wiring", and in other (non-software) component domains, components have no 
clue of the wiring/connection process or what sits/connected to the other end 
of the connection/wire.

An alternative would be to let a separate ApplicationListener (BlockListener) 
do the wiring, which seems more IoC to me. BUT I can't find any way to 
configure the ApplicationListener and tell generic listeners how to wire the 
components.

Or another logical way to do it, is to create a EventWiringComponent (EWC), 
which is much smarter, that has a configuration of;

<wire>
  <event>Channel</event>
  <source>MySource3</source>
  <destination>MyDestination4</destination>
</wire>

which will basically locate the objects and with reflection do;
	mySource3.addChannelListener( myDestination4 );

There is a lookup problem with this approach. The .xinfo file of the EWC 
requires to have a dependency on ALL roles, which are not known at design 
time of the EWC, and would require modification of .xinfo at deploy time. 
This is not acceptable.

Finally, that leads me to think of implementing a whole new container, or 
extending Phoenix to have a better wiring system, which IMHO is a bit weak.

Are these issues handled better in Fortress or Merlin? (I have previously got 
the impression that they are more for "anonymous components", unlike my use.)

Any comments?

Niclas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message