Leo Simons wrote:
>All (Steve, Pete's, Marcus, Berin, Paul, Nicola, Leo),
>
>recent discussion on extending the lifecycle (or the need to do so) let
>me to review the decisions that led to the lifecycle being defined in
>the way it is now.
>The main point of debate is not really the way to define it (using
>well-known interfaces, coupled to contracts, implemented by components,
>with metadata inside XML config files, as we have before), but the way
>to support it inside a Container.
>
>The definition of the Container
>-------------------------------
>During development of Avalon Framework 4, the concept of the container
>was not formalized. In fact, framework sources have little to no mention
>of a "container", and the same is true for the framework docs.
>
>It has been recognized by all that the concept of the container is vital
>for proper SoC in COP. We have found that early attempts at writing
>these (ECM, Cocoon) muddied their design by mixing composition and
>container concerns.
>
>Until recently, the only reference for an architecturally clean
>implementation of a framework-supporting container was Phoenix. Mainly
>because of popularity growth of avalon in servlet environments, efforts
>are now underway (merlin, fortress, plexus) to write a clean
>framework-supporting container optimized for embedded use. An effort
>targetting run-once (as opposed to server) usage (myrmidon) is also
>showing promise.
>
>Work on defining the container is underway. The current informative
>definition reads:
>
>" The Container is the entity that manages your Components. It handles
>things like loading of configuration files, resolution of dependencies,
>component management, component isolation, and lifecycle support.
>
>The Container is not formalized in the form of an interface or contract
>within Avalon Framework, though it might be at some point in the future.
>The informal contract for the container is that it has the ability to
>host any fully avalon-framework compliant component. Most current
>containers place additional requirments on the component. "
>
>The parts of a Container
>------------------------
>"Combine those new containers with the many iterations and designs
>phoenix has seen in the past and extract the common parts, and you will
>have a framework-level container definition." That's the thought that
>led to the creation of something dubbed "ContainerKit", and the offspin
>projects.
>
>The parts that can usually be identified in a well-written container
>are:
>o the Embeddor/bootstrapper
> *************************
> This will likely remain a completely container-specific part as one
> of the main reasons for having different containers is having
> different problem domains with different bootstrapping needs.
>
>o the Kernel
> **********
> The Kernel will remain mostly container-specific as this is the
> defining part of the container.
>
>o the Component MetaData/MetaInfo/Type/Profile
> ********************************************
> It would be advantagious to develop a common meta model for components
> that is sharable at the object instance level (at least) across
> containers, as this is a requirment for complete component
> portability.
>
>o the ComponentManager/ServiceManager implementation
> **************************************************
> This is not an area of much concern as framework implementation
> details are already transparant to clients, and this part of the
> Container already has a definition inside the framework.
>
>Common Container Extensions
>---------------------------
>In complex setups where the container provides many features, the Kernel
>will often become more and more elaborate;
>
I would replace the word "will" with "may". In the case of Phoeix yes -
it has not alternative due to its linear component maangemnt
architectue. In the case of a container based on the Avalon Meta Model
- such as Merlin, the container does not need to grow in complexity due
to the inclusion of an extension framework and the benefits derived from
a hierachical container management approach.
>the best option in the end is
>usually to adopt a micro kernel architecture, like Phoenix has. Many of
>the most powerful kernels (like, for example, linux) allow pluggable
>modules to be inserted into the Kernel for added or modified behaviour.
>
>Work is now in progress to define a set of common interfaces that would
>allow reuse of modules across micro-kernel-based containers. Since the
>avalon framework is centered around the lifecycle, modularization of the
>container is centered around lifecycle modularization.
>
>As it has been recognized that support for the core lifecycle interfaces
>(ie the interfaces in framework v4) is vital to all kernels, this is not
>considered part of the discussion. A LifecycleHelper has been available
>for a while so containers can delegate core lifecycle support.
>
>Thus the remaining issue is lifecycle extension. A lifecycle extension
>module would need to specify its relationship to the core lifecyle. It
>seems wise to follow the same pattern used with the actual lifecycle:
>use well-known interfaces, coupled to contracts, implemented by the
>extension modules, with any metadata in XML configuration files.
>
This is a very powerful approach. When building a good container, the
author is constantly dealing with the struggle between bootrap services
such as logging and lifestyle management, as opposed to pluggable
extensions components that expand the container's functional capability.
>
>When these interfaces have been defined, a common helper object
>(following the same line of thought that created the LifecycleHelper)
>can be created to support them easily inside a container.
>
>It has been suggested that it would be advantagious to move these module
>extension interfaces to the framework (as well as eventually the
>LifecycleExtensionHelper) to guarantee adoption across containers that
>provide lifecycle extension support.
>
>Common Component MetaData
>-------------------------
>Work is also underway to define a common model for component metadata.
>It has been recognized that the lowest level of component model support
>is at the class level, and work is underway to define the common
>interfaces and support classes that will make up this model.
>
>It has further been recognized that additional common ground in the form
>of shared XML DTD definitions (and locations wrt the component
>classfiles) would allow another level of reuse. There is strong
>disagreement on the DTDs though.
>
>I'm missing some pieces
>-----------------------
>You will notice lack of implementation discussion. This is on purpose. I
>have stated before that I feel the current arguments are focussed a lot
>on implementation details where the underlying concept or preferred
>architecture has not been separated out and agreed upon. Yet the
>arguments for or against a particular implementation reference concepts
>and architecture decisions.
>
This is a difficult point.
If we take somethig lie Phoenix - its an implementation that I consider
to be wellin advance of Merlin in terms of its role as an app-server. On
the other handl - Phonix management of extension and evolution is
primative relative to Merlin. This is not critisism of Phoenix or
Merlin - its just reality - Merlin took the best of Phoienix and created
a next generation. There are implementation issues that Phoenix must
deal with. These einclude the extension requirements pushed by the
EC/Cocoon community (and others). Thee are also implemetation iosue
that Merlin must deal with - for example .. support for management
access points. Total interoperability today is a matter of adation.
Merlin adapts for the potential inclusion of Phoenix based compoents.
The same it possible for Phoinix (although the Phoenix comunity hve
chosen not to engage in the process).
In practice we should be be dealing with three level of interoperability:
1. DTD componet type defintion
So at least a container can read in a defintion of a compoent and
know if it understands the defintion
2. Componet type validation
So a container container can manafe or reject a component type based
on the information it understands
3. Component deployment
WIthin a context that a container knows that it can satisfactory
resolve the complete component requiements
>Could someone please fill me in where this little analysis goes awry?
>
The analysis is good.
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]>
