User Documentation

One minute description
Two minute tutorial
Five minute introduction
Advanced Topics
FAQ
Container
Components
Terminology
Mock Objects
Inversion of Control Types

Patterns

Inversion of Control 
Dependency Injection 
Constructor Injection 
Setter Injection 
Interface Implementation Separation 
Lifecycle 
Antipatterns

Developer Documentation

 Current build status
How To Contribute
Relative Volunteering
Release Process

Project Information

Slogan
Mailing lists
Source Repositories
Open Issues
Blog entries 
Statistics
Team
Sister Projects
TShirts

Miscellaneous

Differentiators
Nirvana

Full Sitemap

Feeds


Site
News
Differentiators

Authors: Paul Hammant

There are a number of specifications from the last few years that proport to be container/component designs…

Sun specified nearly-IoC Containers & Component designs

It could be said that Sun have created a few container/component designs.......

Enterprise Java Beans

Clearly Entity and Session beans run inside a container. The API is well defined, and to varying degrees of success one can deploy EJB appllications to WebLogic, WebSphere, Orion and JBoss etc. For assembly and configuration, there is high use of element-normal XML . There are some mandated parent objects and interfaces for various to extend and/or implement. Resolution is done by the components themselves via JNDI more often than not.PicoComponents are simpler in they they do not force an extensive XML markup, nor require the implementing of certaing interfaces or extening base classes. Quite importantly the relationship between factory (home), implementation (bean) and interface (remote) parts is much more real in PicoComponents. Lastly, EJB components are nearly impossible to unit-test without much effort.

Servlets

Not so obvious - Servlets are contained by a servlet container. They are generally bundled with (or replaced by) value added propositions like JSP, but it is still a container/component design. High use of XML for assembly and configuration. Servlets have no concept of parent container or the conatainer above that (sometimes EJB) and its provision of components, which is very unfortunate. Servlets have a number of interfaces to honor, none of which is too malignent. Servlets typically deal with external (or parent) components via RMI or JNDI. In more recent releases of EJB, local interfaces rather than RMI may be the mechanism for connection the parent components. WebLogic have always provided an optimizing mechanism for this interoperationAs with EJB, PicoComponents are far simpler. This is probably because they offer no web experience, apart from anything else. Servlets again are not that unit-testable.

Applets

Applets, though presently not so often used, are a good example of Container/Component separations. There is very little XML in use by Applets. Configuration is typically delivered in applet tags in HTML. Applets are granted some access to the parent container, the brower, and its DOM model for pages and other applets. There very little standardisation for Browser as a container.As with EJB, PicoComponents are far simpler. Applets are unit-testable but with a little effort. Complex DOM interoperation is impossible under unit testing.

Non IoC container-like things by various

Mainable (Sun)

public static void main(String[] args) {}


Familiar? Hopefully not Static plays no part in a good IoC container/component design. This includes static launching of Java Webstart (JNLP) applications. If you have to keep mainable functionaility separate your components away from the main() class so they may be instntiated separately. In .NET you'll have to make sure that the application assembly is a small bootstrap to a component one.

Singleton (pattern)

See Singleton antipattern.

Static Factory (pattern)

Used in a similar way the Singleton pattern (and similarly detailed in "Design Patterns"), this allows disparate classes to create/get other components. Very dirty applications result from overuse of static factories.

(TODO: move to antipatterns section?)

JNDI ( Java API )

A huge map of clunkily access components via a very non-IoC mechanism. It has to be strapped with much XML to prevent inappropriate access. This is not IoC because the component reaches out for external component dependancies whenever it feels like. This last fact clouds Serlvets and EJB use.

AWT, Swing, SWT (Java graphic toolkits)

Nice container/component designs. In the case of Swing, perhaps a little difficult for coders to easily assemble applications.

Eclipse (Java grapical application platform)

The Eclipse platform is very compelling. It supports the notion of a pluggable application concept. Each component statically accesses other components via a factory (which at least Paul does not like), though it is clear that some complex classloader magic is going on. The underpinning set of graphical components, SWT , are a simple and elegant design.

Other IoC container / component designs

Avalon-Framework and its containers

Apache hosts a project that has been running for years called Avalon. It has many components that fit that its design and many containers is writtern in Java, with a port underway to C#. Avalon components are characterised by implementation of many optional interfaces. Avalon components are distributed with meta-information in XML in the jar file. More XML is required to assemble components together for the same of a application. Avalon-Phoenix, Excalibur Component Manager (ECM), Avalon-Fortress and Avalon-Merlin are the pertinent containers .

Apache-Avalon requires implementing components to implement a number of interfaces. This has proven historically to be a bit of a turn-off for component writers. Luckily there are no abstract classes that have to be extended by component writers. Those interfaces are :-

Avalon Interface PicoContainer equivalent
LogEnabled Logging agnostic
Contextualizable n/a
Serviceable (used to be called Composable) Arguments in Constructor
Configurable Arguments in Constructor
Parameterizable n/a
Initializable Constructor is eqivalent lifecycle place
Startable Startable
Suspendable n/a
Recontextualizable n/a
Recomposable n/a
Reconfigurable n/a
Reparameterizable n/a
Disposable Disposable


Avalon is a type-1 IoC design. Its flaw is that components written for it cannot be used without an Avalon-Framework compatible container. Many say that the XML that has to accompany each component is also a flaw. Unit-testing of Avalon components is very difficult because it is difficult to manage the components from JUnit.

Carbon

todo