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-excalibur/fortress/src/xdocs design-notes.xml menu.xml
Date Tue, 21 Jan 2003 21:12:01 GMT
bloritsch    2003/01/21 13:12:01

  Modified:    fortress/src/xdocs menu.xml
  Added:       fortress/src/xdocs design-notes.xml
  Log:
  add the design notes from the WIKI here
  
  Revision  Changes    Path
  1.4       +1 -0      jakarta-avalon-excalibur/fortress/src/xdocs/menu.xml
  
  Index: menu.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/fortress/src/xdocs/menu.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- menu.xml	5 Jan 2003 15:29:29 -0000	1.3
  +++ menu.xml	21 Jan 2003 21:12:00 -0000	1.4
  @@ -20,6 +20,7 @@
           <menu name="Reference">
               <item href="api/" name="API Docs"/>
               <item href="lifecycle-extensions.html" name="Lifecycle Extensions"/>
  +            <item href="design-notes.html" name="Design Notes"/>
           </menu>
       </body>
   </project>
  
  
  
  1.1                  jakarta-avalon-excalibur/fortress/src/xdocs/design-notes.xml
  
  Index: design-notes.xml
  ===================================================================
  <?xml version="1.0"?>
  
  <document>
    <header>
      <title>Excalibur Fortress - Design Notes</title>
      <authors>
        <person name="Berin Loritsch" email="bloritsch@apache.org"/>
      </authors>
    </header>
    <body>
      <s1 title="Fortress Design Notes">
        <p>
  	    Fortress has two design goals: facilitate heirarchical containers and
          take management functions outside of the critical path. The critical
          path is the code execution path that is required to find and use a
          component. Fortress assumes that the developer has explicit knowledge of
          his domain--which Fortress itself would never have any knowledge of. It
          also assumes that there is one root container, although it does not
          force that upon the developer.
        </p>
        <s2 title="Asynchronous Management">
  	    <p>
            Due to the long startup times of certain components like the
            DataSourceComponent ECM based code suffered from slowness. The problem
            was also made worse by the delayed loading and running of components.
            Components would only be instantiated when they were first looked
            up--which made problems for components that needed to be started
            immediately.
          </p>
  	    <p>
            Fortress makes use of the Event package's CommandManager so that all
            components can be started up immediately, but it is done in the
            background. That means that components are still starting while
            Fortress is ready to work. If a component hasn't been started yet
            before it is needed, then Fortress will make sure it starts before it
            turns over the requested component. It will also make sure no
            component gets started twice.
          </p>
          <p>
            All component pool sizing and management is done by background threads
            so that as Fortress responds to requests for components, it manages
            resources without adding that cost to the client code. That means the
            critical path (the code that actually does the work of the system) is
            not delayed unnecessarily.
          </p>
        </s2>
        <s2 title="Hierarchical Containers">
  	    <p>
            Part of the design concept for Fortress heirarchical containers is to
            use a ContainerManager to make sure all the necessary services are set
            up and running. For example, the Fortress container needs a
            CommandManager--so the ContainerManager checks to see if it is already
            set up and uses it. That way we can have one Container that has one or
            more ContainerManagers that all use the kernel level services of the
            parent container.
          </p>
          <p>
            The kernel level services are: CommandManager, InstrumentManager,
            LoggerManager and ThreadManager. The actual setup and configuration of
            these services are done using a Context. The choice for the Context
            object was a conscious decision because we didn't want to extend the
            objects in a proprietary manner (LoggerManageable, etc.) like the ECM
            did. By passing the kernel services in the context, the kernel
            services can be forwarded to any child containers.
          </p>
          <p>
            To assist in the setup of the Context, Fortress uses a ContextManager.
            The ContextManager will either set up the context based on a Context
            passed in, or from a default context. Once the ContextManager assists
            the ContainerManager to set up any missing kernel services, you can
            get the Container from the ContainerManager and start using it.
          </p>
          <s3 title="Why Not Set Up a Standard Container Interface?">
            <p>
              Each domain has its own needs. For instance, Cocoon is based on a
              request/response processing model. Component based tools are based
              on a useage model. Swing based Apps are based on other models. There
              is no one size fits all solution, and Fortress can be used in all of
              these solutions. As an interim solution, the DefaultContainer does
              have one public method exposed: <code>getServiceManager()</code>.
            </p>
          </s3>
          <s3 title="Why Not Use a Central Kernel?">
            <p>
              This was actually planned in a future release. There are some issues
              to work out with a central kernel though. Those issues include how
              to detect and set up sub-containers, how to make sure the container
              instance you want is set up instead of the default version, etc. In
              essence, what is needed is <em>meta information</em>. Meta
              information is information about the container heirarchy and the
              components involved. In the future Avalon Container: Merlin release,
              we will have a proper meta model.
            </p>
          </s3>
        </s2>
      </s1>
    </body>
    <footer>
      <legal>
        Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
        $Revision: 1.1 $ $Date: 2003/01/21 21:12:00 $
      </legal>
    </footer>
  </document>
  
  
  

--
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