avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schier <MSch...@infogation.com>
Subject RE: [VOTE] RE: ComponentManager interface
Date Thu, 14 Feb 2002 23:58:51 GMT
I've been following this discussion for quite a while now and this is my
first comment to this mailing list.
This is great and I would like to see it implemented, cause it's exactly
what I would need to continue working with Avalon!

Thanks so much.


-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@osm.net]
Sent: Thursday, February 14, 2002 3:34 PM
To: Avalon Developers List
Subject: RE: [VOTE] RE: ComponentManager interface

I've been through all of the email on this subject in detail and 
carried out a useful exercise.  I basically combined all of the 
ideas that have been circulating into one big interface. The 
result of the combination was a rather unwieldy set of lookup, 
query and release operations. I then tried to apply some 
rationalisation.  The result of a rationalisation is three 
distinct interfaces (a) a simple service lookup facility, (b) a
simple selection facility, and (c) a simple pool facility.

  interface ServiceManager
      Object lookup( String role );
      boolean hasService( String role );

The ServiceSelector interface handles isolation of the case where 
supplementary policy is needed.  Instead of escalating the number 
of lookup arguments on ServiceManager, I'm taking the approach that
a ServiceSelector is returned from a ServiceManager.  While I realise 
that this is equivalent to lookup( role, policy ), I think this better 
clarifies behaviour of ServiceManager by isolation of the abstract 
policy argument (policy is forced down to implementation enabling 
sophisticated service selection/generation/deployment alternatives).

  interface ServiceSelector
      Object select( Object policy );
      boolean isSelectable( Object policy );

The ServicePool interface captures the discussion concerning 
referenced objects.  It is modelled on the assumption that a 
ServicePool instance is located via a ServiceManager, therefore, 
the pool is dealing with a particular type of pooled object.
Semantics of the interface are that objects that are 
"checked-out" must be returned to the pool either individually
or collectively via reference to a token.  The criteria argument
on "checkout" is provides as a means by which implementation may
introduce more sophisticated behaviour without being constrained by 
the interface.

  interface ServicePool
      Object checkout( Object token );
      Object checkout( Object token, Object criteria );
      void release( Object object );
      void releaseAll( Object token );

At a usage level service selection becomes simple, unambiguous and 
maintains the loose binding advantage.  There is no policy or criteria
so reuse of the ServiceManager is not jeopardised.

     MyService service = (MyService) manager.lookup( "MY-ROLE" );

Service selection deals with the case of selection of multiple instances 
of a particular service type, qualified by a policy argument. Expressing
policy as an Object means that this interface is abstract so again, 
isolation from ServiceManager is a good thing.

     ServiceSelector selector = (ServiceSelector ) 
       manager.lookup( "MY-SELECTOR" );
     MyService variant = selector.select("MY-HINT");

I'm making the assumption here that pooling implementations will 
typically deal with a single type of object. I.e. you will get a 
pool for a particular type from a service manager and apply checkout
and release operations against the returned pool.

     ServicePool pool = (ServicePool) manager.lookup( "MY-POOL" );     
     MyService service = pool.checkout( this );
     MyService service = pool.checkout( this, myCriteria ); // alternative
     pool.release( service );
     pool.releaseAll( this ); // alternative

Benefits of the above are a clear separation of concerns between 
service location, service selection, and service pooling. The direct 
result is that all facilities become unambiguous. 

Thoughts ?

Stephen J. McConnell, OSM sarl
digital products for a global economy

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

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

View raw message