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:[EMAIL PROTECTED]]
>>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:[EMAIL PROTECTED]]
>>>>>
>>>>>
>>>>>
>>>><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:[EMAIL PROTECTED]
>>http://www.osm.net
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>><mailto:avalon-dev-> [EMAIL PROTECTED]>
>>For
>>additional commands,
>>e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
