avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: [VOTE] RE: ComponentManager interface
Date Fri, 15 Feb 2002 04:42:12 GMT


> -----Original Message-----
> From: Antti Koivunen [mailto:anryoshi@users.sourceforge.net]
> Sent: Friday, 15 February, 2002 04:44
> To: Avalon Developers List
> Subject: Re: [VOTE] RE: ComponentManager interface
>
>
> Good work, Steve!

Thanks!

> I really appreciate the good SOC on the service management side, but I
> think we should perhaps pay more attention to the concerns of the client
> using the ServiceManager.

It was a issue always with me during the reconstruction process - so just
to let you know I'm sensitive to you interests!

> Stephen McConnell wrote:
> >
> >   interface ServiceManager
> >   {
> >       Object lookup( String role );
> >       boolean hasService( String role );
> >   }
> >
> >   interface ServiceSelector
> >   {
> >       Object select( Object policy );
> >       boolean isSelectable( Object policy );
> >   }
>
> ServiceSelector is a good idea, but using it this way would require one
> extra operation from the client. I'd rather have:
>
>    interface ServiceManager
>    {
>        Object lookup( String role );
>        Object lookup( String role, Object policy );
>        boolean hasService( String role );
>        boolean hasService( String role, Object policy );
>    }
>
> Eliminating the intermediate ServiceSelector lookup would be more
> convenient for the client and also allow potentially more efficient
> implementations. I would then have a ServiceManager implementation that
> supports ServiceSelectors:
>
>    void addService( String role, ServiceSelector selector );
>
> This approach would retain the advantages of ServiceSelectors while
> keeping things easy for the client.
>

I thought long and hard about the issues you have raised above.  My
decision to separate was driven on the grounds that an implementation
can easily apply these patterns and default implementation.  For example,
in your case above .. it easy to define what you need by doing something
like the following (ignoring exception management):

    interface ServiceResolver extends ServiceManager
    {
        Object lookup( String role, Object policy );
        boolean hasService( String role, Object policy );
    }

    public class DefaultServiceResolver extends DefaultServiceManager
    {
        Object lookup( String role, Object policy )
        {
            ((ServiceSelector)super.lookup( role )).select( policy );
        }

        boolean hasService( String role, Object policy )
        {
            ((ServiceSelector)super.lookup( role )).hasService( policy );
        }
    }

The issue is - should there exist something like ServiceResolver and
DefaultServiceResolver in the framework, or should that placed in the
"not-my-problem" basket (meaning your/my basket)?  My conclusion is
that its a matter of prioritisation - before thinking about client
convenience we should agree on a mode that does demonstrate and
deliver good SOC.  Given that, the introduction of things like a
ServiceResolver become a bunch easier to deal with.

> >   interface ServicePool
> >   {
> >       Object checkout( Object token );
> >       Object checkout( Object token, Object criteria );
> >       void release( Object object );
> >       void releaseAll( Object token );
> >   }
>
> You have nicely encapsulated the issue of "checkout/release", as it
> clearly is a separate concern. However, it shouldn't be a concern of the
> client. IMO, the client should be able to access different services in a
> consistent way and not worry about whether certain instance is actually
> pooled. This approach would require changes in the client code, when you
> switch to a poolable service implementation.

I'm not convinced that it isn't a client concern.  The contract between
the client and the provider of the service is that it is the clients
responsibility to check something back in.  Ok, I understand that it is more
convenient in a highly pooled environment for arbitrary release - but I
don't find this a convincing argument in terms of the functionality of the
framework.  The reason why is that if you declare release on ServiceManager,
you are implying that an implementation may support this (a generally
speaking "may" is a very bad word).

> As a separate issue, can someone show me a clean implementation of the
> ServicePool interface, where the checkout operation doesn't include an
> object instantiation. (One way to achieve this would be to use a
> separate Token class, as suggested by Berin.)

Can't help you here.

> Now, for the reasons mentioned above, I believe we have to include the
> "checkout/release" functionality in the ServiceManager interface. Here
> are a few suggestions that (attempt to) address all the issues:
>
>    interface ServiceManager
>    {
>        boolean hasService( String role );
>        boolean hasService( String role, Object policy );
>
>        Object lookup( String role );
>        Object lookup( String role, Object policy );
>
>        void release( Object service );
>    }
>
> or --------------------------------------------------------
>
>    interface ServiceManager
>    {
>        boolean hasService( String role );
>        boolean hasService( String role, Object policy );
>
>        Object lookup( Token token, String role );
>        Object lookup( Token token, String role, Object policy );
>
>        void release( Token token );
>    }
>
>    final class Token { /* To be defined */ }
>
> or --------------------------------------------------------
>
>    interface ServiceManager
>    {
>        boolean hasService( String role );
>        boolean hasService( String role, Object policy );
>
>        Token lookup( String role );
>        Token lookup( String role, Object policy );
>
>        Token lookup( String[] roles );
>        Token lookup( String[] roles, Object[] policies );
>    }
>
>    interface Token
>    {
>        Object nextReference(); // easier to use and optimize
>                                // than Object[] references();
>        void release();
>    }
>
>
> What do you think? Any favorites/suggestions?

No favourites!  What you have above is real close to the consideration
interface I cam up with before posting the rationalisation email. I'm
warm towards the potential introduction of a ServiceResolver in the
interest of client side convenience BUT only after the core elements
are agreed and committed. I'm quite cold on the soft remove method.
I think that it is not too onerous for code to be aware of the
checkout versus lookup policy applicable and take care of this
explicitly.

Cheers, Steve.



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