avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [A4:Fortress/Merlin] Coming to grips with terminology
Date Tue, 28 Jan 2003 08:13:18 GMT

Berin Loritsch wrote:

> One of the issues that any Avalon newbie has to come to grips with is
> a new vocabulary.  Component Oriented Programming is similar in many
> respects to its OOP cousin, but there are a few terms that need to
> be understood first.  One of my concerns with the Merlin effort isn't
> so much the technology, but the overloading of terms and adding
> semantics that don't exist in other contexts.
> We are all very clear on what constitutes a component.  We also are
> aware that they interact with a container.  The problem is the exact
> definition of the container.  I think we need to standardize on what
> we mean by that word, and leverage what is already out there.  That
> way we all speak the same language.
> Everywhere I have looked regarding component systems defines containers
> very broadly as:
> * the code or server that manages component instances and component
>   implementation mappings.
> The exact text changes, but the concept is still the same.  In fact
> that is the rough definition I run off of.  In other words, a container
> not only controls the component instances, but it also controls what
> we call the "assembly".
> 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.


> 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.

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

  In Fortress / ComponentHander

      Object get();
      void put( Object object );

  In Assembly / Appliance

      Object resolve( Object partition);
      void release( Object object, Object partition );

  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.


    ComponentHandler is the equivalent abstract to Appliance.

  Most of the content in Fortress is dealing with the above and
  can be compared (generally speaking) with the Assembly package.
  When we at the remaining classes in Fortress we are left with
  the Container abstraction.  In effect the handler and lifecycle
  packages are simply the mechanisms used to provide containment
  functionality. This is similar in Merlin - the Assembly package
  handles the concerns related to lifecycle, lifestyle, etc. and
  the abstract concerning "containment" is separated out into the
  Merlin package.

  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

  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.

  Block provides the bridge between published services and an
  implementation strategy that happens to be based on a container
  hierarchy.  This bridge enables a complete approach to composition
  in that service and dependencies published by a block are the
  dynamic equivalent of a classic component.

  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.


    Fortress / Container is the equivalent abstract to the Merlin

    Block is a composite component.

> 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.

  * support for *meta* management
      - management of information about a component *type*
      - management of information about a component *profile* or
      - management of a *registry* of deployment candidates (type and
        deployment *criteria* - e.g. roles and xconf)
      - candidate *establishment* and *termination*
      - the ability to *assemble* and *disassemble* candidates
  * the ability to support *deployment* and *decommissioning* of
    component instances
       - *sequence* management
       - *lifestyle* management
       - *lifecycle* management
  * and management of the *containment-context*
       - component isolation
       - management localization

> In essence, the traditional container as described in all texts that I
> have read is the combination of a Merlin container and an Appliance.

I agree.

> 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.

  * Appliance & ApplianceContext <-----> ComponentHandler

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

  * 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.

Cheers, Steve.


Stephen J. McConnell

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

View raw message