commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hlshipli...@comcast.net>
Subject RE: [HiveMind] Separating service declarations from their implementations
Date Fri, 02 Apr 2004 18:24:58 GMT
You solution is pretty much what I've always envisioned.

The problem isn't the indirection ... its the *selection*. 

For example, perhaps you are creating a DAO system, and you have different implementations
based on
database type (oracle vs. db2 vs. postgres vs. mysql). 

I can imagine something like:

<contribution configuration-id="foo.DAOImplementations">
  <dao database="mysql" service-id="foo.MySQLDAO"/>
  <dao database="db2" service-id="foo.DB2DAO"/>
  (etc)
</contribution>

<contribution configuration-id="hivemind.ApplicationDefaults">
  <default symbol="foo.active-database" value="db2"/>
</contribution>

And of course, if different parts of the system use different databases, it gets more complicated.

Putting any specific solution into the framework creates a kind of lock that will be hard
to break
in the future. Providing a reasonably flexible solution in the standard library or (the forthcoming)
contributions library is a better approach ... the less in the core framework, the better.
The
HiveMind framework is supposed to be the bare minimum needed to construct more elaborate solutions
... the more that's in the framework itself, the more locked into a specific solution we become,
and
that's a trap to avoid!


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components 
http://howardlewisship.com


> -----Original Message-----
> From: Luke Blanshard [mailto:luke@blanshard.us] 
> Sent: Friday, April 02, 2004 11:06 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] Separating service declarations from 
> their implementations
> 
> 
> Hi all,
> 
>   I have what I assume to be a common desire: to define a 
> service in one
> module, and plug in one of several possible implementations in a
> different module.  Furthermore, I want to select the correct
> implementation at run time based on system properties or other
> externally specified configuration data.
> 
>   For example, I have a service that returns a list of 
> customers.  This
> service has 2 different implementations: an EJB-based one, and a local
> demo/debug version that reads from a file.  I want to declare the
> service in one module, and the implementations in another 
> module.  And I
> want to select the implementation (one of these two, or even 
> a third one
> written later provided by yet a third module) at run time.
> 
>   Here's how I've approached this.  I've created a service 
> factory that
> just returns a different service -- I call it 
> ServiceReferenceFactory. 
> So I declare my customer list service as being created by 
> this factory,
> and I pass in a variable reference as the name of the service 
> to return.
>  The hivemodule looks something like this:
> 
> <service-point id="Customers" interface="pkg.CustomersService">
>   <invoke-factory service-id="example.ServiceReferenceFactory">
>     <service-id="${customers-implementation}" />
>   </invoke-factory>
> </service-point>
> 
>   Then in the implementation module I provide a default definition for
> "customers-implementation" that has the id of one of the
> implementations.  And I arrange symbol sources so that I can override
> this default at runtime.
> 
> 
>   My question: Isn't this kind of overkill?  Since we already have the
> ability to separate service-point declarations from their
> implementations, wouldn't it be reasonable to build this kind of
> indirection right in to HiveMind's core?  Or am I missing 
> something, and
> we can already do what I want without this somewhat bogus 
> service factory?
> 
> Luke
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message