Leo Sutic wrote:
>
> > From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
> >
> > Based on the ServiceManager/ServicePool interfaces as presented
> > in 06099, I think you would need a higher level abstraction that
> > aggregates the two concerns. For example:
> >
> > interface ServiceResolver extends ServiceManager, ServicePool {}
> > interface Resolvable extends Serviceable
> > {
> > public void resolve( ServiceResolver resolver );
> > }
I've made a mistake here concerning inheritance of ServicePool.
ServicePool parameters assume the role is already established
so my suggestion is invalid unless pool interfaces included the
role argument. A corrected spec of ServiceResolver in included
below.
> I still have one issue with this: ServicePool uses "checkout" while
> ServiceManager uses "lookup", leading to different code and semantics
> for poolable/non-poolable components.
>
> However, if:
>
> interface ServiceResolver {
> Object lookup (String role);
> void release (Object service);
> }
>
> in order to get the same code/semantics for poolable/non-poolable
> components, then we're back to the old CM interface.
>
> How would you solve this?
This suggests that poolable services are resolvable without a token.
I really need you guys to clarify this for me because according to
all of the discussions so far, you would need something like:
interface ServiceResolver extends ServiceManager
{
Object lookup (String role, Object token );
void release( Object object );
}
The above interface explicitly assumes that lookup( String role ) is a
valid and semantically relevant operation for poolable services. If it
is, the Resolvable/ServiceResolver as described above is workable. Can
you confirm ?
Cheers, Steve.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
