Developer’s Guide to Understanding Enterprise JavaBeans

mapping, the developer may find it more effective to use bean-managed persistence. Developer’s Guide to Understanding Enterprise JavaBeans™ …

More PDF Content

Developer\'s Guide to Understanding Enterprise JavaBeansTM

Developer\'s Guide to
Understanding Enterprise
JavaBeansTM

Chris Crenshaw
Nova Laboratories
www.nova-labs.com

Version 1.4.1

For more information about Nova Laboratories or the Developer Kitchen Series, or to add
your name to our monthly mailing list, visit our website at http://www.nova-labs.com
Nova Laboratories also offers in-house and on-site training and consulting services.
Nova Laboratories
187 Monmouth Park Highway
West Long Branch, New Jersey 07764
732-263-9000
732-263-0189 (fax)
This material is copyrighted by Nova Laboratories (c) 1998. This material shall not be reproduced or
distributed in any form without the express written consent of Nova Laboratories.
All rights reserved.
The Developer Kitchen is a registered servicemark of Nova Laboratories. Java and all Java-based
trademarks and logos trademarks or registered trademarks of Sun Microsystems, Inc. in the United
States and other countries. All other products referenced herein are trademarks of their respective
holders. (c) 1998 Nova Laboratories.

2

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

1 - Preface

Purpose of this Document
The Enterprise JavaBeansTM 1.0 Specification is the formal specification for
Enterprise JavaBeansTM. It formally defines a set of standards for a JavaTM
server component specification. However, it tends to be targeted more toward
the vendors who need a blueprint describing the mininal requirements for
creating an EJB server than for developers who are looking to learn about EJB.
This document is not intended to replace the Specification. The Specification is
the official blueprint for Enterprise JavaBeansTM. Instead, this document will
hopefully serve as a useful primer for developers who want a technical
introduction to EJB. It attempts to summarize areas of the Specification that
are of particular interest to developers who are trying to learn EJB.
Nor is this document a tutorial on EJB. Such a document could be several
hundred pages in itself. Instead, its goal is to clearly lay out a detailed
description of the architecture of EJB, and how the various components fit
together.
Overall, the purpose of this document is to provide a solid technical
introduction to EJB. It should benefit both developers looking to start writing
with EJB as well as developers who need to perform a detailed analysis of EJB
to determine whether an EJB solution is appropriate for their application.

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

3

Version 1.4.1

How to read this document
This document consists of three sections, plus this Preface. Additional sections
will be added to this document over time that address some of the more
specific advanced features of Enterprise JavaBeansTM.
Preface - This section. Defines some basic terms that will be used throughout
this document. Lists some available documents and products that may be
useful to the reader.
Introducing Enterprise JavaBeansTM - This section more fully describes the
purpose of this document. The high-level architecture of Enterprise
JavaBeansTM is illustrated, along with simplified definitions of the major
components. Also in this section are explanations of how Enterprise
JavaBeansTM relates to other technologies, such as JavaTM RMI, JavaBeansTM,
and CORBA(R) . Some of the benefits of Enterprise JavaBeansTM are listed here,
along with definitions of the various roles that a developer or vendor may fill
in creating an Enterprise JavaBeansTM solution.
Understanding EJB Components - In this section the reader will get very
detailed definitions of the components of Enterprise JavaBeansTM. The focus of
this section is to explain how these components operate in a runtime
environment. An attempt is made to describe the minimal behavioral
requirements of the components as defined in the Enterprise JavaBeansTM
Specification, along with some practical scenarios describing how vendors
will likely implement these components.
Transactions - Transaction control is a powerful feature of Enterprise
JavaBeansTM, and can be a very complicated subject. This section will explain
how transactions are used and controlled within Enterprise JavaBeansTM. Also
in this section is coverage of the CORBA(R) Object Transaction Service, or OTS.
The transaction model in Enterprise JavaBeansTM is essentially an
implementation of OTS, and understanding the interfaces and semantics of the
components in OTS will allow the reader to better understand transactions in
Enterprise JavaBeansTM.

Defining some basic terms
EJB - a common abbreviation of Enterprise JavaBeansTM.
developer - person who writes implementations of EJB classes.
vendor - creator of an EJB product that can be used to develop, install, or
deploy an EJB class written by a developer. This term is generally used in this
document to refer to an organization that has created a server product capable
of running EJB classes written by an EJB developer.
EJB class - a JavaTM class written and compiled by a developer that conform to
the interfaces and requirements described in the Enterprise JavaBeansTM
Specification.
EJB instance - an instantiation of an EJB class.
Specification - the Enterprise JavaBeansTM Specification

4

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

Additional terms will be defined at the appropriate times throughout this
document.

Sources and references
Documentation
Nova Laboratories website containing this document, descriptions and
availability of EJB lecture and workshop training, and source code examples:

http://www.Nova-Labs.com

Main page for Enterprise JavaBeansTM:

http://java.sun.com/products/ejb

Enterprise JavaBeansTM Specification and other documentation:

http://java.sun.com/products/ejb/docs.html

JNDI - Java Naming and Directory InterfaceTM:

http://java.sun.com/products/jndi

JTS - JavaTM Transaction Service:

http://java.sun.com/products/jts

OTS - CORBAservices(R) Object Transaction Service:

http://www.omg.org/docs/formal/97-12-17.pdf

Trademarks
Enterprise JavaBeansTM , JavaTM, JavaBeansTM, JDBCTM, and JavaTM Naming and
Directory InterfaceTM are trademarks or registered trademarks of Sun
Microsystems, Inc.
CORBA(R), CORBAservices(R), and IIOPTM are trademarks or registered
trademarks of Object Management Group, Inc.

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

5

Version 1.4.1

This page intentionally left blank

6

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

2 - Introducing Enterprise JavaBeansTM

Introducing Enterprise JavaBeansTM
Services Framework
Enterprise JavaBeansTM is not a product. It is a specification for a JavaTM
server-side services framework from which vendors can create EJB server
implementations. The benefit to application developers is that they can focus
on writing the business logic necessary to support their application without
having to worry about implementing the surrounding framework.
The Specification details certain minimal yet crucial services such as
transactions, security, and naming. The vendors must follow these
specifications to ensure that an enterprise bean can always rely on certain
required services. The Specification does not state how vendors should go
about implementing these services. While this can make it harder to learn EJB
simply by reading the Specification, it does allows vendors the freedom to
provide enhancements without sacrificing portability regarding core services.
JavaBeansTM vs Enterprise JavaBeansTM
JavaBeansTM is the component model for JavaTM. Within the JavaBeansTM
Specification there are features defined such as events and properties.
Enterprise JavaBeansTM also describes, among other things, a JavaTM
component model, but the component model for Enterprise JavaBeansTM is not
the same as JavaBeansTM.
With JavaBeansTM the emphasis is on allowing developers to visually
manipulate components in a builder tool. To that end, the JavaBeansTM
Specification describes in detail the APIs and semantics for inter-component

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

7

Version 1.4.1

event registration and delivery, recognition and utilization of properties,
customization, and persistence.
The emphasis for Enterprise JavaBeansTM is to detail a model for a services
framework into which JavaTM components can be portably deployed.
Consequently, there is no mention of events, since enterprise beans do not
typically send or receive events. Nor is there mention of properties.
Customization does exist, but is not performed at development time using
properties, but at runtime (deployment time, actually) using a deployment
descriptor.
Do not look for similarities between JavaBeansTM and Enterprise JavaBeansTM.
They are both specifications for component models, but one addresses issues
of application assembly in a builder tool, while the other details a services
framework into which components can be deployed.
Don\'t make the mistake of thinking that JavaBeansTM is for client-side
development and Enterprise JavaBeansTM is for server-side development.
JavaBeansTM can be an appropriate component model for building
non-graphical server-side JavaTM applications. The difference is that when you
use JavaBeansTM to create a server application, you have to build the entire
server framework. With Enterprise JavaBeansTM the framework is provided
for you; you simply conform to its APIs. For complex server-side applications
it is easier to plug in than reinvent.
Enterprise JavaBeansTM Architecture
The EJB server is the high-level process or application that manages EJB
containers, along with providing access to system services. The EJB server may
also provide vendor-specific features, such as optimized database access
interfaces, availability of additional services such as CORBAservices(R),
support for SSL 3.0, and so forth.
An EJB server is required to provide availability of a JNDI-accessible naming
service and a transaction service.
Some examples of EJB servers may be:
i database servers
i application servers
i middleware servers
The EJB container is an abstraction that manages one or more EJB classes
and/or instances. It makes required services available to the EJB classes
through an interface defined in the Specification. The container vendor may
also provide interfaces to additional services implemented either in the
container or in the server.
There is currently no specification for the interface between the EJB server and
the container. Therefore the container is currently provided by the EJB server.
Once an interface is standardized, it is likely that vendors will create
containers that can run in any conformant EJB server.
The home interface lists the available factory methods for locating, creating, and
removing instances of EJB classes. The home object is the implementation of the
home interface. The developer of the EJB class must also define the home

8

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

interface. The container vendor should provide the means to generate the
home object implementation from the home interface.
The remote interface lists the business methods in the EJB class. The EJBObject
implements the remote interface, and is the object that the client must use to
access the business methods of the EJB instance. The EJB class developer
defines the remote interface, and the container vendor should provide the
means to generate the corresponding EJBObject.
The client never gets a reference to the EJB instance, only its EJBObject
instance. When the client invokes a method, the EJBObject receives the request
and delegates it to the EJB instance, providing any necessary wrapper
functionality in the process.
The client is an application that uses the home object to locate, create, or
destroy instances of an EJB class, and uses the EJBObject to invoke the
business methods of an instance. The client can be written in JavaTM and use
JavaTM RMI to access the home object and EJBObject, or it may be written in
another language using CORBA(R)/IIOPTM, providing the required server-side
components are deployed in a manner that makes them accessible through
CORBA(R) interfaces.
EJB Server
EJB Container
Home
create()
remove()

Remote

EJBObject
business
methods

Bean

Client
Remote

EJBObject
business
methods

Bean

Services
Transaction
Naming
Persistence

Here is an illustration of the architecture of Enterprise JavaBeansTM. The next
section will go into greater detail to describe the individual components.

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

9

Version 1.4.1

Benefits of Enterprise JavaBeansTM
As a developer you should be considering whether Enterprise JavaBeansTM is
appropriate for your application.
There are considerations when using EJB.
i the EJB server is a product that you must purchase
i you must implement a minimal API, and understand its semantics
The advantages far outweigh the disadvantages, especially for more complex
applications.
Establishing Roles for Application Development
EJB allows the right person to do the right job. Business developers can focus
on writing code that implements business functions. The deployer can take
care of installation issues in a simple and portable fashion. The EJB server
vendors will take care of providing support for complex services, and make
them available to the bean often without the knowledge or assistance of the
bean developer.

Automatic Transaction Management
One of these services transparently provided by the container vendor is
transaction control.
The person writing the business functions does not have to worry about
starting and terminating transactions, nor about whether or not the operations
in this business function will work correctly in conjunction with business
functions in other beans.
Distributed Transaction Support
Part of the transparency of transactions is through distributed transaction
support. A client can, for example, begin a transaction and then invoke
methods on beans in two different servers. Methods in one bean can call
methods in another bean with the assurance that they will execute in the same
transaction context.
Portability
With the exception of publicized vendor-specific enhancements, an enterprise
bean will install and run in a portable fashion in any EJB server.
Scalability
While the architecture of EJB may appear to be somewhat complex, you\'ll find
that the more you understand the architecture, the more you\'ll see that the
Specification was written to allow vendors to provide extremely
high-performance implementations. In addition, you should expect to see
such features as load-balancing and failover once the EJB server market
matures.
Integration with CORBA(R)
If you are familiar with CORBA(R), a question may arise regarding the apparent
competition between CORBA(R) and EJB. But in fact CORBA(R) and EJB are a

10

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

natural complement to each other. EJB is moving in the direction of using
CORBA(R)/IIOPTM to provide a more robust transport mechanism. In addition,
pure CORBA(R) clients will be able to access enterprise beans as EJB clients.
CORBAservices(R) provides a wealth of features to an application developer.
Rather than trying to replace these services, EJB server vendors will likely
include CORBAservices(R) into their product through a simplified API,
allowing bean developers to use CORBAservices(R) without needing to become
experts in CORBA(R). An excellent example of this is the transaction support
provided by EJB servers to enterprise beans. The transaction service is
probably an implementation of CORBA(R) OTS. For an EJB server to work
correctly with CORBA(R) clients, its transaction and naming services will have
to support the CORBA(R) OTS and Naming Service interfaces, respectively.
Vendor Enhancements
The real value in Enterprise JavaBeansTM is the flexibility the specification
allows for vendors to provide their own enhancements. Features like
automatic object-relational mapping when using container-managed
persistence, gateway services into existing applications, customizable business
frameworks, and integration of CORBAservices(R) are just a few examples of
added value that may be provided by vendors.

Roles in EJB Development
EJB Developer
The EJB developer writes EJB classes using the required classes and interfaces
as defined in the Specification. Within this class are the methods for creating
and removing the EJB instance, along with the business methods of this class.
The EJB developer is a JavaTM developer with an understanding of the
interfaces and semantics of Enterprise JavaBeansTM, and understands the
business needs that must be addressed. The EJB developer is responsible for
implementing the functionality of the business application\'s server side as
discrete business objects.
While the EJB container will usually handle all transaction control on behalf of
the EJB instance, it is important that the EJB developer understand how
transactions work so that he/she may stipulate to the EJB deployer the
transactional needs of the various methods in the EJB class.
EJB Deployer
The EJB deployer is responsible for taking the EJB class and its supporting
classes and installing them correctly in the EJB server. The deployer has an
in-depth understanding of EJB and the characteristics of the runtime server
environment, such as database type and location, and so forth.
The deployer receives the EJB class requirements from the EJB developer, such
as transactional needs, names and descriptions of required environment
properties, and so forth.
The deployer must make these properties, along with their correct runtime
values, available to the EJB class at runtime. The deployer is also responsible

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

11

Version 1.4.1

for ensuring that the home object for the EJB class is available in a namespace
accessible through JNDI.
The EJB deployer may not be a JavaTM developer nor understand the business
rules that an EJB class implements, but understands the application
framework in which the EJB instance runs.
For example, the deployer may not understand the details of a database
application written using EJB, but knows the location, schema, and
transactional requirements of the underlying database.The deployer may be
the person to decide critical runtime attributes such as transaction isolation
levels, and so forth. It is important for the EJB developer and deployer to
communicate clearly to ensure that the EJB class is deployed with the correct
deployment attributes.
EJB Container Vendor
The EJB container vendor provides software to install an EJB class and its
supporting classes into an EJB server. The container vendor must also supply
runtime classes that can provide the required services to the EJB instances at
runtime. Examples of additional tasks are the generation of stub and skeleton
classes to provide access to the EJB class\' home object and EJBObjects,
installation of references to the home object in a JNDI-accessible namespace,
and availability of a suitable EJBObject implementation that can provide
correct proxy services for the EJB class.
EJB Server Vendor
The EJB server vendor provides an application framework in which to run EJB
containers.
The EJB server will implement, or provide access to, required services such as
a JNDI-accessible naming service and an OTS-compatible transaction service.
Since there is currently no standard interface between the EJB server and the
EJB container, the EJB container is actually provided by the EJB server vendor.
Application Developer
The application developer writes the client applications that use EJB classes. A
client may be a JavaTM applet or application, a servlet, or a natively compiled
application that uses a CORBA(R)/IIOPTM interface to access the EJB
components.
The application developer is providing a business application that uses the
available EJB classes and methods as abstractions for obtaining low-level
application services. This allows the application developer to concentrate on
high-level functions such as data representation to the user without having to
worry about how such data is obtained.

12

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

3 - Understanding the EJB Components

You should now be familiar with the overall architecture of EJB, along with its
major components. This section will describe these components in
considerably more detail, and will explain their runtime behavioral semantics.

Home Interface
Factory for Enterprise Beans
A client needing the use of an enterprise bean creates one through its home
interface. The home interface lists one or more create() methods that can be
used to create an instance of this enterprise bean. This home interface is not
implemented by the bean, but by some other class we\'ll call the home object.
An instance of this home object is instantiated within the server and made
available to clients as a factory for the enterprise bean.
Locating the Home Object
A reference to the home object is placed in a naming service that is accessible
from the client using JNDI. The EJB server will likely provide some sort of
namespace implementation, although an external namespace could be used.
In either case the location of the namespace and the JNDI context factory class
name must be provided to the client initially. For example, a client applet
might receive the namespace location and JNDI context factory class name as
applet parameters.
In addition to providing the location and class name, the client must also have
some knowledge of how to locate the home object within the naming tree.
This should also be provided to the client at startup. When the deployer
installs the enterprise bean into the EJB server, he/she may have the option of
specifying a particular location in the naming tree, such as

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

13

Version 1.4.1

ejb/accounting/AccountsPayable. The client must be given this

fully-qualified pathname to locate and obtain the reference to the
AccountsPayable home object.
It is incorrect to say that a container is made available to clients through JNDI.
Clients look up a home interface implementation using JNDI. That
implementation may be provided by a custom container, but this is a
vendor-specific detail that should be ignored by both the enterprise bean
developer and the client.
Methods in the Home Interface
The developer that defines ejbCreate() methods in the enterprise bean must
also declare corresponding create() methods with matching signatures in
the enterprise bean\'s home interface.
Entity beans may also have finder methods which allow clients to locate existing
entity beans based on their identity.
The home interface is defined as extending from javax.ejb.EJBHome. This
interface has the following methods:
public interface javax.ejb.EJBHome extends Remote {
public EJBMetaData getEJBMetaData() throws
RemoteException;
public void remove(Handle handle) throws
RemoteException,
RemoveException;
public void remove(Object primaryKey) throws
RemoteException,
RemoveException;
}

The home interface for a bean might look like this:
public interface myHome extends EJBHome {
public myRem create() throws

RemoteException,
CreateException;

public myRem create(String str) throws
RemoteException,
CreateException;
}

where
public interface myRem extends EJBObject { ... }

The container vendor is responsible for providing the home object which
implements this home interface, since only the vendor can implement the
code that can act as the factory to create the enterprise beans.

14

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

Container
Defining the Container
In reading the Enterprise JavaBeansTM 1.0 Specification the term container
should not be taken literally as a class, but as a level of responsibility where a
set of services must be performed on behalf of the bean. A container vendor
will provide a set of tools and classes that run within an EJB server that fulfill
these responsibilities.
Some of these services are:
i swapping to and from secondary storage (for session beans)
i persistence management (for entity beans)
i availability of a home object implementing creation and lookup services
i visibility of the home object in a JNDI-accessible namespace
i proper creation, initialization, and removal of beans
i ensuring that business methods run in the proper transaction context
i implementation of certain basic security services
i generation of stubs and skeletons for remote method invocation on the
home object and EJBObject
Container and EJBObject as a Pair
The Specification often refers to services that may be provided by either the
container or the EJBObject. These references are illustrative and do not imply
service requirements of a specific class.
Both the EJBObject and the container class(es) are provided by the container
vendor to support an enterprise bean. Together these classes must fulfill the
responsibilities of the bean container.
Both the container and the EJBObject have distinct entry points into the bean,
giving each a unique ability to provide support for a specific service. For
example, the container knows which transaction attributes apply to the
methods of the bean by reading its deployment descriptor. However, it is
through the EJBObject that these business methods are invoked.
The EJBObject must communicate with the container to determine in what
transaction context to call the business method. Once this is determined, the
EJBObject must establish this transaction context before invoking the business
method.
All that matters is that the EJBObject and container work together to
implement the services required by a container. The container vendor
provides the implementations of both objects, and is free to partition this work
any way it likes.
Relationship to the Home Interface
Vendors currently provide their own tools which read the home interface and
generate the home objects as containers. In this case the vendor is using a
separate container class for each enterprise bean class.

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

15

Version 1.4.1

A container vendor is free to use some other implementation strategy, such as
one container class that implements multiple home interfaces, or even a
standard container class with separately created custom home
implementation objects. The only requirement is that the container vendor
make a home object available to clients through JNDI.
Neither the client nor the bean developer are concerned with the
implementation details of the container and home object.

Enterprise JavaBean
The enterprise bean is the class that the developer writes to provide
application functionality.
The developer has the option of creating either a session bean or an entity
bean, and will make this distinction by implementing the appropriate
interface and declaring its type in the deployment descriptor.
For session beans:
public class myBean implements javax.ejb.SessionBean ...

For entity beans:
public class myBean implements javax.ejb.EntityBean ...

The methods in your enterprise bean will never be invoked directly from the
client. The client calls the bean\'s methods indirectly through the EJBObject,
which acts as a proxy. In routing all invocations through the EJBObject, the
container vendor can insert its own functionality into the invocation through
wrapper code, or method interposition. An example of this would be to create a
new transaction context for each method invocation, or to commit or roll back
the transaction when the method returns (to the EJBObject).
When the container vendor\'s tool generates stubs and skeletons as part of the
installation process of a bean, it creates a stub and skeleton for the bean\'s
EJBObject. It doesn\'t actually create a stub or skeleton for the bean itself, since
it is never accessed over the network. The EJBObject is the true network
object. The bean is the delegate that contains the application-specific business
code.
The container may also call certain methods in the bean. For example, the
container will ensure that after a new instance of a bean is created, that the
arguments used in the call to create() on the home object are passed to the
corresponding ejbCreate() in the bean.
There are additional interfaces and requirements for enterprise beans.
However, these requirements vary based on whether the bean is a session
bean or an entity bean. These will be covered in the subsequent sections
detailing session and entity beans.

Remote Interface
After writing the enterprise bean the developer created a home interface to
specify the signatures of the creation methods that should be made available
to the client, with the restriction that for each create() method specified in
the home interface, there had to be a corresponding ejbCreate() method in
the bean.

16

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

In a similar fashion, the developer must create a remote interface which
describes the business methods of the bean that the developer would like the
client to be able to invoke.
Since all client invocations come through the EJBObject, it is the EJBObject, not
the home object, that will formally implement this interface.
The method names and signatures listed in the remote interface exactly match
the method names and signatures implemented in the bean. This differs from
the home interface, whose method signatures matched, but the names were
different.
Here is an example of a remote interface:
public interface Account extends javax.ejb.EJBObject {
public void deposit(double amount)

throws RemoteException;

public void withdraw(double amount) throws RemoteException;
public double balance()

throws RemoteException;

}

The methods all declare that they may throw a RemoteException, since the
specification states that the client-side stub is RMI-compliant. Keep in mind
that this does not preclude the stub/skeleton implementation from using a
different transport, such as CORBA(R)/IIOPTM.
The remote interface extends the javax.ejb.EJBObject interface, which adds
additional method requirements.

EJBObject
The EJBObject is the network-visible object, with a stub and skeleton, that acts
as a proxy for the bean. The bean\'s remote interface extends the EJBObject
interface, and the EJBObject class implements this remote interface, making
the EJBObject class specific to the bean class. For each bean class there will be
a custom EJBObject class.
Here is the definition of the EJBObject interface, which the bean\'s remote
interface extends:
public interface javax.ejb.EJBObject extends java.rmi.Remote {
public EJBHome getEJBHome()

throws RemoteException;

public Object

getPrimaryKey()

throws RemoteException;

public Handle

getHandle()

throws RemoteException;

public void

remove()

throws RemoteException,
RemoveException;

public boolean isIdentical(EJBObject other) throws
RemoteException;
}

The EJBObject class that implements this interface is an RMI server object,
since it is implementing an RMI remote interface. Note that the bean itself is
not a remote object and is not visible over the network. When the container
instantiates this EJBObject class it will initialize it with the reference to the
bean instance, so that it may delegate the business method calls appropriately.

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

17

Version 1.4.1

The vendor implementation will likely maintain this one-to-one relationship
between an EJBObject instance and a bean instance.
Since the remote interface includes the methods of the EJBObject interface, the
bean should obviously not implement this interface, although it does provide
implementations of the listed business methods.
Since the EJBObject must formally implement the remote interface of the bean,
the container vendors generate the EJBObject\'s source code at bean
installation time, where the generated code implements the bean\'s remote
interface. The EJBObject is typically given a unique class name and associated
with the bean as its EJBObject class.

Session Bean
A session bean is an enterprise bean where each instance of a session bean is
created through its home interface and is private to that client connection. The
session bean instance cannot be easily shared with other clients. This allows
the session bean to maintain the client\'s state.
An example of this might be a shopping cart bean, where many customers can
shop simultaneously, adding to their private cart, instead of everyone adding
their personal items to a community shopping cart.
Defining a Session Bean
You create a session bean by defining a class that implements the
javax.ejb.SessionBean interface. The interface is defined as follows:
public interface javax.ejb.SessionBean extends
javax.ejb.EnterpriseBean {
public void ejbActivate()

throws RemoteException;

public void ejbPassivate()

throws RemoteException;

public void ejbRemove()

throws RemoteException;

public void setSessionContext(SessionContext context)
throws RemoteException;
}

The javax.ejb.EnterpriseBean is an empty interface, and is the supertype
for both session and entity beans.
Swapping Session Beans
The container vendor may optionally implement a swapping mechanism to
move instances of session beans from memory to secondary storage,
increasing the total number of beans that can appear to be instantiated at a
time. The implementation would presumably maintain a timeout threshold on
its beans, and when a bean\'s inactivity period has reached the threshold, it
would be copied to secondary storage and deleted from memory.
A container can use any mechanism it chooses to store the bean persistently.
The most likely means of doing this would be serialization of the bean. The
bean developer should avoid using transient fields in the bean. Instead, the
ejbActivate() and ejbPassivate() should be used to maintain the fields
values.

18

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

Developer\'s Guide to Understanding Enterprise JavaBeansTM

Activation and Passivation
To provide support for swapping by the vendors, the specification formally
defines passivation as the process of swapping out a bean, and activation as
the process of restoring it to memory. The methods ejbActivate() and
ejbPassivate(), declared in the SessionBean interface, allow the container
to tell the bean that it is about to be swapped out, and that it has just been
swapped in. The bean developer can use these methods to release and restore
values, references, and system resources that should not be held while the
bean is in a passivated state. An example of this might be a database
connection, since connections are limited resources and cannot be used by a
bean while it is passivated.
Using these methods makes the use of transient unnecessary. In fact, using
transient can be somewhat unsafe, since it results in fields that are reset to
null or 0 implicitly by the serialization mechanism. It is better that the
developer explicitly maintains these fields through the ejbActivate() and
ejbPassivate() methods.
Relying on JavaTM serialization to set transient fields to null is also
non-portable since this behavior would change if this bean were deployed in
an EJB container which did not use JavaTM serialization to achieve persistence.
If the container does not provide swapping, then these methods will never be
called.
The passivated bean is activated as a result of a business method call from the
client. When the EJBObject receives the method invocation request it informs
the container that the bean must be activated. Once the activation is complete
the EJBObject delegates the method call to the bean.
If the bean is currently in a transaction, it will not be passivated. It is more
efficient to leave the bean in memory, since transactions normally complete
within a fairly short period of time.
If the bean does not have state that must be released prior to passivation or
reset after activation, then these methods can be left empty. In most cases, the
bean developer should not expect to have to do anything in these methods.
Session Bean Management State
A session bean\'s deployment descriptor must declare the bean as either
stateless or stateful. A stateless bean is one which does not maintain any state
information between method calls. In general, the benefit of a session bean is
that it does maintain state on behalf of the client.
However, there is a benefit to having session beans that are stateless. Stateless
session beans are not swapped (or passivated). Since they do not maintain
state, there is nothing to preserve. The container instead has the option of
destroying the bean instance. The client is never aware that the bean has been
destroyed. The client\'s reference is to the EJBObject. If the client later invokes
a business method, the EJBObject will work with the container to instantiate a
new session bean. Since there is no state, there is nothing else to restore.
Also, stateless session beans can be shared by clients, with the restriction that
only one client may be executing a method within the bean at a time. Since
there is no state maintained between the method calls, any client can use any

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited

19

Version 1.4.1

stateless bean instance. This would allow the container to possibly maintain a
smaller pool of reusable session beans, saving memory.
Since a stateless session bean cannot maintain state between method calls, it is
technically an error to define create() methods in the home interface that
take arguments. Passing arguments to the bean during creation implies that
state may be maintained in the bean after the call to ejbCreate() returns.
Furthermore, the container must be able to fully recreate a stateless session
bean as a result of a business method call on the EJBObject. At that point it
would no longer have the startup arguments that were used to create the bean
initially. The vendor\'s installation tool should check that the home interface of
a stateless session bean does not contain create() methods with arguments.

Entity Beans
Role of the Entity Bean
Entity beans are used to represent underlying objects. The most common
application for entity beans is their representation of data in a relational
database. A simple entity bean can be defined to represent a row in a database
table, where each instance of the bean represents a specific row. More
complex entity beans could represent views of joined tables in a database,
where one instance represents a specific customer and all of that customer\'s
orders and order items. For these beans there should be considerable demand
for vendor enhancements, such as integrated object-relational mapping.
In most cases it is both simpler and more efficient to have an entity class
represent one database table than a set of related tables. Relationship traversal
can be easily added to the entity class definitions, thus maximizing cache
reuse and minimizing the presence of stale data.
Comparing Entity and Session Beans
It may seem that session beans are not very useful, especially for applications
that are database-driven. This is certainly not true. Since an entity bean
instance represents (for example) an underlying row in a database, the
relationship between the entity bean instance and the database row is exactly
one-to-one. Since multiple clients must be able to access that underlying row,
it means that, unlike session beans, the entity bean instances are shared
among clients. Since they are shared, they do not allow storage of per-client
state information.
Session beans allow the client to store state information on behalf of the client,
and the relationship between the client and the session bean instance is
one-to-one. Entity beans allow storage of row information, making the
relationship between the entity bean instance and the row one-to-one. An
ideal solution might be a client which calls into the server through a session
bean, and the session bean accesses the database through entity beans. This
allows for storage of state information both for the client and for the rows in
the database.

20

Copyright (c) 1999 Nova Laboratories - Reproduction Prohibited
Download Developer's Guide to Understanding Enterprise JavaBeans pdf from java.sun.com, 38 pages, 116.59KB.
Related Books

Leave a Reply