Stephen,
I think this proposal is on a downward spiral.
The proliferation of interfaces is one indicator - we are moving
towards a very find-grained interface with many opportunities
for making mistakes instead of a simple interface.
I was about to ask you how you would handle the selection among
several components for a role where some components are thread-safe
and some poolable: Do you pool the selectors or do you select among
several maybe-pools? But the ServiceChooser interface does that,
albeit in a very ugly way (pools everything).
Now you have:
- ServiceResolver
- ServiceManager
- ConvinienceServiceResolver
- ConvinienceServiceManager
- ServiceReclaimer
- etc...
Plus the lifestyle interfaces for the above.
So you have four ways of obtaining components, some of which require
the calling code to be aware of implementation details such as
poolable/non-poolable.
This is just way too much.
My proposal is:
interface ServiceManager {
public Object lookup (String role);
public Object lookup (String role, Object policy);
public void release (Object component);
}
interface ServiceSelector {
public Object select (Object policy);
}
interface ServiceHandler {
public Object lookup ();
public Object release ();
}
Does everything you need:
ServiceManager:
public Object lookup (String role);
Looks up a role.
public Object lookup (String role, Object policy);
Looks up a role, and gives the policy object to the selector if any.
public void release (Object component);
Releases the component, no matter how it was obtained.
ServiceSelector:
Intended to be implemented by the client, to provide
selection policies for components. The selector
selects among several ServiceHandlers and calls lookup()
on the selected one.
ServiceHandler:
Handles lifecycle management for a service instance/instances.
Most ServiceHandlers will do this based on Avalon marker interfaces -
the default implementation will honor all such interfaces in framework.
However, should a component require a specialized handler, this
can be overridden in the configuration to the SM.
So the lookup is:
ServiceManager ---- Picks among several, based on role ----> Selectors
*or* Handlers
(optional step) Selector ---- selects among several,
based on policy ----> Handlers
Handlers manage lifecycle/lifestyle.
And yes, you will have empty methods. There is no way getting around it.
Gains:
- Unified way of obtaining services, irrespective of poolable/threadsafe.
- Unified way to do N-dimensional lookups (Selection)
- Accomodates components that do not have Avalon lifecycle interfaces via
custom handlers.
- Few interfaces with few methods.
- Easily understood contracts.
- Predictable results.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
