Section 1: EJB 3.0 Overview - 1a

• Identify the uses, benefits, and characteristics of Enterprise JavaBeans technology, for version 3.0 of the EJB specification.
• Identify the APIs that all EJB 3.0 containers must make available to developers.
• Identify correct and incorrect statements or examples about EJB programming restrictions.
• Match the seven EJB roles with the corresponding description of the role's responsibilities.
• Describe the packaging and deployment requirements for enterprise beans.
• Describe the purposes and uses of annotations and deployment descriptors, including how the two mechanisms interact, how overriding is handled, and how these mechanisms function at the class, method, and field levels.

1a) Identify the uses, benefits, and characteristics of Enterprise JavaBeans technology, for version 3.0 of the EJB specification

ENTERPRISE beans are Java Enterprise Edition (Java EE) components that implement Enterprise Java-Beans (EJB) technology. An enterprise bean is a server-side component that encapsulates the business logic of an application. Enterprise beans run in the EJB container, a runtime environment within the Application Server. By using EJB, you can write scalable, reliable and secure applications without writing your own complex distributed component framework. Although transparent to the application developer, the EJB container provides system-level services such as transactions and security to its enterprise beans. EJB is about rapid application development for the server side.




When to Use Enterprise Beans
You should consider using enterprise beans if your application has any of the following requirements:
• The application must be scalable. To accommodate a growing number of users, you may need to distribute an application’s components across multiple machines. Not only can the enterprise beans of an application run on different machines, but also their location will remain transparent to the clients.
• Transactions must ensure data integrity. Enterprise beans support transactions, the mechanisms that manage the concurrent access of shared objects.
• The application will have a variety of clients. With only a few lines of code, remote clients can easily locate enterprise beans. These clients can be thin, various, and numerous.

Benefits of Enterprise Beans

For several reasons, enterprise beans simplify the development of large, distributed applications.

First, because the EJB container provides system-level services to enterprise beans, the bean developer can concentrate on solving business problems. The EJB container—and not the bean developer—is responsible for system-level services such as transaction management and security authorization.

Second, because the beans—and not the clients—contain the application’s business logic, the client developer can focus on the presentation of the client. The client developer does not have to code the routines that implement business rules or access databases. As a result, the clients are thinner, a benefit that is particularly important for clients that run on small devices.

Third, because enterprise beans are portable components, the application assembler can build new applications from existing beans. These applications can run on any compliant Java EE server provided that they use the standard APIs.

Characteristics of Enterprise Beans
The essential characteristics of an enterprise bean are:
• An enterprise bean typically contains business logic that operates on the enterprise’s data.
• An enterprise bean’s instances are managed at runtime by a container.
• An enterprise bean can be customized at deployment time by editing its environment entries.
• Various service information, such as transaction and security attributes, may be specified together with the business logic of the enterprise bean class in the form of metadata annotations, or separately, in an XML deployment descriptor. This service information may be extracted and managed by tools during application assembly and deployment.
• Client access is mediated by the container in which the enterprise bean is deployed.
• If an enterprise bean uses only the services defined by the EJB specification, the enterprise bean can be deployed in any compliant EJB container. Specialized containers can provide additional services beyond those defined by the EJB specification. An enterprise bean that depends on such a service can be deployed only in a container that supports that service.
• An enterprise bean can be included in an assembled application without requiring source code changes or recompilation of the enterprise bean.
• The Bean Provider defines a client view of an enterprise bean. The Bean Provider can manually define the client view or it can be generated automatically by application development tools. The client view is unaffected by the container and server in which the bean is deployed. This ensures that both the beans and their clients can be deployed in multiple execution environments without changes or recompilation.

Flexible Model
The enterprise bean architecture is flexible enough to implement the following:
• An object that represents a stateless service.
• An object that represents a stateless service and that implements a web service endpoint.
• An object that represents a stateless service and whose invocation is asynchronous, driven by the arrival of messages.
• An object that represents a conversational session with a particular client. Such session objects automatically maintain their conversational state across multiple client-invoked methods.
• An entity object that represents a fine-grained persistent object.

Enterprise beans that are remotely accessible components are intended to be relatively coarse-grained business objects (e.g. shopping cart, stock quote service). Fine-grained objects (e.g. employee record, line items on a purchase order) should be modeled as light weight persistent entities, not as remotely accessible components.

Although the state management protocol defined by the Enterprise JavaBeans architecture is simple, it provides an enterprise bean developer great flexibility in managing a bean’s state.

Session, Entity, and Message-Driven Objects
The Enterprise JavaBeans architecture defines the following types of enterprise bean objects:
• A session object.
• A message-driven object.
• An entity object.

Session Objects
A typical session object has the following characteristics:
• Executes on behalf of a single client.
• Can be transaction-aware.
• Updates shared data in an underlying database.
• Does not represent directly shared data in the database, although it may access and update such data.
• Is relatively short-lived.
• Is removed when the EJB container crashes. The client has to re-establish a new session object to continue computation.

A typical EJB container provides a scalable runtime environment to execute a large number of session objects concurrently. The EJB specification defines both stateful and stateless session beans. There are differences in the API between stateful session beans and stateless session beans.

Message-Driven Objects
A typical message-driven object has the following characteristics:
• Executes upon receipt of a single client message.
• Is asynchronously invoked.
• Can be transaction-aware.
• May update shared data in an underlying database.
• Does not represent directly shared data in the database, although it may access and update such data.
• Is relatively short-lived.
• Is stateless.
• Is removed when the EJB container crashes. The container has to re-establish a new message-driven object to continue computation.

A typical EJB container provides a scalable runtime environment to execute a large number of message-driven objects concurrently.

Entity Objects
A typical entity object has the following characteristics:
• Is part of a domain model, providing an object view of data in the database.
• Can be long-lived (lives as long as the data in the database).
• The entity and its primary key survive the crash of the EJB container. If the state of an entity was being updated by a transaction at the time the container crashed, the entity’s state is restored to the state of the last committed transaction when the entity is next retrieved.

A typical EJB container and server provide a scalable runtime environment for a large number of concurrently active entity objects.