Adam Murdoch wrote:
On Tue, 3 Dec 2002 04:05 pm, Stephen McConnell wrote:
> Does the component *really* care whether a particular
> resource is provided by the container or not provided
> by the container? Is this an artificial distinction?
> Why is it useful to the component writer to split them?
So lets explore something like a shutdown service. Presumably a sutdown
service does something along the lines of shutting down a component.
Which component? Should the component instance be part of the argument
to the service ? No. That will be problematic. In effect, we have a
"context" - what the component actually wanted was "give me a handle to
the thing that started me up so that I can tell it that I'm done".
Or, arguably, "give me the thing that I can tell that I'm done". I don't think the component cares either way about the "handle to the thing that started me up".
That
request is not a peer request - it's a container request - and that is
the distinguishing feature here - it's that fact that the component is
responding to a stimulus - the stimulus is the startup service.
There's no question that some resources will almost always be provided by the container. A shutdown service is a perfect example. But why is it useful to expose this fact to the component? Does it care that a shutdown service is provided by the container? I don't believe so. All it cares about is that it is provided with a resource it can notify when it is finished doing whatever it does.
I agree (very strongly) with you that the component should not care where the service comes from.
Assume that the framework will include some way for the container to deliver arbitrary services to a component, and some cross-container way for the component to describe the services it is expecting. Given this, is there any *real* benefit to the component writer, of adding a second mechanism for describing and delivering arbitrary container-provided services to the component? Will the component writer have to write more code, or less code? Write more meta-data or less meta-data? Will the component be more portable, or less portable? Is there more documentation to read? More abstractions to figure out?
Of course, a shutdown service might not actually be such a good example. A case could certainly be made that component shutdown should be dealt with as part of the Startable lifecycle thing (phase? step? stage? what's the correct terminology?). For example, Startable.start() could take as a parameter the resource that the component may use to request that it be stopped.
There is a long thread in the archives on stage/phase. Based on the conclusions reached there ... a phase is something container one or more stages. A component lifecycle goes though two phases - startup and shutdown. A startup phase is composed of a series of stages (logging, contextualization, initialization etc.). A particular stage can be viewed as a phase - e.g. Initialization appears as a stage in a startup phase, but initialization my be implemented as a phase covering extension handler deployment following by final initialization (two distinct sub-stages).
Now that made things totally clear didn't it ;-)
Anyway back to the topic.
The requestShutdown is probably a bad example because it is something that is directly linked to the service that is managing the lifecycle of a component. That's complicating the general issue of context management.
Instead - if both the Serviceable/Composable model is reconsidered as something capable of providing services and data objects from a containers computational perspective - we can shift focus to "what is it that the component writer wants" and look at context service seperation based on a needs as oppposed to container implemetation perspective.
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]>
