by Ken Saks
The latest update to Enterprise JavaBeans (EJB) technology,
EJB 3.1, is nearing completion.
A Proposed Final Draft of
the EJB 3.1 specification is now available. The main goals of this new specification are to further simplify development
using EJB technology and to add a number of long-requested features such as singleton beans.
EJB 3.1 will be included in Java Platform, Enterprise Edition (Java EE) 6. A preview version of Java EE 6 is currently
available for download. The preview version includes
a nearly complete implementation of EJB 3.1 and a sample application that takes advantage of some of the new features
in EJB 3.1.
This Tech Tip introduces a few of these exciting new EJB 3.1 capabilities. It also includes instructions on how
to run the EJB 3.1 sample application in the Java EE 6 preview.
Ease of Development
EJB 3.1 builds on the ease-of-use enhancements in EJB 3.0 by providing many new ways to improve developer productivity.
Chief among these are the ability to implement session beans using only a bean class and the ability to package enterprise
bean classes directly in a
.war file, without the need for an
The EJB 3.0 local client view is based on a plain old java interface (POJI) called a local business interface.
A local interface defines the business methods that are exposed to the client and that are implemented on the bean class.
Although this separation of interface and implementation is a well-accepted approach to application design, the separation
sometimes is unnecessarily cumbersome and adds little value. This is especially true for very fine-grained
components with closely coupled clients that are collocated in the same module.
Developers have asked for a way to get the same enterprise bean functionality without having to write
a separate business interface. The EJB 3.1 specification addresses this by making local business interfaces optional.
The result is the no-interface local view.
The no-interface view has the same behavior as the EJB 3.0 local view, for example, it supports features such as
pass-by-reference calling semantics and transaction and security propagation. However, a no-interface view does not require
a separate interface, that is, all public methods of the bean class are automatically exposed to the caller. By default,
any session bean that has an empty
implements clause and does not define any other local or remote client views,
exposes a no-interface client view.
For example, the following session bean exposes a no-interface view:
As is the case for a local view, the client of a no-interface view always acquires an EJB reference -- either through injection
or JNDI lookup. The only difference is that the Java type of the EJB reference is the bean class type rather than the type of
a local interface. This is shown in the following bean client:
Note that even though there is no interface, the client cannot use the
new() operator to explicitly instantiate
the bean class. That's because all bean invocations are made through a special EJB reference, or proxy, provided by the container.
This allows the container to provide all the additional bean services such as pooling, container-managed transactions, and
The EJB specification has always required that enterprise beans be packaged in an enterprise module called an
ejb-jar file. Since it is common for Java EE web applications to use enterprise beans, this packaging requirement
can be burdensome. These applications are forced to use a web application archive (
.war file) for
the web application, an
ejb-jar file for the enterprise beans, and an enterprise archive (
that encompasses the other packages. This packaging approach is further complicated by the special handling required for
any classes or resources that must be shared between the modules.
The EJB 3.1 specification addresses this problem by removing the restriction that enterprise bean classes must be packaged
ejb-jar file. You now have the option of placing EJB classes directly in the
using the same packaging guidelines that apply to web application classes. This means that you can place EJB classes under
WEB-INF/classes directory or in a
.jar file within the
directory. The EJB deployment descriptor is also optional. If it's needed, you can package it as a
New EJB 3.1 Features
Because of the concentrated focus on ease of use in EJB 3.0, there was not enough time to add many of the other
features that developers have requested. The EJB 3.1 specification adds a number of these features to the EJB API.
Four of the new features are singleton session beans, application initialization/shutdown callbacks,
asynchronous session bean invocations, and automatic EJB timers. This section describes singleton session beans
and application initialization/shutdown callbacks.
A long-standing omission in the EJB API has been the ability to easily share state between multiple instances
of an enterprise bean component or between multiple enterprise bean components in the application. By contrast, the
Java EE web application programming model has always provided this type of capability through a
ServletConfig object. In EJB 3.1, this omission has been addressed with the introduction of
singleton beans, also known as singletons.
A singleton is a new kind of session bean that is guaranteed to be instantiated once for an application in
a particular Java Virtual Machine (JVM)\*. A singleton is defined using the
@Singleton annotation, as shown in the following code example:
Because it's just another flavor of session bean, a singleton can define the same local and remote client views
as stateless and stateful beans. Clients access singletons in the same way as they access stateless and stateful
beans, that is, through an EJB reference. For example, a client can access the above
singleton as follows:
Here, the container ensures that all invocations to all
PropertiesBean references in the same JVM are serviced
by the same instance of the
PropertiesBean. By default, the container enforces the same threading
guarantee as for other component types. Specifically, no more than one invocation is allowed to access a particular
bean instance at any one time. For singletons, that means blocking any concurrent invocations. However, this is just the
default concurrency behavior. There are additional concurrency options that allow more efficient concurrent access to
the singleton instance.
Application Startup/Shutdown Callbacks
The introduction of singletons also provides a convenient way for EJB applications to receive callbacks during application
initialization or shutdown. By default, the container decides when to instantiate the singleton instance. However,
you can force the container to instantiate the singleton instance during application initialization by using the
@Startup annotation. This allows the bean to define a
@PostConstruct method that is guaranteed
to be called at startup time. In addition, any
@PreDestroy method for a singleton is guaranteed to be called
when the application is shutting down, regardless of whether the singleton was instantiated using lazy instantiation
or eager instantiation. In lazy instantiation, the singleton isn't instantiated until it's method's are first needed.
In eager instantiation, the singleton is instantiated at startup time whether or not it gets used.
Here is an example that shows part of a singleton that includes a
@Startup annotation as well
The Java EE 6 SDK Preview release includes an
application that uses each of the EJB 3.1 features covered in this tip. The application is composed of a servlet,
a singleton session bean, and a stateless session bean. Each session bean exposes a no-interface
view. The singleton defines a callback that is called by the container during application initialization.
Both the servlet and stateless bean use the singleton to access common application configuration information.
When the servlet is accessed, it invokes both session beans and prints some messages containing the return values.
The entire application is packaged within a
.war file, without any
To run the sample application, do the following:
<javaee_home>is where you installed the Java EE 6 SDK.
You should see the following output appear in a browser window:
You can view the source code for the application in the
For more information, see the following resources:
About the Author
Ken Saks is the Specification Lead for EJB 3.1 and a Senior Staff Engineer in the Java EE team at Sun.
Read his blog.