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 06:48:47 GMT

Adam Murdoch wrote:

>On Wed, 4 Dec 2002 11:24 am, Stephen McConnell wrote:
>>>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.
>Of course.  But that's the container's problem, right?  So long as the 
>container gives the privileged service to the privileged component when it 
>asks for it, and refuses to hand over the privileged service to a 
>non-privileged component, then everyone's happy.  There's nothing that needs 
>to be added to framework to allow a container to do this: it's 
>container-specific behaviour, driven (presumably) by container-specific 
>assembly info.

Actually in the case of extensions - we defined specific interfaces and 
meta to facilitate the explicit declaration by a component implemetation 
that it is providing a privialiged function (in this case, handling a 
lifecycle extension).  Those interfaces and associated meta enable a 
container to select candidates within the containment context as 
distinct from the componet deployment context.

>The whole issue of access control of services might be a good thing to 
>formalise and add to framework, at some point.  But definitely out-of-scope 
>for a 'what is a context?' discussion.

Yes - I agree (when we are looking at the question from the 
implemetation of a component that it the recipient of context).
No - when we are looking at a component that is a candidae provider of 

>>If we take the same concept and apply it to contextualization - and we
>>want to extend contextualization in an open way
>Not sure what you mean here.  Are you talking about some way for a component 
>to contribute resources to another component?

Imagine you declare a component that needs to be contextualized and 
somewhere is states that this is to be provided as a context that can be 
narrow to VoteContext.  Image also that your container has no idea of 
what a VoteContext is.  In effect, a container can interprit this as a 
criteria expressed by the target component for the deployment of a 
context provider component that provides context consistent with the 
VoteContext criteria.  So at some point the container starts hunting 
around in the component types it knows about that (a) is a context 
provider, and (b) provides support for the VoiteContext criteria.  On 
locating such a beast, the container can apply classic deployment of the 
provider and bundle it within a context object implemetation.  When the 
clinet request the voting context, the context implementation just 
delegates the request off to the context provider.

Alors... portable context!

>>>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.
>Ok, good.  So why do "non-classic" components (whatever they are) care?

They (as implementions) don;t care - but the container needs extra info 
to these "non-classic" providers. E.g.:

*  lifecycle extension handler
* context provider

>And the second part of the question:  Do components care whether data and 
>services are delivered together, or separately?  Why?

Because it feels right.


>>>>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.
>Not sure what you mean.  Can you give some example (pseudo-) code?  I'm 
>interested in the contextualize() and service() methods of these components.

Consider the following:

  component type: net.osm.vault.DefaultVault

  deployment profile: vault

     includes the Vault type plus persistence service
     configration info and general vault configuration
  appliance: CA vault

     component profile "vault" supplied with a CA cert-chain
     under context

  appliance: RA vault

     component profile "vault" supplied with a RA cert-chain
     under context

In the case of CA vault and RA vault, the service model is the same - 
the context model is different.  There is no magic in the serviceable or 
contextualizable implemetation - the magic is the container 
configuration which knows about container abstractions of type, profile, 
and appliance.

Cheers, Steve.


Stephen J. McConnell

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>

View raw message