At the core of the Avalon framework is the component. We define it as "a passive entity that performs a specific role". This is important to grasp because it requires a specific way of thinking.
John Donne wrote, "No man is an island." to communicate that we are all interdependent. The same is true for the component. That is why there are different concerns regarding the component. In the section on roles we specified one of the concerns: the role. The concerns directly supported by the Avalon Framework are: configuration, external component use, management, and execution.
We used to have a marker interface component. This has been deprecated because requiring all components extend this interface makes integrating Avalon with other component systems like CORBA very cumbersome.
As you might have guessed, each one of these concerns has a separate interface that describes that concern. We will delve deeper into the interfaces and the reasoning behind them in other sections. It is important to know the order of precedence for the concerns so that you know the overall contracts of how they are put together.
The contract surrounding this order means that the methods defined by each of those interfaces are called in a specific order by the object that created the component. Each interface represents a narrow view of the component or object being controlled.
Notice that each interface is separate from Component, so you can use them for simple objects.
In Avalon, Serviceable is defined as an active entity that controls or uses components. Its best analogy is that of a musical composer. The musical composer chooses instruments (components) by their role in the symphony (system) and tells them which notes to play.
The Avalon Serviceable follows the principles of Inversion of Control, and is assigned a Service Manager. Within this section we will discuss how to look up specific components, and then how to prepare the ServiceManager for the Serviceable.
compose
method must ignore all subsequent
requests to set the ServiceManager after it is successfully set.
lookup
method will look up the component based on the
fully qualified name (FQN) of the work interface (Role). See the following
example:
final MyComponent component = (MyComponent)manager.
lookup( "com.mycompany.myproject.MyComponent" );
It is important to note that role is not the same thing as functional
equivalence. In other words, if you have a MailSpooler that is functionally
equivalent to a FileStore (they do the same thing), it does not mean that
they perform the same role. The FileStore is used to store objects to
files, and the MailSpooler is used to temporarily store messages until
they are sent. Thus they are separate roles. Some containers require
that the interface name match the key used to lookup component. In this
situation you may need to create a new interface that does nothing
more than extend another interface and add a new role.
It is the responsibility of the entity that creates the Serviceable to give it a ServiceManager with all of the Roles populated. If you create your own implementations of the ServiceManager and ServiceSelector then you have the liberty of deciding how to populate them. Keep in mind that there are default implementations included, and you should model their behavior as much as possible.
put
to populate
the ServiceManager. One feature of the DefaultComponentManager is that
it can cascade. In other words, if the role is not found in this ServiceManager,
the default implementation will look in the parent ServiceManager.
For the paranoid developer, the cascading feature of the ServiceManager
can be seen as a security hole as opposed to a usability enhancement. You
are free to create your own implementation that does not use the cascading
feature--but you have to manually populate it with anything that would
have been in the parent ServiceManager that your child Serviceable needs.
Truth be told, there is very little risk due to the set-once contract for
ComponentManagers. The method is never exposed to hostile agents before
the ServiceManager is set.
put
to populate the ServiceSelector.
The ServiceSelector does not have the cascading feature of the ServiceManager,
nor should it. A ServiceSelector simply holds a number of components that
implement the same role--there really is no need to cascade.
After the ServiceSelector is populated, you must put it in the ServiceManager.
Please use the role of the component you are selecting, not the role of the selector
itself. An acceptable convention is to add the "Selector" name to the end of the
role you are looking up. Just be consistent.
The container is the entity that manages your components. It handles things like loading of configuration files, resolution of dependencies, component management, component isolation, and lifecycle support.
The container is not formalized in the form of an interface or contract within Avalon Framework, though it might be at some point in the future. The informal contract for the container is that it has the ability to host any fully Avalon-Framework compliant component. Most current containers place additional requirements on the component.