EJB3.1概述

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.