avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@citi-us.com>
Subject [A4:Fortress] Design scratchings
Date Tue, 21 Jan 2003 14:39:45 GMT
Can also be viewed here:


This is to get you started on the thinking that went behind the Fortress

= Fortress Design Docs =

Fortress has two design goals: facilitate heirarchical containers and
take management functions outside of the <i>critical path</i>.  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.

== Asyncronous Management ==

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.

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.

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.

== Hierarchical Containers ==

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.

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.

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

=== Why Not Set Up a Standard Container Interface? ===

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: getServiceManager().

=== Why Not Use a Central Kernel? ===

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 <i>meta
information</i>.  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

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message