Stephen McConnell wrote:
>
> Take a look at the JavaDoc for Appliance at the following URL and let
me know if it's understandable. Sorry - no pictures just yet. Maybe later.
>
> :-)
>
>
>
http://www.osm.net/doc/assembly/api/org/apache/avalon/assembly/appliance/DefaultAppliance.html
You are packing too much into each sentence. Simplify by building
knowledge one step at a time. The hardest thing for me to learn was
how to go back and bring my readers to where I was. The ASCII text
below will hopefully show what I mean:
--*-------------*------------->
Reader Me Where I want to go
^ ^
+------+------+
|
Gap that needs to be bridged first.
This is the general feeling. Break it down really simple.
From the JavaDoc mentioned:
>
> The DefaultAppliance class manages the establishment of a component
> type relative to a deployment criteria. Once established, an appliance
> provides support for the deployment of component instances on request.
> An appliance is responsible for component lifestyle and lifecycle
> management during the deployment and decommission cycles.
Immediate questions:
Deployment criteria? What is that? How do I control it?
Deployment of component instances is confusing.
From Merrium Webster (http://www.m-w.com):
One entry found for deploy.
Main Entry: de�ploy
Pronunciation: di-'ploi
Function: verb
Etymology: French d�ployer, literally, to unfold, from Old French
desploier, from des- dis- + ploier, plier to fold -- more at PLY
Date: 1786
transitive senses
1 a : to extend (a military unit) especially in width b : to place in
battle formation or appropriate positions
2 : to spread out, utilize, or arrange especially strategically
intransitive senses : to move in being deployed
- de�ploy�able /-&-b&l/ adjective
- de�ploy�ment /-m&nt/ noun
Definition 2 is the deployment we are speaking of. To me deployment
speaks more of assembly and the process of putting the *whole*
application into service. Deploying a component is the process of
putting it into service--more generally than what you are using it
for.
The last sentence makes no sense at all.
Lifestyle:
Main Entry: life�style
Pronunciation: 'lIf-'stI(&)l, -"stI(&)l
Function: noun
Date: 1939
: the typical way of life of an individual, group, or culture
I.e. in our terminology how the component lives inside the container.
Lifecycle :
Main Entry: life cycle
Function: noun
Date: 1873
1 : the series of stages in form and functional activity through which
an organism passes between successive recurrences of a specified primary
stage
2 : LIFE HISTORY 2
3 : a series of stages through which something (as an individual,
culture, or manufactured product) passes during its lifetime
I.e. how a component is instantiated and destroyed.
I tend to lean toward the appliance doing too much if it cannot be
easily explained. Your docs are saying that the appliance is
responsible for four functions:
Deployment (a container concern)
Decommissioning (a container concern)
Lifecycle
Lifestyle
Lifecycle is constant (or should be), so that can easily be handled
via a Factory like I did with Fortress. Lifestyle is consistent,
which means each lifestyle is handled the same way, like I did with
the ComponentHandler in Fortress.
Deployment and Decommissioning is something that the Fortress
container conserns itself with.
Deployment is the process by which the component is placed into the
list of usable components, the container assembles it or connects it
to other components that need to use it. The Lifecycle and Lifestyle
do not come into play here.
Decommissioning is the opposite process by which the component is
removed from the list of usable components, and the container
unassembles or deconnects it from other components that need to use
it. The process of decommissioning one component may have a waterfall
effect and force the decommissioning of other components.
> The implementation supports the association of possibly multiple
> appliance instances as service providers in accordance with component
> type dependency declarations during assembly. Once assembled, an
> appliance is capable of handling resolve and release requests.
> Components instances returned from the resolve method are guaranteed
> to be fully deployed. Client applications may subsequently release the
> acquired component back to the appliance when no longer needed. The
> appliance implementation will apply appropriate recovery policies
> based on the lifestyle policy associated with the component type.
>
Again, this is greek to me. Take knowledge that is built elsewhere
and use that. In the context of JavaDocs, use the @see tag to point
to where the different terms are originally defined.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
- [A4:Fortress/Merlin] Coming to grips with terminology Berin Loritsch
- Re: [A4:Fortress/Merlin] Coming to grips with term... Stephen McConnell
- Re: [A4:Fortress/Merlin] Coming to grips with ... Berin Loritsch
- Re: [A4:Fortress/Merlin] Coming to grips with term... Leo Simons
- Re: [A4:Fortress/Merlin] Coming to grips with ... Stephen McConnell
- Re: [A4:Fortress/Merlin] Coming to grips w... Stephen McConnell
- Re: [A4:Fortress/Merlin] Coming to gri... Berin Loritsch
- Re: [A4:Fortress/Merlin] Coming t... Nicola Ken Barozzi
- Re: [A4:Fortress/Merlin] Coming to gri... Leo Simons
- RE: [A4:Fortress/Merlin] Coming t... Leo Sutic
- Re: [A4:Fortress/Merlin] Comi... Leo Simons
- Re: [A4:Fortress/Merlin] Coming t... Ulrich Mayring
- Re: [A4:Fortress/Merlin] Comi... Leo Simons
