Date: 2004-02-27T14:09:05
Editor: 198.152.13.71 <>
Wiki: Apache Avalon Wiki
Page: OverviewOfAvalon
URL: http://wiki.apache.org/avalon/OverviewOfAvalon
no comment
Change Log:
------------------------------------------------------------------------------
@@ -12,7 +12,7 @@
Once we know what services and components our application is made of we need an
actual concrete implementation which will fulfill that component's "role." In fact, in
some cases we may have several different implementations of a particular "service"
which are needed for different contexts within the over all application. In order to
sort out what implementation fulfills what role, Avalon introduces the idea of a
"RoleManager." The RoleManager, usually configured via an XML file, keeps track of
these relationships.
-The use of roles solves another problem: implementation lock . Since components are
only tied to one another via their roles, you are free to change, upgrade, swap,
migrate, or in general transform your component implementation without incurring
application instability. As long as the new implementation can fulfill the contract
defined by the component role, you can replace existing implementations with newer
ones. For example, one could easily write adaptors for third-party modules, be they
commerical or open source, to be used as components in your Avalon-based project.
+The use of roles solves another problem: implementation lock . Since components are
only tied to one another via their roles, you are free to change, upgrade, swap,
migrate, or in general transform your component implementation without incurring
application instability. As long as the new implementation can fulfill the contract
defined by the component role, you can replace existing implementations with newer
ones. For example, one could easily write adaptors for third-party modules, be they
commercial or open source, to be used as components in your Avalon-based project.
You might be wondering right now, "Well, that's all well and good, but how do I get a
hold of these components in my application?" In other words, you still need a way to
consistently instantiate, configure, use and release these components. You need
lifecycle management .
@@ -35,13 +35,13 @@
1. Stoppable
1. Disposable
-If that list doesn't mean much to you yet, don't worry about it. The imporant thing
to know right now is that components have lifecycles which are distinct from the
"services" or contract they offer.
+If that list doesn't mean much to you yet, don't worry about it. The important thing
to know right now is that components have lifecycles which are distinct from the
"services" or contract they offer.
A "container" is a special component which handles the lifecycles of the components
it hosts. Only the container has this responsibility of lifecycle management. The
Avalon Framework provides a number of utilities which ease this function. Specifically
a "ServiceManager" is used by the container to properly handle component lifecycle
methods. Between the ServiceManager and the RoleManager, the container can find roles
and bring them to life.
Other components get access to the ServiceManager via the "serviceable" lifecycle
listed above, allowing components to interact with one another. When one component
requests another component via it's role name, the ServiceManager and container insure
that the referenced component has gone through the appropriate lifecycle methods
before the calling component gets it's grubby little hands on it. Additionally, the
role design allows the calling component to interact with the referenced component
only via the defined methods of the role (i.e.- the interface).
-This is the crux of the "inversion of control" ideas expressed in the Avalon
framework. Components only interact via well defined contracts and calling (or parent)
components are responsible for the handling of referenced (or child) components.
Following this design increases the stability of your code since each component
behaves in well defined ways and lifecycle management is strictly controled.
+This is the crux of the "inversion of control" ideas expressed in the Avalon
framework. Components only interact via well defined contracts and calling (or parent)
components are responsible for the handling of referenced (or child) components.
Following this design increases the stability of your code since each component
behaves in well defined ways and lifecycle management is strictly controlled.
Moreover, by using properly defined roles one gains "Separation of Concerns." Each
role or component is only concerned with fulfilling its contract and nothing more. It
allows components (and developers) to focus on one thing at a time.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
