In the past few years, 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 Advanced
Edition and WebSphere Application Server Enterprise Edition 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, connecting the client tier (Java
servlets, applets, applications, and JSP) with the resource management tier
(the data source). The WebSphere Application Server contains two types
of EJB servers. If you have the Advanced Application Server, you get
only one of these EJB servers; if you have the Enterprise Application
Server, you get both. When referring generically to EJB servers, this
documentation uses the phrase EJB server; when the
documentation needs to refer specifically to one or the other, it uses the
following terms:
- EJB server (AE)--The EJB server that comes with the
Advanced Application Server. (Because Advanced Application Server is
available as a part of Enterprise Application Server, this EJB server is also
available with Enterprise Application Server.)
- EJB server (CB)--The EJB server that comes only with the
Enterprise Application Server and is part of Component Broker (CB).
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.
The EJB server (CB) includes two standard types of containers: entity
containers and session containers. As their names imply, these
containers are specifically optimized to handle entity beans and session
beans, respectively. The EJB server (AE) has one standard container
that supports both entity and session beans.
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.
There are some similarities between the security service in the two EJB
server environments. In both EJB server environments, 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 major differences between the two security services are discussed in
the following sections.
Security in the EJB server (AE) environment
In the EJB server (AE) environment, 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 in the EJB server (AE)
environment, see the WebSphere InfoCenter and the online help available with
the WebSphere Administrative Console.
Security in the EJB server (CB) environment
In the EJB server (CB) environment, you must secure all the Component Broker
name servers and applications servers in the network. Securing the name
server on each server host prevents unauthorized access to the system objects
(including name contexts used in the Component Broker namespace) in that
server. Securing an application server prevents unauthorized access to
the business objects for applications in that server.
To secure your name servers and application servers, you must do the
following:
- Install and configure the Distributed Computing Environment (DCE) to
provide authentication services to the servers. This allows secure
access between servers.
- Configure key rings for clients and servers to provide authentication
services to Java-based SSL clients.
- Configure authorization for access to business objects in the application
service.
- Create a delegation policy to allow the application server to pass the
requesting client principal to other servers.
- Configure credential mapping to provide access to any third tier
system.
- Configure the qualities of protection to be used to protect messages that
flow between clients and the application server.
The Component Broker System Administration Guide
provides more detail about each of these tasks.
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 the EJB server (AE)
environment and from within the Systems Management End User Interface for the
EJB server (CB) environment. 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.
In the EJB server (AE) environment, 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 the EJB server (CB) environment, the persistence service uses the
following components to accomplish its task:
- The X/Open XA interface, which gives entity beans a standard interface to
relational databases.
- The Object Management Group's (OMG) Object Transaction Service (OTS),
which is also discussed in Using transactions in the EJB server environment.
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:
- The EJB server (AE) supports DB2(R), Oracle, Sybase, and
InstantDB.
- The EJB server (CB) supports DB2, Oracle, CICS(R), IMS(TM), and
MQSeries(R).
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. For the EJB server (CB), a Java applet can be used to directly
interact with enterprise beans. For the EJB server (AE), a Java applet
can be used only in combination with a servlet.
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 (AE) 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.
- All EJB clients that access an EJB server (CB) and EJB clients that access
an EJB server (AE) by using RMI (for example, Java applications) encounter the
second security layer only. Like HTTP-based EJB clients, these EJB
clients must authenticate with the security service.
For more information, see The security service.
- 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.
In the EJB server (CB) environment, an enterprise bean can also be accessed
by EJB clients that use Microsoft(R) ActiveX(R), CORBA-based Java, and
to a limited degree, CORBA-based C++. More information on EJB clients specific to the EJB server (CB) provides additional information.
- Note:
- In the EJB server (AE) environment, ActiveX and CORBA-based access to
enterprise beans is not supported.
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 (CB) and EJB server (AE) each have their own administration
tools:
- The EJB server (AE) 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.
- The EJB server (CB) uses the System Management End User Interface (SM
EUI). For more information on this interface, see the Component Broker
System Administration Guide.
You can also administer the EJB server (AE) using the wscp
command-line tool. For more information, see the Advanced Edition
Information Center.