Inversion of Control

Purpose:
The user of a service should depend on the interface (abstractions) and not on the concrete implementation. The user don't call the service by creating a new instance of a service-implementation. The service is injected in the user instead. The services can be components like Enterprise Java Beans or CDI-Beans with its own lifecycle and scope.

Example: EJB-Service in JEE 6:

1. Create a service interface

@Local
public interface MyService extends Serializable {
 String doSomething();
}

Note: For EJBs, this is not needed anymore and will be created automatically from EJB-Container of your JEE Server. 2. Create an the service implementation

@Stateless(name = "MyService")
public class MyServiceImpl implements MyService {
 
 private static final long serialVersionUID = 2426831807321817571L;

 public String doSomething() {
  return "Das ist ein Test";
 }
}

3. Call service for usage

public class MyBean implements MyService {

 @Ejb
 private MyService service

 public String doSomethingWithService() {
  return service.doSomething();
 }
}

Usage: 

Change Implementation via configuration: In a shop, a payment method is used to pay via card. The implementation may be different depending on the payment methode provider. It is integrated into the shop via configuration.

Use specific instances (states) of compontents: In CDI you can have components with a specific states (like session or appication). In this case, you can use depencency injection to get the specific state. The component is managed by the cdi-container and you have not to care about how get, create and delete the instance of the component.

Exchange implementations at runtime: E.g. with OSGI you have the possibility to reload a component during the java-programm (e.g. an application server like glassfish) is running.

Implementations: Spring, OSGI, JEE CDI (Component Dependency Injection)