commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Lindquist <jo...@kawoo.co.uk>
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 ...

thanks,

Johan


On Mon, 10 Nov 2003 15:01:46 +0000, <hlship@comcast.net> 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.
>
>
> --
> hlship@apache.org
>
> Creator, Tapestry: Java Web
> Components
> http://jakarta.apache.org/tapestry
>> 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>



-- 
you too?

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


Mime
View raw message