David Bernard wrote:
Hi,
But sometime component don't know at configuration time which components are needed. In my case I know the type of needed component but not which instances, depends of input request. Dataflow, pipeline, seda,... architecture doesn't predicate at configuration time all dependencies.
It's right (in my case) I could define all potential needed component at configuration time, but when I code, I don't know the number of intances (of a type) needed.
It's why I think react is better. An other aspect is what's append with Merlin, if needed components are remote, ala Jini?
This is a fundimental question concerning the specification of ServiceManager and the associated semantics. The interpritation of ServiceManager semantics in Merlin and Phoenix is to provide services relative to declared dependencies. The Fortress/ECM approach is to use the ServiceManager as service discovery service. These two semantic assumptions are completely different. In the Phoenix/Merlin world, what your describing is a dependency on a dynamic discovery service - so what you should do is declaring a dependency on such a service.
The important aspects to consider here is:
* Should a container be resoponsible for dynamic service discovery as part of the core container contract?
* If yes then we need to declare this assumption in the component meta info so that a container can recognize that the assumption exists and do what it has to do to provide support for this.
* And if support means doing something under the ServiceManager interface, we need open up a discussion about getting in place a usable specification of selector (because the current spec is insufficient).
Stephen.
R.
IOC
The objective is that the container supplies everything the component needs. To do this, the component needs to declare this. The big diference between Merlin/Phoenix verus Fortress/ECM is that the first group know in advance of component instantiation what the solution is wheras the Fortress/ECM is reacting to noise from the component. Ok - maybe that's a dramatic way of looking at it - but there are big advantages in knowing about component dependencies before instantiation:
* build time validation of deployment scenarios
* substantially reduced risk of runtime exceptions
* ability to resolve a provider in advance from a set of candidates and selection policy
* ability to control orderly deployment and decommissioning
Stephen.
Regards, Vjeran
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
