Characteristics of an Enterprise JavaBean and EJB 3.0 Technology

The first objective of the SCBCD exam includes a reference to the characteristics of Enterprise JavaBeans technology. Page 34 of the JSR 220: EJB Core Contracts and Requirements documents lists the key characteristics of an EJB. I think we'll find some easy questions on these points on the Sun Certified Business Component Developer Exam. I'll put some mocks on the topic together soon, but for now, here's the study material, as I said, page 34:

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 annota-
tions, 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 addi-
tional 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 manu-
ally 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 envi-
ronments without changes or recompilation.

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, as described in [2],
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.