avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Son of ComponentManager
Date Sun, 17 Feb 2002 16:07:47 GMT


> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Leo Sutic wrote:
> >
> > > From: Stephen McConnell [mailto:mcconnell@apache.org]
> > >
> > > 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.

Two cases:

 1) Allow the client to release multiple components with a single call.
    In this case you need a token. The ServiceResolver maps tokens ->
    sets of components, and when you do a release(token), it releases
    all components mapped to that token.

 2) Only allow release of a single component at a time. No token is needed.
    The object obtained in lookup() is used in the call to release().

So, yes, poolable services are resolvable without a token. But then
you can not do a releaseAll or equivalent.

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

So for me this is workable:

   interface ServiceResolver extends ServiceManager
   {
      void release( Object object );
   }

This interface:

   interface ServiceResolver extends ServiceManager
   {
      Object lookup (String role, Object token );
      void release( Object object );
   }

is workable, provided that:

  void release( Object object ) is defined as follows:

  void release( Object object ) {
    if (object is a token that was passed to lookup(role, token))
    {
      release all services obtained with this token
    }
    else // In this case, object is a service obtained via lookup(role) or
lookup(role, token)
    {
      release just this service. If a token maps to this service,
      remove the service from the token.
    }
  }

But I would want:

   interface ServiceResolver extends ServiceManager
   {
      Object lookup (String role, Object token );
      void release( Object object );
      void releaseAll( Object token );
   }

So you have lookup(role)/release(object) and
lookup(role,token)/releaseAll(token).

> If it
> is, the Resolvable/ServiceResolver as described above is workable.  Can
> you confirm ?

Confirmed (sorta) above.

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?

/LS


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message