A Sampling of EJB 3.1

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 ejb-jar file.

No-interface View

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:

      public class HelloBean {

          public String sayHello() {
              String message = propertiesBean.getProperty("hello.message");
              return message;


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:

   private HelloBean helloBean;


   String msg = helloBean.sayHello();

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 concurrency management.

Simplified Packaging

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 (.ear file) 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 in an ejb-jar file. You now have the option of placing EJB classes directly in the .war file, using the same packaging guidelines that apply to web application classes. This means that you can place EJB classes under the WEB-INF/classes directory or in a .jar file within the WEB-INF/lib directory. The EJB deployment descriptor is also optional. If it's needed, you can package it as a WEB-INF/ejb-jar.xml file.

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:

   public class PropertiesBean {

    private Properties props;
    private int accessCount = 0;

    public String getProperty(String name) { ... }

    public int getAccessCount() { ... }


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 PropertiesBean singleton as follows:

   private PropertiesBean propsBean;


   String msg = propsBean.getProperty("hello.message");

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 as @PostConstruct and @PreDestroy methods:

   public class PropertiesBean {

     private void startup() { ... }

     private void shutdown() { ... }



Sample Application

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 .xml file.

To run the sample application, do the following:

  1. If you haven't already done so, download the Java EE 6 SDK Preview. Also be sure to have an installed version of the Java Platform Standard Edition (Java SE) 6 SDK.
  2. Download the sample application, ejb31-war.war
  3. Start the GlassFish V3 Prelude application server that is packaged with the Java EE 6 SDK by entering the following command:
       <javaee_home>/bin/asadmin start-domain
    where <javaee_home> is where you installed the Java EE 6 SDK.
  4. Deploy the sample application by copying it to the <javaee_home>/domains/domain1/autodeploy directory.
  5. Execute the application by opening a browser and accessing the URL http://localhost:8080/ejb-ejb31-war

    You should see the following output appear in a browser window:

       ejb31-war Servlet
       HelloBean says : Hello, world
       Singleton property access count = 2

You can view the source code for the application in the <javaee_home>/samples/javaee6/ejb/ejb31-war/src directory.

Further Reading

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.

\* As used on this web site, the terms "Java Virtual Machine" and "JVM" mean a virtual machine for the Java platform.


This is a cool technique. I am very excited to use this in my next project. Most welcoming technology

Posted by Reflex Demon on August 04, 2009 at 05:25 PM PDT #

The proposed draft on EJB is excellent. Developer is fully free from the lot of configuration stuff.

Thankyou Ken for sharing the excellent article
on EJB's.

Posted by Kumaraswamy on August 04, 2009 at 05:37 PM PDT #

This is great! I have been an avid user of EJB 3.0 and used them in many of my web applications

Posted by Devlic on August 05, 2009 at 04:09 PM PDT #

i can see that Java EE going to be more flexible but still is not comparable with other open source solutions like spring.

Posted by mohammad on August 06, 2009 at 04:11 PM PDT #

I feel that EJB 3.1 is a step in the right direction. It will allow better productivity and more flexibility for developers using J2EE technologies.

I started to to use EJB 3.0 since last year and compared with EJB 2.1 it was a huge step forward from the point of view of ease of use. EJB 3.1 seems to continue this trend.

Congrats to all the people that made this possible.

Posted by Karl on August 07, 2009 at 09:02 AM PDT #

EJB is getting better as far as its older versions are concerned....way to go EJBs!

Posted by Hammad on August 09, 2009 at 05:37 PM PDT #

Hi Mohammad,

The topic of comparing EE vs. other open source solutions is a large one that isn't easily captured in a short post. However, I will point out that EJB 3.1 addresses many specific features that Spring contains but that were not present in EJB 3.0. Chief among them are :

1. The ability to implement an entire bean using only a single class (the "no-interface" view)

2. Singleton beans

3. Easy use of enterprise beans within a .war

4. Spec-defined EJB JNDI names

5. Spec-defined unit-testing API ( the EJB 3.1 Embeddable API)

6. Startup / Shutdown callbacks

7. Definition of a small subset of EJB 3.1 called "EJB Lite" to be available in a wider range of EE products implementing the Java EE 6 Web Profile.

As you can see EJB 3.1 covers a lot of ground so not all of these were described in this introductory article.

--ken saks

Posted by Ken Saks on August 10, 2009 at 12:12 AM PDT #

EJB is an excellent technology

Posted by gdtesting3 on August 10, 2009 at 08:21 PM PDT #

For me one of the best feature is packaging single EJB as .jar file within the WEB-INF/lib. This will allow one EJB to be represented as OSGi bundle which will totally reduce the risk and will give many additional features.

Posted by Miroslav Nachev on August 11, 2009 at 01:24 AM PDT #

Agree with Ken for new features of EJB3.1, especially
1. The ability to implement an entire bean using only a single class (the "no-interface" view)

2. Singleton beans

3. Easy use of enterprise beans within a .war

the above ones hit the nail on head.

Thanks to all. When does final draft becomes part of EE6 API?

Posted by Abhay on August 17, 2009 at 07:15 AM PDT #

Thanks for the feedback Abhay. The current plan is for Java EE 6 to complete around the end of this year.

Posted by Ken Saks on August 17, 2009 at 07:25 AM PDT #

Does the singleton bean in EJB 3.1 work in clustered environments as well?

Posted by sudharma on September 22, 2009 at 02:39 PM PDT #

to: sudharma

good question. based on the description above singleton will be instantiated once per VM therefore each node of the cluster will have it's own singleton instance?

Posted by Vlad Epshtein on October 14, 2009 at 03:58 AM PDT #

Yes, in a clustered deployment, each server instance would have its own Singleton bean instance. Per-cluster Singletons is something we're considering for a future EJB specification, although vendors are free to support them as a product-specific feature.

Posted by Ken Saks on October 23, 2009 at 12:59 AM PDT #

EJB is really great application for web-development.I think the new version has many good and advanced features for the developers to use.

Posted by externe festplatte on November 09, 2009 at 07:32 PM PST #

EJB 3.1 became really very lightweight
Enterprise framework
//great and nice topic

Posted by guest on November 30, 2009 at 09:40 AM PST #

Why would I need singletons in J2EE? What aspect of service level requirements it would improve?

J2EE Light ... I am speechless ...

Posted by Kostyantyn Oliynyk on November 30, 2009 at 02:03 PM PST #

I started coding in EJB 3.0 for about a year now and if compared to EJB 2.1 you guys made a huge step forward in terms of ease of use. Hope to see better stuff in EJB 3.1..

Posted by gallbladder disease on December 19, 2009 at 06:35 PM PST #

thank you for your article...that is a nice one...i often visit this blog and i enjoy reading all posts...

Posted by dizi izle on January 22, 2010 at 06:50 PM PST #

Post a Comment:
Comments are closed for this entry.



« August 2016