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="[EMAIL PROTECTED]"/>
</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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
