X

A Sampling of EJB 3.1

Guest Author

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:



   @Stateless
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:



   @EJB
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.

Singletons

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:



   @Singleton
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:



   @EJB
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:



   @Singleton
@Startup
public class PropertiesBean {
@PostConstruct
private void startup() { ... }
@PreDestroy
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.

Join the discussion

Comments ( 19 )
  • Reflex Demon Wednesday, August 5, 2009

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


  • Kumaraswamy Wednesday, August 5, 2009

    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.


  • Devlic Wednesday, August 5, 2009

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


  • mohammad Thursday, August 6, 2009

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


  • Karl Friday, August 7, 2009

    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.


  • Hammad Monday, August 10, 2009

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


  • Ken Saks Monday, August 10, 2009

    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


  • gdtesting3 Tuesday, August 11, 2009

    EJB is an excellent technology


  • Miroslav Nachev Tuesday, August 11, 2009

    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.


  • Abhay Monday, August 17, 2009

    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?


  • Ken Saks Monday, August 17, 2009

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


  • sudharma Tuesday, September 22, 2009

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


  • Vlad Epshtein Wednesday, October 14, 2009

    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?


  • Ken Saks Friday, October 23, 2009

    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.


  • externe festplatte Tuesday, November 10, 2009

    Hi,

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


  • guest Monday, November 30, 2009

    EJB 3.1 became really very lightweight

    Enterprise framework

    //great and nice topic


  • Kostyantyn Oliynyk Monday, November 30, 2009

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

    J2EE Light ... I am speechless ...


  • gallbladder disease Sunday, December 20, 2009

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


  • dizi izle Saturday, January 23, 2010

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


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.