As a next step of documenting the Aragon Framework I would like to demystify the idea behind the Aragon Container, the most important component of the Framework. The whole concept of how the FWK works is mainly defined in the Aragon Container (AC from now on).

What do I mean by Component Container(CC)?

When I talk about a Component Container I like to think to an extended object factory & pool which handles the creation, sharing and disposal of complex object type instances. Every object type managed by the CC should have one unique name and should hide the implementation of the Component behind a role (JAVA Interface) defining some special API.

[code lang=”java”]public class Suzuki implements Car{
public void drive(){
System.out.println(“I am a Suzuki car and I am driving better…”);
};
}
[/code]
we say to the container that we have two kind of object types implementing the same role and they have “RenaultCar” and “SuzukiCar” names.

After that we just make our application which does not have to know where is the Renaul or Suzuki type car implemented, it only knows about the fact that both are Cars (implement Car) and they have the mentioned names(which are Strings).

[code lang=”java”]public void main(String[] args0){
Container cont = new Container();
//…do some configuration stuff like “tell the container about the role and its “rolePlayer” components via a config file…or somenthig
//create a Renault type car
Car renault = (Car) cont.select(“Car”,”RenaultCar”);//role,name
renault.drive();
//… and so on also with the suzuki
}
[/code]

Please ignore the fact that I used a method select() inside that example…I will talk about it later on…

Isn’t i interesting how simple is to hide from the rest of the application the real implementation of a component? And would it be more interesting if:

you could tell the container to allow the creation of only ONE instance (singleton) of a component without implementing the taditional getInstace() stuff?

the CC could call some method on the Conponent instance during the creation?

the CC could inject configuration data into the newly created object?

Little history
When the idea of the FWK has come out of my mind, I was working on some Desktop application software witch was built around Apache’s Excalibur project. The Excalibur was and still is a quite straight forward project concerning the concepts of a framework. I really liked the idea of constructing an application from components managed by an Inversion of Control lifecylce container (called Fortress).

So I started playing around with the Fortress container and tried to figure it out how it works. Back then, there was wery limited documentation available so, I kind of had a hard time understanding why it should something be done like that. I have to say that the application I was involved in, was a big help in clearing the fogg around this Fortress stuff.

After a while I decided to begin with the Aragon FWK project, and I tried to use the most stable third party components available (mostly Apache projects). Of corse the FWK was built around the Avalon/Fortress container. And so it went untill I started to face performance problems…and other…and I had to do something about them. Before You think that I am balming the Apache guys for my problems, I would like to point out that the problems were comming from my mistakes. I have built my framework on something that I did not know entirely, and mostly I overlooked the fact that the Excalibur/Avalon was created for highly scalable applications (mostly Entreprise software) and it was far more complex than I needed to be. I had no other choice than port my whole FWK to something else. Ok but to what… That kind of Container architecture was not so common back then in the Open Source community(and I am not the type who can spend a lot of time searching for something on the net and then figure it out how it works) , so I decided to implement my own Component container… as simple and as light as possible, using the lessons learned from Apache’s Avalon/Fortress.

So the Aragon Container has born.

Goals of ACWhen I started to design it I had the following things in my mind:
-make it simple (KISS)
-make it as lightweight as possible
-make it reusable

In my understanding a component lifecycle container had to provide the following features:
-group components using names and roles, where a role whas something that described what component had to act (behave). actually an Interface in JAVA
-take care of the lifecycle of the components created (instanciate, keep alive, dispose)
-provide searching feature based on role and name

This was all I needed from the container. This is what it became:

ConceptsThe main concept of the AC is that every component has to have a unique name inside the container, and has to implement at least one role. A defined role can be implemented by several components identified by their name. Using these two informations components can be looked up (using a role) or selected (using a role and a name).
The role can be seen as a Java interface witch is implemented by a component (witch is reality is NOT a requirement, BUT is a best parctice).

Life-Cycle ExtensionsThe AC defines a few life cycle extensions witch are used to control the created component instances. The AC implements the Inversion Of Control and Dependency Injection patterns using the mentioned extensions. The extension are:

Contextualisable – Extension which when used(implemented) by a component will make the AC to inject the container instance to the created component, to provide an access-point to the rest of the components. (see class net.nWizard.aragon.toolkit.container.Contextualisable)

Configurable – Extension which when used (implemented) by a component will make the AC to inject the configuration node (in XML format) into the component by calling configure() method(see class net.nWizard.aragon.toolkit.container.Configurable)

Initializable – Extension which when used by a component will make the AC to notify the component that initialisation can be done, by calling the initialise() method (see class net.nWizard.aragon.toolkit.container.Initializable)

Startable– Extension which when used by a component will make the AC to notify the component to execute start or stop operation, by calling the start() or stop() method (see class net.nWizard.aragon.toolkit.container.Startable)

Suspendable– Extension which when used by a component will make the AC to notify the component to execute suspend or resume operation, by calling the suspend() or resume() method (see class net.nWizard.aragon.toolkit.container.Suspendable) – funtionality only defined in the A, not yet implemented

Reconfigurable– Extension which when used by a component will make the AC to reconfigure a component, by calling the reconfigure() method (see class net.nWizard.aragon.toolkit.container.Reconfigurable)

Disposable– Extension which when used by a component will make the AC to notify the component to execute dispose operation, by calling the dispose() method (see class net.nWizard.aragon.toolkit.container.Disposable)

ThreadSafe– Extension which when used by a component will make the AC to treat the component as a singleton creating only one instance from the component(see class net.nWizard.aragon.toolkit.container.ThreadSafe)- Marker interface

Lazy– Extension which when used by a component will make the AC to create an instance of the component ONLY when needed (when someone tries to look up that component)(see class net.nWizard.aragon.toolkit.container.Lazy)

Logable– Extension which when used by a component will make the AC to to inject a Log4J logger instance (customized for the component) into the component instance by calling method, by calling the setLogger() method (see class net.nWizard.aragon.toolkit.container.Logable)

As you may noticed the AC has lots of functionality already implemented, to support the Aragon Framework.

Since the AC is part of the Aragon Toolkit, you can integreate this container into your application only by adding the toolkit.jar to your application classpath. The AC container does not depend of the Aragon Framework, it is a generic container implementation. The toolkit.jar contains all the necessary classes needed to integrate the AC into your app.

Container hierarchy

You may have several aragon containers in your application. To centralize the access between the containers these can be structured in a hierarhical (tree) structure. (One AC instance can have one parent and many children).

Organizing the AC instances in a tree structure may solve the problem of trying to look-up a component which is created and held in AC22, from a component located in AC11.

In this case the lookup functionality will be propagated until the top of the AC hierarchy and then will be processed downwards.

The Aragon framework is based on a same Container hierarchy, where on the top you can find the Kernel container, containing the services provided by the framework. On the second leve the installed modules will create their containers and hook them dynamically to the Kernel container. Using this feature the application context can be extended in the most elegant way. Every container created and hooked to the hierarchy will have full access to the components of the system.

For further information you can consult the Java DOC of the classes from net.nWizard.aragon.toolkit.container and net.nWizard.aragon.toolkit.container.components packages, or see for usage examples in the source-code of the Aragon Framework.

I hope that this small article helps to understand some ideas behind the Aragon Container. I still think that you canot understnad something only from the documentation…you need to try it out(at least this is true for me). So if you need further information about this or other topics around Aragon Framework, feel free to contact me via e-mail.