avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Merlin Container
Date Tue, 27 Aug 2002 16:16:35 GMT

Berin Loritsch wrote:

>I began trying to use Meta and Container in Fortress, and started to
>look at Merlin 2 on how to best do this.  The Container interface 
>exposes methods to the implementing container so that the kernel can 
>do its magic.
>There are some things that look suspiciously like subversion of 
>control that I am curious about.  First, the simplified interface 
>that I would be happy with is:
>interface Container
>    void install( Profile[] profiles );

Probably possible - the addContainer operations could be resolved under 
an install where the installed component is a profile of a container.

>The reason is simple: information should flow inward, not outward.
>Container hierarchies should not be determined based on the kernel's 
>viewpoint, but on the way that the developer sets it up.  

The kernel is basically handling the information it is provided with - a 
set of component profiles it has to establish and - in the special case 
of a root kernel - establishment of a set of kerenel level services.  In 
effect this is what the developer/assembler is asking for, ... bu let me 
read on ;-)

>Granted, the current approach allows the kernel to set 
>everything up, but let me illustrate why Fortress and 
>Merlin have very different viewpoints on setting up the 
>container hierarchy.
>* Querying the state of the child
>  - Merlin's kernel queries the state of the child container, as 
>    opposed to knowing it.

The only queries applied by the kernel to the container relates to 
container verification.  There was a higher level of kerenl container 
interaction before but this has eliminated (see current CVS version). 
 There is still container-to-container interaction related to 
synchronzation across multiple threads suring deployment processes that 
I'm not 100% happy with - so in that respect I agree about intaction 
levels and the interest in reducing this.

>  - Fortress knows the state of the child container because the 
>    parent container set it.  Information flows from the parent 
>    to the child (inward), but no information flows from the 
>    child to the parent (outward).

Aside from thread synchronization (i.e. a parent container considers 
itself initializated when all of its subsidiary containers are 
initialized), what specifically are the outward flows you thinking of? 
 Based on the current implemetation the outward flows re available 
services based on what the container can achieve relative to its 
supplied deployment criteria.  It can also provide state in that it can 
be suspended, redeployed, etc. and in that respect it may be obliged to 
notifiy a parent of that state change.  This isolation of deployment 
status is really useful - you can limit the impact of system 
modifications (reconfiguration, etc.) to the container level without 
interupting the entire hierachy.

>* True hierarchy vs. Flat hierarchy
>  - Merlin asks a container to create an instance of a child 
>    container, presumably so that it can directly manage it--or pass
>    in the profiles.

Merlin contains provide two levels of interaction:

1. the assembly stage - this is where the container is provided with its 
profile, and the profile sincludes information about all of the 
subsidiary containers and immediate components

2. the progammatic entry point - Merlin containers enable dynciamic 
addition of container and componets to a container at run time - so you 
programmatically build things is a dyanmic environment

>  - Fortress allows the containers to create whatever child 
>    containers it needs.
>    It provides the framework that does not bind the container writer
>    into one way of doing things.  You don't even *have* to use the 
>    provided Container interface or the provided ServiceManager/
>    ComponentManagers.

A container in Merlin must implement the Meerlin Container interface. 
With respect to SM/CM, a container can declare its own implementation of 
a deployment manger which allows different CM/SM solutions.

>* Architecture specific constants
>  - Both Merlin and Fortress have architecture specific constants 
>    that are passed in (presumably by the context object).  These 
>    constants are container specific.
>  - Fortress deals with this by separating out the constants into
>    separate interfaces instead of merging them.
>Both Merlin and Fortress do work, but Merlin side-steps IOC by making
>all containers in a system as peers--at least that is how it looks.  

I think that's a reasonably statement.

>I would like to understand the thought processes behind the decisions.

And the reason is:

1. container are not peers when we are looking at them in terms of 
component management frameworks - they a hierarchical and are subject to 
constraints concerning access to classloaders, kernel resources and so 
on.  However, when we get to the management of the services that provide 
- we are into a different spectrum or viewpoint.  A container is a 
functional unity - it provides a service - namely the assembly of a set 
of components with the objective of establishing a set of services.  It 
does this using a shared type manager (well, sort of shared - each 
container gets it own type manger and it can see up the hierarchy but 
not across).  The question of exposure of the resources it manages is 
what I think your getting at.  In the Phoenix world you can deploy a 
James application - but you cannot access the James service from another 
application - this was a real limitation to things I was dealing with - 
I wanted pluggable components - and I wanted a framework where the 
services derived from those components could be easily managed across a 
distributed environments.  This means I needed to be able to deploy a 
set of components (implementations) and arrive at a situation where I 
had a set of available services.  Some of these services may me private 
to a container (privacy policy not implemented yet) and others may be 
public - ie. published by a container.  Of the published (public) 
services, some of these may be remotely accessible and may be provides 
solutions to component composition in other containers in different 
organizations.  Given this ability, you can chain together services (and 
the service activation semantics across different organizations).  Throw 
into this some smart business, collaboration and security context 
management and your looking at some really interesting mechanisms for 
collaborative peer-to-peer business solutions.

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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