The major differences i have seen between EJB 2.x and EJB 3.0 versions are as follows :1).

Removal of home interface enabled simple lookup process in ejb 3.0 2). EJB deployment descriptors are not required in ejb3.0 3). Annotations are used in ejb3.0 4). EJB 3.0 entity beans don?t have home and remote interfaces. 5). EJB 3.0 entity beans/JPA becomes local. Remote annotations are not at all supported for entity beans. 6). EJB 3.0 beans don?t implement the standard interfaces like javax.ejb.SessionBean and hence no need to implement the container call back methods like ejbActivate() etc 7). Query is very flexible. Multiple levels of joins are enabled through the refined EJB-QL 8). Can be used with pluggable third party persistence providers 9). Security can be provided either through annotations or through deployment descriptors 10). POJO like EJB 3.0 entities become lightweight and easy to convert from a DAO to Entity bean or vice versa. Since EJB 3 entities don?t need implement any interface.

The major differences i have seen between EJB 2.x and EJB 3.0 versions are as follows :1). Removal of home interface enabled simple lookup process in ejb 3.0 2). EJB deployment descriptors are not required in ejb3.0

3). Annotations are used in ejb3.0 4). EJB 3.0 entity beans don?t have home and remote interfaces. 5). EJB 3.0 entity beans/JPA becomes local. Remote annotations are not at all supported for entity beans. 6). EJB 3.0 beans don?t implement the standard interfaces like javax.ejb.SessionBean and hence no need to implement the container call back methods like ejbActivate() etc 7). Query is very flexible. Multiple levels of joins are enabled through the refined EJB-QL 8). Can be used with pluggable third party persistence providers 9). Security can be provided either through annotations or through deployment descriptors 10). POJO like EJB 3.0 entities become lightweight and easy to convert from a DAO to Entity bean or vice versa. Since EJB 3 entities don?t need implement any interface.

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 typically 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 this 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 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. These requirements create a tight coupling between the developer-written code and the interface classes from the EJB framework package. It 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.

Problems with EJB 2.x specification

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

Table 1. Comparison of steps to create beans in EJB 2.1 and EJB 3.0 Steps to define a stateless session bean in EJB 2.x To create a stateless session bean according to EJB 2.x specification, define the following components:

Steps to define a stateless session bean inEJB 3.0 To declare a stateless session bean according to EJB 3.0 specification, simply define a POJO:

EJB component interface: Used by an EJB client to gain access to the capabilities of the bean. This is where the business methods are defined. The component interface is called the EJB object. There are two types of component interfaces: o Remote component interface (EJBObject):Used by a remote client to access the EJB through the RMI-IIOP protocol. o Local component interface (EJBLocalObject): Used by a local client (that runs inside the same JVM) to access the EJB. EJB home interface: Used by an EJB client to gain access to the bean. Contains the bean life cycle methods of create, find, or remove. The home interface is called the EJB home. The EJBHome object is an object which implements the home interface, and as in EJBObject, is generated from the container tools during deployment, and includes container-specific code. At startup

@Stateless public class MySessionBean implements MyBusinessInterface { // business methods according to MyBusinessInterface ..... }

To expose the same bean on the remote interface, use the @Remote annotation:
@Remote(MyRemoteBusinessInterface.class) @Stateless public class MyBean implements MyRemoteBusinessInterface { // ejb methods .....

Table 1. Comparison of steps to create beans in EJB 2.1 and EJB 3.0 Steps to define a stateless session bean in EJB 2.x time, the EJB container instantiates the EJBHome objects of the deployed enterprise beans and registers the home in the naming service. An EJB client accesses the EJBHome objects using the Java Naming and Directory Interface (JNDI). There are two types of home interfaces: o Remote home interface (EJBHome):Used by a remote client to access the EJB through the RMI-IIOP protocol. o Local home interface (EJBLocalHome): Used by a local client (that runs inside the same JVM) to access the EJB. EJB bean class: Contains all the actual bean business logic. Is the class that provides the business logic implementation. Methods in this bean class associate to methods in the component and home interfaces.

Steps to define a stateless session bean inEJB 3.0

Comparison of EJB 2.1 class plus Deployment Descriptor file with equivalent EJB 3.0 class EJB 2.1 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(); ... } ... }

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>

EJB 3.0 Java Class

@Stateless public class AccountBean implements Account { @Resource private DataSource accountDB; public void setAccountDeposit(int customerId, double deposit) { ... Connection conn = accountDB.getConnection(); ... } ... }

EJB3.0 has No Deployment Descriptor

Related concepts Developing EJB 3.0 Applications EJB modules Editing EJB 3.0 applications Securing enterprise applications Testing EJB 3.0 applications Deploying EJB 3.0 applications Related tasks Creating EJB projects Feedback