EJB 3.1: The EJB Application Gets Simpler, More Flexible, Page 2
EJB Components in WAR File
While annotations and optional deployment descriptors have significantly simplified the development and deployment of enterprise Java applications, the packaging structure of Java EE applications (see Figure 1) raised a problem. Developers had to place EJB components in a separate JAR file, and the file would be packaged along with the WAR file in an EAR file.
Figure 1. Post List Page with Tags: This is how packaging was done prior to EJB 3.1.
WEB-INF\classesdirectory of a WAR file. Figure 2 shows the packaging in EJB 3.1.
Figure 2. EJB 3.1 Packaging Structure: Here is packaging in EJB 3.1.
Asynchronous Session Bean
Enterprise applications typically require asynchronous processing. Message-driven beans were introduced in EJB 2.0 to support asynchronous invocation in a simplified way. However, before using message-driven beans, you must set up other criteria such as messaging systems and the JMS API.
Until EJB 3.1, session bean invocations were always synchronous, irrespective of whether the session bean was local or remote or had no interface invocation. When a client invokes a method on the session bean, the client call is blocked for the duration of the invocation. The control is released after all of the processing is complete.
Beginning with EJB 3.1, a session bean can support asynchronous method invocations. Some methods can be marked as asynchronous in the session bean. Bean methods annotated with
@Asynchronous are invoked asynchronously. When a client invokes a method marked as
@Asynchronous, the container returns control to the client immediately and the processing of the invocation is handled on a separate execution thread.
Asynchronous methods return a
Future<V> object of the
java.util.concurrent API. Most of the requirements for asynchronous processing will have the return type of the method as
void. For a method that is expected to have a return value, the
Future<V> object is returned as a result value. The
Future<V> API (V is the result value of the asynchronous invocation) will allow the client to get the status of the invocation, retrieve the return value of a method, check for an exception, or even cancel the invocation.
If the client receives an exception, it is understood that the container will not be able to service the request for the asynchronous method and the client should try invoking the method again. However, if no exception is received, then the client can expect a return value from the container because of the asynchronous method invocation, which usually will be the
The EJB specification has large set of features for developing a wide variety of enterprise applications. Many enterprise applications do not require the complete set of these features and do not use the full range of EJB APIs. So, EJB 3.1 introduced EJB Lite, a minimal subset of EJB APIs that still includes all the required features for creating an enterprise application.
A carefully selected collection of simple yet powerful EJB features -- without any specialized APIs -- EJB Lite provides vendors with the option to implement a subset of EJB APIs within their products. Applications created with EJB Lite can be deployed in any server that supports EJB technology -- whether it is full EJB or EJB Lite. Embeddable containers support EJB Lite as well.
EJB Lite has the following subset of EJB APIs:
- Session bean components
- Singleton session beans
- Supports only synchronous invocation
- Container-managed transaction and bean-managed transaction
- Declarative and programmatic security
- Support for deployment descriptor (
EJB Lite offers simple and lightweight implementations. It allows you to develop applications with more annotations and much less configuration. The table in Figure 3 summarizes the features supported in the full EJB 3.1 API and in EJB Lite.
Figure 3. EJB 3.1 Full and EJB Lite Feature Comparison: EJB Lite has a subset of the EJB APIs.
Executing EJB in Java SE Environment
EJB 3.1 has an embeddable API that allows EJBs to run in Java SE environments (i.e., the client and the EJB run in the same JVM and class loader). The benefits of having an embeddable API include:
- Better support for testing
- Batch processing
- Usage of the EJB programming model in desktop applications
To run EJBs, EJB 3.1 provides an embedded EJB container and uses JNDI for lookup. The embeddable EJB container provides an environment to manage EJBs with support for a limited set of services. The
javax.ejb.EJBContainer class represents an embeddable container.
The new features introduced in EJB 3.1 bring a lot of advantages to developing enterprise Java applications with EJBs. With the promising features discussed in this article, EJB 3.1 is bound to attract the same developer community support that EJB 3.0 did.
AcknowledgementsThe authors would like to sincerely thank Mr. Subrahmanya (SV, VP, ECOM Research Group, E&R) for his ideas, guidance, support and constant encouragement and Mr. Nitin KL for kindly reviewing this article and providing valuable comments.
About the Authors
Sangeetha S. works as a Senior Technical Architect at the E-Commerce Research Labs at Infosys Technologies. She has over 10 years of experience in design and development of Java and Java EE applications. She has co-authored a book on 'J2EE Architecture' and also has written articles for online Java publications.
Page 2 of 2