avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From blorit...@apache.org
Subject cvs commit: jakarta-avalon/src/proposal/avalon5 proposed-architecture.html
Date Fri, 13 Dec 2002 16:46:09 GMT
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.&#160; We learned the importance
  of the foundational principles (IOC, SOC), and the overall architecture of
  component based design.&#160; 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.&#160; 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.&#160; Most importantly we need
  to document what a container is required to provide, beyond the lifecycle
  objects and lifestyle management.&#160; 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.&#160; For this
  document, we don't want to make any distinction between Meta information and
  Meta data.&#160; 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.&#160; Our experience with
  ECM and Fortress brought to light the implementation choices of �singleton�
  components, pooled components, one-off components, and thread local
  components.&#160; The flexibility of just
  these four lifestyles allow for a wide range of deployment options.&#160;
   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.).&#160;
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.&#160; Some of those like
  Component and Composable are deprecated.&#160; Others like Context have come
  under recent fire due to insufficient description of what goes inside.&#160; There
  is even the idea of a unified namespace being thrown around like JNDI--but without
  its weight.&#160; Lastly, we are looking at extensible lifecycles as introduced
  by the Merlin/Fortress unified proposal and Phoenix's
  next-generation interceptor concepts.&#160; 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.&#160; The Context concept is so
  generic it is really hard to nail down.&#160; The JNDI
  concept has a scalable namespace environment, but a heavy implementation.&#160;
   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.&#160; That
  will allow us to provide a namespace mechanism that binds configuration
  information, system artifacts, and services.&#160; 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.&#160; 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.&#160; 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.&#160; 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.&#160; The advantage here is that we have
  contextual purity, and we have the
  same advantages with JNDI as the �Locator� pattern.&#160; 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.&#160; 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.&#160; Later, Fortress and Merlin
  cooperated to develop a simple variant.&#160; 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.&#160; I
  propose that we establish an interface that exposes all the Avalon specific
  artifacts to the lifecycle management mechanism.&#160; 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.&#160; The
  LifecycleArtifacts interface is implemented differently for each
  container.&#160; One container may use the
  JavaBean approach, storing unique values for each component.&#160; 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.&#160 This
  allows us to experiment with the
  relatively simple Merlin/Fortress approach or the more complicated
  Phoenix/interceptor approach.&#160; 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.&#160; The container
  will use standard meta information and assembly information to perform the
  logic.&#160; There are a couple variations we
  can look at, such as one manager per component type or one for all
  components.&#160; 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:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>


Mime
View raw message