Differences are:
1) EJB 3.0 allows developers to program EJB components as ordinary Java objects with ordinary Java business interfaces rather than as heavy weight components like EJB 2 (home, remote).
2) In EJB 3.0 you can use annotation or deployment descriptors but in EJB 2 you have to use deployment descriptors.
3) EJB 3 introduced persistence API for database access. In EJB 2 you can use Entity bean.
4) EJB 3.0 is much faster the EJB2
2). What are the key features of the EJB technology?
3). What is the difference between EJB and RMI
Both of them are java solution for distributed computing.
RMI offers remote access to an object running in another JVM and no other services.
But EJB offers far more services than RMI apart from remote method calling. EJB leverages this remote-object feature of RMI and ORB (RMI-IIOP) which can be called by any COBRA client, but also provides other services such as persistence, transaction management, security, resource management, object pooling and messaging.
4).What are the ways for a client application to get an EJB object?
5). What are the different kinds of enterprise beans?
Stateless session bean- An instance of these non-persistent EJBs provides a service without storing an interaction or conversation state between methods. Any instance can be used for any client.
Stateful session bean- An instance of these non-persistent EJBs maintains state across methods and transactions. Each instance is associated with a particular client.
Entity bean- An instance of these persistent EJBs represents an object view of the data, usually rows in a database. They have a primary key as a unique identifier. Entity bean persistence can be either container-managed or bean-managed.
Message-driven bean- An instance of these EJBs is integrated with the Java Message Service (JMS) to provide the ability for message-driven beans to act as a standard JMS message consumer and perform asynchronous processing between the server and the JMS message producer.
6). What is Entity Bean?
The entity bean is used to represent data in the database. It provides an object-oriented interface to data that would normally be accessed by the JDBC or some other back-end API. More than that, entity beans provide a component model that allows bean developers to focus their attention on the business logic of the bean, while the container takes care of managing persistence,transactions, and access control.
There are two basic kinds of entity beans: container-managed ersistence (CMP) andbean-managed persistence (BMP).
Container-managed persistence beans are the simplest for the bean developer to create and the most difficult for the EJB server to support. This is because all the logic for synchronizing the bean's state with the database is handled automatically by the container. This means that the bean developer doesn't need to write any data access logic, while the EJB server is
supposed to take care of all the persistence needs automatically. With CMP, the container manages the persistence of the entity bean. Vendor tools are used to map the entity fields to the database and absolutely no database access code is written in the bean class.
The bean-managed persistence (BMP) enterprise bean manages synchronizing its state with the database as directed by the container. The bean uses a database API to read and write its fields to the database, but the container tells it when to do each synchronization operation and manages the transactions for the bean automatically. Bean-managed persistence gives the bean developer the flexibility to perform persistence operations that are too complicated for the container or to use a data source that is not supported by the container.
7). Why does EJB needs two interfaces(Home and Remote Interface)?
There is a pure division of roles between the two .
Home Interface is the way to communicate with the container which is responsible for creating , locating and removing beans and Remote Interface is the link to the bean that allows access to all methods and members
EJBContext is an interface that is implemented by the container, and it is also a part of the bean-container contract. Entity beans use a subclass of EJBContext called EntityContext. Session beans use a subclass called SessionContext. These EJBContext objects provide the bean class with information about its container, the client using the bean and the bean itself. They also provide other functions. See the API docs and the spec for more details
9). Does the container create a separate instance of the generated EJBHome and EJBObject classes?
The EJB container maintains an instance pool. The container uses these instances for the EJB Home reference irrespective of the client request. While referring the EJB Object classes the container creates a separate instance for each client request. The instance pool maintenance is up to the implementation of the container. If the container provides one, it is available otherwise it is not mandatory for the provider to implement it. Having said that, yes most of the container providers implement the pooling functionality to increase the performance of the application server. The way it is implemented is again up to the implementer.
A session in a Servlet, is maintained by the Servlet Container through the HttpSession object, that is acquired through the request object. You cannot really instantiate a new HttpSession object, and it doesn't contains any business logic, but is more of a place where tostoreobjects.
A session in EJB is maintained using the SessionBeans. You design beans that can contain business logic, and that can be used by the clients. You have two different session beans: Stateful and Stateless. The first one is somehow connected with a single client. It maintains the state for that client, can be used only by that client and when the client "dies" then the session bean is "lost".
A Stateless Session Bean doesn't maintain any state and there is no guarantee that the same client will use the same stateless bean, even for two calls one after the other. The lifecycle of a Stateless Session EJB is slightly different from the one of a Stateful Session EJB. Is EJB Container's responsibility to take care of knowing exactly how to track each session and redirect the request from a client to the correct instance of a Session Bean. The way this is done is vendor dependant, and is part of the contract.