Enterprise Java Beans (EJB) is a specification which defines a component architecture for developing distributed systems. Applications written using the Enterprise JavaBeans architecture are resusable,scalable, transactional, and secure. Enterprise Java Bean's allow the developer to only focus on implementing the business logic of the application.

There are 3 types EJB's and they are:
1. Entity Bean's
2. Session Bean's
3. Message Driven Bean's(MDB's)

There are 2 types Entity bean's and they are:
1. Container Managed Persistence(CMP) Entity Bean's
2. Bean Managed Persistence(BMP) Entity Bean's

There are 2 types Session bean's and they are:
1. Statefull Session Bean's
2. Stateless Session Bean's

There are no different kinds of Message driven beans.

Both the enterprise bean and the java bean are designed to be highly reusable. But other than being reusable there is no similarity between them. Java bean is mostly a simple client-side component whereas enterprise bean is a complex server side component.

3 java files has to be provided by the developer. They are:
1) an Home Interface
2) a Remote Interface
3) And a Session Bean implementation class.

Home interface contains factory methods for locating, creating and removing instances of EJB's.

Remote interface defines the business methods callable by a client. All methods defined in the remote interface must throw RemoteException.

EJB doesn't allow the client to directly communicate with an enterprise bean. The client has to use home and remote interfaces for any communication with the bean. The Home Interface is for communicating with the container for bean's life cycle operations like creating, locating,removing one or more beans. While the remote interface is used for remotely accessing the business methods.

Callback methods are bean's methods, which are called by the container. These are called to notify the bean, of it's life cycle events.

We have to specify the it in the deployment descriptor(ejb-jar.xml) using tag.

The process of transferring an enterprise bean from secondary storage to memory.

The process of transferring an enterprise bean from memory to secondary storage.

An re-entrant Entity Bean is one that can handle multiple simultaneous, interleaved, or nested invocations which will not interfere with each other.

To have a consistent interface, so that there is no different interface that you need to implement for Stateful Session Bean and Stateless Session Bean. Both Stateless and Stateful Session Bean implement javax.ejb.SessionBean and this would not be possible if stateless session bean is to remove ejbActivate and ejbPassivate from the interface.

EJBContext is an object that allows an enterprise bean to invoke services provided by the container and to obtain the information about the caller of a client-invoked method.

EJB Container implements the EJB component contract of the J2EE architecture. It provides a runtime environment for enterprise beans that includes security, concurrency, life cycle management, transactions, deployment, naming, and other services. An EJB Container is provided by an EJB Server.

Entity Bean is an enterprise bean that represents persistent data maintained in a database. An entity bean can manage its own persistence or can delegate this function to its container. An entity bean is identified by a primary key. If the container in which an entity bean is hosted crashes, the entity bean, its primary key, and any remote references survive the crash.

Primary Key is an object that uniquely identifies an entity bean within a home.

Primitive data type cannot be directly used as primary key, it should be wrapped using a wrapper class.

Deployment Descriptor is a XML file provided with each module and application that describes how they should be deployed. The deployment descriptor directs a deployment tool to deploy a module or application with specific container options and describes specific configuration requirements that a deployer must resolve.

1. New CMP Model. It is based on a new contract called the abstract persistence schema, that will allow to the container to handle the persistence automatically at runtime.
2. EJB Query Language. It is a sql-based language that will allow the new persistence schema to implement and execute finder methods.
3. Message Driven Beans. It is a new bean type, that is introduced to handle asynchronous messaging.
4. Local interfaces. Enabales beans in the same EJB Container to communicate directly.
5. ejbHome methods. Entity beans can declare ejbHome methods that perform operations related to the EJB component but that are not specific to a bean instance.

Local Interfaces are new mechanism introduced in EJB 2.0 specification which enables components in the same container to bypass RMI and call each other's methods directly. In general, direct local method calls are faster than remote method calls. The downside is a loss of flexibility: because bean and client must run in the same container, the location of the bean is not transparent to the client (as it is with remote interfaces). remote interfaces pass parameters by value, while local interfaces pass them by reference.

Yes.

EJB 2.0 allows entity beans to declare ejbHome methods in the home interface. These methods perform operations that are not specific to a particular bean instance.

A transaction is a sequence of operations that must all complete successfully, or leave system in the state it had been before the transaction started.

ACID is the acronym for the four properties guaranteed by transactions: atomicity, consistency, isolation, and durability.
Atomic : All or nothing. If a transaction is interrupted, all previous steps within that transaction are undone.
Consistent : The state of objects and/or the state of tables within a database move from one consistent state to another consistent state.
Isolated : What happens within one transaction should not affect or be visible within another transaction.
Durable : The effects of a transaction are persistent.

Transaction management is specified in the deployment descriptor(ejb-jar.xml) using <transaction-type> tag.

In an enterprise bean with container-managed transactions, the EJB container sets the boundaries of the transactions. You can use container-managed transactions with any type of enterprise bean: session, entity, or message-driven. Container-managed transactions simplify development because the enterprise bean code does not explicitly mark the transaction's boundaries. The code does not include statements that begin and end the transaction.

We should not invoke any method that might interfere with the transaction boundaries set by the container. The list of restricted methods are as follows:
1. The commit, setAutoCommit, and rollback methods of java.sql.Connection
2. The getUserTransaction method of javax.ejb.EJBContext
3. Any method of javax.transaction.UserTransaction

For bean-managed transactions, the bean specifies transaction demarcations using methods in the javax.transaction.UserTransaction interface. Bean-managed transactions include any stateful or stateless session beans with a transaction-type set to Bean. Entity beans cannot use bean-managed transactions.
For stateless session beans, the entering and exiting transaction contexts must match. For stateful session beans, the entering and exiting transaction contexts may or may not match. If they do not match, EJB container maintains associations between the bean and the nonterminated transaction.
Session beans with bean-managed transactions cannot use the setRollbackOnly and getRollbackOnly methods of the javax.ejb.EJBContext interface.

In container-managed transaction, the transaction boundaries are defined by the container while in bean managed transaction, the transaction boundaries are defined by the bean. Entity Beans transactions are always container managed.

Entity bean's represent the data and responsible for the integrity of the data. Entity bean's doesn't represent business operations to manage transactions. So there is no requirement for an entity bean managing it's transaction.

There 6 types of Transaction Atributes defined in EJB. They are as follows:
1. NotSupported : If the method is called within a transaction, this transaction is suspended during the time of the method execution.
2. Required : If the method is called within a transaction, the method is executed in the scope of this transaction; otherwise, a new transaction is started for the execution of the method and committed before the method result is sent to the caller.
3. RequiresNew : The method will always be executed within the scope of a new transaction. The new transaction is started for the execution of the method, and committed before the method result is sent to the caller. If the method is called within a transaction, this transaction is suspended before the new one is started and resumed when the new transaction has completed.
4. Mandatory: The method should always be called within the scope of a transaction, else the container will throw the TransactionRequired exception.
5. Supports : The method is invoked within the caller transaction scope; if the caller does not have an associated transaction, the method is invoked without a transaction scope.
6. Never : The client is required to call the bean without any transaction context; if it is not the case, a java.rmi.RemoteException is thrown by the container.

No. You cannot change the transaction isolation level in the middle of transaction.

Enterprise beans are restricted from invoking multithreading thread functionality.

Yes. A same bean can be deployed multiple times in the same server with different JNDI names.

No. EJB Clients never access an EJB directly. The container insulates the beans from direct access from client applications. Every time a bean is requested, created, or deleted, the container manages the whole process.

An application is distributed when its components are running in separate runtime environments(JVM's), usually on different platforms connected via a network.
Distributed applications are usually of 3 types. They are :
1. two tier (client and a server)
2.three tier (client and a middleware and a server)
3. multitier (client and multiple middleware and multiple servers).

EAR is Enterprise Archive file. A archive file that contains a J2EE application.

A method of an enterprise bean that implements the business logic or rules of an application.

A method defined in the home interface and invoked by a client to locate an entity bean.

A select method can return a persistent field (or a collection thereof) of a related entity bean. A finder method can return only a local or remote interface (or a collection of interfaces).

Because it is not exposed in any of the local or remote interfaces, a select method cannot be invoked by a client. It can be invoked only by the methods implemented within the entity bean class. A select method is usually invoked by either a business or a home method.

A select method is defined in the entity bean class. For bean-managed persistence, a finder method is defined in the entity bean class, but for container-managed persistence it is not.

You shouldn’t. What will happen depends on the implementation, but the call will most likely be ignored.

The default transaction attribute of an EJB is

Quote:

SUPPORTS

.

The setEntityContext() method is used to set the EntityContext interface for that bean. The EntityContext contains information about the context under which bean is operating. EntityContext interface gives security information about caller. The EntityContext is set only once in the life time of an entity bean instance.

The unsetEntityContext() method is called at the end of a beans life cycle before the instance is unloaded from memory. It is used to dereference EntityContext and to perform any clean up operations if required.

ejbLoad method is primarily used for data retrievals. ejbStore is used for updating data. Typically the container invokes ejbLoad before the first business method in a transaction and the ejbStore is invoked at the end of the transaction. ejbStore method will be invoked when any values of the entity are changed as part of the transaction.

The definition of EJB states that it is a distributed, transactional, persistent software component written in Java Programming Language. From this definition, it can be derived that EJBs are required in the following scenarios.

When the application is distributed: When the resources and data are distributed across multiple sites, then it is ideal to go for an application that is based on EJBs. Choose EJB when you know your application will need to scale beyond initial low usage levels and support multiple, concurrent users.

When the application is performance-centric, use of EJBs and the application server provide high performance and very good scalability.

Declaratively manage transactions. When transaction management is required to ensure data integrity, EJBs may be used. In EJB, you merely specify whether a beans methods require, disallow, or can be used in the context of a transaction. The EJB container will manage your transaction boundaries appropriately. In a purely servlet architecture, you will have to write code to manage the transaction, which is difficult if a logical transaction must access multiple DataSources.

Declaratively manage security. The EJB model allows you to indicate a security role that the user must be assigned to in order to invoke a method on a bean.

Separation of Business Logic. The most significant difference between a web application using only servlets and one using servlets with EJBs is that the EJB model mandates a separation between display and business logic.