avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Merlin Container
Date Tue, 27 Aug 2002 16:40:32 GMT
> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> 
> Berin Loritsch wrote:
> 
> >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.

I think that would be preferable.


> >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 ;-)

Ok.


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

It should be doable.  I think that one thing simplifying the Fortress
approach is that the containers are largely passive.  In other words,
anything that happens in threads is relegated to the CommandManager,
and when a container recieves a suspend() or related signal, it can
directly propogate it to the children.

This is distinct from having a separate thread for each container.


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

Outward flows of information include:

* getName() (not setName())
* Container createContainer(...)
* getState()
* getResources()

Basically anything where the parent would query the child


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

Ok.


> 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

It can be done via Fortress as well.  Provided your container
implementation
knows how to do it.


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

Right.  But you must implement the Container interface.  I think that
is part of the communication you designed into Merlin.


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

Not all containers are peers though.  I need to throw together
some real art (PNG or GIF for your preferred format?) to demonstrate
what I mean.

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

The assembly and management of the instances of those components.
Now, as to exposing services from one application to another, that
is a container specific thing.

Keep in mind that in some cases the added security of refusing inter-
application communication is necessary.  A different container might
allow authenticated access (i.e. public key authentication or
something).
Still another container provides a "trusted system" in which all
applications can request services one of another without the need
for authentication--which is where I think Merlin is.

When you have two applications on the same server like in J2EE and
Phoenix environments, they are for all intents and purposes isolated
from each other.  The only exposure you have to their internals is
done through the wire protocols that are exposed like SOAP, or the
web application.

We do need to be careful with inter-application communication.  As
you pointed out one size does not fit all.

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

Right.

However it is the responsibility of the container, or root container
to determine how it implements those privacy policies.  In the InfoMover
application, I want to be able to publish access to a management server
to the JobManager.  I also want to publish the control of the individual
jobs.

Perhaps the interaces as they are need to change.  However, there are
many ways to publish a component, and to mark a component as
publishable.
Keep in mind that the container does not have to respect the publishable
attribute.  It is perfectly valid to be more restrictive, but it is
definitely not valid to be more lenient.


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