[Phoenix] Design issue about wiring

[Niclas Hedhman <ni...@hedhman.org>]

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

Re: [Phoenix] Design issue about wiring

[pe...@realityforge.org]

Let me see if I have this correct. You have N event sources
that get wired to N listener. The wiring is done by the
deployer. There is generally 3 ways to do it in the latest Phoenix
source.

1. Get each listener to depend on an array of sources. This
means postfixing the dependency with "[]" and then wiring
multiple instances in assembly.xml something like

/**
 * @phoenix.dependency type="com.biz.Source[]"
 */
public void service( ServiceManager sm )
{
   _sources = (Source[])sm.lookup( Source[].class.getName() );
}

2. Use a listener to collect all the blocks that implement
the Source interface and then register them with the listeners
in applicationStarted() method.

3. Use linking components. These components have one dependency
on listener and one on source.

(3) is the most flexible as you can easily add metadata to the registration
but it is also the hardest for the deployer as they have to register every
source-listener.

(1) is the easiest to code but it is still fairly hard for the deployer as
they
have to to register every source-listener - though less work than (3).

(2) is easy to code and easy for the deployer as long as the registration
is relatively standard and no need to do too much custom registration it
is probably the easiest.



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