Differences between EJB1.1 and EJB2.0

EJB 2.0 introduces support for message driven beans, new home interface method syntax, local interfaces and also enhances the container managed persistence model defined in EJB 1.1

A. Message Driven Beans:
EJB 2.0 integrates JMS (Java Messaging Service) Technology with EJB architecture. So there is a new kind of bean called MDBs (in addition to Session and Entity Beans).
JMS sends and receives text messages of specified format between disparate systems and have things like queues that hold messages while they wait to be transmitted and received.

B. Home Interface Methods:
The EJB 2.0 specs provide more freedom of naming create methods. In 1.1 specs you have to name all create methods “create” but in EJB 2.0 you can name it anything staring with “create”. eg. “createNewAccount”, etc
In EJB 2.0 we can write business methods in the home interface- if the methods are not specific to the instance of the bean (in a way these methods can be called static). Previously in EJB 1.1 the home interface would only contain “create” and “find” methods and no business methods.

C. Local Interfaces:
EJB 2.0 provides for local interfaces in addition to the traditional “remote interfaces”. This gives us the option of leveraging the other advantages of EJBs without being “forced” to build a distributed system.
In local interfaces the Home and Remote interfaces are not remote objects. They are regular objects in the same JVM.
Using local interfaces can improve performance, but in coding one must be aware that
• Parameters are passed by reference rather than by copy, so object instances passed through a local invocation can be shared by the client and component. If the component modifies the object, the client sees the changes.
• Local interfaces are not location transparent. The called component must be hosted on the same server process as the calling component

D. In EJB 1.1 the specification did not include the XML syntax for specifying CMP related settings. In that case, Application servers usually used their own specific xml files such as jboss.xml or weblogic-ejb.jar.xml to contain meta-data.

E. In EJB 2.0 the CMP information is included in the regular ejb-jar.xml that follows the EJB 2.0 specified syntax. The deployment descriptors more fully describe the persistent fields in the bean and the required database queries.
This enables CMPs to work across application server without any customization in configuration files. Simply dropping a jar file from one vendor’s application server to another vendor’s application server should make the CMPs work without having to make any changes./

CMP entity bean in EJB 2.0

EJB 2.0 introduced the bean model in which the programmer writes the code for the entity bean in a super class devoid of any jdbc. The container subclasses this bean and generates the jdbc itself. Thus there is a clear separation between the business logic and the jdbc.The actual bean is a combination of this subclass and super class. EJB 1.1 does not require such subclassing. EJB 2.0 on the other hand must support both these models.
In EJB 2.0 the superclass does not have any declared fields. On the other hand the persistent fields are container generated in the subclass. The subclass not the super class implements the get/set methods. The super class on the other hand contains empty abstract method declarations and the super class itself is declared abstract.
Any method in the super class that needs to use instance variables for some operation has to call these abstract get/set methods instead. The ejbCreate method in the entity bean (super class) sets the value of the primary keys by calling the corresponding set methods instead of initializing the instance variables unlike EJB 1.1. The container knows which fields are container managed from the information in the deployment descriptor ejb-jar.xml. Finder methods are container generated from the information in the deployment descriptor.