Comments on J2EE Development without EJB (2)

Further thoughts on IoC, particularly, Dependency Injection (DI).

DI is depicted as a mechanism to enable collaborations among objects. But object collaboration mechanism is a very large topic, potentially containing a lot of different patterns, Apache Avalon, Pico Container and Spring etc.. actually are concerned mainly with some more common use cases: one is (1) configuration between managed object and configuration model, and the other is (2) collaboration between business service provider and enabling system service providers.

It will be interesting to properly classify all the collaboration patterns in object-oriented programming. The popular term “design pattern” can be regarded as a collaboration pattern identification effort from the system point of view.

In the configuration case, there are three participants in the pictures: the managed object, the configuration model, and the context. Looking from this perspective, what is in this IoC movement is still the classical pursuit in software architecture: loosely coupling and reusability. It is a separation of managed objects and configuration model. The context (the XML file defining reference relationship of beans in Spring) glues them together. In Spring framework, the context is statically defined and very simple, only includes instance by instance relationship in one JVM between managed object and configuration model. In reality, the context definition mechanism can be very complicated. The context may need to be defined dynamically, and we may also have to consider relationships (1) across JVMs; (2) across class-loaders. For example, the same managed object defined by the class file, when loaded by different class-loader, may need different instances of the same configuration model.

A second example is in integration. Suppose we have a connection object. If we want to add a new system, the configuration of the new connection instance is different from the old one, therefore a new instance of the configuration model is needed.

To make the dynamic context definition possible, a controlling interface and a persistence mechanism for context definition is required. The way those are achieved in the OAM framework I discussed in (1) of this series is as follows: a fourth entity is introduced to manage the configuration model. This fourth one is MBean. Associated with the introduction of mbean, there comes the requirement of synchronization among managed object, configuration model and the mbean. It is achieved through a event notification mechanism.

As a side note, IoC is not really inversion. In the old case, the managed object eagerly looks for the configuration model; in the new case, it is not that the configuration model will look for the managed object. The light-weighted container is acting as a broker, and the governing rule is the defined context.