< Zurück | Inhalt | Weiter >

21.2.1 EJB Concepts

In a way, the use of the term Enterprise JavaBean, with its echo of the older term JavaBean, is unfortunate. Apart from the similar intention of creating reusable components, the two technologies have little in common.


21.2.1.1 The Life Cycle of an Enterprise JavaBean

Most of the books on EJBs that we have seen start with the simplest type of bean and work their way up in complexity. We’re going to dare to be different, because the most complex case isn’t that hard, and once you understand it, the functions of all the other types of EJBs become obvious. They simply don’t implement what they do not need.

For the moment, assume that an EJB is a simple class that provides a set of methods to clients. The methods represent business functions that clients want the server to carry out.

Implementing an Enterprise JavaBean requires implementing three Java source files:

• An object that represents the bean implementation

• An interface called the home interface that represents the interface between the bean and the EJB container

• An interface called the remote interface which represents the methods that a client may call on the bean

We’ll get into the details of these interfaces (and the sometimes obtuse reasons behind) a little later on. For now, we will concentrate on the implementation.

The implementation class contains methods that are there only to allow the container to control the bean and to inform the bean of impending changes


to its status. Those methods are defined in the bean class that the implementa- tion class extends. The classes one extends to implement a bean are:

SessionBean

EntityBean

MessageBean

Please forgive us right now for admitting that we will not cover message beans in this book beyond a brief description in the next section. For details on message beans, take a look at Chapter 8 of Enterprise JavaBeans Component Architecture by Gail Anderson and Paul Anderson (ISBN 0-13-035571-2).

Not all of the control methods need to be implemented in all cases, but the full set is not that large or difficult to understand. They correspond to im- portant “life events” in lifetime of the bean. The primary events are: creation, destruction, passivation, activation, persist to DB, restore from DB, and context switching.

Creation. A bean is created when its constructor is called. As we shall learn, the calling of the constructor has absolutely no connection with a client request. For session beans, the container maintains a pool of instances to handle client requests. For entity beans, a bean (most commonly) represents a database table, and the setEntityContext() method is used to move that bean from row (instance) to row as needed.

In practice, this usually means that a number of instances of the bean are created when the application server is started. Additional instances are created as the demand for this bean (number of clients, number of calls per unit time) increases.

Destruction. As you know, Java objects do not have explicit destructors, but when a bean instance is destroyed, an explicit method in the Bean class is called to permit shutdown operations to take place.

This is quite distinct from activation and passivation. Activation and pas- sivation are operations carried out when the application server needs to shove aside some Bean instances that may still be needed by clients in order to make room for an active request that requires more than the available system resources.

Passivation and activation. As we said above, passivation involves the container asking the beans that are still potentially needed to step aside to allow


more urgent tasks (probably beans that are being actively called) to use resources tied up by otherwise idle beans. Think of this as like memory swap in an operating system. The bean will save any data and context information into some sort of persistent storage, which may be a database, flat files, XML files, whatever, when it is passivated.

Context switching. Since both session and entity beans may be called upon to service requests from multiple clients, it is necessary to provide a method whereby the container can notify the bean which “context” (which may be loosely said to be a client) is active at the moment. In stateless session beans this is not necessarily implemented, but in stateful session beans and in entity beans this activity must be supported.

How is this distinct from passivation and activation? Passivation is the temporary “swapping out” of a bean to make room for something else. Context switching is the move of a Bean instance from client to client. Or, to put it another way, passivation makes room for some other bean to become active and serve a client.1 Context switching switches a given bean from client to client.2


21.2.1.2 The EJB Container

A J2EE application server has two containers: a Web container and an EJB container. You can also think of these as “servers” in the more classic sense. J2EE calls them containers because it emphasizes the idea that you place Java objects (applets, servlets, and Enterprise JavaBeans) into the container that can run them (a browser, a Web container, an EJB container). The J2EE specifica- tion specifies the exact relationship between these application objects and their container. For EJB’s, the container provides lifecycle control, network manage- ment, load management, perhaps clustering services, CMP (container-managed persistence) services, and so on. We’ll talk a lot more about container services


image

1. This is a simplification. A container can passivate a bean to make resources available for any purpose, not just for another EJB. Beans might be passivated because some process on the server outside the application server needs resources. It is entirely dependent on how the application server is written. What is said here is conceptually true, if not actually true ;-)

2. Again, saying “client-to-client” is a simplification. A single client may have multiple threads interacting with multiple beans, and a context switch might be performed to serve different requests from a single client. Again: conceptually true, if not actually true.


as we go along. For now, be aware that the container will start, stop, instantiate, destroy, and provide network services to the EJBs it contains.