- The client’s view
- Fundamentals of the EJB architecture
- Types of EJB
- Distributed and local EJB semantics
- Anatomy of an EJB
- Principle of operation: session and entity EJBs
- Principle of operation: message-driven EJBs
- The EJB container and its proxies
- Overview of the EJB API
- EJB rules, standards and limitations
- Assembly and deployment
- Configuration
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Types of EJB
Version 1.1 of the EJB Specification [EJB1.1 4.3] defined two types of EJB: the session EJB and the entity EJB. Version 2.0 introduces a third type, the message-driven EJB [EJB2.0 4.3]. It is possible to envisage EJB applications where the EJBs don’t fit neatly into any of these categories, but in practice one of these types can be adapted to suit most jobs. As there are separate chapters on each of these EJB types, the discussion here will be an outline only.
3.3.1 Session EJBs
A session EJB is a nonpersistent object: Its lifetime is the duration of a particular interaction between the client and the EJB. The client normally creates an EJB, calls methods on it, and then removes it. If the client fails to remove it, the EJB container will remove it after a certain period of inactivity. Session EJBs are subdivided into ‘stateful’ and ‘stateless’ types. A stateless session EJB is shared amongst a number of clients, while a stateful session EJB is created for a specific client and not used by any others. The use of stateless EJBs offers efficiency advantages but, of course, it is not always possible to use them.
Session beans are defined and described in Chapters 5–7 of the EJB Specification, and discussed in detail in Chapter 6 of this book.
3.3.2 Entity EJBs
Entity EJBs represent persistent objects: Their lifetimes are not related to the duration of interaction with clients. In nearly all cases, entity EJBs are synchronized with relational databases. This is how persistence is achieved. Entity EJBs are always shared amongst clients: A client cannot get an entity EJB to itself. Thus, entity EJBs are nearly always used as a scheme for mapping relational databases into object-oriented applications.
Whereas a client normally creates a session EJB and removes it after use, clients normally look up an existing entity EJB. Creation of an entity EJB corresponds to adding new data items to the application (e.g., adding rows to database tables).
An important feature of entity EJBs is that they have identity—that is, one can be distinguished from another. This is implemented by assigning a primary key to each instance of the EJB, where ‘primary key’ has the same meaning as it does for database management. Primary keys that identify EJBs can be of any type, including programmer-defined classes.
Entity beans are defined and described in Chapters 8–13 of the EJB Specification, and discussed in detail in Chapter 11 of this book.
3.3.3 Message-driven EJBs
A message-driven bean acts as a consumer of asynchronous messages: It cannot be called directly by clients, but is activated by the container when a message arrives. Clients interact with these EJBs by sending messages to the queues or topics to which they are listening. Although a message-driven EJB cannot be called directly by clients, it can call other EJBs itself.
Message-driven EJBs are the only type that do not follow a strict request-response interaction with clients. They are defined and described in Chapters 14 and 15of the EJB Specification, and discussed in detail in Chapter 10 of this book.