Download Clarkson University

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
Department 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 standards 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 platform 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 Department. This
application is compliant to the Java 2 Enterprise Edition standards and the Model-ViewController 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 entity 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 entire 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 did not permit for the proper testing necessary to finish the application.
TABLE OF CONTENTS
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 architecture ............................................................................................ 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
LIST OF FIGURES
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 of 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
Figure 13: PETCard database tables ............................................................................... 28
Figure 14: PETCard database access diagram ................................................................ 30
Figure 15: Example of tracing ........................................................................................ 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 WebSphere 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 should 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 bookstore 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
compliant. 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 applications.
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 the 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 for
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 compliance tests. It
calls for object oriented modular components, which allows for easy scalability and
maintainability.
Applet
Container
WebSphere
HTTP
SSL
Applet
Web Container
EJB Container
EJB
Servlet
JSP
J2SE
Application
Client
Container
Application
Client
HTTP
SSL
JTA
JMS
JTA
JMS
Java
Mail
JNDI
Java
Mail
JNDI
RMIIIOP
JDBC
J2SE
JDBC
RMIIIOP
J2SE
JMS
JAAS
JAXP
Database
JDBC
J2SE
Figure 2: Example of J2EE architecture (containers) [3]
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 makes 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 separate 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 fact, 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 requests 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.
Model
Enterprise Java Beans
State
Query
Change
Notification
State
Change
View
Selection
View
Java Server Pages
Controller
Servlets
User
Gestures
Method Invocations
Events
Figure 3: Model View Controller 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 web 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 user'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 tier 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
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.
Sample J2EE Application
Client
Machines
J2EE Server Machine
Client Tier
Web Tier
Web
Browser
JSP Pages,
Servlets
Business Tier
Java Beans
(optional)
Database,
Legacy
Systems
Web
pages,
applets,
Java Beans
Class
(optional)
Database
and other
servers
EIS Tier
Entity
Beans,
Session
Beans,
MessageDriven
Beans
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,
you can use it to make dynamic calls to databases from Java applications through the
JDBC Application Program Interface (API), which uses standard network connections
(see Figure 5).
client
Application
lookup
jdbc/nameofDB
DataSource
JDBC Driver
JNDI
Naming
Service
Database
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 when 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-independent API
specified in Java technology that provides naming and directory functionality to
applications written in the Java programming language. Designed specifically for the
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
provides 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 architecture.
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 encapsulate 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 JavaBean (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).
EJB
Synchronous
Entity
CMP
Asynchronous
Session
BMP
Stateless
Message-Driven
Stateful
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
not have to wait 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 the 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 search. 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
memory. 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 can 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 remote 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 persistence (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. This 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 across 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, manage 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 reside 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 return 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 with distributed clients
(such as a servlet) and expose its methods across the network tier [4].
Remote
Client
Remote View
EJB
Home
EJB
Object
EJB
Local
Home
Local
Client
EJB
Component
EISs
EJB
Local
Object
Container
EJB Server
Local View
Java Virtual Machine
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 beans, only the session
bean data transfer objects (DTOs) limit inter-layer data sharing to serializable JavaBeans,
therefore avoiding remote references.
Chapter 3: Project Requirements
3.1 Specifications
The goal of this software design and development 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 Application 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 restarted, 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 servlets, 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 integration 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 errors 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 transport 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 pieces 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 using 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
advantage 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 turn 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 then 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 accesses the DTO to build the
user response, and returns the resultant HTML to the client.
HTTP
Web Client
1
Control
RMI/IIO
P
2
Facade
3
5
5
7
View
4
6
DTO
Entity
Model
Web Module
EJB Module
Web Container
EJB Container
Application Server
Figure 8: Application component model and workflow [4]
Chapter 4: Implementation Details of Sunset Books Model
4.1 The view
The view (see 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, Reports.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, category, 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
information 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
book 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
easy 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.
Search.jsp
Index.jsp
Results.jsp
Details
Help.jsp
Reports.jsp
Cart.jsp
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 from 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 from 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 the 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
Results.jsp. The Buy servlet gets its data from the model and returns it to either Cart.jsp
or Order.jsp.
Order.jsp
Cart.jsp
Results.jsp
Details.jsp
Browser
Action
servlet
Buy
servlet
FeaturedBooks
servlet
MQ
Browse
servlet
EJBs
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 bean 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 will 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
controller. Only the three function calls getDetails(), getResults(), and FeaturedBooks()
can be used.
Results
Local
Featured
Servlet
BookBrowse
EJB
Session Bean
Results
Local
Home
Book
Browse
EJB
Results
Bean
Book
Browse
EJBHome
Results and
Details Entity
Beans
Book
Browse
EJBBean
Browse
Servlet
DetailsLocal
DetailsLocal
Home
EJB Tier
Web Tier
DB2
Enterprise
Information
System or
Database Tier
DetailsBean
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
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 request 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 price. 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 price, 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 ambiguous 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 several 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 implemented 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 order. 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 category 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
information 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
direction 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 would
have been an added stress on DB2, and it probably would have been faster than anything
we wrote on our own.
Select a1, a2, … an
From r1, r2, … rm
Where P
[order by …]
[group by…]
[having…]
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
wrote 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 possible
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 using 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.
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 more. 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 tremendous. 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 server 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 implementation 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 against 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 below (see Figure 13).
Customer Table
Customer
ID
Last
Name
Address
Merchant Table
Merchant
ID
Billable
PK
PK
Billable
Customer
ID
FK
Account Table
Account
ID
Credit
Limit
Current
Balance
Billable
Customer
ID
Status
PK
Available
Credit
FK
Credit Card Table
Card
ID
PK
Account
ID
Valid
From
Expiration
Date
Name
On
Card
Status
PIN
FK
Transaction Table
Transaction
ID
PK
Card
ID
FK
Account
ID
FK
Merchant
ID
Timestamp
Transaction
Amount
Return
Code
FK
Transaction
Type
Authorization
Code
Figure 13: PETCard database tables
5.3 Program flow
Do transaction
Credit transaction
Check merchant identity (future implementation)
Verify customer identity, parameters: customer name, transaction amount, card
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 transaction 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), do 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). The 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.
Entity
Beans
Verify merchant identity
Merchant
Message
Driven
Bean
Verify customer identity
CreditCard
Make transaction
Session
Bean
Get billable customer
Customer
DB2
Request transaction
Get approval
Account
PETCardEJB
Return request
successful/failed
Create transaction record
Transaction
Web Tier
EJB Tier
Enterprise
Information
System or
Database Tier
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 merchant 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 customer 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 account 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
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 all 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 own
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 not 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 build 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 the 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 application, 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 test 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 tested 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 also 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 the 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 development 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 user 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. Level 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 Conclusion
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 extensively 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
DB2, 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 levels
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
the 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
higher 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 Sunset 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 accordingly.
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
components. 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 slow 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.edu/~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 Microsystems.
<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://www306.ibm.com/software/info1/websphere/index.jsp?tab=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/>.
[10] 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://http://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://www106.ibm.com/developerworks/db2/library/techarticle/0301jones/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 Patterns 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 Tutorial”, 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>.
Sliwa, 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>.