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:[EMAIL PROTECTED] http://www.osm.net
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
