commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Lindquist <>
Subject Re: [hivemind] Multiple implementations for the same service ...
Date Mon, 10 Nov 2003 16:11:16 GMT
My thoughts exactly - previously been using the "selector" model of avalon 
which does just that.

One issue is that the implementation is bound to a different service point 
- so the implementor of the service has to define a *well-known* name 
rather than simply contribute an implementation to a service point.

Not sure if I am thinking in circles here or not, but allowing several 
implementation contributions would be a nice to have as the implementor 
does not have to bind to a different service point (and module) and the 
proxy provide the selector functionality if more than one service is 
availabe ...



On Mon, 10 Nov 2003 15:01:46 +0000, <> wrote:

> My thinking on this is that you have several different *services* 
> sharing the same service interface.
> In addition, there's a "lookup" service also implementing the service 
> interface.
> The service impl builder for the lookup service will find the correct 
> service and return that, rather than constructing an actual new service.
> My thoughts on this were related to different DAO implementations.
> Let's say we want a DAO for Orders.  We have an interface, foo.OrdersDAO 
> that defines read(), write() and update() methods (etc.).
> Service foo.OracleOrdersDAO implements OrdersDAO for Oracle.
> Service foo.MySQLOrdersDAO implements OrdersDAO for MySQL.
> Configuration foo.OrdersDAO will have two contributions; one will say 
> "for Oracle use foo.OracleOrdersDAO", the other will say "for MySQL use 
> foo.MySQLOrdersDAO".
> Service foo.OrdersDAO's builder will read the foo.OrdersDAO 
> configuration, combine it with some other piece of configuration data 
> ("are we using Oracle or MySQL") and choose and return the correct 
> implementation.
> User code (from outside HiveMind, or other services within HiveMind) 
> will just connect to the foo.OrdersDAO with no care to the fact that the 
> work is really being done by OracleOrdersDAO or MySQLOrdersDAO.
> Of course, this solution is just a starting point; you could have the 
> foo.OrdersDAO implementation be a kind of proxy that *dynamically* 
> chooses the correct implementation to re-route to.
> --
> Creator, Tapestry: Java Web
> Components
>> Trying to construct a service that has many implementations but use the
>> same interface.  I can do this by putting them into different modules, 
>> but
>> that require the service points to be defined for each one of the
>> implementations.
>> Ideally it would be nice to have one service point with several
>> implementations to that service point, allowing users to select the
>> correct implementation depending on some defined (meta) information (a 
>> la
>> avalon).
>> Are there any plans of allowing this?  could this be considered a
>> different service model?
>> Thanks,
>> johan
>> --
>> you too?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

you too?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message