Types of Enterprise JavaBeans

Although the containers provide the actual interface to the client, most people think in terms of the actual JavaBean itself. As with the EJB containers, Enterprise JavaBeans themselves come in two flavors:

• Session beans

• Entity beans

Session Beans

As the name implies, session beans persist for only as long as the actual session. After the session terminates, the session bean terminates. Normally, a session bean is associated with only a single client. Session beans are used when the business model calls for situations when the EJB does not have to survive beyond the session for other applications to user . A session bean can be either one of the following:

• Stateful

• Stateless

Sometimes a session bean needs to continuously communicate with the client. Often, this is called conversational mode . In short, the client might need to invoke multiple methods on the EJB, and needs the EJB to maintain its state. Based on our knowledge regarding the state of an object, we can apply this to the EJB.

For example, when the client invokes a method of an EJB and the method terminates, certain state information should still be stored in the EJB's attributes. As we know, the attributes represent the state of an object. The next time the client invokes a method on the EJB, the state of the EJB should still be stored in the attributes. We can say that the client is conversing with the EJB. When this conversation is taking place, the EJB is said to be stateful .

On the other hand, in the stateless mode, an EJB does not converse with the client. For example, a client can invoke a method, which might actually set the attributes of the EJB. However, when the method returns, the state is not tracked. When the next method invocation is made, the pervious state is irrelevant, and the new state is maintained only for the scope of the method's call.

Stateful or Stateless

Regardless of whether a session bean is stateful or stateless, the session bean does not persist.

For example, if an application creates a shopping cart, it would be in the best interest of the store to save the contents of the shopping cart if the system connection goes down. If this is properly done, a user would simply have to reconnect , and the shopping cart would still be available. In this way, the customer does not have to suffer the frustration of having to start over. In this situation, a session bean is not the proper way to design the system because the information will be lost when the session is lost.

Entity Beans

Whereas session beans can be stateful or stateless, entity beans always have a specific state. Entity beans can also serve multiple clients. Thus, in the shopping cart example, using an entity bean will allow for the saving of the state of the shopping cart EJB. You might also want multiple clients to have access to the EJB, but that is probably not the best design for a shopping cart because the user should have a single session. Entity beans can survive both expected and unexpected system terminations. There are also two flavors of entity beans:

• Container-managed persistence

• Bean-managed persistence

In container-managed persistence, the container is responsible for saving the state of the EJB. Because the EJB is in charge, the state of the EJB can be persisted in any type of storage device. In short, persistence is automatically dealt with by the EJB contained. The EJB itself does not contain any SQL code.

In bean-managed persistence, the EJB itself is responsible for the calls to the database and thus contains SQL code. This makes bean-managed persistence much less flexible.