avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antti Koivunen <anryo...@users.sourceforge.net>
Subject Re: [VOTE] RE: ComponentManager interface
Date Fri, 15 Feb 2002 03:43:32 GMT
Good work, Steve!

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.

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.

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

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

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?

(: A ;)

-- 
Antti Koivunen | "Anrie" [un-ree] <anryoshi@users.sf.net>
---------------------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------------------



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