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; 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. 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. Could someone please fill me in where this little analysis goes awry? cheers, Leo Simons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
