EJB 3.1: The EJB Application Gets Simpler, More Flexible

The Enterprise JavaBeans (EJB) 3.0 specification made the developer's life easier with simplicity-focused initiatives such as removing the home interface and ease-of-development features such as annotations. As a result, it was very well received and highly adopted by the enterprise Java developer community. The latest release of the spec -- EJB 3.1 -- makes development even simpler with conveniences such as making business interfaces optional, a feature that makes EJBs look very similar to a normal POJO.

Apart from that addition, EJB 3.1 introduced several other interesting features, such as Singleton beans, easy EJB packaging, asynchronous session beans, the ability to run EJBs in a Java SE environment, and the concept of EJB Lite.

In this article, I introduce these new features in EJB 3.1 and discuss each one with code examples. If you are new to EJB and want to learn more about the 3.1 version of the spec, this article can serve as a good starting point. EJB veterans will be able to appreciate the drill down on the new features.

Removal of Local Business Interface

EJB 3.0 made enterprise Java application development easier by introducing POJO-based development and removing home interfaces. EJB 3.1 goes one step further and makes even the business interface optional. Even though interface-based programming promotes good loosely coupled application development, interfaces often are written only when they are needed.

As you can see, making business interfaces optional provides client-to-session-bean access without a separate local business interface. However, it is important to understand that business interface are optional only for local clients; remote clients require them.

Singleton Beans

EJB 3.1 also introduced a new type of bean, the Singleton bean. The primary goal of Singleton beans was to enable application-wide data sharing and to support concurrent access. With Singleton beans, the EJB specification now provides a flexible concurrency option.

By marking a session bean as Singleton, you share a single session bean instance between clients and enable it to support concurrent access. When a bean is marked as Singleton, the container guarantees a single instance per JVM that is shared across the application tier. This feature can be used for effective caching as well, as Singleton beans can cache state across the application tier.

Singleton beans, which are like any other EJB, are POJOs that are marked as Singleton beans with the @Singleton annotation. Optionally, the bean can be marked as a Singleton using a deployment descriptor. In effect, Singleton beans are like stateless session beans except that they are not pooled and there can be only one Singleton bean instance per JVM.

Flexible Concurrency

Singleton beans also pave the way for flexible concurrency options. All Singleton beans by default are transactional and thread safe, and they are never passivated. Concurrency is managed either by the container or by the bean, with the default concurrency manager being the container. The annotation @ConcurrencyManagement(CONTAINER) is used for container-managed concurrency, and @ConcurrencyManagement(BEAN) is used for bean-managed concurrency. EJB 3.1 introduces concurrency annotations to perform locked read and write operations on the getter and setter methods. Annotations like @Lock(READ) and @Lock(WRITE) are used to restrict the read/write access on the methods by concurrent clients.

Singleton beans help you maintain application state, similar to what the Servlet application scope object tries to do. Singleton beans are useful for sharing state across the application, when multiple threads are accessing the bean concurrently and when a bean must perform some tasks during application startup and shutdown.