Reading Notes：Enterprise JavaBeans, 3.0 Chapter 2. Architectural Overview

Enterprise JavaBeans, 3.0 Chapter 2. Architectural Overview

 

 

Section 2.1.  The Entity Bean

A good rule of thumb is that entity beans model business concepts that can be expressed as nouns . For example, an entity bean might represent a customer, a piece of equipment, an item in inventory, or even a place. In other words, entity beans model real-world objects; these objects are usually persistent records in some kind of database.

 

 

A good way to understand the design of entity beans is to look at how you'd go about implementing one. To implement an entity bean, you need to define a bean class and decide what field you will use as the identifier (primary key) of that bean class:

Primary key

The primary key is something that provides a pointer into the database. It gives the entity bean class's identity both in memory as an object and in the database as a row in a table. The primary key can be a class or a primitive type.

Bean class

The entity bean class may contain business logic but is usually just the object representation of persistence storage . In general, only business logic like validation should be placed in the entity bean class. The bean class is a POJO that does not have to implement any interface or even be serializable. It must be tagged with the @javax.persistence.Entity annotation and have at least one field or getter method that is designated as the primary key of the entity bean class in the database. This is usually done with the @javax.persistence.Id annotation. Entities have other annotations available to define a full object-relational database mapping as well.

 

2.1.1. The Entity Bean Class

 

Entity beans are different from EJB session beans in that they are POJOs. They do not have a remote or local interface and can be accessed only as POJOs. Later on, we'll see how to interact with an entity bean using the EntityManager service, but for now, we'll just take a peek at how to implement this bean type.

 

 

 

2.1.2. XML Deployment Descriptors and JAR Files

 

Many feel that database mappings are configuration metadata that should be defined separate from the entity bean class. To facilitate this requirement, the Java Persistence specification allows you to define the bean to database mappings in an additional XML deployment descriptor called a mapping file. This XML mapping file can be used instead of bean class annotations.

 

Once you have defined your XML deployment descriptors and entity bean classes, you must package them all in a Java Archive (JAR) file. The JAR file is used as both a library at runtime and a holder for deployment information. Whether you are using persistence in an application server or within a standalone Java application, the persistence provider will examine the JAR file to determine how to deploy one or more persistence units into your environment.

 

2.2. The Enterprise Bean Component

 

Enterprise JavaBeans server-side components come in two fundamentally different types: session beans and message-driven beans . Session beans are server-side components that can be accessed using a variety of distributed object protocols. Message-driven beans process messages asynchronously from systems like the JMS, legacy systems, and web services. All EJB servers must at least support a JMS-based message-driven bean, but they may also support other types of message-driven beans.

 

Session beans are extensions of the client application that manage processes or tasks.

Similarly, message-driven beans coordinate tasks involving other session and entity beans. Message-driven beans and session beans differ primarily in how they are accessed . While a session bean provides a remote interface that defines which methods can be invoked, a message-driven bean subscribes to or listens for messages. It responds by processing the message and managing the actions that other beans take.

 

 

The relevant distinction for Enterprise JavaBeans and Java Persistence is that an entity bean has persistent state; session and message-driven beans model interactions but do not have a persistent state.

 

2.2.1. Classes and Interfaces

 

Remote interface

Local interface

Endpoint interface

Message interface

Bean class

 

The term taskflow was coined specifically for this book. It's derived from the term workflow , which is frequently used to describe the management of business processes that may span several days with lots of human intervention. In contrast to workflow, taskflow is used in this book to describe the interactions of beans within a single transaction that takes only a few seconds to execute.

 

Entity beans represent the behavior and data of a business object, and session beans model the taskflow. The client application uses the TravelAgent EJB to perform a task using other beans.

Clients of session beans interact with the beans through the remote and local interfaces implemented by EJB objects.