commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Huegen <ahue...@gmx-topmail.de>
Subject Re: [HiveMind] Separating service declarations from their implementations
Date Mon, 05 Apr 2004 19:55:43 GMT

> You solution is pretty much what I've always envisioned.
>
> The problem isn't the indirection ... its the *selection*.
>
...
> 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!

I regard switching of services as a very important feature which shouldn't
be completely moved to the contributions library. I fear that without 
direct
support in the core, it could be very expensive to setup in terms of
needed configurations, factories etc.
So I would suggest that the core libary at least "acknowledges" that there
is the need to switch between different implementations, but the selection
mechanism is left to the user.
For example we could allow the definition of multiple implementations of
a service :

	<service-point id="Simple" 
interface="hivemind.test.services.SimpleService">
	</service-point>

	<implementation service-id="Simple" id="impl1" >
	  <create-instance 
class="hivemind.test.services.impl.SimpleServiceImpl1"/>
	</implementation>

	<implementation service-id="Simple" id="impl2" >
	  <create-instance 
class="hivemind.test.services.impl.SimpleServiceImpl2"/>
	</implementation>

The first time this service is used, a special service broker (you already 
mentioned
this one in a previous mail) is used for selecting the right 
implementation.
The default (core) implementation of the broker could just raise an 
exception, or
select the first implementation found. This is the current behaviour in 
this case.
If there is a well defined interface for changing the implementation of the
service broker itself, the user could choose from different selection 
strategies
that are available in the contribution library. Properties, configuration 
or environment variable, choose whatever you want and configure it at a 
central location for all
of your services.

This solution is not too specific but eases things a lot.

Achim Huegen









---------------------------------------------------------------------
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