Differences between EJB 3.0 and EJB 2.1
Compared to EJB 2.1, EJB 3.0 simplifies the process of creating Enterprise Java bean applications.
EJB 2.x
Complexities of J2EE 1.4 architecture
Business Layer In the J2EE 1.4 architecture, session beans are used to wrap business logic components, providing them with transactional, distributed, remote and security services. They usually implement a facade pattern to reduce the network traffic among the client and the service provider. Session beans can be accessed by local clients (that means clients resident inside the same JVM™) or remote clients.
Message-driven beans are used to integrate external JMS providers (such as MQSeries®) to enable asynchronous message handling services; they do not contain any business logic.
Session beans and message-driven beans together constitute the business logic layer. We speak about layers, because another fundamental paradigm adopted in the design of these enterprise architecture is the layering, which enables core features such as separation of duties and skills, clustering, and component reuse.
Persistence Layer The other fundamental layer is the so called persistence layer, which is the set of services and components that allow the application data to be persistent in a relational database. The persistence layer can be implemented in these ways:
- Entity beans (container-managed
and bean-managed beans)
- JDBC™ data access objects (DAOs)
- Object-relational mapping (ORM) frameworks
Problems with EJB 2.x specification
- The EJB 2.x specification requires
that the component interface must
extend an interface from the EJB framework package, and the business
logic
implementation class must implement an interface from the EJB
framework
package. This causes a tight coupling between the developer-written
code and
the interface classes from the EJB framework package. This also requires
the
implementation of several unnecessary callback methods (ejbCreate,
ejbPassivate,
ejbActivate) not directly related to the main design goal of the EJB,
and
the handling of unnecessary exceptions.
- EJB deployment descriptors
are overly verbose, complex, and error prone.
- EJBs are difficult
to test, since the application needs a J2EE container
to provide all the services required to correctly run the EJB component.
- The reliance on JNDI every time you have to access a resource
(such as
a data source, or an EJB home reference) is a repetitive and tedious
operation
of J2EE development.
- The container-managed persistence model is complex to develop and manage.
Simplified model in EJB 3.0
The overall architecture of Java EE and EJB 3.0 reflects the simplification of the EJB 3.0 model:
The underlying concept of the EJB 3.0 specification centers on a plain old Java™ object (POJO) programming model that uses Java annotations to capture information that deployment descriptors used to contain. Deployment descriptors are now optional in most cases. Using default values liberally also means that you need to write and maintain less supporting code. This greatly simplifies the programming experience in creating and using EJB 3.0 components. Main features of this simplified model include
- EJBs are now plain old Java
objects (POJO) that expose regular business
interfaces (POJI), and there is no requirement for home interfaces.
- Use of metadata annotations, an extensible, metadata-driven, attribute-oriented
framework that is used to generate Java code or XML deployment descriptors.
- Removal of the requirement for specific interfaces and deployment
descriptors
(deployment descriptor information can be replaced by annotations).
- Interceptor facility to invoke user methods at the invocation
of business
methods or at life cycle events.
- Default values are used whenever
possible (“configuration by exception”
approach).
- Reduction in the requirements for usage of checked
exception.
- A complete new persistence model (based on the JPA standard), that supersedes EJB 2.x entity beans
| Steps to define a stateless session bean in EJB 2.x | Steps to define a stateless session bean inEJB 3.0 |
|---|---|
|
To create a stateless session bean according to EJB 2.x specification, define the following components:
|
To declare a stateless session bean according to EJB 3.0 specification, simply define a POJO:
|
Comparison of EJB 2.1 class plus Deployment Descriptor file with equivalent EJB 3.0 class
The examples in Table 1 are functionally equivalent:
| EJB 2.1 | EJB 3.0 |
|---|---|
|
Java Class public class AccountBean
implements javax.ejb.SessionBean {
SessionContext ctx;
DataSource accountDB;
public void setSessionContext(SessionContext ctx) {
this.ctx = ctx;
}
public void ejbCreate() {
accountDB = (DataSource)ctx.lookup(
"jdbc/accountDB");
}
public void ejbActivate() { }
public void ejbPassivate() { }
public void ejbRemove() { }
public void setAccountDeposit(int empId,
double deposit) {
...
Connection conn = accountDB.getConnection();
...
}
...
}
|
Java Class @Stateless
public class AccountBean implements Account
{
@Resource private DataSource accountDB;
public void setAccountDeposit(int customerId,
double deposit) {
...
Connection conn = accountDB.getConnection();
...
}
...
}
|
|
Deployment Descriptor <session>
<ejb-name>AccountBean</ejb-name>
<local-home>AccountHome</local-home>
<local>Account</local>
<ejb-class>com.example.AccountBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<resource-ref>
<res-ref-name>jdbc/accountDB</res-ref-name>
<res-ref-type>javax.sql.DataSource</res-ref-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
...
<assembly-descriptor>...</assembly-descriptor>
|
Related concepts
Developing EJB 3.0 Applications
Securing enterprise applications
Deploying EJB 3.0 applications
Related tasks