Re: Context: usage recommendations? ( Re: [SUMMARY] Context )

[Stephen McConnell]

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

 

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