avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [A5] CM Use Cases from real requirements
Date Tue, 18 Jun 2002 09:49:48 GMT


Leo Sutic wrote:

>Stephen,
>
> 1) What will the CM interface look like? I think you just end 
>    up back where you started...
>  
>

I've been using the CM term relative to Avalon 4 ComponentManager,
or, Avalon 4 ServiceLocator or ServiceManager as a A4 migration
path.

>
> 2) what is the difference between ComponentRegistry and a 
>    ComponentSelector?
>

The important difference is the the ComponentRegistry is not part of the 
Avalon Framework, its just a service interface, possibly something that 
could live in Excalibur land.  The actual operations exposed by that 
interface could then be crafted to match the ECM/Cocoon/Fortress 
application space - e.g. it would extend from Component (to be backward 
compatible with CM), and it would contain a suite of lookup operations 
that leverage structured roles, hints, queries, whatever the 
ECM/Fortress/Cocoon community think is rational (i.e. minimise migration 
headaches).

> 3) Could you go through Berin's use cases and show how this
>    looks like from a component's point of view?
>

  Case 1:

     Supplying an interface name to lookup on CM - this is a query that
     should be resolved through a ComponentRegistry (and I know that's
     painful) - its the only way to seperate the concerns.

  Case 2:

     Optional CM lookup - no change from current practice - you would
     lookup the service you want on a ComponentRegistry in the same way
     you currently lookup the component on a CM.

  Case 4:

     Component that declare dependencies - this has come into ECM or
     Fortress scope sooner or later otherwise services with dependencies
     will never be usable in that scope.  In this context, a component in
     ECM/Fortress declaring a dependecy will lookup that service directly
     in the CM supplied to it.

  Case 5:

     Resolution of a selection of multiple services - for non-meta enabled
     components - the component implementation would supply constraints
     (role/hint/query/whatever) against a ComponentRegistry.  I the
     meta-enabled case, the container would do the resolution of a single
     selection and supply this directly to the CM.


>
>It's nice and all, but:
>
> + We *still* have that CM interface there... Since that is
>   all that the component will see, the ComponentRegistry/container
>   part is hidden.
>

Let's look at the impact - ECM based components (i.e. components that 
lookup a service by supply the arguments for interpritation by the 
container) continue to use ECM.  Components migrating from ECM to 
Fortress or Merlin should either:

   (a) get a reference to a ComponetRepository via the
       ComponentManager before invoking an interprited lookup
       on the ComponetRepository service
   
   (b) update the component to declare dependencies, in which
       case the usage pattern between component and CM would
       be direct (no intermidiate ComponetRepository stuff - the
       component would access the services directly via the CM)

 From the above migration path, current ECM components will 
progressively become more and more meta-enabled (declaration of services 
provider and dependecies).  This will result in broader applicability of 
these component.  For example, they will be usable in Merlin as services 
that higher level component can depend on.  Merlin components will be 
usable as providers of dependent services in the Cocoon world.

I think the number 1 biggest benefit is that it will result in the 
inevitable convergence of Fortress and Merlin and Phoenix - where we 
differentiate in terms of the type of component maangement problems but 
we share a standard framework for things like:

  - component type repositories
  - classloader management
  - jar extension library management
  - automated assembly graph creation
  - dynamic component type addition
  - policy management framework for type and instance selection
  - component and assembly instantiation and valdation
  - security policy management
  - auto documentation tools
 
Sound good?

Cheers, Steve.

>
>
>/LS
>
>  
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@osm.net] 
>>Sent: den 18 juni 2002 10:51
>>To: Avalon Developers List
>>Subject: Re: [A5] CM Use Cases from real requirements
>>
>>
>>
>>Which implies the following:
>>
>> |-----------------------------------|
>> | container                         |
>> |                                   |
>> |                                   |      creates   |-----------|
>> | creates and prepares components   | -------------> | component |
>> | using CM/SM which are private to  |                |           |
>> | the container and the component   |                |           |
>> | implementation                    |                |           |
>> |                                   |                |           |
>> |-----------------------------------|                |           |
>>    ^                                                 |           |
>>    | uses container to                               |           |
>>    | create new components                           |           |
>>    v                                                 |           |
>> |------------------------------------|     |-----|   |           |
>> | ComponentRegistry                  |---->| CM  |<--|           |
>> | Serves component requests          |     |-----|   |           |
>> |                                    |               |           |
>> |                                    |        query  |           |
>> |                                    | <------------ |           |
>> |                                    |               |           |
>> |                                    |       service |           |
>> |                                    |  -----------> |           |
>> |------------------------------------|               |-----------|
>>
>>
>>Stephen McConnell wrote:
>>
>>    
>>
>>>Vadim Gritsenko wrote:
>>>
>>>      
>>>
>>>>>From: Stephen McConnell [mailto:mcconnell@osm.net]
>>>>>  
>>>>>          
>>>>>
>>>><snip/>
>>>>
>>>> 
>>>>
>>>>        
>>>>
>>>>>In the context of Cocoon (which I don't know much about), 
>>>>>          
>>>>>
>>it appears 
>>    
>>
>>>>>that ECM is being used as an object repository.  A 
>>>>>          
>>>>>
>>sitemap processor 
>>    
>>
>>>>>is basically invoking lookup on ECM to get the pre-configured 
>>>>>components that it wants.  From all of the discussion so far, it 
>>>>>seems to me that ECM is serving these request out of the lookup 
>>>>>operation - and I think this is breaking the thinking 
>>>>>          
>>>>>
>>pattern - and 
>>    
>>
>>>>>potential solutions.
>>>>>
>>>>>Let me explain:
>>>>>
>>>>>Imagine we design a modern, clean container.  Imagine that the 
>>>>>lookup operations is *never* exposed to anything but a component 
>>>>>instance that has been instantiated by the container, and 
>>>>>          
>>>>>
>>to which 
>>    
>>
>>>>>the container has supplied a component manager. In this 
>>>>>          
>>>>>
>>situation, 
>>    
>>
>>>>>the component manager knows the classname of the component, know 
>>>>>lookup labels based on the components meta-info, knows 
>>>>>          
>>>>>
>>the service 
>>    
>>
>>>>>to include in the supplied manager, can basically take care of 
>>>>>everything to completely satisfy the component.  HOWEVER, 
>>>>>          
>>>>>
>>how does 
>>    
>>
>>>>>the container serve request for components to a client?
>>>>>  
>>>>>          
>>>>>
>>>>Stephen,
>>>>
>>>>Let me correct you a bit before somebody else does :)
>>>>
>>>>        
>>>>
>>>Given my knowledge of Cocoon and ECM - yep - I'm open to
>>>corrections:
>>>
>>>:-)
>>>
>>>      
>>>
>>>>Cocoon's sitemap processor *is* a component, managed by the 
>>>>container, and instantiated by container, and provided 
>>>>        
>>>>
>>with component 
>>    
>>
>>>>manager by container.
>>>> 
>>>>
>>>>        
>>>>
>>>Mechanically - yes - but the very fact that ECM does not deal with 
>>>dependencies means that component is responsible for component 
>>>selection via a query (as distinct from Merlin/Phoenix where the 
>>>container does the selection and handes the compoent only what it 
>>>needs).
>>>
>>>Problem is that the semantic that are assumed in ECM are that the
>>>component
>>>under composition is free to ask for any service - which 
>>>      
>>>
>>means that the
>>    
>>
>>>model of interaction is that the component being serviced 
>>>      
>>>
>>is acting as a
>>    
>>
>>>client towards a component registry.  In this model, restrictions to
>>>scalability are infurred by the expresssiness of the 
>>>      
>>>
>>repository lookup
>>    
>>
>>>interface (in ECM the ComponentManager interface is being 
>>>      
>>>
>>used as the
>>    
>>
>>>repository query interface).  This is the important distinction.
>>>
>>>Workarounds to this include the ComponentSelector - enabling the
>>>client to
>>>enter into a finer-grain of selection semantics. As the application
>>>complexity grows, debate on additional parameters on the 
>>>      
>>>
>>lookup operation
>>    
>>
>>>emerge as solutions to the problem.  In fact, the problem 
>>>      
>>>
>>is that the
>>    
>>
>>>manager is being used as a repository.  If we can figure a way of 
>>>breaking
>>>out of this usage pattern then life will become a lot easier.
>>>
>>>I sure the following will raise a torrent of objections, but its an 
>>>example of seperating concerns:
>>>
>>> 1. Component manager check component type it is instantiating
>>>    for its formal, contractual dependecies - if available, the
>>>    the manager provides only these service in the service
>>>    manager.
>>>
>>> 2. If the component implements composable/serviceable and no
>>>    dependecies are declared - we can assume (a) its a broken
>>>    component, or (b) its a component that is implicity
>>>    requesting a component repository service.
>>>
>>>    I.e. component composable imp:
>>>
>>>    public void lookup( String role )
>>>    {
>>>        ComponentRepository rep = (ComponentRepository)lookup(
>>>          ComponentRepository.ROLE );
>>>
>>>        final String role = Something.ROLE;                 Query 
>>>query = getQuery();
>>>        Object object = rep.query( role, query );
>>>    }
>>>
>>>Cheers, Steve.
>>>
>>>      
>>>
>>-- 
>>
>>Stephen J. McConnell
>>
>>OSM SARL
>>digital products for a global economy
>>mailto:mcconnell@osm.net
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>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>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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