Seems like Inversion of Control is all the rage these days. The Apache Excalibur project is completely based around it. Excalibur uses detailed assembly descriptions to tie services together ... there's no way an Excalibur component can "look up" another component; in Excalibur you explicitly connect services together.
That's the basic concept of Inversion of Control; you don't create your objects, you describe how they should be created. You don't directly connect your components and services together in code, you describe which services are needed by which components, and the container is responsible for hooking it all together. The container creates all the objects, wires them together by setting the necessary properties, and determines when methods are invoked.
More recently, this concept has been renamed Dependency Injection.
There are three different implementation pattern types for IoC:
| type-1 | Services need to implement a dedicated interface through which they are provided with an object from which they can look up dependencies (other services). This is the pattern used by the earlier containers provided by Excalibur. |
| type-2 | Service dependencies are assigned via JavaBeans properties (setter methods). Both Gaderian and Spring use this approach. |
| type-3 | Services dependencies are provided as constructor parameters (and are not exposed as JavaBeans properties). This is the exclusive approach used by PicoContainer, and is also used in Gaderian and Spring. |
Gaderian is a much looser system than Excalibur. Gaderian doesn't have an explicit assembly stage; it wires together all the modules it can find at runtime. Gaderian is responsible for creating services (including core implementations and interceptors). It is quite possible to create service factories that do very container-like things, including connecting services together. gaderian.BuilderFactory does just that, instantiating an object to act as the core service implementation, then setting properties of the object, some of which are references to services and configuration point element data.
In Gaderian, you are free to mix and match type-2 (property injection) and type-3 (constructor injection), setting some (or all) dependencies via a constructor and some (or all) via JavaBeans properties.
In addition, JavaBeans properties (for dependencies) can be write-only. You only need to provide a setter method. The properties are properties of the core service implementation, there is no need for the accessor methods to be part of the service interface.
Gaderian's lifecycle support is much more rudimentary than Excalibur's. Your service implementations can get Gaderian callbacks when they are first created, and when they are discarded, by implementing certain interfaces.
Purist inversion of control, as in Excalibur, may be more appropriate in well-constrained systems containing untrusted code. Gaderian is a layer below that, not an application server, but a microkernel. Although I can see using Gaderian as the infrastructure of an application server, even an Excalibur application server, it doesn't directly overlap otherwise.