Now the question is, whether to use EJBs or CDI managed beans.

In general, EJBs ship more functionality that is already usable out of the box. CDI managed beans offer a somewhat lighter alternative. What are the main differences between these technologies and how does it affect the developer's work?

The first difference are the scopes. EJB session beans are either stateless, that is, active during the duration of the client request, stateful, that is, active during the lifespan of a client's HTTP session, or singletons. CDI managed beans come with similar scopes plus more possibilities, such as adding custom scopes and the default dependent scope which is active depending on the lifespan of its injection point. The topic Scopes will handle bean scopes more detailed.

Another difference between EJBs and CDI beans is that EJBs implicitly comprise certain cross-cutting concerns, such as monitoring, transactions, exception handling, and managing concurrency for singleton beans. For example, calling an EJB business method implicitly starts a technical transaction, which is active during the method execution and which integrates datasources or external systems.

Also, stateless EJBs are pooled after usage. This means that after a stateless session bean's business method has been invoked, the bean instance can and will be reused from the container. Due to this fact, EJBs perform a little better than CDI beans, which are instantiated every time their scope requires it.

Practically, the technical differences don't impact the developer's work too much. Besides using different annotations, both technologies can be used in the same look and feel. The direction of Java EE moves toward a more open choice of these two; for instance, since Java EE 8 it's possible to handle asynchronous events solely with CDI, not just EJB.

The integration of functionality that CDI provides is, however, one of the biggest features of the Java EE APIs. Just alone dependency injection, CDI producers, and events are effective means to tackle various situations.

The single most used CDI feature is dependency injection using the @Inject annotation. The injection is built in such a way that no matter which Java EE technology manages the beans, it just works for developers. You can mix and match CDI beans and EJBs with all scopes; the framework will take care of which beans are instantiated or used in which scope, respectively. This enables a flexible usage, such as cases when beans with a shorter scope are injected into longer scoped beans; for example, when a session scoped bean is injected into a singleton.

This feature supports the business domain in such a way that boundaries and controls can just inject required dependencies without worrying about instantiating or managing them.

The following code demonstrates how a boundary implemented as stateless session bean injects the required controls.

import javax.ejb.Stateless;
import javax.inject.Inject;

@Stateless
public class CarManufacturer {

    @Inject
    CarFactory carFactory;

    @Inject
    CarStorage carStorage;

    public Car manufactureCar(Specification spec) {
        Car car = carFactory.createCar(spec);
        carStorage.store(car);
        return car;
    }
}

The CarManufacturer class represents a stateless EJB. The injected CarFactory and CarStorage beans are realized as dependent scoped CDI beans that will be instantiated and injected into the EJB. The Java EE platforms simplifies dependency resolution by enabling to use @Inject to inject any project-specific beans. This was not always the case; In the past, the @EJB annotation was used to inject EJBs. @Inject simplifies the usage within Java EE.

Attentive readers may have noticed the field-based injection with package-private Java scopes. Field-based injection has the least impact on the contents of a class - since a custom constructor can be avoided. Package-private visibility enables developers to set and inject dependencies in a test scope. We will cover this topic and potential alternatives in Chapter 7, Testing.