You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apps-dev@avalon.apache.org by Adam Murdoch <ad...@apache.org> on 2002/12/03 11:16:34 UTC
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
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.
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.
--
Adam
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Posted by Stephen McConnell <mc...@apache.org>.
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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>