avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [A4:Fortress/Merlin] Coming to grips with terminology
Date Tue, 28 Jan 2003 14:26:44 GMT
Stephen McConnell wrote:

 >
 > Berin Loritsch wrote:
 >
 >> The Merlin project adds two more terms and overloads the meaning of a
 >> third:
 >>
 >> Container (overloaded meaning), Block, and Appliance
 >
 >
 >
 >
 > I disagree on the "overloaded" - see below.
 >
 > :-)


The description I had of what I understood came from "overhearing" your
conversations with others on the list.

 >> In essence my understanding is that Merlin places the distinction
 >> between the container which only manages the component implementation
 >> mappings (or assembly), and the appliance which only manages the
 >> component instances.  I am not sure exactly what the block is.
 >
 >
 >
 > I'm completely ok with the above definition.  Relative to what exists 
in Avalon I would class Fortress, Merlin and Phoenix as containers.  The 
all share the common characteristic of managing component instances.


So the "appliance" is merely an internal construct to a container?

 > Looking inside-out:
 >
 >  The Fortress DefaultContainer provides the developer with access
 >  to ComponentHandlers.  This is sort of parallel with the Merlin
 >  DefaultContainer in that an implementation can access Appliance
 >  instances.
 >
 >  In Fortress / ComponentHander
 >
 >      Object get();
 >      void put( Object object );
 >
 >  In Assembly / Appliance
 >
 >      Object resolve( Object partition);
 >      void release( Object object, Object partition );


Ok.

 >  In Fortress a component handler is dedicated to a particular
 >  lifestyle whereas the Appliance class encapsulates a lifestyle
 >  handler based on meta data.  The Fortress component manager
 >  uses a factory object that implements the classic Avalon
 >  lifecycle stages.  Appliance lifecycle management is a little
 >  different in that the component type can declare alternative
 >  lifecycle strategies (i.e. non-Avalon approaches).  Another
 >  important difference is that the Appliance pre-builds context
 >  and service managers based on (a) dependencies declared in meta
 >  information, using (b) a repository of appliance instances when
 >  populating service mangers and context instances.  Both Fortress
 >  and Merlin use the respective ComponentHandler/Appliance
 >  instances within a service manager (enabling activation on
 >  demand).  Merlin also the same approach inside context objects.
 >
 >  Conclusion:
 >
 >    ComponentHandler is the equivalent abstract to Appliance.


I see.  So if Fortress were to be incorporated into Merlin,
it would have to be a Container and you lose whatever benefit
you had with the Appliance.

Of course, in the codename Merlin release of Avalon container,
we could adjust the Fortress container to use Appliances instead
of ComponentHandlers

 >  This separation is demonstrated by the fact that you manage
 >  component establishment using only the Assembly package. I.e.
 >  the Assembly package is an API supporting component
 >  establishment.


I thought it was a package supporting component declaration.  IOW,
the meta info/data is declarative and the container interprets it.
IMO that is the best model.  Isn't that how the Assembly package
relates?

 >  When we compare the Fortress Container and Merlin Container we
 >  need to introduce the notion of a Block.  A Block is specialized
 >  appliance that manages a component type called Container. This
 >  is similar to relationship between the Fortress ContainerManager
 >  and Container.  However, there is an important distinction between
 >  Fortress and Merlin at this point - while specialization of
 >  DefaultContainer in Fortress and Merlin are for all practical
 >  purposed equivalent, the Block abstract considers a container to
 >  be nothing more than the implementation mechanisms through which
 >  a set of services are established.


Let me try to rephrase that and see if I "got it".

A Block is approximately like the ContainerManager (itself a special
purpose container that manages one service [the container itself]).
In Fortress the ContainerManager can be used within a container,
and as such it is recursive.

I am still not clear on the distinction.  The ContainerManager
has some knowledge about what services the container will need
to operate.  Are you saying that the Block makes no assumption,
and uses meta data to find out what the container needs?  Is
that the distinction?

 >  For example - consider the James block.  It is a container of a
 >  bunch of different components (mail store, user store, thread
 >  manager, DNS server, POP server, SMTP server, etc.).  However, the
 >  actually services that a James Block can publish to other components
 >  will be quite different (perhaps the dynamic addition of a mailet,
 >  suspend/resume reconfigure functionality, etc.).  This ability is
 >  described by the block, acting in the role of a component.
 >
 >  Conclusion:
 >
 >    Fortress / Container is the equivalent abstract to the Merlin
 >    Container.
 >
 >    Block is a composite component.


Block is an abstract representing a component collection?  Or
Block is an abstraction representing a mechanism by which we can
expose services to a higher level?


 >> Stephen, I am going to need your help one coming up with the proper
 >> terminology.  I am not against the separation of the two functionalities
 >> of the container (i.e. assembly and instance management), but I am
 >> against the redefinition of container--which will only server to
 >> confuse people.
 >
 >
 >
 > I would rephrase the seperation - mainly because the word assembly 
can be used on both sides (to assemble versus an assembly).  I think we 
have three main areas of functionality: meta management; deployment and 
decommissioning; and the management of a containerment context.


Ok, I will concede that there is no real distinction in our concepts of
"container.  However now we have a new distinction here that you
introduced.  The container is responsible for the assembly, which means
it needs to assemble by inference.  One is the final product, and the
other is the action used to get there.  By simple logic, if a Container
needs an assembly, it needs to assemble the component mappings.  Whether
it hands that off to a library to take care of the nitty gritty details
or not is irrelevant--the container initiates the assembly process and
uses the product of that assembly process.

 >> If we are going to separate the concepts, we need to come up with a
 >> new name to express the assembly contract.
 >>
 >> The only plausible definition I can think of for a Block is a
 >> component that also behaves as an embeded container (traditional).
 >> Hense a Block can be recursive.
 >
 >
 > I think the Cocoon documentation of Block functional requirements is
 > the best reference.  The above information is more about "block" as a
 > computational approach to encapsulation of a composite component model
 > as the implementation solution to service provision.
 >
 > I'm sure I'm probably raising more questions than answers - sorry about
 > that but I'm also trying to factor into my thinking the possible areas
 > where we can synchronize Fortress/Merlin before releasing Fortress.


That's fine.  We can put all our definitions in a document and use them
consistently.  I want to get away from artificial distinctions or words
that are so close together yet have a different connotation.  IOW I want
us to simplify our language set.

 >  * Appliance & ApplianceContext <-----> ComponentHandler
 >
 >       First step could be seperation out the Reclaimable
 >       interface and use this on both Appliance and Component
 >       Handler.
 >            Further convergence is possible by building meta
 >       information based on roles and conf information and
 >       then evolving ComponentManager towards Appliance.


Right.  I had started that when I had time, and then I didn't have time
anymore.

 >  * DefaultContainer <-----> DefaultContainer
 >
 >       There are some immediate things that could be done here
 >       such as a common approach to contextualization of the
 >       container and using the same lookup keys.  This would
 >       eliminate the need to expose all of those protected state
 >       members. I also think (with some help from yourself) that
 >       we could update the event model on the Merlin container
 >       to bring it in line with the Fortress approach.


Right.  Managing things in the background makes it so much easier
to reduce the overhead associated with component based design.




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message