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
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
