hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Wannheden <knut.wannhe...@gmail.com>
Subject Re: Few interfaces with a lot of implementation
Date Wed, 18 May 2005 13:59:38 GMT
Massimo,

On 5/18/05, Massimo Lusetti <mlusetti@gmail.com> wrote:
> On 5/18/05, Knut Wannheden <knut.wannheden@gmail.com> 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?

I'm afraid I don't quite understand what you mean by first and second
"kind of data bits". If you'd like more than one of your
implementations to somehow react to a call of a service method you
should investigate the hivemind.lib.ChainFactory and
hivemind.lib.PipelineFactory service implementation factories. See
online docs and
http://howardlewisship.com/blog/2004/06/new-in-hivemind-pipelineservice.html
and http://howardlewisship.com/blog/2005/01/hivemind-in-chains.html.

> Isn't true that i need to declare all the possible
> services/implementation within every hivemodule.xml ?
> 

Well you certainly only need to declare every one of the possible
combinations in one hivemodule.xml. But you're free to spread the
declarations across multiple hivemodule.xml files. If you can use
StrategyFactory, ChainFactory, or PipelineFactory then you might end
up with far less services or at least many private services.

--knut

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org


Mime
View raw message