Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Mon, 10 Nov 2003 17:11:16 +0100
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [hivemind] Multiple implementations for the same service ...
References: <111020031501.349.32b2@comcast.net>
From: Johan Lindquist <johan@kawoo.co.uk>
Content-Type: text/plain; format=flowed; charset=iso-8859-15
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-ID: <opryfi821b5c7tcy@localhost>
In-Reply-To: <111020031501.349.32b2@comcast.net>
User-Agent: Opera7.20/Win32 M2 build 3144

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