Interview Questions and Answers

Enterprise java bean (EJB) is a server side component which runs on application server or we call container, developed for the purpose of distributed and enterprise level application.

J2EE defines three types of archives:

The entity bean is used to represent data in the database. It provides an object-oriented interface to ____.

An EJB container is a run-time environment that manages one or more enterprise beans. The EJB container manages the life cycles of enterprise bean objects, coordinates distributed transactions, and implements object security. Generally, each EJB container is provided by an EJB server and contains a set of enterprise beans that run on the server.

An EJB server is a high-level process or application that provides a run-time environment to support the execution of server applications that use enterprise beans. An EJB server provides a JNDI-accessible naming service, manages and coordinates the allocation of resources to client applications, provides access to system resources, and provides a transaction service. An EJB server could be provided by, for example, a database or application server.

EJB technology is the core of J2EE. It enables developers to write reusable and portable server-side business logic for the J2EE platform.

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.

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.

An entity bean consists of 4 groups of methods, create methods.

Container-managed persistence (CMP) and bean-managed persistence (BMP). With CMP, the container manages the persistence of the entity bean.

The bean class defines create methods that match methods in the home interface and business methods that match methods in the remote interface. The bean class also implements a set of callback methods that allow the container to notify the bean of events in its life cycle. The callback methods are defined in the javax.ejb.EntityBean interface that is implemented by all entity beans.The EntityBean interface has the following definition. Notice that the bean class implements these methods.

public interface javax.ejb.EntityBean {
public void setEntityContext();
public void unsetEntityContext();
public void ejbLoad();
public void ejbStore();
public void ejbActivate();
public void ejbPassivate();
public void ejbRemove();
}

The setEntityContext() method provides the bean with an interface to the container called the EntityContext. The EntityContext interface contains methods for obtaining information about the context under which the bean is operating at any particular moment. The EntityContext interface is used to access security information about the caller; to determine the status of the current transaction or to force a transaction rollback; or to get a reference to the bean itself, its home, or its primary key. The EntityContext is set only once in the life of an entity bean instance, so its reference should be put into one of the bean instance�s fields if it will be needed later.

The unsetEntityContext() method is used at the end of the bean�s life cycle before the instance is evicted from memory to dereference the EntityContext and perform any last-minute clean-up.

The ejbLoad() and ejbStore() methods in CMP entities are invoked when the entity bean�s state is being synchronized with the database. The ejbLoad() is invoked just after the container has refreshed the bean container-managed fields with its state from the database. The ejbStore() method is invoked just before the container is about to write the bean container-managed fields to the database. These methods are used to modify data as it�s being synchronized. This is common when the data stored in the database is different than the data used in the bean fields.

The ejbPassivate() and ejbActivate() methods are invoked on the bean by the container just before the bean is passivated and just after the bean is activated, respectively. Passivation in entity beans means that the bean instance is disassociated with its remote reference so that the container can evict it from memory or reuse it. It�s a resource conservation measure the container employs to reduce the number of instances in memory. A bean might be passivated if it hasn�t been used for a while or as a normal operation performed by the container to maximize reuse of resources. Some containers will evict beans from memory, while others will reuse instances for other more active remote references. The ejbPassivate() and ejbActivate() methods provide the bean with a notification as to when it�s about to be passivated (disassociated with the remote reference) or activated (associated with a remote reference).

Session and Entity EJBs consist of 4 and 5 parts respectively, a remote interface.

Yes. In some cases the data is inserted NOT using Java application.

If a developer doesn�t want a Container to manage transactions, it�s possible to implement all database operations manually.

The transaction attribute specifies how the Container must manage transactions for a method when a client invokes the method via the enterprise bean�s home or.

Transaction_read_uncommitted, Transaction_read_committed, Transaction_repeatable_read.

The main technologies in J2EE are: Enterprise JavaBeansTM (EJBsTM), JavaServer PagesTM (JSPsTM), Java Servlets, the Java Naming and Directory InterfaceTM (JNDITM), the Java Transaction API (JTA), CORBA, and the JDBCTM data access API.

EJB is a specification for J2EE server, not a product; Java beans may be a graphical component in IDE.

The process by which the contents in the memory of one physical m/c are replicated in all the m/c in the cluster is called in-memory replication.

Session and Entity EJBs consist of 4 and 5 parts respetively:

1. A remote interface (a client interacts with it),

2. A home interface (used for creating objects and for declaring business methods),

3. A bean object (an object, which actually performs business logic and EJB-specific operations).

4. A deployment descriptor (an XML file containing all information required for maintaining the EJB) or a set of deployment descriptors (if you are using some container-specific features).

5.A Primary Key class - is only Entity bean specific.

The main reason is because there is a clear division of roles and responsibilities between the two interfaces. The home interface is your way to communicate with the container, that is who is responsible of creating, locating even removing one or more beans. The remote interface is your link to the bean, that will allow you to remotely access to all its methods and members. As you can see there are two distinct elements (the container and the beans) and you need two different interfaces for accessing to both of them.

If a developer doesn�t want a Container to manage transactions, it�s possible to implement all database operations manually by writing the appropriate JDBC code. This often leads to productivity increase, but it makes an Entity Bean incompatible with some databases and it enlarges the amount of code to be written. All transaction management is explicitly performed by a developer.

EJBs can be clients of other EJBs. It just works. Use JNDI to locate the Home Interface of the other bean, then acquire an instance reference, and so forth.

In case of a stateless session bean it may not matter if we call or not as in both cases nothing is done. The number of beans in cache is managed by the container.

In case of stateful session bean, the bean may be kept in cache till either the session times out, in which case the bean is removed or when there is a requirement for memory in which case the data is cached and the bean is sent to free pool.

EJB QL is a Query Language provided for navigation across a network of enterprise beans and dependent objects defined by means of container managed persistence. EJB QL is introduced in the EJB 2.0 specification. The EJB QL query language defines finder methods for entity beans with container managed persistenceand is portable across containers and persistence managers. EJB QL is used for queries of two types of finder methods: Finder methods that are defined in the home interface of an entity bean and which return entity objects. Select methods, which are not exposed to the client, but which are used by the Bean Provider to select persistent values that are maintained by the Persistence Manager or to select entity objects that are related to the entity bean on which the query is defined.

Step 1: Retrieve Home Object reference from Naming Service via JNDI.
step 2: Return Home Object reference to the client.
step 3: Create me a new EJB Object through Home Object interface.
step 4: Create EJB Object from the Ejb Object
step 5: Return EJB Object reference to the client.
step 6: Invoke business method using EJB Object reference.
step 7: Delegate request to Bean (Enterprise Bean).

The transaction attribute specifies how the Container must manage transactions for a method when a client invokes the method via the enterprise bean�s home or component interface or when the method is invoked as the result of the arrival of a JMS message. (Sun�s EJB Specification) Below is a list of transactional attributes:

1. NotSupported - transaction context is unspecified.

2. Required - bean�s method invocation is made within a transactional context. If a client is not associated with a transaction, a new transaction is invoked automatically.

3. Supports - if a transactional context exists, a Container acts like the transaction attribute is Required, else - like NotSupported.

4. RequiresNew - a method is invoked in a new transaction context.

5. Mandatory - if a transactional context exists, a Container acts like the transaction attribute is Required, else it throws a javax.ejb.TransactionRequiredException.

6. Never - a method executes only if no transaction context is specified.

EJBs can be clients of other EJBs. It just works. Use JNDI to locate the Home Interface of the other bean, then acquire an instance reference, and so forth.

In several ways, the dynamic creation and allocation of message-driven bean instances mimics the behavior of stateless session EJB instances, which exist only for the duration of a particular method call. However, message-driven beans are different from stateless session EJBs (and other types of EJBs) in several significant ways: Message-driven beans process multiple JMS messages asynchronously, rather than processing a serialized sequence of method calls. Message-driven beans have no home or remote interface, and therefore cannot be directly accessed by internal or external clients. Clients interact with message-driven beans only indirectly, by sending a message to a JMS Queue or Topic. Only the container directly interacts with a message-driven bean by creating bean instances and passing JMS messages to those instances as necessary. The Container maintains the entire lifecycle of a message-driven bean; instances cannot be created or removed as a result of client requests or other API calls.

You can pass the HttpSession as parameter to an EJB method, only if all objects in session are serializable.This has to be consider as passed-by-value, that means that it�s read-only in the EJB. If anything is altered from inside the EJB, it won�t be reflected back to the HttpSession of the Servlet Container.The pass-by-reference can be used between EJBs Remote Interfaces, as they are remote references. While it is possible to pass an HttpSession as a parameter to an EJB object, it is considered to be bad practice in terms of object-oriented design. This is because you are creating an unnecessary coupling between back-end objects (EJBs) and front-end objects (HttpSession). Create a higher-level of abstraction for your EJBs API. Rather than passing the whole, fat, HttpSession (which carries with it a bunch of http semantics), create a class that acts as a value object (or structure) that holds all the data you need to pass back and forth between front-end/back-end. Consider the case where your EJB needs to support a non HTTP-based client. This higher level of abstraction will be flexible enough to support it.

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.

A Java Bean is a software component written in the Java programming language that conforms to the JavaBeans component specification. The JavaBeans APIs became part of the �core� Java APIs as of the 1.1 release of the JDK.

The JavaBeans specification defines a Java-based software component model that adds a number of features to the Java programming language. Some of these features include:
.introspection
.customization
.events
.properties
.persistence

Enterprise JavaBeans (EJBs) are Java-based software components that are built to comply with Java�s EJB specification and run inside of an EJB container supplied by a J2EE provider. An EJB container provides distributed application functionality such as transaction support, persistence and lifecycle management for the EJBs.

Abstract schema is part of an entity bean�s deployment descriptor which defines the bean�s persistent fields and their relationship. Abstract schema is specified for entity beans with container managed persistence. We specify the name of the Abstract schema name in the deployment descriptor. The queries written in EJB QL for the finder methods references this name. The information provided in this Abstract Schema is used by the container for persistence management and relationship management.

An EJB can use local client view only if it is really guaranteed that other enterprise beans or clients will only address the bean within a single JVM. With local client view, you can do pass-by-reference, which means your bean, as well as the client, will work directly with one copy of the data. Any changes made by the bean will be seen by the client and vice versa. Pass-by-reference eliminates time/system expenses for copying data variables, which provides a performance advantage.

An MDB is essentially a message consumer that can listen to a message destination or a message endpoint and gets activated when a message arrives. By design, MDBs are anonymous in nature and hence cannot be directly invoked by a client. The only way to invoke an MDB is to send a message to the destination or endpoint to which it is listening. As MDBs are stateless in nature and are not related to any specific client, they can be pooled for concurrent processing of messages.

Container services are totally depends upon the �vendor implementation�. But more or less most of the vendors suppots the basic services like,
LifeCycle Management - It is Automatic.
Session Management - it is used by Developer coded callback methods.
Transaction Management - it is used by configuring deployment descriptor (DD) .
Security management - it is used by configuring deployment descriptor (DD) .
The other services, if any will be in advanced versions, and depends on Vendor specific.

For a Session bean - one EJB object for one bean instance.
For entity bean - it depends , if 2 users are accessing one row at time then one EJB object is used for both the beans other wise for each bean one EJB object.

Lazy loading means not creating an object until the first time it is accessed. Lazy loading typically looks like this:

public class Example {
private Vector data = null;
public Vector getData() {
if (this.data == null) {
this.data = new Vector();
// Load data into vector �
}
return this.data;
}
}

This technique is most useful when you have large hierarchies of objects (such as a product catalog). You can lazy-load subordinate objects as you navigate down the hierarchy, and thereby only create objects when you need them.

No, you cannot map more than one table to a single CMP Entity Bean. CMP has been, in fact, designed to map a single table.

No. Decorator design pattern, is the one which exhibits very low level runtime polymorphism, for the specific and single object (Instance of the class), but not for atleast for a class. It is the stuff to add specific functionality to a single & pointed object and leaves others like it unmodified. It is having close similarities like aspectJ stuff, but not with EJB stuff.

Since EnterpriseBeans live in a managed container, the container is free to call your EJB components methods at its leisure. The container houses the information like current status of bean,security credentials of the user currently accessing the bean in one object is called EJBContext Object. A context represents a way for beans to perform callbacks and modify their current status Sessioncontext is EJB context for session bean Entitycontext is EJB context for entity bean Message driven context is EJB context for message driven bean.

Stateless SessionBean create() method doesnot contain any parameters and the syntax is as follows:
public interface XSessionEJBHome extends EJBHome
{
XSessionEJB create() throws RemoteException, CreateException;
}

The bulk of the changes in EJB 2.0 are found in the definition of a new CMP component model. It�s radically different from the old CMP model because it introduces an entirely new participant, the persistence manager, and a completely new way of defining container-managed fields, as well as relationships with other beans and dependent objects.

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 acces to all methods and members.

An EJB client JAR file is an optional JAR file that can contain all the class files that a client program needs to use the client view of the enterprise beans that are contained in the EJB JAR file. If you decide not to create a client JAR file for an EJB module, all of the client interface classes will be in the EJB JAR file.