EJB 2.1 vs EJB 3

Problems with EJB 2.x specification

• . 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   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 ) not directly related to the main design goal of the EJB, and the handling of unnecessary exceptions.
• 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

• 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 container-managed persistence model is complex to develop and manage.

From EJB 3.0

• 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.so there is no requirement for home interfaces.

• Interceptor facility to invoke user methods at the invocation of business methods or at life cycle events.

• 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