bloritsch 2002/12/13 08:46:09 Added: src/proposal/avalon5 proposed-architecture.html Log: add proposed architecture for discussion Revision Changes Path 1.1 jakarta-avalon/src/proposal/avalon5/proposed-architecture.html Index: proposed-architecture.html =================================================================== <html xmlns="http://www.w3.org/TR/REC-html40";> <head> <meta http-equiv=Content-Type content="text/html; charset=windows-1252"> <title>Avalon 5 Architecture</title> </head> <body> <h1>Avalon 5 Architecture</h1> <p>We have learned much from our experiences with Avalon up to this point.  We learned the importance of the foundational principles (IOC, SOC), and the overall architecture of component based design.  We also learned the limitations of our Framework 4.x generation container designs and the fact that our contracts are too generic.</p> <p>For the future we want to be able to support an architecture that is powerful, flexible, but sufficiently specified so that we can have multiple implementations of containers.  To achieve that end we need proper component verification, and modular container architecture.</p> <h2>Container Contracts</h2> <p>We have learned a great deal from all of our container implementations, and have learned what could be made better and what could be lived without.  Most importantly we need to document what a container is required to provide, beyond the lifecycle objects and lifestyle management.  We need to describe the contracts for what is inside the lifecycle objects.</p> <h2>Meta Information</h2> <p>Due to the experience with the Phoenix and Merlin containers, we learned the value of using Meta information to describe and validate our components.  For this document, we don't want to make any distinction between Meta information and Meta data.  We only want to say that it is necessary to properly describe our components to the container.</p> <h2>Lifestyle</h2> <p>We have learned that while we can only think of a handful of implementations for lifestyle, we do not want to limit ourselves to only those implementations.  Our experience with ECM and Fortress brought to light the implementation choices of �singleton� components, pooled components, one-off components, and thread local components.  The flexibility of just these four lifestyles allow for a wide range of deployment options.  However, there are other lifestyles that will more than likely be necessary in different usage scenarios (like SEDA or request/response based environments).</p> <p>What we need to do is describe the particular environment that the component is designed to work within, and let the container decide what the proper lifestyle implementation should be.<span style="mso-spacerun: yes">� </span>We need to look more into this, but so far the two major proposals on the table for this is to either infer it based on component <i>scope</i>, or based on lifestyle <i>properties</i> (e.g. reusable, sharable, etc.).  We need to figure out what is the most scalable solution.</p> <h2>Lifecycle</h2> <p>We have several lifecycle interfaces and lifecycle objects that are required for Framework 4.x compliance.  Some of those like Component and Composable are deprecated.  Others like Context have come under recent fire due to insufficient description of what goes inside.  There is even the idea of a unified namespace being thrown around like JNDI--but without its weight.  Lastly, we are looking at extensible lifecycles as introduced by the Merlin/Fortress unified proposal and Phoenix's next-generation interceptor concepts.  We need an extensible lifecycle so that we can easily adapt to new needs in a compatible manner.</p> <h3>Unified Namespace</h3> <p>I think this idea has some serious merit.  The Context concept is so generic it is really hard to nail down.  The JNDI concept has a scalable namespace environment, but a heavy implementation.  The ServiceManager concept is fairly well defined (in community concept if not in a document), but its namespace environment is fairly restricted.</p> <p>By "unified namespace" we do not mean that all components share the same namespace, we mean that we can get all information we need for a component from the same namespace.  That will allow us to provide a namespace mechanism that binds configuration information, system artifacts, and services.  It should also allow the component itself to "rebind" or "write" information back to the namespace so that the container has the option of storing it for later use with the component.  An example would be a component that writes its configuration back to the namespace so that it can either "self-heal" (i.e. upgrade its configuration elements to the latest non-deprecated format) or add new entries (i.e. for things like Apache Axis that needs to manage the SOAP message handlers that may have been added or removed during runtime).</p> <p>One strategy is to follow the Sun �Locator� pattern, which abstracts away the JNDI system and manages cached entries.  The advantage is that the design pattern is documented elsewhere, we do not have to back it with JNDI for J2ME systems, and we have the option to back it with JNDI for J2SE or J2EE environments.  The disadvantage is that the concept of "Locator" is biased for <i>finding</i> things, not <i>managing</i> things.</p> <p>Another strategy is to provide a simpler variant of JNDI much like JDOM did for the DOM package.  The advantage here is that we have contextual purity, and we have the same advantages with JNDI as the �Locator� pattern.  The disadvantage is that we are working with a proprietary interface, and not a pattern that has been documented elsewhere.</p> <p>Whatever solution we choose, we need to work together to describe its interface and contracts.  We need to look at what things are <b>required</b> to be bound, and what things can be made optional.</p> <h3>Extensible Lifecycle</h3> <p>Phoenix is the first container to experiment with extensible lifecycle.  Later, Fortress and Merlin cooperated to develop a simple variant.  The underlying motivation is that we want to be able to support user-defined lifecycle that is application specific in a manner that is not container dependent.</p> <p>In order to make a cross-container extensible lifecycle system work when lifecycle artifacts are required, we need to standardize <b>how</b> we provide those lifecycle artifacts.  I propose that we establish an interface that exposes all the Avalon specific artifacts to the lifecycle management mechanism.  The lifecycle management mechanism can in turn work with the standard lifecycle artifacts to take care of application specific lifecycle events.</p> <p>Translating this into English, one example would be defining these two interfaces:</p> <pre> /** * Lifecycle artifacts working with A4 artifacts */ public interface LifecycleArtifacts { Logger getLogger(); Context getContext(); Configuration getConfiguration(); Parameters getParameters(); ServiceManager getServiceManager(); } /** * Lifecycle management */ public interface LifecycleManager { void initialize( Object component, LifecycleArtifacts artifacts ); void lookup( Object component, LifecycleArtifacts artifacts ); void release( Object component, LifecycleArtifacts artifacts ); void dispose( Object component, LifecycleArtifacts artifacts ); } </pre> <p>The LifecycleArtifacts interface describes to the LifecycleManager how to get the information to pass in to the Configurable interface for example.  The LifecycleArtifacts interface is implemented differently for each container.  One container may use the JavaBean approach, storing unique values for each component.  Another container may use that as an alias to itself and supply a common set of artifacts to all components.</p> <p>The LifecycleManager interface allows us to change the implementation details of how we create the managers and provide a standard way for the container to perform all of the functions with the manager.  This allows us to experiment with the relatively simple Merlin/Fortress approach or the more complicated Phoenix/interceptor approach.  It also allows us to plug in the logic once we have figured out how to make it work.</p> <p>I would like the actual creation/assembly of the LifecycleArtifacts type object and LifecycleManager type object to be done by the container itself.  The container will use standard meta information and assembly information to perform the logic.  There are a couple variations we can look at, such as one manager per component type or one for all components.  I prefer a type based approach as it allows some containers to customize the manager for each type (so that no �instanceof� or casting needs to be done on initialization).</p> </body> </html>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
