Leo Sutic wrote:
[snip]
> The question is then: Given a ServiceResolver that provides a
> unified way of obtaining services irrespective of whether they are
> pooled or not, what use is there for ServiceManager?
Because an implementation of ServiceManager is not polluted with
operations against which it has not semantics. Specifically, all
operations defined under ServiceManager are well defined - no ambiguity.
ServiceResolver captures semantics of pooled services without ambiguity.
So the up-side is that the interfaces are cleaner and the object mode is
consistent. The down-side is that a lifecycle pipeline needs to be aware
of the additional ServiceResolver interface. For me the up-side
significantly outweighs the downside.
Here is consolidation of the interfaces based on a logical extrapolation
of the conclusions reached under this thread:
interface Serviceable
{
public void service( ServiceManager manager ) throws ServiceException;
}
interface ServiceManager
{
Object lookup( String role );
boolean hasService( String role );
}
interface ServiceSelector
{
Object select( Object policy );
boolean isSelectable( Object policy );
}
interface Resolvable extends Serviceable{};
interface ServiceResolver extends ServiceManager
{
Object lookup( String role, Object token );
void release( Object object );
void releaseAll( Object token );
}
interface PooledSelector extends ServiceSelector
{
Object select( Object token, Object policy );
}
Over to you.
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
