|
The example uses two entity Beans and two session Beans.
The entity Beans, AuctionItemBean and
RegistrationBean, represent persistent items that
could be stored in a database, and the session Beans,
SellerBean and BidderBean,
represent short-lived operations with the client and data.
The session Beans are the client interface to the entity beans. The SellerBean
processes requests to add new auction items for sale. The BidderBean processes
requests to retrieve auction items and place bids on those items.
Changing and adding to the database data in a container-managed Bean is left
to the entity Beans.
AuctionServlet
The AuctionServlet
is essentially the second tier in the application and the focal point for
auction activities. It accepts end user
input from the browser by way of hypertext transfer protocol
(HTTP), passes the input to the appropriate Enterprise
Bean for processing, and displays the processed results to the end user
in the browser.
Here is a
Unified Modeling Language (UML)
class diagram for the AuctionServlet class.
The AuctionServlet methods shown above invoke
business logic that executes on the server by looking up an
Enterprise Bean and calling one or more of its methods. When
the servlet adds
HTML codes
to a page for display to the user, that logic executes on the client.
For example, the listAllItems(out) method
executes code on the client to dynamically generate an HTML
page to be viewed by the client in a browser. The HTML page is
populated with the results of a call to BidderBean
that exeuctes logic on the server to generate a list of all auction items.
private void listAllItems(ServletOutputStream out)
throws IOException{
//Put text on HTML page
setTitle(out, "Auction results");
String text = "Click Item number for description
and to place bid.";
try{
addLine("<BR>"+text, out);
//Look up Bidder bean home interface.
BidderHome bhome=(BidderHome) ctx.lookup("bidder");
//Create Bidder bean remote interface.
Bidder bid=bhome.create();
//Call Bidder bean method through remote interface.
Enumeration enum=(Enumeration)bid.getItemList();
if(enum != null) {
//Put retrieved items on servlet page.
displayitems(enum, out);
addLine("", out);
}
} catch (Exception e) {
//Pring error on servlet page.
addLine("AuctionServlet List All Items error",out);
System.out.println("AuctionServlet <list>:"+e);
}
out.flush();
}
Entity Beans
AuctionItemBean and RegistrationBean
are entity Beans. AuctionItemBean
adds new auction items to the database and updates the
bid amount as users bid on the item. RegistrationBean
adds information to the database on registered users. Both
Beans consist of the classes described here.
AuctionItem Entity Bean
Here are the AuctionItemBean classes. Remember that these
Enterprise Beans are distributed objects that
use the Remote Method Invocation (RMI) API, so when
an error occurs, an RMI remote exception is thrown.
AuctionItem is the remote interface. It describes
what the Bean does by declaring the developer-defined methods that
provide the business logic for this Bean. These methods are the ones
used by the client to interact with the Bean over the remote connection.
Its name maps to the
AUCTIONITEMS table shown just below.
AuctionItemHome is the home interface. It describes how
the Bean is created in, found in, and removed from its container. The
Enterprise Bean server deployment tools will provide the implementation
for this interface.
AuctionItemBean is the Enterprise Bean. It implements
EntityBean, provides the business logic for
the developer-defined methods, and implements EntityBean
methods for creating the Bean and setting the session context. This
is a class that the Bean developer needs to implement. Its
field variables map to fields in the AUCTIONITEMS table
shown just below.
AuctionItemPK is the primary key class. The Enterprise
JavaBeans server requires a container-managed entity Bean to have
a primary key class with a public primary key field (or fields, if
using composite primary keys). The Bean developer implements this class.
The ID field is the
primary key in the AUCTIONITEMS table shown just
below, so the
id field is a public field in this class. The
id field is assigned a value when the primary key
class is constructed.
You can request the container manage database persistence for an Enterprise Bean
or write the code to manage the persistence yourself. In this chapter,
all beans (entity and session) are container-managed. With
container-managed Beans, all you do is specify which fields are
container managed and let the Enterprise JavaBeans server do the
rest. This is great for simple applications, but if you are coding
something that is fairly complex, you might need more control.
How to override the underlying Enterprise JavaBeans services to gain
more control or provide similar services for non-Enterprise JavaBean
applications is covered in Chapter 3.
Auction Items Table
Here is the AUCTIONITEMS table.
create table AUCTIONITEMS (SUMMARY VARCHAR(80) ,
ID INT ,
COUNTER INT ,
DESCRIPTION VARCHAR(1000) ,
STARTDATE DATE ,
ENDDATE DATE ,
STARTPRICE DOUBLE PRECISION ,
INCREMENT DOUBLE PRECISION ,
SELLER VARCHAR(30) ,
MAXBID DOUBLE PRECISION,
BIDCOUNT INT,
HIGHBIDDER VARCHAR(30) )
Registration Entity Bean
RegistrationBean consists of the same kinds
of classes and database table as the AuctionItem
Bean, except the actual business logic, database table fields, and
primary key are somewhat different. Rather than describe the classes,
you can browse them and refer back to the AuctionItem
Bean discussion if you have questions.
Registration Table
Here is the REGISTRATION table.
create table REGISTRATION (THEUSER VARCHAR(40) ,
PASSWORD VARCHAR(40) ,
EMAILADDRESS VARCHAR(80) ,
CREDITCARD VARCHAR(40) ,
BALANCE DOUBLE PRECISION )
Session Beans
BidderBean and SellerBean are the session
Beans. BidderBean retrieves lists of auction items,
searches for an item, checks the user ID and password when
someone places a bid, and stores new bids in the database.
SellerBean
checks the user ID and password when someone posts an auction
item, and adds new auction items to the database.
Both session Beans are initially deployed as stateless Beans. A stateless
Bean does not keep a record of what the client did in a previous call;
whereas, a stateful Bean does. Stateful Beans are very useful if the operation
is more than a simple lookup and the client operation depends on something that
happened in a previous call.
Bidder Session Bean
Here are the BidderBean classes.
Enterprise
Beans use the Remote Method Invocation (RMI) API, so when
an error occurs, an RMI remote exception is thrown.
There is no
primary key class because these Beans are transient and no database access is involved.
To retrieve auction items from the database,
BidderBean creates an instance of
AuctionItemBean, and to process bids,
it creates an instance of RegistrationBean.
Bidder is the remote interface. It describes what
the Bean does by declaring the developer-defined methods that
provide the business logic for this Bean. These methods are the ones that
the client calls remotely.
BidderHome is the home interface. It describes
how the Bean is created in, found in, and removed from its
container.
BidderBean is the Enterprise Bean. It implements
SessionBean, provides the business logic for the
developer-defined methods, and implements SessionBean
methods for creating the Bean and setting the session context.
Seller Session Bean
SellerBean consists of the same kinds of classes
as BidderBean, except the business logic is
different. Rather than describe the classes, you can browse them
and refer back to the BidderBean discussion if you
have questions.
Container Classes
The classes needed by the container to deploy an Enterprise Bean onto
a particular Enterprise JavaBeans server are generated with
a deployment tool. The classes include _Stub.class and
_Skel.class classes that provide the RMI hooks on the client
and server respectively.
These classes are used
for marshaling (moving) data between the client program and the
Enterprise JavaBeans server. In addition, implementation classes are created
for the interfaces and deployment rules defined for our Bean.
The Stub object is installed on or
downloaded to the client system and provides a local proxy
object for the client. It implements the remote interfaces
and transparently delegates all method calls
across the network to the remote object.
The Skel object is installed on or downloaded
to the server system and provides a local proxy object for the
server. It unwraps data received over the network from the
Stub object for processing by the server.
[TOP]
|
