One of the key design principles behind Avalon is the principle of Inversion of Control. Inversion of Control is a concept promoted by one of the founders of the Avalon project, Stefano Mazzocchi. The principle enforces security by design.
It is difficult to track down one paper that defines this pattern at length, so here are a couple of different definitions of Inversion of Control.
The Framework plays the role of the main program in coordinating and sequencing events and application activity.
A designer sets up a chain among objects that can all react to certain messages in a delegation hierarchy. There is one major semantic detail: Inversion of Control refers to a parent object controlling a child object. With this distinction, the SAX API is not considered Inversion of Control because its purpose is to send information from a source to a handler.
There are a couple of different analogies that make understanding Inversion of Control easier. We experience this in many different ways in regular life, so we are borrowing the form in code. One analogy is called the "Chain of Command" in the military.
This is probably the clearest parallel to Inversion of Control. The military provides each new recruit with the basic things he needs to operate at his rank, and issues commands that recruit must obey. The same principle applies in code. Each component is given the provisions it needs to operate by the instantiating entity (i.e. Commanding Officer in this analogy). The instantiating entity then acts on that component how it needs to act.
There are some deficiencies in this analogy as some military or ex-military people have explained to me. In the military, any Commanding Officer can issue commands to anyone under his or her rank. In the development world, to ensure proper security, this is not a pattern you want in your software. In Avalon, Inversion of Control (IoC) is from one parent (controlling) object to a child (controlled) component. A parent may have many children, but children only have one parent.
Inversion of Control is applied in a very simple manner. Basically, it means that the component architecture employs a passive structure. See the following code:
class MyComponent
implements LogEnabled
{
Logger logger;
public enableLogging(Logger newLogger)
{
this.logger = newLogger;
}
myMethod()
{
logger.info("Hello World!");
}
}
The parent of MyComponent instantiates MyComponent, sets the Logger, and calls myMethod. The component is not autonomous, and is given a logger that has been configured by the parent.
The MyComponent class has no state apart from the parent, and has no way of obtaining a reference to the logger implementation without the parent giving it the implementation it needs.
A big advantage of IOC for server applications is that it promotes security. You can read an analysis about this here .