The proliferation of internet- and intranet-based applications
has created a great need for distributed transactional
applications that leverage the speed, security, and
reliability of server-side technology. One way to meet this
need is to use a multitiered model where a
thin-client application invokes business logic that executes on the server.
Normally, thin-client multitiered applications are hard to write because
they involve many lines of intricate code to handle transaction and
state management, multithreading, resource pooling, and other complex
low-level details. And to compound the difficulties, you have to rework
this code every time you write an application because the code is so
low-level it is not reusable.
If you could use someone's
prebuilt and pretested transaction management code or even reuse some of
your own code, you would save a lot of time an energy that you could better
spend solving the business problem. Well, Enterprise JavaBeansTM
technology can give you the help you need.
The Enterprise JavaBeans technology makes distributed transactional
applications easy to write because it separates the low-level
details from the business logic. You concentrate on creating the best
business solution and leave the rest to the underlying architecture.
This chapter describes how to create the example auction application
using the services provided by the Enterprise JavaBeans platform. Later
chapters will show how you can customize these services and integrate
these features into existing non-EJB applications.
Enterprise Beans Defined
An Enterprise Bean is a simple class that provides two types of
methods: business logic and lifecycle. A client program calls the business
logic methods to interact with the data held on the server.
The container calls the lifecycle methods to manage the Bean on the server.
In addition to these two types of methods, an Enterprise Bean has an
associated configuration file, called a deployment descriptor, that is
used to configure the Bean at deployment time.
As well as being responsible for creating and deleting Beans the Enterprise
JavaBeans server also manages transactions, concurrency, security and
data persistence.
Even the connections between the client and server are provided by using
the RMI and JNDI APIs and servers can optionally provide scalabilty through
thread management and caching.
The auction house example implements a complete Enterprise
JavaBeans solution by providing only the business logic and using
the underlying services provided by the architecture. However, you may
find that the container managed services, although providing
maximum portability, do not meet all your application requirements.
The next chapters will show how you can provide these services in your
Bean instead and also use these services in non-Enterprise Bean applications.
Thin-Client Programs
A thin client is a client program that invokes business logic
running on the server. It is called thin because most
of the processing happens on the server. In the figure below,
the servlet is the thin client. It invokes Enterprise Beans
that run on the Enterprise JavaBeans server. It also executes
logic that creates web pages that appear in the browser.
Multitiered Architecture
Multitier architecture or three-tier architecture
extends the standard two-tier client and server
model by placing a multithreaded application
server between the client and the database.
Client programs communicate with the database through the
application server using high-level and platform independent
calls. The application server responds to the client
requests, makes database calls as needed into the
underlying database, and replies to the client program
as appropriate.
The three tiers in the web-based auction house
example consists of the thin-client servlet, the Enterprise
JavaBeans server (the application server), and the
database server as shown in the figure.
Entity and Session Beans
There are two types of Enterprise Beans: entity Beans and session Beans.
An Enterprise Bean that implements a business entity is an entity
Bean, and an Enterprise Bean that implements a business task
is a session Bean.
Typically, an entity Bean represents one row of persistent
data stored in a database table. In the auction house example,
RegistrationBean is an entity Bean that represents
data for one registered user, and AuctionItemBean is
an entity Bean that represents the data for one auction item.
Entity Beans are transactional and long-lived. As long as the data
remains, the entity Bean can access and update that data.
This does not mean you need a Bean running for every table row. Instead,
Enterprise Beans are loaded and saved as needed.
A session Bean
might execute database reads and writes, but it is not required.
A session Bean might invoke the JDBC calls itself or it might use an
entity Bean to make the call, in which case the session Bean is a client
to the entity Bean. A session Bean's fields contain the state of the
conversation and are transient. If the server or client crashes, the
session Bean is gone. A session Bean is often used with one or more entity
Beans and for complex operations on the data.
| Session Beans |
Entity Beans |
|---|
| Fields contain conversation state. |
Represents data in a database. |
| Handles database access for client. |
Shares access for multiple users. |
| Life of client is life of Bean. |
Persists as long as data exists. |
| Can be transaction aware. |
Transactional. |
| Does not survive server crashes. |
Survives server crashes. |
| Not fine-grained data handling |
Fine-grained data handling |
Note: In the Enterprise Java
Beans specification, Enterprise JavaBeans Server support for
session Beans is mandatory. Enterprise JavaBeans server support
for entity Beans was optional, but is mandatory for
version 2.0 of the specification.
Auction House Workings
The diagram shows the Enterprise Beans for the auction house
application and their relationship to the Enterprise JavaBeans server.
The thin-client server invokes business logic in the four Enterprise
Beans through their home and remote interfaces. The Enterprise
JavaBeans server in this example handles the low-level details including
database read and write operations.
The four Enterprise Beans in the example are:
AuctionItemBean is an entity Bean that maintains
information for an auction item.
RegistrationBean is an entity Bean that stores user
registration information.
BidderBean is a session Bean that uses
AuctionItemBean to retrieve a
list of all auction items, only new items, items due to close,
and items whose summary matches a search string from the
database. It also checks the user ID
and password when someone places a bid, and stores new bids in the database.
SellerBean is a session Bean that uses
RegistrationBean to check the user ID and password when
someone posts an auction item, and AuctionItemBean to add
new auction items to the database.
As depicted in the figure above, an entity or session Bean is really
a collection of interfaces and classes. All entity and session Beans
consist of a remote interface, home interface, and the Bean class.
The servlet looks up the Beans's home interface running in the
Enterprise JavaBeans server, uses the home interface to create
the remote interface, and invokes Bean methods through the remote
interface.
- An Enterprise Bean's remote interface describes the Bean's
methods, or what the Bean does. A client program or another
Enterprise Bean calls the methods defined in the remote interface
to invoke the business logic implemented by the Bean.
- An Enterprise Bean's home interface describes how a client program
or another Enterprise Bean creates, finds (entity Beans only), and removes
that Enterprise Bean from its container.
- The container, shown in light blue (cyan), provides the interface
between the Enterprise Bean and the low-level platform-specific
functionality that supports the Enterprise Bean.
Developing and Running Applications
Deployment tools and an Enterprise JavaBeans server are
essential to running Enterprise JavaBeans applications.
Deployment tools generate containers, which are classes that
provide an interface to the low-level implementations in a
given Enterprise JavaBeans server. The server provider can include
containers and deployment tools for their server and will typically
publish their low-level interfaces so other vendors can develop
containers and deployment tools for their server.
The auction house example uses the Enterprise JavaBeans server
and deployment tools created by
BEA Weblogic.
Visit this site for a free
30-day trial.
Because everything is written to specification, all Enterprise Beans
are interchangeable with containers, deployment tools, and servers
created by other vendors. In fact, you might or might not write your
own Enterprise Beans because it is possible, and sometimes desirable,
to use Enterprise Beans written by one or more providers that you
assemble into an Enterprise JavaBeans application.
How Multitiered Applications Work
The goal in a multitiered application is that the client be able to work on
application data without knowing at build time where the data is stored. To
make this level of transparency possible, the underlying services in a
multitiered architecture use lookup services to locate remote server objects
(the Bean's remote interface object), and data communication services to move
data from the client, through the remote server object, to its final destination
in a storage medium.
Lookup Service
To find remote server objects at runtime, the client program needs a way
to look them up. One way to look remote server objects up at runtime is to use
the Java Naming and Directory InterfaceTM (JNDI) API. JNDI is a common interface
to existing naming and directory interfaces. The Enterprise JavaBeans containers
use JNDI as an interface to the Remote Method Invocation (RMI) naming service.
At deployment time, the JNDI service registers (binds) the remote interface with a name.
As long as the client program uses the same naming service and asks for the
remote interface by its registered name, it will be able to find it.
The client program calls the lookup method on a
javax.naming.Context object to ask for the remote interface
by its registered name. The javax.naming.Context object
is where the bindings are stored and is a different object from the
Enterprise JavaBeans context, which is covered later.
Data Communication
Once the client program gets a reference to a remote server object, it
makes calls on the remote server object's methods. Because the client
program has a reference to the remote server object, a technique called
data marshalling is used to make it appear as if the remote server object
is local to the client program.
Data marshalling is where methods called on the remote server object are wrapped
with their data and sent to the remote server object. The remote server
object unwraps (unmarshalls) the methods and data, and calls the Enterprise Bean.
The results of the call to the Enterprise Bean are wrapped again, passed back
to the client through the remote server object, and unmarshalled.
The Enterprise JavaBeans containers use RMI services to marshal data. When
the Bean is compiled, stub and skeleton files are
created. The stub file provides the data wrapping and unwrapping
configuration on the client, and the skeleton provides the same
information for the server.
The data is passed between the client program and
the server using serialization. Serialization is a way to representat JavaTM
objects as bytes that can be sent over the network as a stream and reconstructed
on the other side in the same state they were in went originally sent.
[TOP]
