What Is an Enterprise Bean?

As it was mentioned in Chapter 1, "Introduction to Enterprise Applications," Enterprise JavaBeans is an architecture for component-based distributed computing. Enterprise beans are arguably the most important aspect of that architecture. They are the bread and butter, so to speak, of the architecture. Although other components work alongside the enterprise beans to make all the magic happen, the enterprise beans are the mainstay of what you need to understand.

Enterprise beans are components that are part of a distributed transaction-oriented enterprise application. They typically have the following characteristics:

• They depend on a container environment to supply life-cycle services for them.

• They contain business logic that operates on the enterprise's data.

• EJB instances are created and maintained by the container.

• They can be customized at deployment time by editing an XML-based deployment descriptor.

• System-level services, such as transaction management and security, are described separately from the enterprise bean.

• A client never accesses an enterprise bean directly; the container environment mediates access for the client.

• The enterprise bean is designed to be portable across EJB servers provided by different vendors .

Starting with the EJB 2.0 Specification, there are three types of enterprise beans:

• Entity bean

• Session bean

• Message-driven bean

Each type of enterprise bean is used for a different purpose in your enterprise application. Although you will get a very detailed explanation of each bean type later in this book, the following sections briefly describe the purposes of each.

Entity Bean

An entity bean typically represents a row in a relational database. Although this is not the only purpose it can be used for, it's generally the most common. Just as there is a row in a database table for each record, there is possibly a single entity bean instance created for each row. For example, if you have an Order table that represents all the orders placed by customers, you would have one entity bean instance for each Order , although there is some flexibility for how the vendors implement this exactly.

Note

Mapping an entity bean to a single row in a relational database might be too simplified and might lead to a poor design. Whether an entity bean maps to a single table or across multiple tables really depends on your specific application needs and requirements.

This doesn't mean that a container creates an entity bean instance in memory for every database row when the server starts up. That obviously wouldn't scale very well and would be wasteful . There is, however, a different instance used for each row when a client needs it. All clients accessing the same row in the database would be doing so through the same entity bean instance. As you'll see, the EJB architecture provides for concurrent user access to the same EJB instance through proper synchronization. Due to limited resources on the server, however, it might be necessary for less-often used instances to be put back into a pool of beans so that other clients can use them. You'll see more about object pools later in this chapter.

An entity bean is considered to be long-lived because it will survive a server crash. When the server is restarted, the entity bean is still there because the state that the entity bean represents is persisted in the database. Not every table in your persistence schema has to map to a single entity bean. You might have entity beans that are composed of several tables. As you'll see in Chapter 5, "Entity Beans," not every persistent object must be an entity bean. There are other factors to consider when deciding whether something is an entity bean or not.

Session Bean

A session bean typically represents business-level logic that an application needs to execute. It usually combines several processing steps that must be completed as an atomic unit. Atomic means that all the operations should be completed or none of them should. For example, if you had a method called completeOrder that needed to confirm and charge a customer's credit card, submit the order to the system, and then generate an e-mail message to the shipping department to start pulling the order, these operations may be combined and put into a session bean method. If the order could not be submitted, the customer should not be charged. All these operations can be combined into a single session bean method call.

There are two variations of session beans, stateful and stateless. A stateful session bean is designed to be used by one client at a time and can maintain conversational state between method invocations. Conversational state is a state that is maintained for a specific client/ session pair. This means that a stateful session bean maintains instance variable state for a specific client. Although a stateless session bean can also have instance variables , it shares this state among various clients. This is one of the most commonly misunderstood things about session beans. A stateless session bean can hold state ”it just can't be counted on to hold client-specific state because a client is not guaranteed to use the same session bean instance for different method invocations. The container has the freedom to swap stateless instances back and forth between clients. This helps increase scalability because a smaller number of session bean instances can service a larger number of clients.

All instances of stateless session beans are considered identical from the client viewpoint, which is why most EJB developers try to use stateless session beans whenever possible. Stateful session beans are not identical to each other because they maintain conversational state. One client's ShoppingCart will probably contain different items from another client's ShoppingCart . In this way, the session bean has knowledge about a specific client and can't be shared with other clients.

Message-Driven Bean

The message-driven bean is new to the EJB architecture starting with version 2.0. The new bean type is used to handle Java Message Service (JMS) messages asynchronously. It is very different from the other types of enterprise beans in two key ways. For one, the message-driven bean is not exposed directly to clients. A message-driven bean listens for messages that are sent using JMS and processes those messages anonymously. For more information on JMS, see Chapter 10, "Java Message Service."

The container delegates a received message either to an existing method-ready instance or to a new instance allocated to handle the message. Message-driven beans are stateless; therefore, any instance may service a message equally. Likewise, similar to stateless session beans, message-driven beans are anonymous, having no identity to a client. The second key difference is that message-driven beans are managed completely by the container, rather than allowing a client to possibly manage the life cycle by creating and removing them. You'll see more about message-driven beans in Chapter 11, "Message-Driven Beans."