Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 7836 invoked from network); 18 Jun 2002 09:53:52 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Jun 2002 09:53:52 -0000 Received: (qmail 29513 invoked by uid 97); 18 Jun 2002 09:54:07 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 29495 invoked by uid 97); 18 Jun 2002 09:54:07 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 29483 invoked by uid 98); 18 Jun 2002 09:54:06 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D0F023C.5080505@osm.net> Date: Tue, 18 Jun 2002 11:49:48 +0200 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: [A5] CM Use Cases from real requirements References: <000a01c216a6$34cd7ee0$0801a8c0@Lagrange> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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] >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>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: >> unsubscribe@jakarta.apache.org> >>For >>additional commands, >>e-mail: >> >> >> >> > > >-- >To unsubscribe, e-mail: >For additional commands, e-mail: > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: