on multiple personalities

[Stephen McConnell <mc...@apache.org>]

Noel J. Bergman wrote:

>If the Avalon V container is based upon the micro-kernel + container
>services (some of which, to borrow a term used in other microkernel
>environments, would be "personalities") approach, what percentage of COMMON
>code do you believe would be reasonable between an A5 container configured
>with a Phoenix personality and one configured with a Merlin personality?  I
>think that subject should be addressed in a separate thread (so lets not go
>into *details* in this one), but my point for bringing it up is to suggest
>that it will be easier for the Community to sustain multiple personalities
>if there is more commonality between them.
>

This is a not an easy question!

First of all, one has to identify what the personality is that the A5 
container is dealing with.  There are in fact several facets to deal 
with, I call the first facet the "structural personality".

The structural personality deals with partitioning and isolation.  
Within Phoenix you have partitioning of applications made up of 
components that are assembled together (2-tier model).  Merlin is quite 
different in that structural model is on one-hand a containment concern, 
but on the other, the result of the deployment is simply a component 
proving services (n-tier model). The magnitude of difference at this 
level suggest that we have to look deeper into the mechanics in order to 
establish useful common services.

Some of the things that you isolate include:

  * definition of a partition
  * classloader management including extension management
  * scoped repository management, supporting:
     - type repositories
     - service repositories
     - profile repositories

One could assume a common A5 structural service, responsible for the 
establishment of things like partitions, classloading hierarchies, and 
meta-info/data repositories.  Given these facilities, one would need to 
be able to plug-in a system-assembly-strategy.  A 
phoenix-system-assembly-strategy would understand the notions of 
application and block with Phoenix.  A merlin-system-assembly-strategy 
would understand the notion of blocks, containers, and components from 
the Merlin environment.

Assuming we have just fired up a strategy handler - there are a bunch of 
additional common services that the handler could leverage in the areas 
of meta info management and meta data management.

In both Phoenix and Merlin there is the concept of a component type and 
the communication of this information to a container.  While the 
actually XML representations are different, the structural approaches to 
reading and manipulating this information are similar.  Assuming that A5 
container has its own meta-info model, the next aspect of the 
personality management would concern the ability to construct a type 
definition using a variety of schemas.

   * an A5 meta-info-loading service
   * identifies and installs a meta-info factory implementation
      - block-info factory (phoenix)
      - type factory (merlin)
      - roles factory (fortress)
      - any other factory that respects a meta-info-loading SPI

Another aspect of personalities is the supply by a component type of 
named deployment profiles, templates, and default information.  This 
sort of information is where we see much higher degrees of divergence, 
but just like above, this can be handled via mapping between meta-data 
factories and a mata-data-loading-service.

   * an A5 meta-data-loading service
   * identifies and installs a meta-data factory implementation

Finally, there is one more aspect to the personality question - the way 
in which the containment context is modified.  Phoenix uses a set of 
base-components (components without dependencies) that are declared as 
part of the system.  I see this simply as part of the definition of a 
partition.  This is different in Merlin because in Merlin your 
deployment information is defining the system.  In both cases these 
aspects can be addressed by the structural personality plug-in mentioned 
above.

As to the question - what percentage of common code ... ?
My guess is somewhere between 60-80%.

Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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