The Java EE 5 Tutorial

(from JavaEETutorial.pdf)

Types of Enterprise Beans
Table 20–1 summarizes the two types of enterprise beans. The following sections discuss each
type inmore detail.

TABLE 20–1 Enterprise BeanTypes
Enterprise BeanType Purpose

Session Performs a task for a client; optionallymay implement a web service
Message-Driven Acts as a listener for a particularmessaging type, such as the Java Message Service API

Note – Entity beans have been replaced by Java Persistence API entities. For information about
entities, see Chapter 24, “Introduction to the Java Persistence API.”

What Is a Session Bean?
A session bean represents a single client inside the Application Server. To access an application
that is deployed on the server, the client invokes the session bean’smethods. The session bean
performs work for its client, shielding the client fromcomplexity by executing business tasks
inside the server.
As its name suggests, a session bean is similar to an interactive session. A session bean is not
shared; it can have only one client, in the same way that an interactive session can have only one
user. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to
a database.)When the client terminates, its session bean appears to terminate and is no longer
associated with the client.
For code samples, see Chapter 22, “Session Bean Examples.”
StateManagementModes
There are two types of session beans: stateful and stateless.
Stateful Session Beans
The state of an object consists of the values of its instance variables. In a stateful session bean,
the instance variables represent the state of a unique client-bean session. Because the client
interacts (“talks”) with its bean, this state is often called the conversational state.
The state is retained for the duration of the client-bean session. If the client removes the bean or
terminates, the session ends and the state disappears. This transient nature of the state is not a
problem, however, because when the conversation between the client and the bean ends there is
no need to retain the state

Stateless Session Beans
A stateless session bean does notmaintain a conversational state with the client.When a client
invokes themethods of a stateless bean, the bean’s instance variablesmay contain a state speciic
to that client, but only for the duration of the invocation.When themethod is inished, the
client-speciic state should not be retained. Clientsmay, however, change the state of instance
variables in pooled stateless beans, and this state is held over to the next invocation of the
pooled stateless bean. Except duringmethod invocation, all instances of a stateless bean are
equivalent, allowing the EJB container to assign an instance to any client. That is, the state of a
stateless session bean should apply accross all clients.
Because stateless session beans can supportmultiple clients, they can ofer better scalability for
applications that require large numbers of clients. Typically, an application requires fewer
stateless session beans than stateful session beans to support the same number of clients.
A stateless session bean can implement a web service, but other types of enterprise beans
cannot.


When toUse Session Beans
In general, you should use a session bean if the following circumstances hold:
■ At any given time, only one client has access to the bean instance.
■ The state of the bean is not persistent, existing only for a short period (perhaps a few hours).
■ The bean implements a web service.
Stateful session beans are appropriate if any of the following conditions are true:
■ The bean’s state represents the interaction between the bean and a speciic client.
■ The bean needs to hold information about the client acrossmethod invocations.
■ The beanmediates between the client and the other components of the application,
presenting a simpliied view to the client.
■ Behind the scenes, the beanmanages the work low of several enterprise beans. For an
example, see the AccountControllerBean session bean in Chapter 37, “TheDuke’s Bank
Application.”
To improve performance, youmight choose a stateless session bean if it has any of these traits:
■ The bean’s state has no data for a speciic client.
■ In a singlemethod invocation, the bean performs a generic task for all clients. For example,
youmight use a stateless session bean to send an email that conirms an online order.


Defining Client Accesswith Interfaces
Thematerial in this section applies only to session beans and not tomessage-driven beans.
Because they have a diferent programmingmodel,message-driven beans do not have
interfaces that deine client access.
A client can access a session bean only through themethods deined in the bean’s business
interface. The business interface deines the client’s view of a bean. All other aspects of the bean
(method implementations and deployment settings) are hidden fromthe client.
Well-designed interfaces simplify the development andmaintenance of Java EE applications.
Not only do clean interfaces shield the clients fromany complexities in the EJB tier, but they
also allow the beans to change internally without afecting the clients. For example, if you
change a session bean froma stateless to a stateful session bean, you won’t have to alter the
client code. But if you were to change themethod deinitions in the interfaces, then youmight
have tomodify the client code as well. Therefore, it is important that you design the interfaces
carefully to isolate your clients frompossible changes in the beans.
Session beans can havemore than one business interface. Session beans should, but are not
required to, implement their business interface or interfaces.
When you design a Java EE application, one of the irst decisions youmake is the type of client
access allowed by the enterprise beans: remote, local, or web service.


Introduction to the Java Persistence API
The Java Persistence API provides an object/relationalmapping facility to Java developers for
managing relational data in Java applications. Java Persistence consists of three areas:
■ The Java Persistence API
■ The query language
■ Object/relationalmappingmetadata

Entities
An entity is a lightweight persistence domain object. Typically an entity represents a table in a
relational database, and each entity instance corresponds to a row in that table. The primary
programming artifact of an entity is the entity class, although entities can use helper classes.
The persistent state of an entity is represented either through persistent ields or persistent
properties. These ields or properties use object/relationalmapping annotations tomap the
entities and entity relationships to the relational data in the underlying data store.
Requirements for Entity Classes
An entity classmust follow these requirements:
■ The classmust be annotated with the javax.persistence.Entity annotation.
■ The classmust have a public or protected, no-argument constructor. The classmay have
other constructors.
■ The classmust not be declared final.Nomethods or persistent instance variablesmust be
declared final.
■ If an entity instance be passed by value as a detached object, such as through a session bean’s
remote business interface, the classmust implement the Serializable interface.
■ Entities may extend both entity and non-entity classes, and non-entity classesmay extend
entity classes.
■ Persistent instance variablesmust be declared private, protected, or package-private, and
can only be accessed directly by the entity class’smethods. Clientsmust access the entity’s
state through accessor or businessmethods.



The Java Persistence Query Language
The Java Persistence query language deines queries for entities and their persistent state. The
query language allows you to write portable queries that work regardless of the underlying data
store.
The query language uses the abstract persistence schemas of entities, including their
relationships, for its datamodel, and it deines operators and expressions based on this data
model. The scope of a query spans the abstract schemas of related entities that are packaged in
the same persistence unit. The query language uses a SQL-like syntax to select objects or values
based on entity abstract schema types and relationships among them.
This chapter relies on thematerial presented in earlier chapters. For conceptual information,
see Chapter 24, “Introduction to the Java Persistence API.” For code examples, see Chapters
“The persistence.xml File” on page 701 and “UpdatingData in theDatabase” on page 708.



Query LanguageTerminology
The following list deines some of the terms referred to in this chapter.
■ Abstract schema: The persistent schema abstraction (persistent entities, their state, and
their relationships) over which queries operate. The query language translates queries over
this persistent schema abstraction into queries that are executed over the database schema
to which entities aremapped.
■ Abstract schema type: All expressions evaluate to a type. The abstract schema type of an
entity is derived fromthe entity class and themetadata information provided by Java
language annotations.
■ Backus-Naur Form(BNF): A notation that describes the syntax of high-level languages.
The syntax diagrams in this chapter are in BNF notation.
■ Navigation: The traversal of relationships in a query language expression. The navigation
operator is a period.
■ Path expression: An expression that navigates to a entity’s state or relationship ield.
■ State ield: A persistent ield of an entity.
■ Relationship ield: A persistent relationship ield of an entity whose type is the abstract
schema type of the related entity.
.