avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Wed, 04 Dec 2002 01:24:26 GMT


Adam Murdoch wrote:

>On Wed, 4 Dec 2002 04:50 am, Stephen McConnell wrote:
>
>  
>
>>About all I can draw out of the requestShutdown example is that there is
>>perhaps a need for some standard interface that can be provided by a
>>container to handle child request - and, that the container
>>implememntation still needs to know that the handler needs privaliged
>>(i.e. container sourced) information.
>>    
>>
>
>I don't think this follows at all.  All the requestShutdown example shows is 
>that some components need to use services provided by the container.  You 
>can't really draw any conclusions about how the component might get hold of 
>the service.
>
>This is the problem.  We all agree container-provided services are essential.  
>They must be made available to components.  But we're jumping straight to 
>*how*, without answering the basic question: Are container-provided services 
>*really* any different to the other types of services, from the component's 
>POV?  If the answer is no, then the *how* is already there:  Whack them in 
>ServiceManager.  Done.
>

Throwing them into the service manager isn't a problem - and yes - the 
component implementation should not know if something is from a 
container or a peer.   However - the container implementation, when 
building a the component that its going to put into the service manager 
- it needs to know if the component is requesting a privaliged service.  

Let me explain this a little more.

Take the example of the extensions mechanism in Merlin.  Here we have an 
example of a clear destinction between a classic component and a 
privaliged component.  The classic component is the component that is 
the target of extension - it does not know where the extension data is 
comming from - it just knows that it is going to be extended in 
accordance with the extension depedencies it declares.  The privaliged 
component is the extension handler - the handler is computationally part 
of the containment solution and as such it is implicitly a privaliged 
component.  

If we take the same concept and apply it to contextualization - and we 
want to extend contextualization in an open way, we need an equivalent 
container-side privaliged component - something like a standard 
ContextManager.  An implemetation of this could be a 
ShutdownRequestManager component - it it could potentially declare 
depedencies on standard services within the containerment system 
(service that are not normally available to classic components).  But to 
keep this open, this means the containerment API needs to be formal - 
exposing things like a StartupService, etc.

>  
>
>>But anyway - what I can draw from things at the moment is that there is
>>perhaps a meta model issue here.  At the meta model level we have the
>>notions of context criteria and service depedencies as different
>>abstractions and container map these respective notions into the SM/CM
>>and Context implemetations provided to the component.  Adam Murdoch is
>>persistently raising a bunch of good question that suggest that there
>>may be a more deeply rooted problem
>>    
>>
>
>Sorry for being such a broken record.  
>

Far from it - I think you getting to some very valid issues.

>Answer my question, and I'll go away.  
>Promise. (but only if you give the answer I want :)
>

My answer is that "classic" components should not be aware of where the 
service or data comes from.

:-)


>  
>
>>But if context/service seperation dissapeared I know I'm still missing
>>something important - and I think its about granulirity in lifecycle -
>>    
>>
>
>Can you expand on what exactly you feel is missing?  Is it just a vague 
>feeling that something is not right?  Or something more specific?
>  
>

I have real requireements context level differentiation.  I use in my 
day-to-day work the notion of component profile (component type + 
dependency spec + config). For any given profile I have cases of 
multiple deployed component instances, differentiated by the context 
that I'm providing them with.

Hope that helps.

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>


Mime
View raw message