Clarkson University

fortunabrontideInternet and Web Development

Nov 13, 2013 (3 years and 11 months ago)

164 views

Clarkson University




Adding the model component and a credit card extension to IBM's

"SunSet Books" workload application utilizing the platform independent J2EE

standards and the Model
-
View
-
Controller architecture




A Thesis by


Danielle Chianese


Depa
rtment of Mathematics and Computer Science




Submitted in partial fulfillment of the requirements for a


Bachelor of Science Degree with


University Honors




May 2004




Accepted by the Honors Program





______________________________

Advisor



Date



_
_____________________________

Honors Reader


Date



______________________________

Honors Director


Date







Adding the model component and a credit card extension to IBM's
"SunSet Books" workload application utilizing the platform
independent J2EE stan
dards and the Model
-
View
-
Controller
architecture












Written by

Danielle Chianese


Advised by

Douglas J. Macintosh

Assistant Professor of Software Engineering

Clarkson University



Acknowledgements


Many thanks go out to Professor Douglas Macintosh
, my advisor who continually
motivated me to stay on track. I would also like to thank Professor David Craig and
Professor Hayley Shen for their patience.


Thanks also go out to all the IBMers who helped make this thesis possible: my manager
Greg Lacey,
and all our technical advisors, Loraine Arnold, Jim Stutzman, Tom Sirc, and
Karen Smolar.






































Abstract

Adding the model component and a credit card extension to IBM's

"SunSet Books" workload application utilizing the platf
orm independent J2EE

standards and the Model
-
View
-
Controller architecture

by Danielle Chianese


A thesis is presented on the design and implementation of the model portion of a
workload application for IBM Corporation's zSeries Integrated Testing Departmen
t. This
application is compliant to the Java 2 Enterprise Edition standards and the Model
-
View
-
Controller architecture, and is in the format of an online bookstore. In addition, the
design and implementation of a credit card workload application was also

attempted.


To accomplish this, IBM's WebSphere Application Developer was used. A facade
between the controller and model aspect of the application was written as an Enterprise
Java session bean. The model itself was written as two Enterprise Java entit
y beans, both
of which accessed IBM's DB2 database, then returned the information via the facade back

to the controller. Furthermore, as this is a testing application, three levels of tracing were
implemented for debugging purposes.


In the end, the entir
e workload application, called SunSet Books, was completed and has
now been incorporated into IBM's zSeries Integrated Testing Department's testing suite.
While the design of the credit card application and most of the implementation was
completed, time d
id not permit for the proper testing necessary to finish the application.


T
ABLE OF
C
ONTENTS



Chapter 1
-

Introduction ............................................................................. 1

1.1 z/Series System Integration Test ..................
................................................... 1

1.2 Previous SunSet Books application ................................................................ 2

1.3 Hypothesis .................................................................................
....................... 3

Chapter 2
-

Background ............................................................................. 4

2.1 J2EE technology overview ............................................................................. 4

2.2 MVC architec
ture ............................................................................................ 5

2.2.1 The model ........................................................................................ 5

2.2.2 The view ................................
........................................................... 5

2.2.3 The controller ................................................................................... 6

2.3 Tiers ...........................................................................
..................................... 7

2.4 Java Database Connectivity ............................................................................ 8

2.5 Java Naming and Directory Interface ............................................................. 9

2.6 JavaServer Pages ........................................................................................... 10

2.7 Servlets .......................................................................................................... 10

2.8 Enterprise

Java Beans ................................................................................... 11

2.8.1 Message
-
driven beans ..................................................................... 11

2.8.2 Session beans ....................................
............................................. 12

2.8.3 Entity beans .................................................................................... 12

2.9 Data Transfer Objects ........................................................................
........... 14

Chapter 3
-

Project Requirements ........................................................... 15

3.1 Specifications ................................................................................................ 15

3.2 High level design ..
........................................................................................ 16

Chapter 4
-

Implementation Details of Sunset Books Model ................ 19

4.1 The view .........................................................................
............................... 19

4.2 The controller ................................................................................................ 20

4.3 The model ......................................................................................
............... 21

Chapter 5
-

Implementation Details of Credit Card Extension ............ 27

5.1 Overview ....................................................................................................... 27

5.2 Database table setup ..............
........................................................................ 27

5.3 Program flow ............................................................................................... 28

Chapter 6
-

Development Environment ..........................
........................ 32

6.1 WebSphere Studio Application Developer ................................................... 32

Chapter 7
-

Tracing ................................................................................... 34

7.1 Tracing .........
................................................................................................. 34

Chapter 8
-

Discussion and Conclusion ................................................... 36

8.1 IBM's intended use ......................................
.................................................. 36

8.2 Further Development .................................................................................... 39

Literature Cited ........................................................................
................. 40

References .................................................................................................. 41


L
IST OF
F
IGURES


Figure 1: Members of BookBrowse class ..................................................................
........ 3

Figure 2: Example of J2EE architecture (containers) ........................................................ 4

Figure 3: Model View Controller example ........................................................................ 7

Figure 4: Example o
f J2EE architecture (tiers) .................................................................. 8

Figure 5: Connecting to a Data Source ............................................................................. 9

Figure 6: EJB Types ...................
..................................................................................... 11

Figure 7: View of the EJB architecture (local and remote) ............................................ 14

Figure 8: Application component model and workflow ........
......................................... 18

Figure 9: Sunset Books view component ........................................................................ 20

Figure 10: The controller component ...........................................................
.................. 21

Figure 11: The model component ................................................................................... 22

Figure 12: General form of SQL statements ................................................................... 25

F
igure 13: PETCard database tables ............................................................................... 28

Figure 14: PETCard database access diagram ................................................................ 30

Figure 15: Example of tra
cing ........................................................................................ 34

Figure 16: Index page of application .............................................................................. 37

Figure 17: Searching for a book ......
................................................................................ 37

Figure 18: Search results for “King” .............................................................................. 38

Figure 19: A Detail for “King” ....................
...................................................................



Chapter 1: Introduction


1.1 z/Series System Integration Test


IBM’s zSeries operating system server testing division is always looking for new
workload applications to test the limits

of their software/machine and to make sure they
have not "broken" any old code in a new operating system release. Each release goes
through four stages of testing: unit test, function test, system test, and system integration
test.

System Integration
Test is the department that puts the product through the last
series of tests before shipment. These tests stress various interactive combinations of the
common software packages combining IBM's DB2 database, WebSphere Application
Server (WAS), and WebSph
ere Message Queuing (MQ). The department attempts to
find problems before users can, and recreates problems that users have found. They write
workload applications that are as similar as possible to a real client situation.


These workload applications s
hould be flexible in how much they stress each of
IBM's software applications. This stress should vary not only in intensity but also in
variety. Errors need to be logged along with any known causes.


Among their current applications is an online booksto
re application called Sunset
Books, which can have a user browse for books and place and cancel orders. This
simulates a high demand book retailer's website. This application currently strains the
limits of the server with a workload by having thousands,

or even hundreds of thousands,
of “users” using the bookstore’s services at once.

It is currently written to test WebSphere, DB2, and WebSphere MQ. However,
the structure of the old bookstore is neither scalable nor portable, and is not itself J2EE
com
pliant. This project completely rewrote the bookstore to be J2EE compliant, which
now allows for both scalability and portability, and continues along previous lines to
constantly improve the quality of IBM's testing product.

In addition, a component to

add credit card functionality to Sunset Books was also
designed and developed. However, there was not enough time for full testing. This
credit card application is also be J2EE compliant and is fully modular, with the ability to
be reused in other appli
cations.


1.2 Previous SunSet Books application

The old bookstore application was written over several summers by a collection
of interns. It also had a web interface, but was not J2EE compliant. Instead of being split
into a model, view, and controller
, it was written in one large PETservlet class that took
care of all these of these pieces. This made it difficult to add new features or modify old
ones. For example, the old bookstore only did a search on author. It would have been
complicated to add
a similar search for title (see Figure 1).


Figure 1: Members of BookBrowse class


1.3 Hypothesis


The new Sunset Books bookstore application will be more scalable and easier to
maintain and extend than the previous version. This is because following th
e J2EE
standard provides for separation of components, separation of implementation and
interface, and greater modularity.



Chapter 2: Background


2.1 J2EE technology overview


J2EE stands for the Java 2 Enterprise Edition. It is an industry standard f
or
developing multi
-
tier enterprise applications (see Figure 2) [8]. Because it is a standard,
it ensures the portability of the applications that follow it across many systems and
platforms. The standard includes both complete specifications and complia
nce tests. It
calls for object oriented modular components, which allows for easy scalability and
maintainability.

















Figure 2: Example of J2EE architecture (containers) [3]






J2SE

Application
Client
Container



J2SE

Applet

Container


Database

JDBC

JAAS

JAX
P

JMS

Application
Client

Applet

WebSphere







J2SE

Web Container

EJB Container







J2SE

JTA

JNDI

JDBC

Java
Mail

RMI
-
IIOP

JMS


EJB


Servlet


JSP

JTA

JNDI

JDBC

Java
Mail

RMI
-
IIOP

JMS

HTTP

SSL

HTTP

SSL

2.2 MVC architecture

By applying the Model
-
View
-
Controller (MVC)

architecture to a J2EE
application, you separate core data access functionality from the presentation and control
logic that uses this functionality (see Figure 3). Such separation allows multiple views to
share the same enterprise data model, which make
s supporting multiple clients easier to
implement, test, extend on, and maintain. Each of the three components can reside on
separate systems. This cross
-
platform communication means that the components can be
located in separate buildings, or even separ
ate countries, and still perform together. This
allows for more efficient use of resources. Another benefit of this architecture is that the
components can interact among themselves with no need to know the implementation of
the other components. In fac
t, this separation of components allows for the division of
developer responsibilities and minimal code duplication, which promotes faster
production.


2.2.1 The model

The model represents enterprise data and the business logic that governs access
to, and

updates of, this data. The business logic is represented by Enterprise Java Beans
(EJBs). This exposes the application functionality. It encapsulates the application state
and responds to state queries. The model is responsible for notifying the view
of
changes. It responds to requests from the controller to access or modify the data it
represents.


2.2.2 The view

In its basic form, the view is a web interface that the user sees. It usually takes
the form of JavaServer Pages (JSPs). These webpages
are a mixture of static html and
Java function calls which dynamically provide data based on user requests. The view
renders the contents of a model by accessing enterprise data through the model and
specifying how that data should be presented. It reques
ts updates from the models and
sends user gestures to the controller. It allows the controller to select the view. It is the
view's responsibility to maintain consistency in its presentation when the model changes.


2.2.3 The controller

The controller

is the "middleman" which translates interactions with the view by
the user requests understood by the model [15]. There is one controller for each
functionality, and it takes the form of a servlet. These servlets use data transfer objects
(DTOs) to pass

information to and from the view and the model. They map user actions
to model updates and select which view to respond to based on the last client action and
the results of the corresponding model actions.



















Figure 3: Model View Control
ler example [15]

2.3 Tiers

Another way of looking at the architecture is through tiers. Most applications
have three tiers, although some have four (see Figure 4). The top tier is the client tier. It
exists on the client machine. For a typical large w
eb application similar to the one we are
trying to emulate, the client would be a user at home on their personal computer, or
perhaps someone in the workplace on a computer there. The client contains mostly
applets and small scripts that are run on the us
er's machine. An optional tier is the web
tier, which can include JSPs and servlets. Next is the business tier, which holds the EJBs.
Lastly there is the Enterprise Information System tier, where the database is located.

The enormous benefit to this tie
r architecture is that each tier can be worked on by
separate people with no loss to efficiency, and they can be built and executed on separate
platforms as well. This makes it easier to organize the implementation. The tier
Model

Enterprise Java Beans

View

Java Server Pages

Controller

Servlets

State
Query

Method Invocations

User
Gestures

View
Selection

State
Change

Change

Notification

Events

architecture allows each tier

to be developed in different languages if necessary. For
example, in the case of the Bookstore application, the top tier web interface is a JSP
written in html, Java, and Javascript. The middle tier is servlets written in Java. The
lowest tier consists

of EJBs, and they are written in Java and execute SQL queries on the
DB2 database.











Figure 4: Example of J2EE architecture (tiers) [16]


2.4 Java Database Connectivity

Continuing in the spirit of portability, Java Database Connectivity (JDBC)
allows
a J2EE program to be written only once, but be able to connect to any type of database
because it is vendor neutral [11]. This makes it both portable and versatile. To access a
database, DML statements need to be executed from the host language.
The JDBC
standard provides the corresponding features to the Java language. In a web application,
Web
Browser


Web
pages,
applets,
Java Beans
Class

(optional)

Entity
Beans,
Session
Beans,
Message
-
Dri
ven
Beans

Client Tier

EIS Tier

Client
Machines

J2EE Server Machine

Database,
Legacy
Systems

Java Beans

(optional)

JSP Pages,

Servlets

Web Tier

Business Tier

Database
and other
servers

Sample J2EE Application

you can use it to make dynamic calls to databases from Java applications through the
JDBC Application Program Interface (API), which uses standard network co
nnections
(see Figure 5).












Figure 5: Connecting to a Data Source [11]


To reduce database connection time, the EJB container maintains database
connections in a JCBC connection pool to cache these connections so that they are
always available w
hen the application needs them. When an EJB requests such a
connection, its container gets one from this pool and assigns it to the bean.


2.5 Java Naming and Directory Interface

Java Naming and Directory Interface (JNDI) is another platform
-
independen
t API
specified in Java technology that provides naming and directory functionality to
applications written in the Java programming language. Designed specifically for the
JDBC Driver

Application

client

jdbc/nameofDB


DataSource


Database

JNDI

Naming

Service

lookup

Java platform, it uses Java's object model, which means that applications can store

and
retrieve named Java objects of any type. Naming and directory services play a
fundamental in any kind of network by providing network
-
wide sharing of a variety of
information about applications, machines, networks, services, and users. The JNDI
prov
ides methods for performing standard directory operations, such as associating
attributes with objects and searching for objects using their attributes [12].



2.6 JavaServer Pages


JavaServer Pages (JSPs) are the "view" of the model
-
view
-
controller archi
tecture.
JSP technology allows for the mixing of static html with dynamic html [2]. In keeping
with object oriented tradition, JSP technology separates the user interface from content
generation and supports a reusable component
-
based design. This means

web designers
can change page layout without altering the dynamic content, and makes it faster and
easier than ever to build web
-
based applications. In keeping with J2EE standards, JSPs
are platform independent. The technology uses XML
-
like tags that en
capsulate the logic
that generates the content for the page.


2.7 Servlets


Like JSPs, servlets provide a component
-
based, platform
-
independent method for
building web
-
based applications. A servlet is a Java programming language class used to
extend the

capabilities of servers that host applications accessed via a request
-
response
programming model. Servlets are commonly used to extend the applications hosted by
web servers. There are http
-
specific servlet classes defined by Java Servlet technology
for

this purpose. Servlets are good for web pages based on data submitted by a user, for
pages where data changes frequently, and pages where the information is from a
corporate database or other such source [2].


2.8 Enterprise Java Beans

An Enterprise Jav
aBean (EJB) is a server
-
side J2EE component that implements a
business task or business entity [6]. There are three kinds, message
-
driven
beans, session
beans, and entity beans (see Figure 6)
.









Figure 6: EJB Types [5]


2.8.1 Message
-
driven beans

Message
-
driven beans (MDBs) are stateless, server
-
side, transaction
-
aware
components that listen for and process asynchronous messages delivered via the Java
Message Service (JMS) [5]. This means that a sender can send his messages, and does
Message
-
Driven

Asynchronous

CMP

BMP

Stateful

Stateless

EJB

Synchronous

Session

Entity

not have to w
ait for the receiver to receive it. This bean is responsible for processing
messages, and can be modeled to represent tasks [4].


2.8.2 Session beans

A session bean is non
-
persistent enterprise bean created by a client and that
normally exists only for t
he duration of a single client
-
server session. It represents
behaviors associated with client sessions, and can be modeled to represent a task or
workflow of a system, and to provide coordination of those activities. In our case, it could
be a user book se
arch. It is commonly used to implement the façade of EJB modules.
This bean performs operations for the client. These objects can be either
stateless

or
stateful. Stateful session beans keep track of the conversational state with a specific
client, and
therefore cannot be shared among clients. Stateless session beans maintain
noconversational state, and are pooled by the container to be reused.

If they do maintain
state, then the EJB container manages this state if the object must be removed from
memor
y. However, session bean objects must manage their own persistent data. This
application will be using a stateless session bean.


2.8.3 Entity beans

An entity bean, on the other hand, is modeled to represent business or domain
specific concepts. They c
an be thought of as the “nouns” of the system [4]. Enterprise
beans represent persistent data maintained in a database, and encapsulate operations on
the data they represent. Both session beans and entity beans are accessed synchronously
through a remot
e or local EJB interface method invocation. It is a synchronous
invocation because there is a request, and then a blocking wait for the return. There are
two ways to handle entity bean persistence, bean
-
managed persistence (BMP) and
container
-
managed per
sistence (CMP). [1].

In this application, container
-
managed persistence (CMP) is used. CMP has
several advantages over BMP. The EJB container manages the relationships between the
entity beans, and handles all database storage and retrieval calls. Th
is way, the developer
does not need to code the database access calls in the entity beans themselves. Instead,

they must specify the settings in the entity bean's deployment descriptor. This allows
both for faster development and greater portability acr
oss database servers. The
containers are responsible for registering the unique lookup name in the JNDI namespace
when the server starts up, and then binding the appropriate object type into the JNDI
namespace. EJB containers create bean instances, manag
e pools of these instances, and
destroy them as necessary. They also provide the means for a remote client to access
components that live within them (see Figure 7).

To have container
-
managed relationships between entity and session beans, the
EJBs must r
eside in the same container and use the local interface capability rather than
the remote interface capability. A bean uses a local interface if it wants to provide tight
coupling with its clients inside the same Java Virtual Machine (such as another EJB)

with
pass
-
by
-
reference semantics and expose its methods to other beans that reside within the
same container. This also avoids the network overhead and performance limitations of a
remote invocation, because in remote invocation, method arguments and ret
urn values are
passed by value. This means that the complete objects have to be serialized and set over
the network to the remote party, which reconstructs them as new objects. So, a bean
usually only uses a remote interface when it needs to interact wit
h distributed clients
(such as a servlet) and expose its methods across the network tier [4].












Figure 7: View of the EJB architecture (local and remote) [4]


2.9 Data Transfer Objects


Since we do not expose a remote interface to our entity be
ans, only the session
bean data transfer objects (DTOs) limit inter
-
layer data sharing to serializable JavaBeans,
therefore avoiding remote references.





EJB
Object

Local
Client


EJB
Component

EJB
Local
Object

EJB
Local
Home

EJB

Home


EISs

Remote

Client

Container

EJB Server

Java Virtual Machine

Remote View

Local View

Chapter 3: Project Requirements


3.1 Specifications


The goal of this software design and developme
nt project was to rewrite a
software application to adhere to stricter standards and be scalable, portable, and
maintainable. This application is currently used to test IBM proprietary software. The
new Sunset Books was written using the WebSphere Applic
ation Developer and built
conforming to J2EE 1.3 standards and following the MVC architecture.


The code needed to be flexible enough so that it does not need to get rewritten. If
that had been necessary, the code would have needed to be recompiled. To

detect the
changes, the application server would need to be reset. This is not the only testing
application being run on the zSeries test servers. If all such testing applications were
repeatedly being recompiled and the servers constantly being restart
ed, the testing
department could never test their operating system long enough to find defects.


The application is run on a WebSphere Application Server (WAS) version 5.0.
This transaction engine is perfect for such a use as an online bookstore, because
it is
high
-
performance and scalable. It is a J2EE compliant Web services
-
enabled application
server that is capable of handling high volume secure transactions [7].

The front end are Java Server Pages version 1.2. These pass information to
several servle
ts, which then forward requests to Enterprise Java Beans version 2.0. These
EJBs use EJB Query Language to query the backend, which is a DB2 database version
7.2.


IBM's DB2 7.2 has built
-
in support for Java based operating environments. It
also has in
tegration into WebSphere and its web services, and also supports message
queuing technologies. It has cross
-
platform capabilities. It also has a very useful Control
Center for easy database administration [13].

The application also uses WebSphere Message

Queuing Service (MQ) to buy
books. MQ is used to exchange information across different platforms. This helps
enable our portability specification. It offers secure and reliable deliverability of
messages, and ensures the data is delivered free from err
ors and safe from unauthorized
access. It makes the best use of resources by dynamically distributing its workload. In
this case, the bookstore application puts a buy message to a buy queue and waits to
receive confirmation. MQ's role in this is to tran
sport that buy message to Webbuy, a C
script which will then process the buy and return the looked
-
for confirmation via MQ.


3.2 High level design


Sunset Books was split into three pieces corresponding to the three parts of the
MVC architecture. These p
ieces are the model, the view, and the controller (see Figure
8). The whole application is a high demand online website for a bookstore. This
represents the average client who would use the zSeries server and its z/OS operating
system.


The benefit of us
ing the MVC architecture for this project means that the
developers did not need to know the implementation of the other two components. They
merely needed to agree on common interfaces between their respective components and
then they could proceed with
their own implementation. Later on, if the application
needs to be extended or scaled larger, it can easily be done because of the modularity of
the components of the project.


Three programmers, including myself, were assigned to the project. We took
ad
vantage of the MVC architecture and each took one of the three components. Because
of the modularity and separation of implementation of the J2EE standard, this was
relatively easy to do and increased the speed of development. While all three
components
will be mentioned, this thesis focuses on the Model component's design and
implementation.


As seen in the figure below, when this application is run the first event that will
occur is an HTTP request issued by the Web client to the server. This is in tur
n answered
by a servlet in the controller component, when then extracts the parameters from the
request. The controller passes the request on to the session EJB façade. This bean
executes the necessary business logic by accessing the entity beans. It th
en creates and
DTO and populates it with the data returned by the entity beans, and returns it to the
controller. The servlet in the controller sets this DTO as a request attribute and forwards
it back to the appropriate JSP in the view. This JSP then ac
cesses the DTO to build the
user response, and returns the resultant HTML to the client.















Figure 8: Application component model and workflow [4]















RMI/IIO
P

Web Client

2

7


4

6











EJB Container








EJB

Module


Entity
Model

Facade

3











Web Container








Web Module

View

Control

5

5

HTTP

1

Application Server

DTO


Chapter 4: Implementation Details of Sunset Books Model


4.1 The view

The view (s
ee Figure 9) is a website consisting of JSPs that encompass specific
functionalities. The names are self
-
explanatory. Index.jsp is the home page for the
project. From there the user can navigate to Help.jsp to receive hints on how to use the
website, Re
ports.jsp to see a list of annual reports and links to the corresponding
applet/html file, Results.jsp to see a list of top ten featured books, and Search.jsp to
search for a book. Using Search.jsp, the user can search for a book by title, author,
ISBN, c
ategory, or any category thereof. This will send them to Results.jsp, which will
display the ISBN, author, title, category, and price of all the matching books. The books
can be ordered by any of these categories. Once the user chooses a book to see
inf
ormation about, it will send them to Details.jsp. This will display the same
information as Results.jsp, along with a second category, publisher, year, and price.
From Details.jsp the user can order a book, which will send them to Cart.jsp and add the
bo
ok to their "shopping cart." They can then return to Search.jsp to search for more
books. They can also be able to "checkout." This will return Order.jsp with the order
information from the WebBuy processing. With the modularity of J2EE, it would be
ea
sy to add more JSPs so a user could login or use a credit card to buy a book without
having to change the current structure of the view.












Figure 9: Sunset Books view component


4.2 The controller

The controller (see Figure 10) is the "traffic
director" who receives requests from
the view and forwards them to the model, and takes the returned information from the
model and sends it to the view. It performs error checking on both the requests it
receives from the view and the data it receives fr
om the model. The view can only call
the Action servlet within the controller. This helps keep the application modular, because
to add additional functionality only code in the Action servlet would need to be modified.
Calling only the Action servlet fr
om the view is also good security, because users cannot
see exactly what type of data retrieval is being used, and therefore cannot "hack" the
system. This servlet then sends the information requests to the appropriate servlets. The
Browse servlet gets t
he details and results of a book request from the model and passes it
to either Details.jsp or Results.jsp. FeaturedBooks servlet returns the top ten books to
Search.jsp

Results.jsp

Cart.jsp

Reports.jsp

Help.jsp

Details

Index.jsp

Results.jsp. The Buy servlet gets its data from the model and returns it to either Cart.jsp
or
Order.jsp.









Figure 10: The controller component


4.3 The model

In this case, the model is an enterprise java session bean and two entity beans (see
Figure 11). The model takes the forwarded requests from the controller by means of its
session be
an facade BookBrowseEJB. This is another case of separation of
implementation, because the controller does not need to know how the model works, it
just needs to know the interfaces allowable by the session bean. The facade provides a
simple and unified
interface to the complex model that lies behind it. This way, the
dependencies between the model classes and its clients are reduced, which means more
freedom to adapt to new requirements. Through this bean, either the results or details
entity beans wil
l be called, depending up on the request. These entity beans will retrieve
the book data from the DB2 database and forward it back through the session bean to the
Action

servlet

Browse

servlet

Order.jsp

C
art.jsp

Details.jsp

Results.jsp

Browser

MQ

Buy

servlet

EJBs

FeaturedBooks
servlet

controller. Only the three function calls getDetails(), getResults(), and FeaturedBooks()
c
an be used.


Figure 11: The model component


EJBs work by querying a database using EJB QL (EJB Query Language), a query
language similar to SQL. EJB QL statements are independent of database
implementation because queries can

be expressed at the entity attribute level instead of

DetailsLocal


DetailsLocal

Home


DetailsBean

Results

Local

Results

Local

Home

Results

Bean

Book

Browse

EJB

Book

Browse

EJBHome

Book

Browse

EJBBean


DB2

Res
ults and
Details Entity
Beans

Web Tier

EJB Tier

BookBrowse

EJB


Session

Bean

Enterprise
Information
System or
Database Tier


Featured

Servlet


Browse

Servlet

tables and columns, which are the underlying implementation in a relational database.
These queries are defined in the deployment descriptor, then the EJB provider generates
the SQL statements for the

actual database access.

Initially, the user will look up a book by ISBN, author, title, category1, or any
combination thereof, and choose how he would like the Results ordered (alphabetically
by title or author, or price ascending or descending). This re
quest will be sent down
through the view and the controller to the session bean, and call getResults(). He will
then get his ordered Results back in a data transfer object (DTO) called ResultsDTO.
These results will contain a title, author, ISBN, and pri
ce. Then, based on these few
pieces of information, he can choose to see the additional Details about the book. This
will again be sent to the session bean as a request to getDetails(). These Details will
contain not only the ISBN, author, title, and pr
ice, but also year of publication, both
categories, and the publisher, and are returned to the view via DetailsDTO. Based on the
Details of a book, the user could choose to purchase it, and the flow of information would
then leave the model.

It may seem a
mbiguous why we chose to split the entity returned into two entities,
Results and Details. The benefit gained by not sending what could potentially be several
thousand category1's, category2's, publishers, and years was big, especially considering
that se
veral hundred users would be doing this each second.

Finally there was the last function call, FeaturedBooks. The purpose of this was
to have an added feature on the website, just as a real online bookstore may have a top
bestseller list. We implemente
d it by passing the function a year and how many results
we wanted. We temporarily hardcoded it for the current year and ten Results. One
interesting facet of this feature was that since we were searching by year, we needed to be
able to access the year
field in the database. However, only the Details bean could do
that. Therefore, we used the Details entity bean to get the information, then parsed out
only the information we needed to put into the ResultsDTO.

Now that the data the searched for has been

acquired, we need to present it to the
viewer. The next stage is formatting the output. If the user searched for author, they
probably want it displayed alphabetically by author. Or maybe they searched for title, but
want it listed in ascending price o
rder. Regardless, we needed to make a decision about
where this was done.

A real client application would want to reduce the load on the server as much as
possible. Therefore, it did not make sense to send not only the requested data, but the
orderby cat
egory as well, and then order the data on the server. With thousands of
browse requests, this increased need for resources would add up to an unacceptable and
unnecessary amount.

It therefore made sense to do it on the backend before sending the ordered
i
nformation back to the view. Ordinary SQL statements that query a database follow a
specific format (see Figure 12). Conveniently, there's an ORDERBY clause that would
allow us to choose what we wanted the resulting information ordered by, and in which
d
irection it would be ordered (ascending or descending). However, EJB QL follows EJB
2.0 specifications, which did not have an ORDERBY clause. This meant that we could
not do the ordering within the database. This was unfortunate for two reasons: it wou
ld
have been an added stress on DB2, and it probably would have been faster than anything
we wrote on our own.






Figure 12: General form of SQL statements


Since using ORDERBY was out of the question, we had to decide where to order
the information.
As I stated before, it reduced the server load to keep the ordering in the
backend. So we chose to order it after we retrieved the information from the database,
but while it was still in the model component and before it was passed up to the view. I
wro
te several functions in session bean to order the information based on which category
they chose to order the data on. As necessary (as in the case of more than one book with
the same author), a secondary ordering by ISBN was imposed. This was made possi
ble
by implementing the Comparator class to suit the variable requirements. Only after that
was the information passed from the model to the view.

There was another reason for keeping the ordering in the model component. Later
on, IBM would upgrade to us
ing the EJB 2.1 specifications, which did include an
ordering clause. They could then choose whether to continue to order the data in the
model component, or change to ordering in the database. Since either way the
information passed to the view would be

ordered, this kept the interfaces between the
view and model the same no matter how the internal logic was conducted. This kept the
model modular, which was in keeping with the J2EE standards.

Select a
1
, a
2
, … a
n

From r
1
, r
2
, … r
m

Where P

[order by …]

[group by…]

[having…]


Once the data was ordered, we had to decide how to display it

to the user. While
this is normally completely taken care of by the view, we had to consider a few things
ahead of time. You may search for "cat" on Google and get 45 million results, but
Google will only display the first ten until you choose to see mo
re. This is for two
reasons. The user will probably not want to look at more than the ten displayed results,
so this way they do not waste their time. Secondly, the difference in the load on the
server for ten results, and for 45 million results, is tre
mendous. Multiply that by the
thousands of users searching for things each second and you will quickly understand why
they display ten results at a time. Sunset Books had the same conceptual problem. A
realistic application would want to limit their ser
ver load, and they would also want to
limit their displayed results to a reasonable amount. Therefore, we choose to make the
amount displayed variable. We then set the variable to 25.

While this seems to be only a view problem, the necessary implementa
tion takes
place in the model. Sending the first 25 results is easy, however, if the user wants to see
the next page of the results, the model needs to fetch results 26
-
50, and not resend 1
-
25.
We solved this by keeping track of which section of results
to display, and then parse out
the correct Results to display to the user.







Chapter 5: Implementation Details of Credit Card Extension


5.1 Overview


Once the main Bookstore program was finished, I began adding an extension.
The ease of doing so was

made possible by the fact that we had used J2EE standards.
Now it was easy to add this completely modular extension. Not only that, but we have
hopes to use this extension with other workload applications, such as IBM's "Travel
Agency."


This extension
allowed for the books to be bought with credit cards. The basic
idea is to have the "customer" attempt to purchase a book. His information, such as his
name, credit card number, and expiration date, will be send to the credit card database,
matched again
st that to verify his identity, then it will check to make sure this purchase
will not put him over his credit limit. If both of these things are ok, the purchase will go
through. If not, the purchase will be rolled back and the customer will be notified

of the
reason why.


5.2 Database table setup


Unlike the model component of the bookstore application, this application's
database was not already in place, but instead would need to be written from scratch. The
final database and its tables are shown b
elow (see Figure 13).






















Figure 13: PETCard database tables


5.3 Program flow

Do transaction


Credit transaction


Check merchant identity (future implementation)


Verify customer identity
, parameters:
customer name, t
ransaction amount, card


Transac
tion

ID


Card

ID


Merchant

ID


Timestamp


Transaction

Amount


Account

ID

Transaction Table


Card

ID


Account

ID


Valid

From


Expiration

Date


Name

On

Card


Status


PIN

Credit Card Table

Customer Table


Billable


Address


Last

Name


Custo
mer

ID

Account Table


Current

Balance


Credit

Limit


Account

ID


Status


Billable

Customer

ID

PK

PK

PK

PK

FK

FK

Merchant Table


Merchant

ID

PK


Billable

Customer

ID

FK

FK

FK

FK


Available

Credit


Return
Code


Authorization
Code


Tra
nsaction
Type


number, expiration date, merchant id


Check that name, card number, and date match those in credit card table.


Check that credit card status in table is ok


If verified,


If tra
nsaction type is charge,
get approval


Check account status


Check credit rating


Check that transaction amount will not cause balance to go over limit


If approved (or if transaction type is credit),
d
o transaction


Charge balance (this would need to be flushed periodically)


Change available credit


Create transaction record


Create new transaction id and add


Add timestamp


Add card id



Add account id


Add merchant id


Add transaction type


Return successful result


Return result via MDB


Within the credit card database, each main step of this algorithm touches a
different table (see Figure 14). Th
e merchant identity is verified through the merchant
table, the customer identity is verified via the credit card table, the billable customer
identity is gotten by the customer table, approval is found in the account table and is
based on available credit
, and the transaction record is recorded in the transaction table.



















Figure 14: PETCard database access diagram



To explain the tables in a little more detail, the merchant table is a future
implementation that will verify that a merchan
t is valid and not someone trying to steal
credit card numbers. The credit card table is where the customer's information that they
sent (name, card number, and expiration date) are compared with the table's data to verify
the customer's identity. The cu
stomer table billable customer verification can be
explained thus
-

Many married couples, or a parent and child, will share a credit card and
both names will be on it. This will check to see which of these names the transaction will
be billed to. The acco
unt table contains information such as a credit card's limit and
balance, and will therefore check and see if the customer has enough available balance to

PETCardEJB


Merchant

Transaction

Customer

Account

CreditCard

Verify merchant identity

Get billable

customer

Get approval

Verify customer identity

Create transaction record


DB2

Session
Bean

Entity
Beans

EJB Tier

Web Tier

Ent
erprise
Information
System or
Database Tier

Return request
successful/failed

Request transaction


Message
Driven
Bean

Make transaction

be able to make the purchase. If the user's information passes all these tests, the
transaction will

go through and will be recorded in the transaction table.























Chapter 6: Development Environment


6.1 WebSphere Studio Application Developer


WebSphere Studio Application Developer (WASD) was a very useful tool in this
project. It is a

development environment specifically designed to assist in writing J2EE
applications. It was an excellent tool that made it easy to develop Java packages for both
the business logic specific to my model component and also for the common code shared
by al
l three components. It made the integration of the three components written by
separate programmers easy to do by allowing for version control. It had its own built in
test environment, complete with a test server so the application could be run on our o
wn
computers before actually being ported to the zSeries test servers. WASD also had an
intuitive debugger to work with.


What I considered the most important part of this developer was its ability to
allow multiple developers to work on a project. It no
t only allowed for the easy addition
of modules such as JAR files to an individual's portion of a project, but allowed for the
easy addition of another developer's entire portion of a project as well. The developer
had only to add the JAR files to the bui
ld path for their project or to the application path
of the application server. Not only would it retain directory structure, but would also
keep track of the current version of that portion.


Below that was its ability to aid the individual developer.
In the case of my EJBs,
there was an intuitive graphical user interface (GUI) that, with a few clicks of the mouse,
would set up the scaffolding for a basic enterprise java bean's code, after which I would
fill in the business logic. It easily allowed for

choosing the specification level, the type of
bean (session or entity), its type of persistence, and adding methods and database queries.
One fantastic component of the developer was the local history. This saved a copy of a
file each time it is edited
and saved. This allowed us to replace a current file with a
previous edit or even restore a deleted file.


Once the code was written, it had to be compiled. This of course involved the
debugger, since any syntax errors or linking problems would prevent t
he compilation
from being successful. Like many visual working environments, it would detect an error,
indicate where it was found, and attempt to diagnose the problem by listing possible
problems/corrections. In order to debug the logic of the applicati
on, the debugger
allowed you to control the execution of the program by setting breakpoints, suspending
launches, stepping through the code, and examining the contents of variables.

Now that the code compiled, it could be tested on the test server that was

provided
by the application developer. The test server was J2EE compliant. I found this to be the
most convenient tool in the application developer. The best part about it was that it
imitated the appearance of being deployed on a WebSphere Application

Server without
actually deploying the code, which is time consuming. Once I had my EJBs written, I
would start the test server. This would allow me to test them without requiring me to
write a front end to my portion of the application. Within this tes
t server I could make
requests from the database and test to see that my queries worked properly even with
invalid or unexpected input. Because of this, integration with the other two components
of the application was easier knowing that I had already tes
ted my portion to the best of
my ability.


Chapter 7: Tracing


7.1 Tracing


Tracing was an essential part of this project (see Figure 15). Since this was a
workload application for a testing department, it meant that our application would be
continually
breaking the system. Because of this, the testers wanted the ability to see
exactly where our program had stopped, what it was doing when it stopped, and what
values it was currently holding at the time.


Figure 15: Example of tracing




Tracing was als
o greatly helping in our own debugging process. While we were
polishing our implementation and interfaces, we would use our tracing object to see what
values were being passed and where the application may have stopped working correctly.
Combined with th
e WSAD debugger, it was a powerful tool.


To do our tracing, we created a BookStoreTestData object, which extended a
basic TestData object. We included a WebAppTraceLogger object we called TRC.

This trace object was created by IBM to assist in the devel
opment and debugging of their
applications. Using it illustrates the modularity of Java and the ease of adding additional
packages. The information it collected could be accessed remotely, which allowed the
information to be reported directly back to a u
ser instead of being output to a logfile.
This trace object had three error levels for its error messages. Level 1 was for critical
errors where continuing was suspect. Level 2 was for serious errors, but recovery and/or
continuation was expected. Leve
l 3 was for likely errors or exceptions handled during
normal operations. Using level 2 would also print out the level 1 error messages, and
using level 3 would print out the level 1 and 2 error messages as well.








Chapter 8: Discussion and Conclusio
n


8.1 IBM's intended use


IBM will phase out usage of the old bookstore application with the new Sunset
Books (see Figures 16, 17, 18, 19). Initially it will be run on the zSeries servers in the
integrated testing department. There it will be run exten
sively to initially find any bugs
in our workload application, and then in turn it will be used to find any bugs or
deficiencies in the z/OS operating system, and particularly with the interfacing between
and the capacities of MQ, DB2, and WebSphere.


The
original goal of the application was to expose bugs in the z/OS before the
product reached the client. Not only does Sunset Books stress the various aspects of the
system, but the stress is variable. Maybe one day the department would like to focus on
DB
2, and in particular with a large number of one type of query, like browsing for a
book. The next week, they may focus more on MQ and do a lot more buys of books. If
they do happen to find a problem due to a bug, they can have it log one of the three lev
els
of tracing to see where the problem is located and potential reasons why.


Once the testing application is working well on the zSeries server, they hope to
phase out the old bookstore on the pSeries server as well. This will be a true test to see if
t
he application is platform independent. They will also be distributing the bookstore
application across multiple systems to make sure that remote data exchange works well.

The end goal is two
-
fold: to make testing the system easier, and to produce a
high
er quality product.


Figure 16: Index page of application


Figure 17: Searching for a book





Figure 18: Search results for “King”


Figure 19: A Detail for “King”



8.2 Further Development


The beauty of using Java and the J2EE standard is that S
unset Books is a scalable
application. Modular components can be added without affecting the structure and
integrity of the existing application. The requirements for this application will be
constantly changing, and it will need to be modified according
ly.

For example, when the credit card application is finished, it can be easily added to
Sunset Books with very few necessary modifications. In addition, because Java is an
object oriented programming language, and through the use of WSAD it is easy to
add
small new features to the application, such as a different method of searching for books.


Another common need to change the Sunset Books will be because of new
versions of the applications it tests, along with new versions of the J2EE standards and
co
mponents. For instance, currently when the session bean receives its book results or
details, they are unordered and therefore must be ordered using java in the session bean.
With the new EJB 2.1 specifications, we will be able to use the SQL statement "
order by"
in the EJBQL. This means the ordering will be done in the database, rather than on the
server. This will reduce the load on the server, making it able to handle more requests.
The sorting will also probably be faster because Java is a rather s
low language, as
opposed to SQL in a database that is designed to execute such statements. Also, the
testing department was thinking of upgrading to DB2 8.0, and the testing application
needs to be able to integrate with the new database seamlessly.








Literature Cited


[1] Armstrong, Eric, et al.
The J2EE 1.4 Tutorial
. 31 Mar. 2004. Sun Microsystems.

<http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html>.


[2] A Tutorial on Java Servlets and Java Server Pages (JSP)
. 1999.

<http://www.apl.jhu.ed
u/~hall/java/Servlet
-
Tutorial>.



[3] Bill Shanon, “Java 2 Platform Enterprise Edition Specifications, v1.4”, Sun
Microsystems, California, 2002.


[4] Brown, Ian, et al.
WebSphere Studio Application Developer Version 5

Programming Guide
. 3rd draft
. N.p.: International Business Machines

Corporation, 2003.


[5] Enterprise JavaBean2.0 Specification Changes
. Apr. 2001. Sun Microsystems.

<http://java.sun.com/developer/technicalArticles/ebeans/ejb20/>.



[6] Enterprise JavaBeans Technology
. Sun M
icrosystems.

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


"IBM Unveils New J2EE WebSphere."
Computer Reseller News

1043 (2003):

98
-
103.


[7] IBM WebSphere Application Server Family
. IBM.

<http://http://www
-
306.ibm.com/software/info1/websphere/index.jsp?t
ab=products/appserv>.




[8] Java 2 Platform, Enterprise Edition (J2EE) Overview
. Sun Microsystems.

<http://java.sun.com/j2ee/overview.html>.


[9] JavaServer Pages Technology
. Sun Microsystems.

<http://http://java.sun.com/products/jsp/>.



[1
0] Java Servlet Technology
. Sun Microsystems.

<http://http://java.sun.com/products/servlet/>.



[11] JDBC Overview
. Sun Microsystems.

<http://http://java.sun.com/products/jdbc/overview.html>.



[12] JNDI Overview
. Sun Microsystems.

<http://h
ttp://java.sun.com/products/jndi/overview.html>.



[13] Jones, Jeff.
The Big Picture: IBM DB2 Information Management Software and DB2
Universal

Database
. 26 Feb. 2004. IBM.

<http://http://www
-
106.ibm.com/developerworks/db2/library/techarticle/0301jo
nes/0301jon

es.html>.



[14] Model
-
View
-
Controller Architecture
. 2001. Sun Microsystems.

<http://www.dpi.ufv.br/downloads/j2ee/j2ee_kit/03_build_and_deploy/design_pattmodel
_vie

w_controller/index.htmlerns/>.


[15] Ramachandran, Vijay.
Design Patter
ns for Building Flexible and Maintainable J2EE

Applications
. Jan. 2002. Sun Microsystems.

<http://java.sun.com/developer/technicalArticles/J2EE/despat/>.


[16] Stefanie Bodoff, Dale Green, Kim Haase, Eric Jendrock, Monica Pawlan, Beth
Stearns, “The J2EE T
utorial”, Addison
-
Wesley, Boston, 2002.



References


Bruce Eckel, “Thinking In Java”, MindView, Inc., 2002.


IBM z/OS Integration Test: Parallel Sysplex Test Report Library
. IBM.

<http://www
-
1.ibm.com/servers/eserver/zseries/zos/integtst/library.html>.


S
liwa, Carol. "Sun Says Java Will Support Key Web Services Standards."
Computerworld

37.6 (2003): 12
-
16. <http://search.epnet.com/direct.asp?an=9148901

&db=mfh>.