On 5/18/05, Knut Wannheden <[EMAIL PROTECTED]> wrote: > 1. If you at registry construction time already know which of the 40 > implementations is the "correct" one for a given service then you > could actually encode this knowledge into the module descriptors, in > which case you would end up with 10 services instead of 400 (of which > 390 would be unused). > > 2. If you on the other hand have to be able to let client code at > runtime chose which of th 40 implementations to use then you indeed > have to create 40 distinct services. This is because a HiveMind > service can at runtime only have one implementation.
I can decide which implementation to use only when data (with the corresponding meta-data) comes in the application flow, i read it and then I'm able to decide which implementation i need, so i think i could go with 2. > 3. If your service itself can at runtime decide (let's say based upon > argument values passed to the invoked service method and environment > settings) which of the 40 implementations to use then you have the > possibility to create a "dispatch implementation". You'd again end up > with a total of 10 services. In version 1.1 of hivemind-lib there is a > service factory that helps here: hivemind.lib.StrategyFactory. See > http://jakarta.apache.org/hivemind/hivemind-lib/StrategyFactory.html > and > http://howardlewisship.com/blog/2004/11/hivemind-adapterregistryfactory.html. I've to investigate this more as it seems quite interesting, but one question comes: How this work if the first kind of data bits are for service-a/implementation-a then the second kind of data bits are for service-a/implementation-b, since this could happen very frequently? Isn't true that i need to declare all the possible services/implementation within every hivemodule.xml ? Ciao -- Massimo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
