You may have witnessed some of the J2EE frameworks provide a technique to get dynamically bound plain objects by making them bind to some features of the framework outside of the plain objects. This technique is called as the IoC or Inversion of Control. If we have to know about the meaning of this term let us emphasize on what inversion depicts in aspect of implementing some features in plain objects.
Suppose I have some functionality of my J2EE application in my model which is nothing but a simple POJO. Now I want this POJO to be incorporated into a web tier which is an MVC (Model View Controller) Architecture. The last thing I would want to do is modify the source of the model, view or controller and put in some additional code which would do this integration. But suppose I choose a framework in such a way that I put what exactly is to be done by the POJO in the MVC architecture in a simple XML config file and then put the config file in the framework and the framework does the rest of the integration work.
This means that the framework injects the special features in my MVC architecture for integration itself, which is called as the Dependency Injection (DI). The framework which exhibits such a capability is called an IOC framework. This is because it inverses the normal developmental procedure.
According to the normal developmental behavior a developer would have to make some special modules and insert code into his source for invoking such modules. In this fashion the control would be in the hands of the developer who is making such an application. Such a control brings in a lot of risks and can introduce bugs due to ignorance of standard principles. This also poses a lot of maintenance problems since the design details have to be known as the creator has made them. This sometimes reduces the flexibility to make the application more scalable.
But due to Dependency Injection feature of the IoC framework it is not the developer who makes the integration but it is the framework which takes the responsibility of the integration. In this way the developer becomes free from the integration introduced errors and dependency issues. The framework now controls the flow thus making an inversion of control.
An article at java boutique says,
The fundamental goal of IoC is to achieve decoupling between two separate objects. You inject the dependency at some stage, typically using a top-level assembler component. Now, this assembler component obviously needs to know the dependencies before it can inject the correct ones to the various objects.
and concludes as,
IoC is a powerful technique you can use to achieve a highly decoupled system in which an application can be assembled by gluing different service components in a configurable manner. No doubt, this leads to a very flexible application, which can be tailored to different environments with minimum re-engineering
IoC is the most efficient way to work in an application removing the hard coding analogy which is attached to application integration and makes the code more easier to debug and the most important to maintain.
Types of IoC
The article on IoC by Mani Malarvannan gives a nice description on the types of IOC and their advantages and disadvantages. A brief summary of them can be stated as follows:
advantage – No need of knowing the details of the implementation class
disadvantage – Exposes all the properties of an object to the outside world when using a setter method
advantage – Only the creator knows about the referenced object
disadvantage – You should have prior knowledge on how the object is to be created.
advantage – Doesn’t need an external configuration file
disadvantage – Interface of any 3rd party API ties your application to the specific IoC framework
Popular frameworks available for IoC
A widely used IoC framework is the Spring framework in J2EE applications. This framework spawns over the entire application domain be it the web tier, the business tier or the persistence tier. For each tier you can either use the default implementations of Spring or integrate with your existing architecture which can involve a whole lot of different frameworks. For example, Spring can be integrated with AJAX, JSF , Struts , etc in the web tier, In the business tier Spring can integrate with EJB’s and on the persistence tier it can be configured to work with hibernate etc.
Spring provides its own AOP architecture but you are free enough to make it work efficiently with AspectJ or AspectWerkz. The Spring framework is an open source framework backed by a strong community of programmers who make the framework robust and it had been supported by many big J2EE vendors like BEA , IBM, etc.
Recenlty JBOSS (an open source community) launched its own clone of Spring called as SEAM. The features are similar to what Spring. Google has joined the bandwagon and has introduced Guice (pronounced Juice) which it claims as being a lightweight framework than Spring, but also admits that it doesn’t yet support all the features that Spring provides.
IoC is a very systematic and smart way of programming an application. Especially when it comes down to integrating your modules. At the end of day who ever wants to sit late night over a cup of coffee debugging some crappy hard coded logic of integration?