An architectural overview of the EJB programming environment
The World Wide Web (the Web) has transformed the way in which businesses
work with their customers. At first, it was good enough just to have a
Web home page. Then, businesses began to deploy active Web sites that
allowed customers to order products and services. Today, businesses not
only need to use the Web in all of these ways, they need to integrate their
Web-based systems with their other business systems. The IBM(R)
WebSphere Application Server, and specifically the support for enterprise
beans, provides the model and the tools to accomplish this integration.
IBM's implementation of the Sun Microsystems Enterprise JavaBeans (EJB)
Specification enables users of the WebSphere Application Server to integrate
their Web-based systems with their other business systems. A major part
of this implementation is the WebSphere EJB server and its associated
components, which are illustrated in Figure 1.
Figure 1. The components of the EJB environment

The WebSphere EJB server environment contains the following components,
which are discussed in more detail in the specified sections:
The EJB server is the application server tier of WebSphere Application
Server's three-tier architecture. The EJB server has three
components: the EJB server runtime, the EJB containers, and the
enterprise beans. EJB containers insulate the enterprise beans from the
underlying EJB server and provide a standard application programming interface
(API) between the beans and the container. The EJB Specification
defines this API.
Together, the EJB server and container components provide or give access to
the following services for the enterprise beans that are deployed into
it:
- A tool that deploys enterprise beans. When a bean is deployed, the
deployment tool creates several classes that implement the interfaces that
make up the predeployed bean. In addition, the deployment tool
generates Java ORB, stub, and skeleton classes that enable remote method
invocation. For entity beans, the tool also generates persistor and
finder classes to handle interaction between the bean and the data source that
stores the bean's persistent data. Before an enterprise bean can
be deployed, the developer must create an EJB module and associated
deployment descriptor. The deployment descriptor provides
information about each enterprise bean in the module and instructions for the
container on how to handle the beans. For more information on
deployment, see Deploying an EJB module.
- A security service that handles authentication and authorization for
principals that need to access resources in an EJB server environment.
For more information, see The security service.
- A workload management service that ensures that resources are used
efficiently. For more information, see The workload management service.
- A persistence service that handles interaction between an entity bean and
its data source to ensure that persistent data is properly managed. For
more information, see The persistence service.
- A naming service that exports a bean's name, as defined in the
deployment descriptor, into the name space. The EJB server uses the
Java Naming and Directory Interface(TM) (JNDI) to implement a naming
service. For more information, see The naming service.
- A transaction service that implements the transactional attributes in a
bean's deployment descriptor. For more information, see The transaction service.
When enterprise computing was handled solely by a few powerful mainframes
located at a centralized site, ensuring that only authorized users obtained
access to computing services and information was a fairly straightforward
task. In distributed computing systems where users, application
servers, and resource managers can be spread out across the world, securing
computing resources has become a much more complicated task.
Nevertheless, the underlying issues are basically the same.
A good security service provides two main functions: authentication and
authorization.
Authentication takes place when a principal (a user
or a computer process) initially attempts to gain access to a computing
resource. At that point, the security service challenges the principal
to prove that the principal is who it claims to be. Human users
typically prove who they are by entering a user ID and password; a
process normally presents an encrypted key. If the password or key is
valid, the security service gives the user a token or
ticket that identifies the principal and indicates that the
principal has been authenticated.
After a principal is authenticated, it can then attempt to use any of the
resources within the boundaries of the computing system protected by the
security service; however, a principal can use a particular computing
resource only if it has been authorized to do so.
Authorization takes place when an authenticated principal requests
the use of a resource and the security service determines if the user has been
granted permission to use that resource. Typically, authorization is
handled by associating access control lists (ACLs) with resources that define
which principal (or groups of principals) are authorized to use the
resource. If the principal is authorized, it gains access to the
resource.
In a distributed computing environment, principals and resources must be
mutually suspicious of each other's identity until both have proven that
they are who they say they are. This is necessary because principals
can attempt to falsify an identity to get access to a resource, and a resource
can be a trojan horse, attempting to get valuable information from the
principal. To solve this problem, the security service contains a
security server that acts as a trusted third party, authenticating
principals and resources so that these entities can prove their identities to
each other. This security protocol is known as mutual
authentication.
The security service does not use the access control
and run-as identity security attributes defined in the deployment
descriptor. However, it does use the run-as mode attribute
as the basis for mapping a user identity to a user security context.
For more information on this attribute, see The deployment descriptor.
The main component of the security service is an EJB server that contains
security enterprise beans. When system administrators administer the
security service, they manipulate the security beans in the security EJB
server.
Once an EJB client is authenticated, it can attempt to invoke methods on
the enterprise beans that it manipulates. A method is successfully
invoked if the principal associated with the method invocation has the
required permissions to invoke the method. These permissions can be set
at the application level (an administrator-defined set of Web and object
resources) and at the method group level (an administrator-defined set of Java
interface/method pairs). An application can contain multiple method
groups.
In general, the principal under which a method is invoked is associated
with that invocation across multiple Web servers and EJB servers (this
association is known as delegation). Delegating the method
invocations in this way ensures that the user of an EJB client needs to
authenticate only once. HTTP cookies are used to propagate a
user's authentication information across multiple Web servers.
These cookies have a lifetime equal to the life of the browser session, and a
logout method is provided to destroy these cookies when the user is
finished.
For information on administering security, see the WebSphere InfoCenter and
the online help available with the WebSphere Administrative Console.
The workload management service improves the scalability of the EJB server
environment by grouping multiple EJB servers into server
groups. Clients then access these server groups as if they are a
single EJB server, and the workload management service ensures that the
workload is evenly distributed across the EJB servers in the server
groups. An EJB server can belong to only one server group.
The creation of server groups is an administrative task that is handled from
within the WebSphere Administrative Console. For more information on
workload management, consult the WebSphere InfoCenter and the online help for
the appropriate administrative interface.
There are two types of enterprise beans: session beans and entity
beans. Session beans encapsulate temporary data associated with a
particular client. Entity beans encapsulate permanent data that is
stored in a data source. For more information, see An introduction to enterprise beans.
The persistence service ensures that the data associated with entity beans
is properly synchronized with their corresponding data in the data
source. To accomplish this task, the persistence service works with the
transaction service to insert, update, extract, and remove data from the data
source at the appropriate times.
There are two types of entity beans: those with container-managed
persistence (CMP) and those with bean-managed persistence (BMP). In
entity beans with CMP, the persistence service handles nearly all of the tasks
required to manage persistent data. In entity beans with BMP, the bean
itself handles most of the tasks required to manage persistent data.
The persistence service uses the following components to accomplish its
task:
- The Java Database Connectivity (JDBC(TM)) API, which gives entity beans a
common interface to relational databases.
- Java transaction support, which is discussed in Using transactions in the EJB server environment. The EJB server ensures that persistent data is
always handled within the appropriate transactional context.
In an object-oriented distributed computing environment, clients must have a
mechanism to locate and identify objects so that the clients, objects, and
resources appear to be on the same machine. A naming service provides
this mechanism. In the EJB server environment, JNDI is used to mask the
actual naming service and provide a common interface to the naming
service.
JNDI provides naming and directory functionality to Java applications, but
the API is independent of any specific implementation of a naming and
directory service. This implementation independence ensures that
different naming and directory services can be used by accessing them by way
of the JNDI API. Therefore, Java applications can use many existing
naming and directory services such as the Lightweight Directory Access
Protocol (LDAP), the Domain Name Service (DNS), or the DCE Cell Directory
Service (CDS).
JNDI was designed for Java applications by using Java's object
model. Using JNDI, Java applications can store and retrieve named
objects of any Java object type. JNDI also provides methods for
executing standard directory operations, such as associating attributes with
objects and searching for objects by using their attributes.
In the EJB server environment, the deployment descriptor is used to specify
the JNDI name for an enterprise bean. When an EJB server is started, it
registers these names with JNDI.
A transaction is a set of operations that transforms data from one
consistent state to another. This set of operations is an indivisible
unit of work, and in some contexts, a transaction is referred to as a
logical unit of work (LUW). A transaction is a tool for
distributed systems programming that simplifies failure scenarios.
Transactions provide the ACID properties:
- Atomicity: A transaction's changes are atomic:
either all operations that are part of the transaction happen or none
happen.
- Consistency: A transaction moves data between consistent
states.
- Isolation: Even though transactions can run (or be
executed) concurrently, no transaction sees another's work in
progress. The transactions appear to run serially.
- Durability: After a transaction completes successfully,
its changes survive subsequent failures.
As an example, consider a transaction that transfers money from one account
to another. Such a transfer involves money being deducted from one
account and deposited in the other. Withdrawing the money from one
account and depositing it in the other account are two parts of an
atomic transaction: if both cannot be completed, neither must
happen. If multiple requests are processed against an account at the
same time, they must be isolated so that only a single transaction
can affect the account at one time. If the bank's central computer
fails just after the transfer, the correct balance must still be shown when
the system becomes available again: the change must be
durable. Note that consistency is a function of
the application; if money is to be transferred from one account to
another, the application must subtract the same amount of money from one
account that it adds to the other account.
Transactions can be completed in one of two ways: they can commit or
roll back. A successful transaction is said to
commit. An unsuccessful transaction is said to roll
back. Any data modifications made by a rolled back transaction
must be completely undone. In the money-transfer example, if money is
withdrawn from one account but a failure prevents the money from being
deposited in the other account, any changes made to the first account must be
completely undone. The next time any source queries the account
balance, the correct balance must be shown.
A distributed transaction is one that runs in multiple processes,
often on several machines. Each process participates in the
transaction. This is illustrated in Figure 2, where each oval indicates work being done on a
different machine, and each arrow indicates a remote method invocation
(RMI).
Figure 2. Example of a distributed transaction

Distributed transactions, like local transactions, must adhere to the ACID
properties. However, maintaining these properties is greatly
complicated for distributed transactions because a failure can occur in any
process, and in the event of such a failure, each process must undo any work
already done on behalf of the transaction.
A distributed transaction processing system maintains the ACID properties
in distributed transactions by using two features:
- Recoverable processes: Recoverable processes are those
that can restore earlier states if a failure occurs.
- A commit protocol: A commit protocol enables multiple
processes to coordinate the committing or rolling back (aborting) of a
transaction. The most common commit protocol, and the one used by the
EJB server, is the two-phase commit protocol.
Transaction state information must be stored by all recoverable
processes. However, only processes that manage application data (such
as resource managers) must store descriptions of changes to data. Not
all processes involved in a distributed transaction need to be
recoverable. In general, clients are not recoverable because they do
not interact directly with a resource manager. Processes that are not
recoverable are referred to as ephemeral processes.
The two-phase commit protocol, as the name implies, involves two
phases: a prepare phase and a resolution phase. In each
transaction, one process acts as the coordinator. The
coordinator oversees the activities of the other participants in
the transaction to ensure a consistent outcome.
In the prepare phase, the coordinator sends a message to each
process in the transaction, asking each process to prepare to commit.
When a process prepares, it guarantees that it can commit the transaction and
makes a permanent record of its work. After guaranteeing that it can
commit, it can no longer unilaterally decide to roll back the
transaction. If a process cannot prepare (that is, if it cannot
guarantee that it can commit the transaction), it must roll back the
transaction.
In the resolution phase, the coordinator tallies the
responses. If all participants are prepared to commit, the transaction
commits; otherwise, the transaction is rolled back. In either
case, the coordinator informs all participants of the result. In the
case of a commit, the participants acknowledge that they have
committed.
The enterprise bean transaction model corresponds in most respects to the
OMG OTS version 1.1. An enterprise bean instance that is
transaction enabled corresponds to an object of the OTS TransactionalObject
interface. However, the enterprise bean transaction model does not
support transaction nesting.
In the EJB server environment, transactions are handled by three main
components of the transaction service:
- A transaction manager interface that enables the EJB server to control
transaction boundaries within its enterprise beans based on the transactional
attributes specified for the beans.
- An interface (UserTransaction) that allows an enterprise bean or an EJB
client to manage transactions. The container makes this interface
available to enterprise beans and EJB clients by way of the name
service.
- Coordination by way of the X/Open XA interface that enables a
transactional resource manager (such as a database) to participate in a
transaction controlled by an external transaction manager.
For most purposes, the enterprise bean developers can delegate the tasks
involved in managing a transaction to the container. The developer
performs this delegation by setting the deployment descriptor attributes for
transactions. These attributes and their values are described in Setting transactional attributes in the deployment descriptor.
In other cases, the enterprise bean developer will want or need to manage
the transactions at the bean level or involve the EJB client in the management
of transactions. For more information on this approach, see Using bean-managed transactions.
Entity beans contain persistent data that must be permanently stored in a
recoverable data source. Although the EJB Specification often refers to
databases as the place to store persistent data associated with an entity
bean, it leaves open the possibility of using other data sources, including
operating system files and other applications.
If you want to let the container handle the interaction between an entity bean
and a data source, you must use the data sources supported by that
container.
If you write the additional code required to handle the interaction between
a BMP entity bean and the data source, you can use any data source that meets
your needs and is compatible with the persistence service. For more
information, see Developing entity beans with BMP.
An EJB client can take one of the following forms: it can be a Java
application, a Java servlet, a Java applet-servlet combination, or a JSP
file. The EJB client code required to access and manipulate enterprise
beans is very similar across the different Java EJB clients. EJB client
developers must consider the following issues:
- Naming and communications--A Java EJB client must use
either HTTP or RMI to communicate with enterprise beans. Fortunately,
there is very little difference in the coding required to enable
communications between the EJB client and the enterprise bean, because JNDI
masks the interaction between the EJB client and the name service.
- Java applications communicate with enterprise beans by using
RMI/IIOP.
- Java servlets and JSP files communicate with enterprise beans by using
HTTP. To use servlets with an EJB server, a Web server must be
installed and configured on a machine in the EJB server environment.
For more information, see The Web server.
- Threading--Java clients can be either single-threaded or
multithreaded depending on the tasks that the client needs to perform.
Each client thread that uses a service provided by a session bean must create
or find a separate instance of that bean and maintain a reference to that bean
until the thread completes; multiple client threads can access the same
entity bean.
- Security - EJB clients that access an EJB server over
HTTP (for example, servlets and JSP files) encounter the following two layers
of security:
- Universal Resource Locator (URL) security enforced by the WebSphere
Application Server Security Plug-in attached to the Web server in
collaboration with the security service.
- Enterprise bean security enforced at the server working with the security
service.
When the user of an HTTP-based EJB client attempts to access an enterprise
bean, the Web server (using the WebSphere Server plug-in) authenticates the
user. This authentication can take the form of a request for a user ID
and password or it can happen transparently in the form of a certificate
exchange followed by the establishment of a Secure Sockets Layer (SSL)
session.
The authentication policy is governed by an additional option: secure
channel constraint. If the secure channel constraint is required, an
SSL session must be established as the final phase of authentication;
otherwise, SSL is optional.
- Transactions--Both types of Java clients can use the
transaction service by way of the JTA interfaces to manage
transactions. The code required for transaction management is identical
in the two types of clients. For general information on transactions
and the Java transaction service, see The transaction service. For information on managing transactions in a Java
EJB client, see Managing transactions in an EJB client.
To access the functionality in the EJB server, Java servlets and JSP files
must have access to a Web server. The Web server enables communication
between a Web client and the EJB server. The EJB server, Web server,
and Java servlet can each reside on different machines.
For information on the Web servers supported by the EJB servers, see the
Advanced Application Server Getting Started document.
The EJB server uses the WebSphere Administrative Console. For more
information on this interface, consult the WebSphere InfoCenter and the online
help available with the WebSphere Administrative Console. You can also
administer the EJB server using the wscp command-line tool.
For more information, see the Advanced Edition Information Center.