Download Thesis Writeup - Computer Science

R.E.X. (Rhodes E-commerce eXchange)
- A Study in Using E-commerce to Facilitate On-line Auctions at
an Institutional Level.
Submitted in partial fulfilment
of the requirements of the degree
Bachelor of Science (Honours)
of Rhodes University
by Roché Naudé
Computer Science Department
November 2001
Acknowledgements
My supervisors- Mr. John Ebden for making sure that I was on track with my proposal and
providing crucial SQL problem solving tips, and Dr. George Wells for endless practical
advice on doing the project effectively and Java™ ‘guidance’ and encouragement in my
battles with the web server.
My mom just for being super and SO supportive, especially during moments of crisis- thanks
for carting all those cups of coffee my way!
Susie Radloff for being a best friend- faithful in prayer and encouragement!
My Dad for his encouraging feedback and interest in my project and website.
Paul Sainsbury for persistently telling me that I can do it, in the face of my ‘but I can’t do it’
arguments.
I love reading, and I think that every book I’ve ever read has had a dedication of some form or
other on the first page. So this is where I get to dedicate something written! To God, for
everything, and particularly for showing me that there is life beyond the lab and that hard
work still means something.
Conventions and Copyright Notices
Code extracts used in this report are formatted as, or as a variation of, the following:
this is code.
Sun, Sun Microsystems, the Sun Logo, iPlanet™ FastTrack Web Server, Java™, Java™ Servlet,
JavaServer Pages™, JDBC™, JavaBeans™, JDK™, JRE™, Enterprise JavaBeans™, JavaMail™,
JavaBeans™ Activation Framework are trademarks or registered trademarks of Sun Microsystems,
Inc. in the United States and other countries.
Borland, the Borland Logo, InterBase®, InterClient™ are trademarks or registered trademarks of
Borland Software Corporation in the United States and other countries.
Microsoft Internet Explorer®, Microsoft Windows 2000® and XP®, Microsoft FrontPage® and any other
Microsoft affiliated product and logos are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
UltraEdit® is a registered trademark of IDM Computer Solutions, Inc., All rights reserved.
R.E.X.
The implementation of the auction based e-commerce system discussed in this report using Java
related technologies.
Copyright (C) 2001, R. Naudé.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU
General Public License as published by the Free Software Foundation; either version 2 of the License,
or any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
Copyright © 2001. R. Naudé, All Rights Reserved.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright
notice and this permission notice, as well as the above stated notices, are preserved on all copies,
and provided that the recipient is not asked to waive or limit his right to redistribute copies as allowed
by this permission notice.
Permission is granted to copy and distribute modified versions of all or part of this manual or
translations into another language, under the conditions above, with the additional requirement that
the entire modified work must be covered by a permission notice identical to this permission notice.
Abstract
In light of the success of some of the mass-market on-line e-commerce (particularly auction
based) sites such as ebay.com, this project investigates the viability and implementation issues
associated with such a site developed at an institutional level using Java technologies.
The system investigated consisted of a web-based application modelled on the three-tier
client-server architecture using free and low-cost software. Technologies used and
investigated include Java, JSP, servlets and JDBC. The implementation part of the project
resulted in a rudimentary proof of concept system proving the viability of an affordable,
dynamic, small to medium scaled, Java based e-commerce endeavour.
Table of Contents
CHAPTER 1:
1.1
INTRODUCTION ........................................................................................................... 1
BACKGROUND ....................................................................................................................................... 1
1.2
THE PROJECT ........................................................................................................................................ 2
1.2.1
Motivation........................................................................................................................................ 2
1.2.2
Description ...................................................................................................................................... 2
1.2.3
Scope ............................................................................................................................................... 3
1.2.4
Deliverables ..................................................................................................................................... 3
1.3
THE THREE-TIERED CLIENT-SERVER APPROACH .................................................................................. 4
1.4
TECHNOLOGIES USED ........................................................................................................................... 4
1.5
OVERVIEW OF THE REPORT ................................................................................................................... 5
CHAPTER 2:
2.1
THE E-COMMERCE ENVIRONMENT ..................................................................... 7
WHY THREE TIERS? .............................................................................................................................. 7
2.2
THE MAJOR DEVELOPMENT AND DEPLOYMENT OPTIONS ..................................................................... 9
2.2.1
Java vs. Microsoft®.NET.................................................................................................................. 9
2.2.2
Why Java? ..................................................................................................................................... 11
2.3
JAVA ................................................................................................................................................... 12
2.4
JAVASCRIPT ........................................................................................................................................ 13
2.5
SERVLETS............................................................................................................................................ 13
2.6
JAVASERVER PAGES(JSP) AND JAVABEANS ....................................................................................... 13
2.7
JAVAMAIL .......................................................................................................................................... 15
2.8
JAVA DATABASE CONNECTIVITY (JDBC) ........................................................................................... 15
CHAPTER 3:
3.1
THE FRONT-END (FIRST TIER) .............................................................................. 16
THE THIN CLIENT APPROACH ............................................................................................................. 16
3.1.1
Thin Client vs. Thick Client ........................................................................................................... 16
3.1.2
Applets vs. Form Elements ............................................................................................................ 19
3.2
TECHNOLOGIES USED IN THE R.E.X. FRONT-END ............................................................................... 20
3.2.1
Browser.......................................................................................................................................... 20
3.2.2
JavaScript ...................................................................................................................................... 20
3.3
FRONT-END FEATURES ........................................................................................................................ 23
3.3.1
Design ............................................................................................................................................ 23
3.3.2
Performance .................................................................................................................................. 23
3.3.3
Maintenance .................................................................................................................................. 23
CHAPTER 4:
4.1
4.1.1
BUSINESS-APPLICATION LOGIC (MIDDLE-TIER) ........................................... 24
THE FUNCTIONALITY AND RESPONSIBILITIES OF THE MIDDLE-TIER ................................................... 24
Session Tracking ............................................................................................................................ 25
4.2
TECHNOLOGIES USED IN THE R.E.X. MIDDLE-TIER ............................................................................ 28
4.2.1
The Web Server .............................................................................................................................. 28
4.2.2
iPlanet FastTrack Web Server ....................................................................................................... 29
4.3
THE ADVANTAGES OF SERVLETS OVER COMMON GATEWAY INTERFACE (CGI) ................................. 30
4.4
THE ADVANTAGES OF JAVASERVER PAGES ........................................................................................ 32
4.4.1
Over ASP ....................................................................................................................................... 32
4.4.2
Over PHP ...................................................................................................................................... 33
4.4.3
Over JavaScript ............................................................................................................................. 33
4.4.4
Over Static HTML ......................................................................................................................... 33
4.5
SERVLETS AND JAVASERVER PAGES ................................................................................................... 34
4.5.1
Servlets vs. JavaServer Pages........................................................................................................ 34
4.5.2
Using Servlets and JavaServer Pages Together ............................................................................ 35
4.6
JAVASERVER PAGES AND JAVABEANS................................................................................................ 35
4.7
JAVAMAIL .......................................................................................................................................... 38
4.8
MIDDLE-TIER FEATURES..................................................................................................................... 39
4.8.1
Design ............................................................................................................................................ 39
4.8.2
Performance .................................................................................................................................. 40
4.8.3
Maintenance .................................................................................................................................. 41
4.8.4
Scalability of Business Side Objects .............................................................................................. 42
CHAPTER 5:
5.1
THE BACK-END (THE DATABASE SERVER) ...................................................... 43
THE SERVICES PROVIDED BY THE DATABASE TIER ............................................................................. 43
5.1.1
The Relational SQL Database ....................................................................................................... 43
5.1.2
Borland InterBase.......................................................................................................................... 43
5.2
JDBC AS AN INTERFACE TO THE DATABASE TIER ............................................................................... 45
5.2.1
Using JDBC ................................................................................................................................... 47
5.2.2
Statement vs. PreparedStatement .................................................................................................. 49
5.3
ADVANTAGES AND DISADVANTAGES OF USING PURE JDBC .............................................................. 49
5.4
BACK-END FEATURES ......................................................................................................................... 50
5.4.1
Design ............................................................................................................................................ 50
5.4.2
Performance .................................................................................................................................. 51
5.4.3
Maintenance .................................................................................................................................. 51
CHAPTER 6:
6.1
THE PRACTICAL IMPLEMENTATION OF R.E.X. .............................................. 52
THE R.E.X. ARCHITECTURE ................................................................................................................ 52
6.1.1
 Client-side (Remote User’s Computer) ..................................................................................... 53
6.1.2
 Middle-tier (Middleware/Communications).............................................................................. 53
6.1.3
 Database Server ........................................................................................................................ 54
6.2
THE INTERACTION BETWEEN THE THREE TIERS.................................................................................. 55
6.3
IMPLEMENTATION BENEFITS ............................................................................................................... 57
6.3.1
6.4
JavaBeans and JavaServer Pages ................................................................................................. 58
IMPLEMENTATION PROBLEMS ............................................................................................................. 59
6.4.1
Web Server Specific Problems ....................................................................................................... 60
6.4.2
Database Server Specific Problems ............................................................................................... 60
6.5
USING THE PROTOTYPE ....................................................................................................................... 60
6.6
TESTING THE PROTOTYPE ................................................................................................................... 61
6.7
SCALABILITY AND PRACTICAL FULL-SCALE IMPLEMENTATION CONSIDERATIONS OF R.E.X.............. 63
6.8
CONCLUSIONS ..................................................................................................................................... 64
CHAPTER 7:
7.1
CONCLUSION .............................................................................................................. 66
OVERVIEW .......................................................................................................................................... 66
7.2
FUTURE DIRECTIONS ........................................................................................................................... 67
7.2.1
Security .......................................................................................................................................... 67
7.2.2
Payment Options............................................................................................................................ 67
REFERENCES .................................................................................................................................................... 68
APPENDIX A ...................................................................................................................................................... 73
R.E.X. FILE HIERARCHY ................................................................................................................................... 73
A LOOK AT R.E.X. ............................................................................................................................................ 79
PRACTICAL SET-UP OF R.E.X. ON WINDOWS 2000 ............................................................................................ 98
APPENDIX B – OVERVIEW OF SOFTWARE USED ................................................................................ 103
APPENDIX C .................................................................................................................................................... 104
CONTENTS OF THE CD-ROM .......................................................................................................................... 104
APPENDIX D .................................................................................................................................................... 105
BIBLIOGRAPHY ................................................................................................................................................ 105
GLOSSARY ....................................................................................................................................................... 106
PROJECT POSTER ......................................................................................................................................... 110
Figures
FIGURE 1-1: THREE-TIERED CLIENT-SERVER ARCHITECTURE ..................................................... 4
FIGURE 3-1: THIN AND THICK CLIENT COMPONENTS [COMPUTING ALTERNATIVES, 2000] ...... 16
FIGURE 3-2: HTML FORM ELEMENTS EXAMPLE....................................................................... 19
FIGURE 3-3: JAVASCRIPT EXAMPLE .......................................................................................... 22
FIGURE 5-1: JDBC FACILITATED COMMUNICATION .................................................................. 48
FIGURE 6-1: THE R.E.X. ARCHITECTURE (ADAPTED FROM [GUPTA, 2001]) .............................. 52
FIGURE 6-2: THE R.E.X. DATABASE TABLE SCHEMA................................................................ 55
Tables
TABLE 2-1: THREE-TIER ARCHITECTURE VS. N TIER ARCHITECTURE .......................................... 8
TABLE 2-2: J2EE AND MICROSOFT.NET COMPARED ................................................................ 11
TABLE 4-1: ADVANTAGES AND DISADVANTAGES OF IPLANET FASTTRACK WEB SERVER ........ 30
TABLE 5-1: INTERBASE FEATURES ............................................................................................ 44
TABLE 5-2: THE JDBC PACKAGE .............................................................................................. 46
Chapter 1: Introduction
1.1 Background
More and more people are gaining access to the Internet and the information and services that
it provides. Electronic commerce (e-commerce) is growing daily [Allamaraju et al, 2001] due
largely to the benefits associated with the Internet such as:

Easy accessibility - all the consumer needs is a computer, a modem and a phoneline

Twenty-four hour access

The delivery of goods to the consumer’s door

On-line credit/debit payment options

The freedom of shopping from the comfort of the consumer’s own home, at the
consumer’s convenience, with little physical exertion or time-wastage on queues,
persistent salespeople, traffic, parking and carrying shopping bags.
As a result of this growth, on-line shopping and trade ventures are expanding into more userfriendly and participative areas, including auction type exchanges.
An example of this
functional evolution is Amazon.com [Amazon, 2001] which is now incorporating auction and
second-hand sales along with its central book selling concern .
Successful on-line stores are usually large-scale commercial endeavours. The author will
attempt to show that the implementation of such a system outside the arena of well-known
large-scale e-commerce businesses such as ebay.com™ [eBay, 2001] is feasible, beneficial
and practically achievable.
1
1.2 The Project
1.2.1 Motivation
The motivation for this project is perhaps best clarified with a practical example. When a
department at Rhodes University closes down there are many practical issues that need to be
addressed. One of these issues is how to dispose of equipment and furniture that will no
longer be used. The obvious solution would be to sell the equipment to interested parties, but
in order to do that, the interested parties would need to be told about the sale of the goods.
The question then, is how can a seller effectively let prospective buyers know about goods?
Students in ‘digs’ (off-campus student housing) have a similar problem. When they leave
Grahamstown, hopefully with degree in hand, they often need to sell furniture that they will
not be using anymore or textbooks that they have finished with. The usual method of
advertising such goods is via notices pinned up in a variety of places around campus. This is
impractical and not cost effective. Most goods advertised in this way are sold when a
prospective buyer ‘happens’ to see the notice as he or she wanders by.
A solution to this problem would be a central repository of second-hand goods for sale that is
accessible to all people interested in buying these goods.
The classifieds section of
newspapers have been utilising this approach for years. If a person is looking for something
second-hand, then their first point of reference is usually the classifieds.
All students at Rhodes University have access to the Internet. If a central repository of
second-hand auction goods could be provided on the Internet then prospective buyers and
sellers would simply have to sit at a computer and access this central repository, via a web
browser.
1.2.2 Description
This project has two primary objectives. The first is an investigation into the development of
an affordable, dynamic, small to medium scaled web-based auction endeavour specifically for
use at an institutional level, such as Rhodes University. This investigation focuses primarily
on the Java related technologies that can be used to accomplish such a development.
2
The second objective results from the outcome of the investigation in the first objectivenamely the production of a small to medium scaled e-commerce application prototype that
could be implemented for use by the staff, administration and students of Rhodes University.
This system provides information about, and facilitates, the auction of products ranging from
books to desks and sporting equipment. Clients interact with the system using an interface
accessible via the Internet. They can register with the system which results in the creation of
their own user account. This user account facilitates all their other interactions with the
system such as bidding, auctioning and so on. The prototype system will from hereon be
referred to as R.E.X., an acronym for Rhodes E-commerce eXchange.
1.2.3 Scope
The author wishes to reiterate that the main focus of this project is an investigation into the
use of Java related technologies in the development of a small to medium-scaled e-commerce
endeavour. It has not been the author’s intention to focus in any great detail on security issues
or payment options relevant to a system such as R.E.X. At a reasonably small university,
such as Rhodes, payment and delivery options are not a major concern as people who use
R.E.X. could conveniently meet on campus to make payment and delivery arrangements.
Much of e-commerce security deals with credit card payments and the secure transfer of the
information associated with these transactions. While these issues, particularly security, are
important they fall outside the scope of this project and have not been addressed explicitly
except as possible future extensions to this project.
1.2.4 Deliverables
This project has resulted in this investigative report and in R.E.X. - a rudimentary practical
system demonstrating the results of the investigation in this report.
3
1.3 The Three-tiered Client-Server Approach
Request
Request
Response
Database
Response
Response
Request
Front-end Client-side
Server-side Middle-Tier
Back-end
Figure 1-1: Three-tiered Client-Server Architecture
Figure 1-1 represents a high-level model of the three-tiered client-server (request-response)
architecture investigated in this report and used in the implementation of the R.E.X. On-line
Auction system prototype. The author has chosen a three-tiered rather than a two-tiered
approach as this facilitates a clear logical separation of the components comprising the
system. The functional separation is as follows:
1. The front-end  handles client interaction. This is the part of the system with which
the end-user interacts.
2. The middle-tier  handles the business application logic of the system. It services
client requests by taking the appropriate action, such as passing requests on to the
database server. It also manages the presentation of the responses to client requests.
3. The back-end  handles persistent data. It is composed of a database server which
houses the R.E.X. database.
The three-tiers illustrated, and the associated implementation/investigative decisions made
concerning these layers, are discussed in greater detail in chapters 3, 4, 5 and 6.
1.4 Technologies Used
It is assumed that the reader of this report has at least a basic understanding and knowledge of
Java as an object-oriented programming language, the Hypertext Mark-up Language (HTML)
and the Structured Query Language (SQL).
4
The Java technologies used in R.E.X. will be discussed and defined briefly in chapter 2 “The
E-commerce Environment” and more specifically in chapters 3, 4, 5 and 6 which discuss the
system tier by tier and the practical implementation of R.E.X.
The technologies used and investigated are listed here for reference:
1. Java
2. JavaScript
3. Servlets
4. JavaServer Pages (JSP) and JavaBeans
5. JavaMail
6. Java Database Connectivity (JDBC)
1.5 Overview of the Report
Chapter 2 “The E-commerce Environment” explores the development and deployment issues
relevant to the production of an e-commerce system with particular emphasis on, and
definitions of, Java related technologies in this field.
The first tier of a three-tiered client-server architecture is defined and discussed in detail in
Chapter 3 “The Front-end (First Tier)”. Similarly, Chapter 4 “Business-Application Logic
(Middle-Tier)” looks at the middle-tier of the architecture and Chapter 5 “The Back-end (The
Database Server)” investigates the database tier of the system.
Chapter 6 “The Practical Implementation of R.E.X.” examines the practical issues involved in
the design and implementation of the prototype in light of the tier by tier discussions in
chapters 3, 4 and 5.
Chapter 7 “Conclusion” concludes the report and shows future directions and possible
extensions to this project.
5
The references used in the report are followed by Appendix A. This details the R.E.X.
prototype file hierarchy and gives a walk through of the system using a combination of
descriptions and screen dumps of R.E.X. in action. Readers interested in using the R.E.X.
implementation can utilise the instructions provided in a “Practical Set-up of R.E.X. on
Windows 2000”, page 98. This is followed by Appendix B which gives URLs to documents
highlighting the general features of the software used by R.E.X.:

iPlanet (Sun Netscape® alliance) FastTrack web server

InterBase Database server

InterClient JDBC driver and InterServer
Appendix C lists the contents of the CD included with this report and Appendix D gives the
report Bibliography and Glossary. Finally, the project poster is provided in A3 format at the
end of this report.
6
Chapter 2: The
E-commerce Environment
The e-commerce environment can be divided into two categories:
1. The environment in which an e-commerce application is developed.
2. The environment in which an e-commerce application can be, and is, deployed.
This chapter focuses primarily on the environment in which an e-commerce application is
developed. This environment consists of the tools, methods and APIs used in designing and
coding a system. The deployment environment, on the other hand, refers to the environment
in which a system operates and is used.
2.1 Why Three Tiers?
A tier can be thought of as a layer defined by its function and/or location. It is composed of
similarly organised objects that help it fulfil its function [whatis?com, 2001].
A three-tiered system is a type of client-server architecture composed of three distinctly
defined processes- a user interface, a business-logic layer and a database layer. Each of these
tiers can run on a different machine or platform [Webopedia, 2001]. For example, the frontend handles client interaction and is located on the user’s machine while the middle-tier is
located on a server and manages business processing.
With the advent of distributed computing, the Internet and large-scale e-commerce
endeavours, the standard one, two or three-tiered architecture now has the potential to expand
into multiple tiers (n-tiers). The middle-tier (server-side) is particularly vulnerable to layer
multiplication because the developer may be tempted to create a new, or separate, layer for
every separate business function or application. For example, creating a separate physical
and/or logical layer for registering a user, for bidding on goods etc.
The developer must choose the architecture that best meets the needs of the specific system in
development [Allamaraju et al, 2001]. This choice involves carefully considering both the
advantages and disadvantages of a specific architecture in terms of the particular system that
is being developed.
In the three-tier architecture the modification or replacement of a single tier, without
influencing or affecting the other tiers, is simplified because of the functional modularity
provided by the high-level definition of each of the three tiers [Webopedia, 2001].
7
Chaffee, 2000 summarises the pros and cons of three and n-tiered architectures in the
following table:
Architecture
Pros
Three tiers

N tiers





Can separate user interface, logic and
storage
Reliable, replicable data
Concurrent data access via transactions
Efficient data access
Support multiple applications more
easily
Common protocol/API
Cons




Need to buy database product
Need to hire database administrator
Need to learn new language (SQL)
Object-relational mapping is difficult




Quite inefficient
Must learn API (CORBA, RMI, etc.)
Expensive products
More complex; thus, more potential
for bugs
Harder to balance loads

Table 2-1: Three-tier Architecture vs. N tier Architecture
One and two-tier architectures will not be discussed in great detail because an e-commerce
site such as R.E.X. relies on a database tier for persistent data storage. A two-tiered
architecture consists of a client, a server and the protocol through which the two
communicate. It does not explicitly define a storage tier and relies on the developer to build
one into the server tier if needed [Chaffee, 2000].
R.E.X., as a whole, is a single application, with a single function- acting as an on-line auction
site. If R.E.X. consisted of multiple applications, then the use of n-tiers would be justified.
Each separate application could function within a separate tier or even on a different machine.
The above table does not apply specifically to the R.E.X. architecture. The author will now
consider the applicability of the above identified disadvantages to the R.E.X. architecture:

“Need to buy database product”
This is not true as the InterBase database product as well as the iPlanet FastTrack
web server used by R.E.X. are available for free.

“Need to hire database administrator”
R.E.X. is not a large system and can easily be managed by anyone with a basic
understanding of relational databases and the R.E.X. database design.

“Need to learn new language Structured Query Language (SQL)”
R.E.X. uses simple SQL queries which can easily be understood by anyone with a
basic working knowledge of SQL.
8

“Object-relational mapping is difficult”
This is not applicable to the R.E.X. system. By making use of object-oriented Java
and simple SQL statements, the relationships between objects in R.E.X. (an
example of which would be users and the goods they put on auction) are easily
established and maintained.
It is therefore apparent that the only real, yet minor, disadvantage to developing and
maintaining R.E.X. would be the necessity of learning the basics of SQL.
Using three tiers keeps a relatively simple and uncomplicated system from becoming
unmanageable. Chaffee, 2000 likens the use of n tiers without proper thought or justification
to opening “a huge can of worms, creating new problems in design, implementation and
performance”. The developer would need to keep track of the specific design, implementation
and performance issues associated with each application involved in an n-tier architecture.
The author decided, in the interest of creating a manageable system, to only incorporate the
tiers necessary to the successful functioning of R.E.X.- a client-side, a business-logic middletier and a database back-end. Adding further tiers and applications (for example,
incorporating an application server in conjunction with a web server when the web server
used, more than adequately supports both functions) adds unnecessary complexity to the
system.
2.2 The Major Development and Deployment Options
2.2.1 Java vs. Microsoft®.NET
The two major choices in the development of web services, particularly using the Extensible
Mark-up Language (XML- see the glossary for a concise definition) are Java 2 Platform
Enterprise Edition (J2EE) and Microsoft.NET.
J2EE is Sun’s Java “platform-independent” “web-based enterprise applications” development
and deployment tool. It provides a collection of services, Application Program Interfaces
(API) and protocols that support multi-tiered web-based application development
[Webopedia, 2001].
9
Microsoft.NET embodies Microsoft’s new web strategy. It is an “operating system platform”
consisting of “applications, a suite of tools and services” relying heavily on the Hypertext
Transfer Protocol and XML [Webopedia, 2001]. “Microsoft's .NET strategy is to offer a Java
technology-like platform that fits the Microsoft business model, which is closed and
proprietary” [J2EEvs.NET, 2001].
Although XML is not part of this project, it is prudent to mention it in view of the
increasingly larger role it is playing in e-commerce and the Internet.
There are similarities between certain of the technologies employed by both these
development options.
For example, Microsoft’s Active Server Pages (ASP) and Sun’s
functionally similar JavaServer Pages, and Microsoft’s Open Database Connectivity (ODBC)
for database access and Sun’s Java Database Connectivity (JDBC).
Microsoft’s recent decision, stemming in part from court cases with Sun Microsystems, to not
include a Java Virtual Machine with Windows XP makes the developer’s choice in terms of
which development and deployment environment to use, even more important [J2EEvs.NET,
2001].
The major difference between the two philosophies is that the Java approach leads to
“platform-independent” development and deployment while the Microsoft route, though
allowing the user “access to their information on the Internet from any device, anytime,
anywhere” [Webopedia, 2001],
limits the user to a “closed and proprietary” software
platform to access this information.
Table 2-2 lists the main comparative information concerning these two options and was taken
from Vawter and Roman, 2001. The author has highlighted in bold the points she considers to
be most applicable to this report and discussed some of these in the next section “Why Java?”.
10
Arguments supporting both platforms





Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE,
Object Oriented training for .NET)
You can build web services today using both platforms
Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE
Both platforms offer a single-vendor solution.
The scalability of both solutions are theoretically unlimited.
Arguments for .NET and against J2EE




.NET released their web services story before J2EE, and thus has some mind-share
.NET has a simpler programming model, enabling rank-and-file developers to be productive without
shooting themselves in the foot
.NET gives you language neutrality when developing new eBusiness applications, whereas J2EE makes
you treat other languages as separate applications
.NET benefits from being strongly interweaved with the underlying operating system
Arguments for J2EE and against .NET









J2EE is being marketed by an entire industry
J2EE is a proven platform, with a few new web services APIs. .NET is a rewrite and introduces risk as
with any first-generation technology
Existing J2EE code will translate into a J2EE web services system without major rewrites.
.NET web services are not interoperable with current industry standards. Their BizTalk framework has
proprietary SOAP extensions and does not support ebXML.
J2EE is a more advanced programming model, appropriate for well-trained developers who want to
build more advanced object models and take advantage of performance features
J2EE gives you platform neutrality, including Windows. You also get good (but not free)
portability. This isolates you from heterogeneous deployment environments.
J2EE has a better legacy integration story through the Java Connector Architecture (JCA)
J2EE lets you use any operating system you prefer, such as Windows, UNIX ®, or mainframe.
Developers can use the environment they are most productive in.
We are finding most ISVs (Independent Software Vendor) and consulting companies going with J2EE
because they cannot control their customers' target platforms.
Table 2-2: J2EE and Microsoft.NET Compared
2.2.2 Why Java?
The following is a list of some of the benefits of Java:

“Simple, object-oriented, interpreted, robust, secure, architecture neutral,
portable, high-performance, multithreaded and dynamic” [Java Language White
Paper, 2001]. Using an object oriented language simplifies e-commerce application
development as it assists in the production of clearly defined functional components
[Allamaraju et al, 2001].
11

“Write once, run anywhere” [Curtin, 1998] Java aims to be a platform-independent
development language. Java programs run on a standard Java Virtual Machine
(JVM). JVMs have hardware-specific implementations so that they can operate on a
variety of different platforms. The author believes that the portability of Java is one
of the most important factors in choosing to use it for e-commerce development.
The Internet is heterogeneous- made up of many different computers, networks and
platforms. Therefore, an e-commerce application developed in a language that is
not bound by a specific platform works with, and accommodates, the diversity of the
Internet.

“Java is network aware” [Allamaraju et al, 2001]. Java has the ability to work with
networks and features APIs that interact with “common network protocols”. This
simplifies e-commerce development because basic network support structure is
inherent to the language.

“Java is multi-threaded” [Allamaraju et al, 2001]. Effective server-side applications,
serving multiple users, need to make use of threading in order to respond to requests
efficiently. If the server has to spawn an entirely new process each time a request is
serviced (as with Common Gateway Interface-CGI), the server would soon be
struggling under the resource and processor demands from those services. Both
Java Servlets and JavaServer Pages make use of threads to handle client requests.
Having argued in favour of using Java technologies for e-commerce development, in the
study of this project and in the implementation of the R.E.X. prototype, the actual
technologies used can be defined.
2.3 Java
Java is “a simple, object-oriented, network-savvy, interpreted, robust, secure, architecture
neutral, portable, high-performance, multithreaded, dynamic language” [Java Language White
Paper, 2001].
12
2.4 JavaScript
A script is source code that is interpreted sequentially, line by line [Morrison and Morrison,
2000]. JavaScript is a scripting language that was originally developed by Netscape to
facilitate interactive web design. It was developed independently of, but does share some
common characteristics with, Java. JavaScript is embedded in the HTML source code of web
pages to provide dynamic content and other non-visual features (for example, data entry
validation). [Webopedia, 2001]
2.5 Servlets
A servlet is a program that runs on a server and acts as a middle layer between a request from
a web browser and databases or other applications/drivers residing on the server. Servlets are
Java’s counterpart to the CGI. Servlets generate content “programmatically”- that is, any
dynamic content which a servlet generates, is done within the code of the servlet and usually
delivered to the front-end of the system via println statements to the response object. The
response
can then be used to serve this content back to the front-end [Allamaraju et al,
2001].
A servlet’s main function includes being able to:

Read data sent by the user (via HTML forms, Java applets and so on).

View other request specific information set in the HTTP request header (for
example, cookies or browser capabilities).

Generate the response - this may include interacting with a database to fulfil a request.

Send the response back to the client in the form of a document which can be
displayed on the client’s browser.
[Hall, 2000]
2.6 JavaServer Pages(JSP) and JavaBeans
“The JavaServer Page(JSP) specification is built on top of the Java servlet specification” and
attempts to offer improved “separation of the presentation (e.g. HTML mark-up) and business
logic (e.g. database operations) parts of web applications” [Bergsten, 2001].
13
The technology provided by JSPs enables the developer to combine “regular, static HTML
with dynamically generated content from servlets” [Hall, 2000]. The static parts of the page
are distinct from the dynamically generated components. This is because JSPs mark the
dynamically changing contents with JSP tags that distinguish them from regular HTML. This
type of content production is referred to as “template-based content generation” [Allamaraju
et al, 2001].
When a browser requests a JSP (distinguished by the .jsp file extension) the web server will
first ascertain if the JSP has changed since it was last requested. If it has changed, or if it is
being requested for the first time, the web server will translate, or re-translate, the JSP into a
servlet class. This servlet can then respond to the client request.
JSP tags are scripting elements which allow the developer to insert code into the servlet that
will result from the translated JSP. There are four types of JSP tags:
1. directives: These statements provide the JSP engine with information pertinent to the
page within which they are used. Here is an example of the use of this tag:
<%@ page import=”java.util.*, rex.*, rex.beans.*” %>
This enables the
servlet produced from the JSP to import the classes necessary to fulfil its function.
[Poulton, 2001b]
2. declarations: [Hall, 2000] These are placed outside of any existing methods into the
body of the ensuing servlet class. They take the following format <%! code %>. An
example of the use of this tag is in the declaration of a global variable, or overriding
the jspInit() (called at instantiation) or jspDestroy() (called when the servlet
becomes eligible for garbage collection) methods [Poulton, 2001b].
3. scriptlets: These are placed in the servlet’s _jspService method and take the
following format <% code %>. Any valid Java code is allowed to be used in this tag.
Scriptlets generally do not contribute directly to the visual output provided by the
servlet but perform other functions needed by the JSP in order to fulfil its purpose.
[Hall, 2000]
4. expressions: These are assessed and placed directly into the servlet’s output, generally
as HTML text. They take the following format <%= expression %> [Hall, 2000].
JSP comments, outside of the four previously mentioned tags, can be specified using the
following format <%-- JSP Comment --%>.
[Hall, 2000]
14
Developers are also free to create their own custom tag libraries specific to their applications.
JavaBeans are defined and discussed in terms of their interaction with JSPs in chapter 4,
section 4.6.
2.7 JavaMail
“The JavaMailTM API is an optional package (standard extension) for reading, composing, and
sending electronic messages” [jGuru-JavaMail, 2001].
2.8 Java Database Connectivity (JDBC)
The JDBC API enables Java programs to execute SQL statements. In this way Java
applications and programs can interact with SQL-accommodating databases. [Webopedia,
2001] Database vendors supplying Java compliant databases usually provide a vendorspecific JDBC driver conforming to the JDBC Java API [Eckel, 2000]. This driver can then
be used by the developer as middleware between the middle-tier and the database tier. JDBC
is the Java equivalent of Microsoft’s ODBC but unlike ODBC, it is language-dependent.
This chapter has shown that Java is ideally suited to e-commerce development. It provides
easily portable source code that can be compiled and run on a variety of platforms. Because of
Java’s platform independence, a Java system can easily be deployed in a variety of
environments. R.E.X. is a practical example of this. The prototype was coded using only Java
technologies, but the system was deployed and tested successfully in a Microsoft environment
using Windows 2000 and Microsoft Internet Explorer.
Furthermore, Java is a fully object-oriented language providing opportunity for component reuse in multiple systems and allowing easy maintenance of system components. The Java
development environment provides an attractive alternative to other closed and proprietary
systems. The technologies used specifically by R.E.X., and which will be discussed in greater
detail in the chapters that follow, include Java, JavaScript, Servlets, JSPs, JavaBeans,
JavaMail and JDBC.
15
Chapter 3: The
Front-end (First Tier)
The front-end is also referred to as the presentation tier. Its core function is to display data in
a manner that is “meaningful” to the user [Computing Alternatives, 2000]. It can transmit data
to the middle-tier as part of a request for a service. It is also able to receive and interpret a
response
from the server and present the resultant data to the client.
3.1 The Thin Client Approach
A thin client consists of a small client-side from which most, or all, of the data processing
work has been removed and allocated to the middle-tier. In contrast, a thick (or fat) client
does the bulk of data processing on the client-side and if needed, stores data on the serverside. [Webopedia, 2001].
Figure 3-1: Thin and Thick Client Components [Computing Alternatives, 2000]
The diagram pictured above shows the distinction between thin and thick clients in terms of
technologies used. A fat client would consist of things such as Windows applications or Java
applets running on the client-side while a thin client would consist mainly of components
such as HTML, scripting and perhaps DHTML (dynamic HTML) and CSS (Cascading Style
Sheets).
3.1.1 Thin Client vs. Thick Client
Using chapters one and two of Simon Ndinga’s Masters thesis [Ndinga, 2000], and the
author’s own knowledge and experience, the thick client front-end approach (using data
processing applets) will be contrasted with the thin client approach.
16
3.1.1.1 Performance
Thick client: Client’s will have to download an applet before they can interact with the
system. If a system is accessed mainly via the Internet then downloading even moderately
sized applets can be slow, unreliable and time-consuming, particularly when using modems
connected to the Internet via phone lines. This is not as noticeable on an intranet, but will be
on any network, internal or external, that is slow. Waiting and download failures can, and
often do, lead to client frustration.
The user will also have to have a JVM (Java Virtual Machine) installed and running on their
computer, as well as a Java compliant browser, before they can make use of a downloaded
applet.
Thin client: There is no major download time involved on the client-side as the bulk of
processing is handled by the middle-tier. All the client needs is a web browser and access to
the Internet. The client does not need to have a JVM implementation on their machine as all
services, requests and responses are serviced by the middle-tier.
3.1.1.2 Maintenance
Thick client: Any changes in the code or functionality of the system require that the applet
class be recompiled and the updated version be downloaded to the user’s machine. This is
particularly annoying if the applet is large or if code changes are made regularly. It further
complicates coding because the applet developer needs to be aware of the platforms and
software on which the clients will run the system so as to be able to ensure software
compatibility.
The server-side programmer needs to work in close collaboration with the front-end designer
to ensure that the applet reflects, both visually and functionally, what is required of the
system. The logical separation between the two layers, client and server, is not clear because
the client-side and server-side are so closely coupled. This overlapping of the two tiers makes
the system more complex to manage.
17
Thin client: The client-side designer’s main responsibility is the visual design of the frontend and they do not need to concern themselves with the business functions, business calls or
business code responsible for fulfilling client requests. They can simply leave space in their
HTML code so that the server-side programmer can insert functional calls. By liasing with the
server-side developer, the front-end designer can easily ascertain what visual aspects (such as
buttons and menus) are required to access the server-side functions and incorporate them in
the front-end HTML development.
The interface of a thin client is not necessarily as rich and versatile as that of a thick client due
to the fact that any code on the client-side is kept to a minimum. This visual deficit is largely
surmountable through the use of technologies such as DHTML, CSS etc. which provide
richer, thin client front-end visual functionality.
3.1.1.3 Resource Requirements
Thick client: The user needs a Java Virtual Machine implementation running on their
machine in order to use the system. Since a lot of the data processing is done on the front-end
each process needs processor time and resources in order to fulfil its function.
Thin client: The thin client needs very little client-side resources in order to function
(essentially only a web browser, Internet connection and the operating system resources to
maintain these two). This is particularly good news for users accessing the system via the
Internet where networks, particularly in South Africa, tend to be slow. The middle-tier
manages business logic and data processing, usually on a separate machine, and serves the
results of client-side requests as content back to the web-browser.
A thin client was chosen for the R.E.X. front-end. This is because R.E.X. is accessed
predominantly via the Internet or, on campus, the Rhodes intranet. The system will be used
occasionally by registered users and should be convenient, transparent, quick and easy to use.
Downloading an applet or doing processor intensive work on the client-side would defeat the
convenience provided by the R.E.X. system.
18
3.1.2 Applets vs. Form Elements
The author had to decide in what form to provide the thin client front-end. The two options
considered were:
1. Applets: In the context of a thin client, an applet would provide the front-end to a
servlet, not fulfil the function of a servlet. It would only be responsible for:
- the collection of data from the user
- the transmission of this data to a servlet as a service request
- the display of the servlet’s response
2. HTML Form elements: Form elements are objects like text boxes, text areas (or
memos), selection lists and combination boxes, and buttons. They are created using
static HTML tags in web pages and facilitate user interaction. Users can enter data
into forms as well as view data in forms. An example of an HTML form is given
below using the R.E.X. login screen component. A user would fill in both the
username and password and then click on the login button. The data would then be
passed to a servlet or JSP for processing.
Figure 3-2: HTML Form Elements Example
The author decided to use form elements on the client-side for the following reasons:

They offer interface data collection controls (forms). These forms are straightforward
to use and can reliably transmit provided data to servlets or JSPs.

Forms are simple and require considerably less effort to create, use and maintain than
applets.
[Hall, 2000]
19
3.2 Technologies Used in the R.E.X. Front-end
3.2.1 Browser
All implementation and testing of R.E.X. was done using Microsoft Internet Explorer
versions 5.5 and 6.0.26. The front-end HTML and middle-tier JavaServer Pages were all
created and coded by the author using Microsoft FrontPage 2000. R.E.X. will work with all
popular browsers, but the way in which the pages are interpreted visually may vary markedly
due to the fact that Microsoft FrontPage and Internet Explorer were used exclusively for
front-end design, implementation and testing.
3.2.2 JavaScript
JavaScript is used only on the front-end of the system as a client-side script. A client-side
script is one which executes only on the client’s machine. JavaScript’s primary aim is to “add
interactivity” to web pages [Thau, 2000]. R.E.X. makes use of JavaScript almost exclusively
“to validate user inputs entered on HTML forms” [Morrison and Morrison, 2000].
20
The following JavaScript characteristics are important to the implementation of the R.E.X.
prototype and contributed to its choice as R.E.X.’s front-end scripting language:
1. It cannot communicate with servers: JavaScript functions solely within the web
browser. This makes it more suited to handling interactive web pages and doing clientside form validation. The JavaScript code does not need to communicate with any
other server-side resource in order to verify the format of information provided. It can
check that required fields are filled in, that dates have been specified correctly, that email addresses have the correct format etc. R.E.X. also makes use of JavaScript for
DHTML content. The date feature at the top right hand corner of the screen is
produced using JavaScript. Every time a user loads the R.E.X. main page the
JavaScript function determines what the current date is on the server and displays it
for the user’s benefit. JavaScript provides security in that it is restricted in terms of its
communication capabilities. So, the less it can do, the less it can be used by malicious
individuals to do damage with.
2. JavaScript functions “differently in different browsers”: Thau, 2000 notes that the
most frustrating problem with JavaScript is the fact that it operates differently in
different browsers. The core functionality provided by JavaScript is the same in all
browsers that support it but fancier features (such as DHTML) can be visually quite
different depending on the browser used. If a developer is creating a system that must
be supported by a variety of browsers, he or she needs to make sure that they cater for
the different ways in which different browsers support JavaScript to ensure that the
front-end looks and acts as it should. The author did not design or implement R.E.X.
to be a perfectly browser portable system, and hence did not spend time JavaScript
coding for a variety of browsers. Microsoft products were used in the deployment of
the system specifically to show that Java is not bound by a particular platform.
[Thau, 2000]
21
JavaScript is imbedded in HTML files between specification tags.
The following code
segment illustrates the use of JavaScript (in bold) and how it is specified in an HTML file:
<html>
<head>
<SCRIPT LANGUAGE="JavaScript">
<!-var theScriptName = "JavaScript";
function theScript()
{
return theScriptName;
}
// End -->
</script>
</head>
<body>
<font face = Courier New>
<script language = "JavaScript">
<!-- hide from browsers that don’t understand JavaScript
//Write a message
document.writeln("<b><font size=1><font color=black> This
printed using " + theScript());
//-->
</script>
</body>
</html>
sentence
was
Figure 3-3: JavaScript Example
JavaScript functions are generally declared in the head section of an HTML page. These
functions can then be called from anywhere within the file as long as the JavaScript is
specified between the script language tags. The above script simply writes a line to the
HTML page by using the user declared function theScript(). This basic example illustrates
the use of JavaScript. Form validation is done using a similar format, but user defined
validation functions are called once the user clicks on a button to submit their information.
22
Using JavaScript for form validation on the client-side has important performance benefits
which the author will discuss in section 3.3.2 “Performance” of this chapter. The other place
in which a three-tiered e-commerce system could have data validation, is on the server-side.
Server-side data validation ensures that the data received by the server, whether via an HTML
request in a web browser, or a command line posting, is valid and secure [Capili, 1999].
3.3 Front-end Features
3.3.1 Design
R.E.X. was designed to be simple and intuitive. Screens are standardised and make use of
similar form based components. By using an uncomplicated design, the author ensured that
the management of the visual and user interaction components of the system could be
managed more than adequately by a single developer.
3.3.2 Performance
A lot of data validation on the Internet is done predominantly by the server-side of a system.
This means that when a user clicks on say, a submit button, their filled-in information is first
sent across the Internet to the server-side, which looks at the data, validates it and responds to
the user according to whether the validation was successful or not. If a user has not filled the
form in correctly, they have to wait for their data to be sent to the server and checked. If the
server detects a problem, it sends a message back telling the user that they have not filled in
the form correctly and should complete the required details properly before resubmitting. This
is particularly frustrating with large forms on the Internet. By using JavaScript, time wasted
waiting and the ensuing frustration can be avoided as data, and data format, is validated on the
client-side before being transmitted for processing on the server-side.
3.3.3 Maintenance
The front-end user interaction component of the system is easily maintained with the use of a
web authoring tool such as Microsoft FrontPage 2000 or Macromedia® Dreamweaver®,
specifically designed for just such a task. Alternatively, the developer can make use of a text
editor (available at very little cost) to edit both HTML files and JSPs.
23
Chapter 4: Business-Application
Logic (Middle-Tier)
4.1 The Functionality and Responsibilities of the Middle-Tier
As previously stated, the middle-tier consists of server-side business-application logic
components.
These middle-tier objects are responsible for:

receiving requests and data from the front-end

interpreting these requests

acting according to the interpretation of requests

interacting with the database tier if necessary

processing and returning results in the form of a response to the front-end
presentation layer
[Computing Alternatives, 2000]
There are two main types of servers that can reside in the middle tier. A web server and/or an
application server. The original definition of a web server was “a computer that delivers
(serves up) web pages” [Webopedia, 2001]. At its core, a web server is simply a software
program that listens on a port for requests for web pages. When requests are received the web
server serves the requested web pages. An application server on the other hand, is a program
that sits between the front-end and back-end of a system and takes care of all “application
operations between users” and the back-end
“applications or databases”. They are
specifically used “for complex transaction-based applications”. [Webopedia, 2001]
Since the R.E.X. middle tier both serves pages and services requests, the author had to decide
whether to use a web server, an application server, or both. The author decided that the best
choice for R.E.X. is a single web server, without an application server. The reasons for this
choice are as follows [Gupta, 2001]:

Web servers are primarily geared towards the display of data (serving of dynamically
generated data). One of the primary functions of an on-line auction site is to display
dynamic data such as available products, current bids etc. The use of a web server
supports this function.
24

The distinction between application servers and web servers has become increasingly
blurred as the e-commerce function evolves into different areas and aims to reach a
wider customer base. Most packages on the market (whether application server or
web server) now provide additional functions beyond their basic services. So, some
web servers now provide certain application server functions and some application
servers now provide certain web server functions.

R.E.X. is a small to medium sized system. Adding another server (that is, an
application server) brings unnecessary complexity to a system of this size. It’s another
server that needs to be managed. This increased complexity would further complicate
both the maintenance and administration of the system which, because of the system’s
size, needs to be minimised so as to be easily administered/maintained by a single
person.
In view of the above discussion, the iPlanet FastTrack web server was selected as it more than
adequately meets both the presentation and application needs of the R.E.X. system. FastTrack
will be discussed in more detail in section 4.2.2 of this chapter.
4.1.1 Session Tracking
Another important function of the middle-tier, particularly in a system such as R.E.X. which
needs to keep track of user accounts and user logins, is session tracking. Hall, 2000 in his
book “Core Servlets and JavaServer Pages” devotes a whole chapter to session tracking in ecommerce. Most of the following section comes from information found in his discussion of
session tracking. Other sources used here will be referenced specifically where appropriate.
25
The Hypertext Transfer Protocol (HTTP) is “stateless”. Every time a client requests a page
from a web server, a separate connection is established to the web server.
Contextual
information appropriate to the request, or involved in a session composed of related requests,
for example, user or shopping cart information in the case of on-line retail etc., is not
automatically maintained by the web server.
This deficiency in contextual information
support poses a number of problems. For example, if a client using R.E.X. logs in to their
account and proceeds to auction an item, bid on other items and change their user information
in a single logged-in session, the participating server-side objects need to know, for all pages,
while the user is logged in, which user is logged in. The server-side objects need to know
who is logged in so that they can determine things like- who placed a bid, who changed their
user information, who is eligible to bid on what etc.
There are four standard approaches to session tracking: cookies, Uniform Resource Locator
(URL)-rewriting, hidden form fields and the Java Session API for use specifically with servlet
technology.
4.1.1.1 Cookies
Cookies “are little bits of information a site leaves on the hard drive of visitors” [Thau, 2000].
For example, a cookie can store information about a client’s shopping session, login name,
last time logged in etc. Every successive request made by the user would then require that
the server inspects the current session and uses this to gather user and session specific
information as needed to fulfil the requests made. Cookies can be used with a specific session
identifier which uniquely identifies a particular session.
Cookies have certain limitations which need to be dealt with by the programmer:

The system needs to be able to extract the appropriate cookie, with the specific session
identifier, from the possibly many other cookies that may be stored on the user’s
machine.

A suitable expiration time needs to be set. A cookie should not be allowed to exist
indefinitely. If a client session has been inactive for more than a couple of hours, then
the session should be terminated and reset.

A unique session identifier needs to be generated for each session to distinguish it
from other sessions.
26

Many users disable cookies in their web browsers because of certain valid, and
supposed, privacy issues. This is the main reason why using cookies alone to support
sessions is not always a wise decision.
4.1.1.2 URL-rewriting
This involves the appending of a session specific identifier to every URL requested by the
client-side during a session.
http://theHost/thePath/theFile.html?thisSessionid=1234
This example shows a requested URL with a unique session identifier appended as
thisSessionid=1234.
URL-rewriting is a good session tracking technique and works even if
a user’s browser does not support cookies. It does, however, share the other disadvantages of
cookies, namely that middle-tier processes have a lot of easy but monotonous session
processing to do using the session identifier provided by URL rewriting. Furthermore, the
programmer needs to conscientiously ensure that every URL referencing the system’s site, or
used in the session, has the appropriate session identifier appended. URLs which are missing
needed appended information, imply that information specific to that session cannot be
looked up, and so, the session is in effect, lost.
4.1.1.3 The Session Tracking API
Java developers wanting to implement session tracking with servlets used in the
implementation of a system can easily utilise the session capabilities inherent in servlets.
The HttpSession API is an interface which sits on top of URL-rewriting and cookies. Each
request automatically has access to an associated HttpSession object. If a browser does not
support cookies, the servlet will automatically make use of URL-rewriting. The developer
does not “have to explicitly manipulate cookies or information appended to the URL, and is
given a convenient place to store arbitrary objects that are associated with each session”.
Making use of sessions in servlets is easy and involves transparent methods which allow the
programmer to do the following:

examine the current request’s associated session object

create a “new session object” when needed

find information relevant to a session

save “information in a session”

“discard completed or abandoned sessions”
27
4.1.1.4 Hidden Form Fields
R.E.X. predominantly makes use of HTML form elements for client interaction. Session
handling in R.E.X. is therefore done with the use of both hidden and visible form fields. The
most commonly hidden form field in R.E.X., is one which lists the username of the logged-in
client. Hidden form fields have the following HTML format:
<input type="hidden" name="userName" value="<%=User.getUsername()%>">
The above line of HTML embeds a hidden field, listing the username of the person currently
logged in, in the web page. The value of this hidden field is determined using a method call
on a JSP declared variable- User. User is a type of developer-defined JavaBean which knows
about a user and his or her associated information.
A hidden form field’s name and value are included in the information which is transmitted
when the form is submitted. This hidden information can then be used by the page that is
requested, when the form is submitted, to maintain the session.
Hidden form fields are only useful if every page in which they are used is dynamically
created. Every page in R.E.X. that handles logged-in users is a dynamically generated JSP
and makes use of hidden form fields to maintain a specific session from page to page.
4.2 Technologies Used in the R.E.X. Middle-Tier
4.2.1 The Web Server
The rapid growth of the Internet has ensured that there are numerous web servers available on
the market. Some are free while others are accompanied by a hefty price tag. It is up to the
individual developer or business to choose its web server in terms of:

The purpose (and functions) of the site and what technologies must be supported by it.

The traffic expected by the site (that is, how many people the web server must be able
to serve efficiently).

How to meet the above two requirements in terms of the available budget.
[Hughes and Birznieks, 2001]
28
The author wanted to use a free web server which has Java support. The two main and well
supported web servers looked at for use in this project were:

iPlanet’s FastTrack web server: a “free Web server with built-in support for Java”
[FastTrack Overview, 2001]

Apache Tomcat: “Tomcat is the servlet container that is used in the official
Reference Implementation for the Java Servlet and JavaServer Pages technologies”
[Tomcat, 2001]. Tomcat is used in conjunction with the Apache web server.
Although both products are free, and well documented, the author decided to use iPlanet’s
FastTrack web server as a case study for the deployment of the R.E.X. prototype. The main
motivation behind this choice was the fact that this server offers “built-in” support for Java
technologies. Apache’s Tomcat on the other hand is a servlet container that can be used in
conjunction with an Apache web server. It is effectively an add-on which makes the server
Java supporting and Java compliant. Because one of the main aims of this project was the
investigation of Java related technologies, the author decided to use a web server that was
inherently Java compliant.
R.E.X. makes frequent use of JSPs. The iPlanet FastTrack web server provides the support
necessary for both servlets and JSPs. In order to use JSPs with the web server, the developer
needs to specify the location of the Java Development Kit (JDK). Once the web server knows
where the JDK is located it is able to access it in order to translate requested JSPs into servlets
as and when necessary. Once the class-path is specified correctly in the web server’s
configuration, FastTrack handles JSP management and translation transparently without
involving the developer.
4.2.2 iPlanet FastTrack Web Server
The iPlanet FastTrack web server was developed by the Sun Netscape alliance. It’s free and
comes with detailed downloadable documentation. FastTrack is primarily used:

by developers creating and testing web applications before full-scale deployment

for low traffic site deployment
[FastTrack Overview, 2001]
29
The following table lists some of the advantages and disadvantages of using FastTrack as
highlighted in the supporting documentation [FastTrack Docs, 2001]:
Advantages










Free
Thorough Documentation
Supports most Java Technologies
Servlets 2.2
JSP 1.1
Plugable JVM
JDK 1.2 (or higher)
JDBC 2.0
Runs under MS Windows
Web application deployment


Disadvantages
Primarily for development and testing
stage of web applications
Limited performance (limited to single
process and only 5 threads)
Table 4-1: Advantages and Disadvantages of iPlanet FastTrack Web Server
It is clear from the above advantages that the iPlanet FastTrack web server supports all of the
technologies under investigation in this report. Furthermore, as the practical implementation
of R.E.X. is a prototype system, the web server does not need to be able to support multiple
user access. This means that the performance limitations which would be detrimental to a
fully implemented deployed site, fall outside the scope of this report. The FastTrack web
server is more than adequately suited to this project as it is specifically designed to be an
application for testing sites for future deployment.
4.3 The Advantages of Servlets over Common Gateway Interface
(CGI)
Although the author admits to being biased towards Java technologies in an e-commerce
environment, the following section will illustrate that this bias is not without good reason.
CGI programs are used to receive data from a requesting client, process that data and send a
response back to the client. Data transmitted in this way must be consistent with the CGI
specification. CGI programs can be written in a variety of languages for example, Java,
PERL, Visual Basic or C [Webopedia, 2001]. Servlets are similarly designed to receive
requests (with data), process the requests and return the results to the client as a response but
they are written exclusively in Java.
30
Servlets have six major advantages over their CGI counterparts and these are [Hall, 2000]:
1. Efficiency: For every CGI program request, a new process is started. This means that
even if the CGI program is small, the performance cost to the server, and associated
with starting a new process, can “cause unacceptable server latency for high volume
web sites” [Hogarth, 2001]. Not so with servlets. When running, the JVM handles
each request for a particular instantiated servlet by providing a low resource
demanding Java thread to service that request instead of spawning an entirely new
process. For example, if N requests were made for a servlet, the JVM would provide N
threads from a “single copy of the servlet class” [Hall, 2000]. A CGI program which
is requested by N clients would create, and load, N new processes into memory.
2. Convenience: Servlets have inherent support for the automatic “parsing and decoding
[of] HTML form data, reading and setting HTTP headers, handling cookies, tracking
sessions” etc. [Hall, 2000] Since the servlet API already supports these functions,
there is no need to go and monotonously program them into a CGI program. CGI can
be written in many different languages, but a Java developer convinced of the
effectiveness and reliability of object oriented Java, developing a site using Java
technologies, would probably not be interested in suddenly writing server-side
programs in other languages such as PERL and C++. [Hall, 2000]
3. Power: Servlets can communicate easily and directly with the web server. CGI
programs cannot do so except through a server-specific API. Servlets can also share
data and work together to more effectively fulfil server-side business functions and to
support session tracking. [Hall, 2000]
4. Portability: Servlets are written in Java and in accordance with the standard Servlet
API. This enables servlets that are written for iPlanet FastTrack web server to function
practically unchanged on Apache Tomcat. Furthermore, servlets “are supported
directly or by a plug-in on virtually every major web server” [Hall, 2000]. This
platform independence caters to a wider market of developers and users in the
heterogeneous Internet environment. CGI programs, however, are usually “platform
dependent”. Even languages such as PERL, which has support on a variety of
platforms, may not port uniformly “to all platforms” [Hogarth, 2001].
31
5. Security: The major security vulnerability in CGI programs is the fact that they are
often run by “general-purpose operating system shells”
[Hall, 2000].
The CGI
developer must therefore implement filtering rules on characters used by the CGI
program so that special characters such as semicolons and back-quotes are not used
maliciously to perform damaging actions within the shell. CGI programs written in
languages such as C and C++ have the added disadvantage of not doing array
checking. A developer may declare a ten element array and then legally assign a value
to the hundredth element which for all he knows is some random point anywhere in
memory. This invites “deliberate or accidental buffer overflow attacks” [Hall, 2000]
such as the recent Code-Red virus which has been wreaking havoc with web servers
vulnerable to this type of attack [Carnegie, 2001].
6.
Affordability: Adding servlet support to a web server, either in the form of plug-ins
or independent programming, is relatively easy and inexpensive.
CGI support
alternatives, however, often require a “significant initial investment” for the purchase
of “a proprietary package” [Hall, 2000].
Because JavaServer Pages are built on top of the servlet API, they too have the same
advantages as servlets over CGI programs.
4.4 The Advantages of JavaServer Pages
JSPs have certain advantages over other technologies used for similarly mixed static and
dynamic content generation purposes.
4.4.1 Over ASP
JSPs closest competitor is Microsoft’s Active Server Page technology. JSPs have two distinct
advantages over ASP:
1. The dynamic components of JSP pages are written in Java, “not VBScript or another
ASP-specific language”. This means that JSPs are more versatile and of greater use in
applications which “require reusable components”, than ASPs. [Hall, 2000]
2. JSPs using “an open approach” [JSP_ASP, 2001] are platform-independent and so are
portable to other operating systems. ASPs rely heavily on Microsoft technologies such
as Windows NT/2000. [Hall, 2000]
32
4.4.2 Over PHP
PHP Hypertext Pre-processor (PHP) is an open-source, free scripting language which is
embedded in HTML and used in a similar way to JSPs. JSPs, however, also have two major
advantages over PHP:
1. The dynamic portion of JSPs is written in Java, and thus is more versatile than PHP
for the same reasons as listed previously in section 4.4.1.
2. A developer using JSPs probably already knows Java and its extensive APIs for
network support, “database access, distributed objects” etc. and so can immediately
begin coding the dynamic parts of JSPs whereas using PHP entails the learning and
understanding of an totally “new language”. [Hall, 2000]
4.4.3 Over JavaScript
JavaScript, like JSPs, is also used to generate dynamic content in web pages. Client-side
JavaScript, however, is processed solely on the client-side and requires that the client use a
JavaScript supporting browser [Tsang and Cannings, 2000]. JavaScript has another distinct
disadvantage in that it cannot access “server-side resources” such as a database or server-side
program. This makes JavaScript obsolete as an alternative to JSPs as most e-commerce JSPs
are used specifically to access databases and service client-side requests. Furthermore, Java is
also “more powerful, flexible, reliable, and portable” than JavaScript [Hall, 2000]
4.4.4 Over Static HTML
Standard HTML cannot contain dynamically generated components. So, in terms of
interacting with the user and user specified data, “the usefulness of static HTML has run its
course” [Tremblett, 1999]. A static web page cannot produce content which is based on client
input or “server-side data sources” [Hall, 2000]. The simplicity of using JSP tags makes
dynamic content generation easy, achievable and maintainable.
Using JavaServer pages is convenient and easy but they have one major disadvantage.
Because JSPs are dynamically translated into their relevant servlet counter parts, syntax and
compilation errors will only be apparent once the page is requested [Hall, 2000]. This
complicates debugging and testing. The author debugged JSPs by using the web server’s
error log and JSP error pages.
33
4.5 Servlets and JavaServer Pages
At this point, the author wishes to state that the use of servlets and JavaServer Pages
practically entails, and offers, much more than the general overview provided in the body of
this report. During the implementation of R.E.X. the author learnt how to use the major
functionalities provided by servlets, JavaServer Pages and JavaBeans. These technologies
were exploited to produce an efficient and working prototype. The object of discussing these
technologies in this report is to investigate their suitability and comparability with similar
technologies in the development of a system such as R.E.X. It has not been the author’s
intention to explicitly provide any sort of written Servlet/JSP coding tutorial or workshop.
4.5.1 Servlets vs. JavaServer Pages
JSP technology is built on the Servlet API. So, conceptually and practically, a developer
could implement exactly the same capabilities in either a servlet or a JSP. JSPs are also
translated into servlets automatically and transparently, without developer intervention, by the
web server. A servlet on the other hand needs to be translated into a class by the developer
using a Java compiler such as javac.
Servlets are better suited to doing processing intensive work (such as maintaining a
database) and little presentation work (in terms of multiple, monotonously coded println
statements to provide content to the client’s browser for visual display) [Thomas, 2001]. The
beauty of JSPs is that static HTML content can be kept separate from the dynamically
generated content. It is much easier to write and maintain static HTML than having to filter
through hundreds of lines of println statements in a servlet. Because of the clear distinction
between the presentation layer and dynamic content generation, different developers can work
on the different components separately. Web design experts can use the tools they are familiar
with to build the site visually and simply leave spaces for the server-side programmers to
insert JSP tags and code. This is especially useful in larger, more complex systems. [Hall,
2000]
34
4.5.2 Using Servlets and JavaServer Pages Together
It is possible to successfully integrate the usage of servlets and JSPs in the following way:

Allow a servlet to take care of the initial client request by reading parameters provided
and any cookie or session specific information needed to service the request.

The servlet then proceeds to handle the computationally intensive processing work of
the request such as database queries and updates.

The servlet can then store the data resulting from the processing work it has performed
in a JSP accessible JavaBean (see section 4.6).

Once the servlet has finished with the request it can forward the response to the
appropriate JSP page which can then easily present the results visually.

The appropriate JSP page extracts the dynamically produced results from the
JavaBean and displays these as content combined with static HTML.
[Hall, 2000]
The above points show that servlets and JSPs can be used together effectively. Servlets
facilitate “convenient management of events and program flow” but provide “cumbersome
ability to generate responses”. On the other hand JSPs provide “excellent definition of
response pages” [Brown et al, 2001] in terms of rendering presentation and visual
components [Thomas, 2001].
4.6 JavaServer Pages and JavaBeans
A JavaBean is an object used to “encapsulate” a function’s “methods and variables”. It
provides “a public interface” that is accessed by developers “from the JavaServer Pages”
within which they are used [Allamaraju et al, 2001].
In order for a class to be a bean it must meet the following requirements [Hall, 2000]:
1. Have a constructor which takes no arguments.
2. Have no publicly declared instance variables. All instance variables in a JavaBean
class must be declared with a private access modifier.
3. Accessor and setter operations must have methods that take the following format:
- getXxx (or isXxx): to get the values stored in instance variables.
- setXxx: to set the values stored in instance variables.
(where Xxx is replaced with the method or instance variable name)
35
JavaBeans can be used in conjunction with JavaServer Pages to do the application businesslogic side processing of requests [Sun JSP, 2001]. They are commonly used to connect to a
database, execute queries and/or updates and then store the results in instance variables which
are accessible by the JSP in which a JavaBean object is created.
The usage of a JavaBean is perhaps best illustrated with an example. In R.E.X., the author
makes use of two types of JavaBeans. User information beans and auction item beans. The
following description illustrates the use of the UserInfoBean.class in a JSP.
A registered user can log in by providing their username and password. Once they click on the
submit button, their username and password are posted to the Login.jsp file. This JSP is then
responsible for verifying the user’s login details and, provided these are correct, establishing a
session according to the client’s username. The client is then presented with the R.E.X. menu.
This is done in the following way:
<jsp:useBean id="UserBean" scope="page" class="rex.beans.UserInfoBean"/>
This JSP line is responsible for the creation of an instance of the UserInfoBean class. This
line means “instantiate an object of type [rex.beans.UserInfoBean] and bind it to a variable
with the name specified by id [UserBean]” [Hall, 2000]. This line can be thought of as
conceptually representing a variable declaration such as:
<% rex.beans.UserInfoBean UserBean = new rex.beans.UserInfoBean(); %>
The fields presented above, in the first statement, are [Hall, 2000]:
jsp:useBean:
id:
This action allows the developer to load a bean for use in the JSP page.
The identifier associated with this bean instance.
scope:
A bean is not bound simply by the page in which it is declared but can be shared
through the scope declaration. If a user specifies the scope of the bean, then that bean
instance can survive and be used by the system for the duration applicable to the specified
scope. There are four possible scope values:
1. page: this is the default value when the scope attribute is not specified. A bean which
has page scope only exists for the length of the current request (that is, for a single
page).
2. application: a bean with this scope will be bound to the local variable name which was
used to declare it but will be available for use by all “servlets in the same Web
application” [Hall, 2000]. It can therefore survive beyond a single page/request.
36
3. session: this means that the bean will be stored in the HttpSession object linked to
the current request.
4. request: this is a slightly varied alternative to page scope.
class:
Is the physical class from which the JavaBean object is instantiated.
All beans used by R.E.X. have been given page scope and so are predominantly used in
setting instance variable values using the setXxx methods and in returning these values using
the getXxx methods. Typically, the UserInfoBean uses the provided username to determine
which user is logged in. If the client’s identification is verified (using username and
password) by the bean’s connection to the database in the Login.jsp, the bean can extract
all the user relevant details and store them in its instance variables. These details are then
accessible to the JSP through method calls on the bean.
If the developer wants to retrieve the userName property from the UserBean mentioned in the
above example, they can do so using one of two JSP methods:
1. <jsp:getProperty name=”UserBean” property=”userName”/> This is used to get
the value of the userName instance variable in the JavaBean.
2. <%=UserBean.getUsername()%> This method calls the getUsername() method
which is defined in the UserInfoBean class.
Similarly, if the developer wants to set the username in the in UserBean, they can do so using
one of two JSP methods.
1. <jsp:setProperty
name=”UserBean”
property=”userName”
value=”SomeName”/>
This is used to set the value of the username instance variable in the JavaBean.
2. <%=UserBean.setUsername(“SomeName”)%>
setUsername(String theName)
This
method
invokes
the
method which is defined in the UserInfoBean
class.
A developer can manipulate instance variable values using these methods as well as calling
other JavaBean methods defined in the specific classes to perform business-logic processing.
The author made use of the second methods specified for getting and setting instance variable
values.
37
The following extract illustrates the usage of JavaBeans in a simple JSP. Explanatory
comments are given in bold, UserInfoBean class methods are in italics.
<%
//set the UserBean username and password variable values by reading the
//user provided information in the request received from the client-side
UserBean.setPassword(request.getParameter("password").trim());
UserBean.setUsername(request.getParameter("userName").trim());
//Connect the userbean to the database
UserBean.connect();
//Attempt to login using received username and password
int loginResult = UserBean.getUserData();
//Disconnect userbean from the database
UserBean.disconnect();
switch (loginResult)
{ case (-1)://username doesn't exist
response.sendRedirect("http://csh15.cs.ru.ac.za/jsp/FailedLoginUsername.
html");//the username does not exist, redirect the user to this page
break;
...username and password checking continues
case 1://login successful, so display rest of JSP page
break;
}
%>
JavaBeans provide extremely simple, yet powerful, processing units on the server-side. The
author has found that conceptually and practically they are highly compatible with JSPs as
well as being easy to use and maintain. For these reasons the R.E.X. prototype makes
extensive use of JavaBeans in JSPs to facilitate user sessions.
4.7 JavaMail
The author implemented client interaction and notification of business events in two ways.
1. Via visual displays (in the form of interactive web pages).
2. Using e-mail.
The JavaMail API offers a set of “abstract classes that define classes and interfaces common
across general mail systems” [Allamaraju et al, 2001]. Sending and receiving e-mail using a
desktop mail client (for example, Microsoft’s Outlook Express) appears deceivingly simple.
Programmatically, however, it is a complicated process requiring the use of a variety of mail
protocols (usually one protocol for sending and one or more protocols for receiving). The
JavaMail API and its classes and methods handle most of the low-level protocol dependent
mail issues transparently allowing the developer to easily implement the sending and
receiving of e-mail.
38
The JavaMail API employs two categories of protocol [Allamaraju et al, 2001]:
1. transport: this is used for sending messages to their intended address(es). For
example, the Simple Mail Transport Protocol (SMTP).
2. store: this is used for message retrieval. For example, Internet Message Access
Protocol (IMAP).
In R.E.X. the author has provided a mail sending utility, the REXmail.class, “based on
business events” [Allamaraju et al, 2001] which is utilised by other classes in the system in
order to send mail to R.E.X. clients. This utility makes use of the transport protocol in the
JavaMail API. Some examples of the use of the REXmail.class are in order to notify the user
of:

the registration of their user account

changes they have made to their user account information

goods that they have put on auction

bids made on goods they own

bids that they make on other users’ goods

goods on which they have been outbidded by other users

goods that have been sold
etc.
4.8 Middle-Tier Features
4.8.1 Design
Because the middle-tier handles all the core server-side business-logic processing, careful
thought must be put into the planning and design of server-side objects. Using an object
oriented Java approach encourages the developer to compartmentalise the functions provided
by the middle-tier. Each major function, distinct from other functions, is encapsulated in a
class or a process. For example, in R.E.X. there is:

a Registration class which takes care of registration

the UserInfoBean class which handles the user account

the AuctionGoodBean class which handles goods and bidding

REXmail
which manages e-mails sent by the system
39
4.8.2 Performance
A web server which handles a large number of clients needs to be able to service the requests
received from each client efficiently. One way of doing this, particularly in large systems, is
to implement a number of web servers (a form of load balancing) so that the client request
network load can be balanced evenly among the different web servers. A single web server,
servicing a large number of clients, tends to act as a bottle neck and significantly increases
access time as many requests try to be serviced simultaneously [Hughes and Birznieks, 2001].
Another way of increasing middle-tier performance is by using server-side objects effectively.
Both servlets and JSPs inherently use threads but they can be made even more efficient. Since
much of the server-side processing done by a three-tiered architecture involves interaction
with a database, improving this interaction would improve the speed and efficiency at which
requests could be serviced.
The most time consuming operation in database interaction is establishing a Connection to a
database (more on databases and connections in chapter 5, section 5.2). [Hall, 2000] This cost
to performance is rarely justifiable, especially when a connection is used only for a short time
[Allamaraju et al, 2001]. Servlets which make use of pre-existing connections to service
multiple requests, will greatly outperform servlets that have to create a new connection for
every request.
In Java, a connection to a database is an object. Objects, once created can be used and
manipulated repeatedly. It therefore makes sense to reuse a connection object for multiple
queries instead of creating a new object for each query. Out of this comes the idea of
“connection pooling: pre-allocating database connections and recycling them as clients
connect” [Hall, 2000]. A connection pool class can be implemented and used effectively by
server-side objects. Such a class needs to perform the following functions [Hall, 2000]:

Pre-allocate the initial programmer specified number of connections.

Control connections which are currently free and available for use.

Allocate free connections to requesting server-side objects and create new connections
if necessary, until the maximum programmer specified connection count is reached.

Wait for a free connection, if all are currently in use.

Once a client has finished with a connection, return it to the connection pool.

Close connections when needed.
40
The author implemented a connection pool class and tested it in the Registration servlet.
Servlets have an init() method which is called only when the servlet is loaded into memory.
It is in this method that the connection pool is created. Even on the local intranet, the
registration speed of a user using the Registration servlet utilising a connection pool was
noticeably faster than that of the Registration servlet which was not using a connection
pool.
A word of caution when using connection pools with servlets. The initial loading of a servlet
into memory (for example, when the servlet is accessed by a client for the first time and
loaded into the JVM) will be slow as the servlet creates the connection pool and the
connections for the connection pool. After the initial call to a servlet, other clients using that
same servlet instance will experience virtually instantaneous servicing of requests. [Hall,
2000] In the same way, the initial call to a JSP may be slow, if the JSP has not been translated
into a servlet yet or if an instance of the JSP servlet does not exist at the time of the request.
4.8.3 Maintenance
Maintaining server-side objects is achievable if the developer ensures that the objects are well
defined functionally. When objects start fulfilling services outside of their primary purpose,
functional distinctions between these objects become blurred. Debugging and streamlining
(making more efficient) these objects then becomes increasingly more complex. This is
discussed further in section 6.8 “Conclusions”.
41
4.8.4 Scalability of Business Side Objects
A good web site, with the potential of being used by multiple users, needs to be practically
scalable to cater for high-volume request traffic. A web site offering outstanding
technological services is not much good if it cannot fulfil every request for those services
successfully. [Fields and Kolb, 2001] The middle-tier, particularly the web server or web
servers, must be able to balance the request load from clients (see section 4.8.2.
“Performance” for details). Business objects must also be easily scalable. The scalability of
both servlets and JSPs is good because a single servlet instance in memory can manage
multiple threads to service multiple requests. CGI programs do not scale well at all. This is
because each request for a CGI program results in the creation of an entirely new process
which needs to be loaded into memory to be run [Hogarth, 2001].
The main limitation on the scalability provided by servlets and JSPs is “system memory”. A
portion of memory is allocated to the JVM. Within this portion of JVM allocated memory all
servlets and JSPs must be loaded and run. It thus follows that the smaller the size of that
portion of memory, the greater the strain on performance particularly in applications doing
processor intensive work such as database connection creation and so on. One solution to this
would be the provision of more main memory on the server-side and the allocation of a larger
portion of that memory to the JVM. [Fields and Kolb, 2001]
42
Chapter 5: The
Back-end (The Database Server)
5.1 The Services Provided by the Database Tier
The database server stores and maintains data required/used by the middle-tier. [Webopedia,
2001]. It is responsible for persistent data management. The middle-tier interacts with the
database server via the JDBC driver. The inclusion of this third tier further benefits the
system by bringing:

Added modularity to the system and thereby making it easier to adjust or replace a tier
without involving the other two tiers.

The separation of the application related functions from the database functions
simplifies the implementation of efficient load balancing amongst the tiers.
The database tier services middle-tier requests via the JDBC driver. These requests can query
and/or update the database.
5.1.1 The Relational SQL Database
This paragraph serves as a brief recap on relational databases. Relational databases are
composed of interrelated tables. A table is made up of rows which consist of a collection of
fields (columns) stored in that table. An example of a table might be a users table in which a
user’s name, e-mail address and telephone number are stored. Tables are related to each other
through common and/or shared fields.
The developer interacts with the database using SQL queries. In R.E.X. SQL statements are
executed through the JDBC driver.
5.1.2 Borland InterBase
The author has chosen to use Borland’s free open source InterBase 6.0.1 SQL server in this
tier for the following reasons:

It’s a freely available product

It comes with thorough documentation

It supports the Java technologies under investigation

It utilises the relational database model and SQL
43
A benefit of open source software is that it enables the entire development community
(national and international) to add to the development of a product by being able to customise
and modify source code and then share these modifications with others.
The following table is comprised from the official InterBase documentation [InterBase Docs,
2001] and lists (most important ones in bold) the features of, and technologies supported by,
InterBase in relation to this project:
Runs on both Windows and Unix platforms
ANSI SQL 92 (entry level) conformance and SQL compliance
UNICODE (universal character set)
JDBC® with InterClient™ for Java access
Internet socket communications over TCP/IP
Easy installation and maintenance
Small footprint (does not require large amounts of disk space) and self-tuning
Practical and easy to deploy for small or large systems
Multi-language support including Java
Table 5-1: InterBase Features
The InterBase Overview says that “Java and InterBase are a natural pair”, which is in keeping
with the scope of the project.
The author also considered using Microsoft Access as the relational database management
system. This choice, however, was rejected mainly for the following reasons:

Visual Basic is the main language supported and used by Access. This restriction is
not in keeping with the Java related technologies used in this project.

Access is not a free product.

Access is a “stand-alone desktop database for personal use, departmental use or for an
entire organization” [MS Access, 2001] with distributed networking capabilities
available as add-ons to the software, not as built-in features of the software. In
contrast to this, InterBase “makes networked access to a database as transparent to the
application as access to a local database” and has “distributed…support and access to
multiple databases…built into the architecture” [InterBase Features, 2001].
This
implies that InterBase is inherently more suitable to a distributed e-commerce
application than Microsoft Access.
44
5.2 JDBC as an Interface to the Database Tier
As previously mentioned, a JDBC driver is middleware which sits between the middle-tier
and the back-end of a system. Code written for services provided by the middle-tier access
the database back-end as needed through the JDBC driver.
JDBC is made up of “a set of classes and interfaces written in” Java. This API enables
developers to interact easily with any relational SQL database with a
vendor-specific
implementation of the JDBC API [Hamilton et al, 1997].
The table on the following page lists the core classes that make up the JDBC API and outlines
the use of each of these [JDBC API, 1999].
45
Use
Class/Component
Connection
A database connection is represented by a Connection object.
Connections incorporate both the SQL statements executed, as
well as the results returned, via them. An application can have a
single or multiple connections with either a particular database or
a variety of databases.
DriverManager
This class manages the drivers that are available to an application
and controls connection establishment between the appropriate
driver and a specified database.
Statement
A Statement object is created using an existing Connection. It
is used to execute SQL statements on the database and retrieve
any associated results. A SQL query can be formulated as a
String
and executed using one of the Statement interface
methods. There are three types of Statement
Statement,
Statement
PreparedStatement
and
objects:
CallableStatement.
is used for the execution of simple, parameterless
statements.
PreparedStatement
This is a sub-class of Statement and allows the developer to precompile statements and specify parameters at run-time.
CallableStatement
This is a sub-class of PreparedStatement and can be used to
“execute a call to a database stored procedure”
ResultSet
The results of an executed SQL statement are contained by this
object. It is essentially a set of rows reflecting the results of the
query, similar to a table of columns and rows. The results are
accessed through a variety of get methods that can be used on the
rows and columns in the ResultSet. Results are manipulated row
by row. To access the subsequent row, the .next() method is
used.
Table 5-2: The JDBC Package
46
5.2.1 Using JDBC
There are six simple steps that the developer needs to follow when querying a database. These
are typical to most JDBC using applications and are discussed briefly below [Hall, 2000].
1. “Load the JDBC Driver.” In this step, the developer must load the JDBC driver
applicable to the application and database. With InterBase this would be the
InterClient driver. This is done in a code block such as:
public static void loadInterClientDriver() {
try {
Class.forName("interbase.interclient.Driver").newInstance();
}catch(ClassNotFoundException e){
System.out.println("Class not found. " + e);
}
}
The above statement causes an instance of the driver to be made available, and
registered with, the JDBC driver manager.
2. Establish a Connection. This step is made up of two parts. Firstly, the connection
URL and properties detailing the database location and other pertinent information
(such as login username and password) needs to be defined. Secondly, this URL
definition is then used to establish a connection to the database. This is illustrated in
the following code extract:
//1) specify the URL- driver and location of database
String theUrl = "jdbc:interbase://localhost/D:/REXdb/REXDB.GDB";
//define database properties, username and password
java.util.Properties props = new java.util.Properties();
props.put("user", someUserName);
props.put("password", somePassword);
Connection con;
try {
//2) get connection using the Driver Manager
con = DriverManager.getConnection(theURL, props);
//do relevant error checking and exception handling here
}
3. “Create a statement object.” Statements are created using a connection object. The
statement can then be used to send SQL commands and queries through to the
database. A statement is created in the following way:
Statement statement = con.createStatement();
47
4. “Execute a query or update.” The two most commonly used SQL statement methods
are executeQuery (used for database queries such as SELECT) or executeUpdate
(database modifying commands such as UPDATE, INSERT or DELETE). Queries return
ResultSet
objects with the query results while updates return integers (int) with the
number of database rows affected (-1 if unsuccessful). An example of a query would
be something like:
String theQuery = “SELECT * FROM aTable”;
ResultSet theResults = statement.executeQuery(theQuery);
5. “Process the results.” ResultSets can be processed row by row using various
getXxx()
methods. R.E.X. makes use of the REXdbUtils and REXdbResults classes
to handle results processing and presentation. A note of caution when using ResultSets
is that the first column has an index of 1, not 0 as in Java arrays.
6. “Close the connection.” A Connection should be explicitly closed so that it can be
eligible for garbage collection immediately once it is no longer needed. This helps to
alleviate memory resource drain by objects no longer in use. Statements are also
managed by the JVM which will determine when they are eligible for garbage
collection but it is good programming practice that they too be closed explicitly once
not needed [Hamilton et al, 1997]. This is done in the following way:
//close a connection
con.close();
//close a statement so it doesn’t sit around doing nothing
statement.close();
In summary, the following figure gives an overall conceptual example of the interaction
between the middle and database tier via JDBC.
JDBC Driver
Middle-Tier
Business-Logic
Object
JDBC wrapped
SQL query
Database
JDBC wrapped
result set
Figure 5-1: JDBC Facilitated Communication
48
5.2.2 Statement vs. PreparedStatement
PreparedStatement
inherits all the functionality of the Statement class but implements its
own versions of executeQuery and executeUpdate which can take run-time specified
parameters or perform multiple queries with differing parameters. A Statement is used for
simple SQL statement execution of parameterless queries and updates. SQL used in R.E.X.
has been kept simple to minimise the complexity of the system, particularly under the
development of a single programmer. The Statement class is thus more than adequate in
executing SQL commands. [Hamilton et al, 1997]
5.3 Advantages and Disadvantages of using Pure JDBC
There are four different ways in which JDBC drivers can be used in database interaction.
They are [Poulton, 2001c]:

Type I: This implementation type involves the combined use of Java and native code.
The native code makes use of a basic query library to query or update the database. An
example of this is the ODBC-JDBC bridge in which the driver translates JDBC
specific calls into their equivalent ODBC calls and then sends this translation onto the
ODBC driver for database interaction.

Type II: This category of drivers again makes use of a combination of Java and native
code. The native code is database specific. This decreases the number of calls by one
as there is no bridge-like set-up involved as with Type I. The JDBC driver can
communicate directly with the vendor specific API.

Type III: These drivers are written exclusively in Java and access databases via a
“generic wire-protocol”. Drivers of this type are very rare mainly because they are
usually implemented by third parties. That is, a type III driver may be compatible with
a whole variety of databases, but may not have been implemented by any of the
vendors of these databases.

Type IV: This type of driver is a pure Java JDBC implementation but accesses a
database via that database’s vendor specific JDBC driver implementation. Major
database vendors (including InterBase) supply this type of driver with their software.
Each of these driver types has its own specific performance and implementation issues. The
driver chosen for R.E.X. is of type IV because this project covered an investigation into Java
related technologies in an e-commerce environment.
In such an environment, the most
commonly used JDBC driver is of type IV.
49
The main advantages of a type IV driver are:

It provides a platform independent database access tool. Once the application specific
Java code is written, it can be ported to any platform.

It takes advantage of all the benefits associated with Java, such as automated garbage
collection.

It is simple to deploy as there are no extra middleware components and libraries that
need to be installed in order to make it work.
The major disadvantage of using a type IV driver is that it is not the most efficient driver to
use in terms of database access and performance issues. Type II drivers out perform type IV
drivers because vendor specific native libraries are provided for, and specifically tuned to, the
database. JDBC interacts directly with a vendor specific database API while in type IV JDBC
interacts with a vendor specific implementation of the JDBC API.
[Poulton, 2001c]
5.4 Back-end Features
5.4.1 Design
When developing a small to medium scaled system, the prudent developer must aim to keep
the database table design, as well as the SQL queries and updates that will interact with this
design, simple. Simplicity combined with the effective use of SQL in database interaction
leads to a system that is fairly easy to implement, debug and maintain. During the
implementation of the R.E.X. prototype the author found that using explicit, detailed SQL
table creation statements (ones which specified primary keys, foreign keys and validation
rules) led to havoc when testing and perfecting communication between the middle-tier and
the back-end. Determining what was causing errors where was very difficult. The author then
simplified all SQL statements. Interaction between tables was achieved through the use of
simple SQL joins of common columns. The author could then make successful use of a
combination of these simple SQL statements and Java coded validation techniques to achieve
a viably working system.
50
5.4.2 Performance
InterBase supports multiple accesses in a distributed environment [InterBase Features, 2001].
This support combined with the use of approaches such as connection pooling, greatly
increase access time and performance in database communication. Re-using and recycling
objects, particularly middle-tier business-logic objects, makes for more efficient memory
management in the JVM as it does not have to handle more objects than it needs to. [Poulton,
2001a]
5.4.3 Maintenance
Again, the keyword here is to keep things simple. Keep redundant information in the database
to a minimum and keep tables tidy through the strategic use of simple SQL statements and
Java code. For example, use primary key and foreign key columns to link tables and only
store information that is absolutely necessary. The R.E.X. users information table holds all
the information related to users of the system. This information would not need to be repeated
in the auction goods table, it could simply be referenced via the unique username assigned to
each user. When a new user registers with the system, Java coded JDBC calls ascertain
whether or not a username is already in the database, if it is, the client is asked to choose a
new, unique username.
The use of utilities classes which contain methods that are used repeatedly by different
business functions, such as a database utilities class, significantly decreases code volume and
simplifies debugging. If problems arise, it is simply a matter of investigating the code within
the utilities class to determine what the problem is instead of having to look through every
single file making use of repeated code to determine in which file an error in syntax, program
logic or usage has been made.
51
Chapter 6: The
Practical Implementation of R.E.X.
6.1 The R.E.X. Architecture
1
Web Browser
e.g. MS Internet Explorer/Netscape
Internet
User Machine
HTML
Data Request
Web Server
e.g. iPlanet FastTrack Web Server
Data
Request
HTML
2
Server Side Technologies
e.g. Java/JSP/Servlets
JDBC (Java Database Connectivity)
Data/Query
Response
3
SQL Query
Database Server
e.g. Borland InterBase SQL Server
Logical separation of functions:
 Client-side
 Middleware/Communications component
 Database Server
Server Machine
all three components can be housed on a single machine, while still being logically
separated.
Figure 6-1: The R.E.X. Architecture (adapted from [Gupta, 2001])
52
Now that the author has lain a foundation for a small to medium-scaled Java based ecommerce system, the practical considerations and implementation issues of the R.E.X.
prototype can be discussed. At this point, the author wishes to acknowledge that she made
great use of both Hall, 2000 and Allamaraju et al, 2001 in the practical coding and
implementation of R.E.X.
Figure 1-1: “Three-tiered Client-Server Architecture” on page 4 of this report shows the highlevel abstract view of an e-commerce system. Figure 6-1, on the previous page, shows the
lower-level more detailed physical and logical layout of R.E.X which will be reviewed in the
following discussion.
6.1.1  Client-side (Remote User’s Computer)
The front-end of R.E.X. consists of an HTML form based GUI (Graphical User Interface).
The actual application/query and business-logic handling is done via the middle-tier.
Processing intensive work is farmed out from the client machine to the server machine and
results in a ‘thin’ client on the front-end.
The R.E.X. GUI has been implemented using:

HTML and HTML form-based components

JavaScript for form-based data validation

JavaServer Pages for dynamically generated user-specific content
The front-end of the system is accessed via a web browser. All significant testing and
implementation of the R.E.X. prototype has been done on, and specifically for use with,
Microsoft’s Internet Explorer. The R.E.X. prototype operates on most other well-known
browsers (for example, Netscape® [Netscape, 2001] and Opera [Opera, 2001]) but, as the
HTML and layout was done specifically for use on Microsoft Internet Explorer, the system
may not look or be interpreted visually in the same way by other browsers.
6.1.2  Middle-tier (Middleware/Communications)
This tier houses:

The iPlanet FastTrack web server

Server-side technologies (Java, JSP and Servlet capabilities)

The JDBC middleware driver facilitating access to, and communication with, the
database server
53
6.1.2.1 Business Logic
The registration of a new user is managed by a registration servlet which establishes a
connection to the R.E.X. database by requesting a connection from a connection pool class. If
the user registers successfully, this servlet utilises the JavaMail API to notify him or her of
this fact. All other user specific interactions are dealt with using a combination of static
HTML, JSPs and the utilities classes (discussed in section 6.3 “Implementation Benefits”).
6.1.3  Database Server
The R.E.X. database is housed in this tier of the system. R.E.X. makes use of three distinct
tables:
1. users: this table stores the user details.
2. goods: this table stores data about goods that have been put on auction by users. It is
linked to the users table with a foreign key- the username.
3. bids: this table stores all the bids that are made on goods that are currently on auction.
Once goods are sold the bids relating to these goods are deleted from this table. This
table is linked to the users and goods tables by two foreign keys- the goods code and
the username.
This following figure shows the structure of the relational tables involved in the R.E.X.
prototype. The tables are linked via a series of primary-foreign key relationships as shown by
the arrows between the tables and the field descriptions within the tables.
54
Users
user_code
first_name
last_name
pssword
email
contact_num
(primary key)
user’s first name
user’s last name
used for login to the user account
user’s e-mail address
contact number (optional)
Bids
user_code
bid_price
goods_code
the_date
(primary key = composite key of goods_code/bid_price/user_code)
code of user who has made the bid
price submitted by user for good
code of good for this bid
keeps track of the day on which the bid was made
Goods
goods_code
user_code
type_of
description
initial_price
current_bid
expires
bidding_open
Primary key
(primary key)
Code of user who has put the good on auction
e.g. book, furniture, other
user given description (text memo)
price owner wants for good
current highest bid
date by which bidding must end
YES/NO flag, bidding can only take place if this is open
Foreign Key
Figure 6-2: The R.E.X. Database Table Schema
6.2 The Interaction Between the Three Tiers
Users of the system interact with R.E.X. via a web browser over the Internet. Information or
services requested at the front-end of the system are passed to the middle-tier as requests.
The middle-tier receives a request and then decides how to respond according to the type of
request and the content of the request. The middle-tier sends information (generally visual
display data) back to the front-end as a response.
This communication is achieved using HTTP which defines how messages are configured and
conveyed [Webopedia, 2001] across the World Wide Web (WWW).
This protocol is
responsible for enabling and facilitating communication between a web browser and a web
server [Hughes and Birznieks, 2001].
55
All database data manipulation is accomplished with SQL. Using SQL with data is done in
one of two ways:
1. At the database- By making use of the Interactive SQL utility accessed through the
InterBase console, the developer can type in SQL statements and maintain the
database at the source.
2. Via the JDBC driver- By making use of Java SQL utilities in the R.E.X. classes,
JavaServer Pages, JavaBeans and Servlets, database queries and updates can be done
using standard Java APIs. The InterBase specific JDBC driver (InterClient) then
manages the interaction between the middle-tier and the back-end without the
programmer having to be aware of exactly how this communication is achieved.
Interactions flow linearly, tier by tier. For example, the front-end cannot speak directly to the
back-end or vice versa. The middle-tier can interact with both the front-end and the back-end
and enables the interaction between these two tiers via middleware.
By enforcing tier by tier communication, the functional distinction between the three tiers is
maintained. Every tier fulfils a specific function and communicates with other tiers in
accordance to this function. That is, the front-end handles user interaction and gathers data.
This data must then be transferred to the middle-tier where the appropriate business-logic
object can process it and pass the ensuing request to the database tier. The front-end cannot
interact directly with the database tier as this would defeat its primary purpose, interacting
with the user and business objects, not the database directly. Similarly, the database cannot
interact directly with the client as any responses made by the back-end must be issued in reply
to a request from the appropriate middle-tier business-logic object.
Although the three tiers are logically separated, there is some overlap between them. This can
be seen firstly, between the front-end and the middle-tier. The front-end presentation layer
depends on the output of the servlets and JSPs so although these objects reside in the middletier, they share in the task of front-end data presentation. A similar situation exists between
the middle-tier and database server. Server-side objects need to access the database and also
take care of some of the validation and interpretation of results gathered from the database.
The JDBC driver sits between the two layers and plays a part in both layers by facilitating this
interaction.
56
6.3 Implementation Benefits
The author decided during the design phase of the prototype to make use of distinct classes
and utilities. The utilities classes manage functions that are repeatedly used throughout the
system. So, instead of the developer having to re-code the same functions (for example,
establishing a database connection or retrieving an entire result set) he or she can simply make
use of the general functionalities provided in the utilities classes.
The main utilities classes are:
1. REXdbUtils.class
This class’ static methods manage [Hall, 2000]:
- loading the InterClient driver and registering it with the DriverManager
- defining the connection URL (to the specified R.E.X. database)
- establishing a connection
- executing database updates and queries
- finding specific records
- processing results
- closing connections
2. REXdbResults.class
This class works with the REXdbUtils.class. Its primary responsibility is to format
database result sets from queries into HTML tables appropriate for display to the
client. [Hall, 2000]
Its methods include:
- returning the number of rows in the result set
- returning the number of columns in the result set
- returning the column names
- returning specific rows of data
- adding rows to a data set
- formatting results as HTML tables
3. ServletUtils.class
This class incorporates some basic servlet utilities, the most significant of which is a
gotoPage
method which forwards a request from one servlet or JavaServer Page to
another servlet or JavaServer Page [Hall, 2000].
57
Other standard classes include:
1. HTMLPage.class
This class can be used in conjunction with servlets to simplify the creation of HTML
pages. It provides the preformatted tags common to most web pages and saves the
programmer having to hard-code these into the servlet’s response to a request.
2. REXmail.class and Recipient.class
These classes are used with the JSPs and servlets to simplify mail message creation
and the sending of mail. They are built on the JavaMail API.
3. ConnectionPool.class
As previously mentioned, the most time consuming process involved in database
interactions is the creation of a connection to the database [Hall, 2000]. This class in
R.E.X. is the practical implementation of the connection pool and its characteristics as
discussed in chapter 4.
6.3.1 JavaBeans and JavaServer Pages
The other main components in the programming of the system consisted of JavaBeans and
JavaServer Pages [Hall, 2000]. All the user specific utilities in the system are facilitated by
JSPs. These make use of the utilities classes, standard classes and beans. There are two main
beans used by the system:
1. UserInfoBean.class
As the name suggests, this bean is used to access and maintain information about a
specific user. It is also used in conjunction with hidden form fields for session
tracking by the system.
2. AuctionInfoBean.class
This bean serves a dual purpose. Firstly, it manages the information stored about a
specific good on auction, and secondly, it handles the bids made on that good.
Both these beans are responsible for, and used in, the majority of the dynamically generated
user specific content in R.E.X.
58
The author has found that the major advantages of using Java technologies in the
implementation of R.E.X. were:

The reusability afforded by fully object-orientated classes.

The way in which Java facilitates object-orientation and enables the developer to
keep the size of components manageable. The R.E.X. prototype consists of a
number of classes and functions which would have been highly difficult, if not
impossible, to program successfully as a large single module or program.
6.4 Implementation Problems
The author chose to use open source and free software products for the R.E.X.
implementation. The main benefit of this is obviously the low cost involved in acquiring
such software. Specific set-up issues of the R.E.X. system and associated software are
detailed in Appendix A- “Practical Set-Up of R.E.X. on Windows 2000”.
The main development resource problem encountered by the author was a shortage of memory
on her computer. The system was developed on a single machine which had to run the GUI
based web server, database server and JDBC driver as well as handle class development and
compilation. During testing these servers had to be repeatedly shut down and started up. The
system was able to perform all these tasks, but very slowly! The amount of time wasted in
simply waiting for the system to perform development tasks escalated rapidly during the
intensive implementation part of this project. This problem was successfully solved simply by
the addition of more memory. The extra memory greatly improved the system’s performance
during development.
The main implementation problems encountered were with the configuration of the system.
These problems were most noticeable when the author was trying to establish communication
between the three tiers.
59
6.4.1 Web Server Specific Problems
1. The author had some problems setting up the class paths correctly so that the server
would know where to find the JDK (Java Development Toolkit) in order to compile
JavaServer Pages into servlets. The on-line help provided with FastTrack did not go
into detailed discussion about how to configure the class paths and associated
parameters.
2. At first, the web server did not have access to all the classes used by components in
R.E.X. This was resolved by packaging all R.E.X. specific classes into rex,
rex.forms
and rex.beans packages and making sure that the main folder in which
these packages reside was accessible to the web server via the class path [Hall, 2000].
6.4.2 Database Server Specific Problems
1. The author’s main problem was with version conflicts when attempting to install the
InterBase Server and the InterClient JDBC driver. This was because the update
patched version of InterClient caused a version conflict when used with the open
source version of InterBase.
2. Because the author was unable to update the InterClient JDBC driver, by making use
of the update patch, changes had to be made in Java coded R.E.X. classes to
compensate for the loss of some functionality when using the previous version of
InterClient as the middleware layer.
Unlike InterBase, InterClient 1.6 does not
understand DATE SQL types, so the author had to store dates, such as bidding dates
and expiry dates, as strings. Conversion and manipulation of these dates were then
done in the middle-tier using business-logic objects.
6.5 Using the Prototype
Appendix A- “A Look at R.E.X.” gives screen dumps of the prototype in use and enables the
reader, albeit to a limited capacity, to visually experience the R.E.X. system.
It is logical that a system that is easy to use, and which looks appealing will be used. Just as a
system which is incomprehensible and visually unappealing, will not be used. The R.E.X.
prototype was designed for practical use and so the author had to consider human-computer
interaction issues when planning the interface of the system.
60
During the storyboarding and design phases of the R.E.X. prototype, the author concentrated
on the following human-computer interaction factors proposed by Shneiderman, 1998 (pages
80-81), as crucial visual factors to the success of a system:
1. “Consistency of data display” This entails ensuring that the visual display of data,
buttons, forms etc. is standardised. The screen dumps in Appendix A- “A Look at
R.E.X.” show that the same display properties/standards have been used throughout
the system. This means a user need only understand one standard interface layout
before they can use the system competently and comfortably.
2. “Efficient information assimilation by the user” The author attempted to make the
interface intuitive, with helpful hints and examples of data input formats (for example,
how to enter a date using the correct format) where appropriate. The user should be
able to, at a glance, understand what the system requires from them. All buttons are
accompanied by labels that clearly describe the function which they fulfil or perform.
3. “Minimal memory load on the user” The author has tried to ensure that the user is
not required to remember large amounts of detail between screens. For example, if the
user is putting a good on auction and the good name already exists, the user is
informed of this by a JavaServer Page that displays the other information the user has
already entered. The user can then simply change the good name without having to
remember and re-enter all the information pertinent to the new good.
4. “Compatibility of data display with data entry” This entails ensuring that data
entry screens and data display screens have a similar format so that users can
subconsciously form a connection between the two. If this compatibility is clear, it
avoids confusion and hesitancy on the part of the user. An example of this in R.E.X. is
the user information update screen. The actual user input screen is the same as the one
in which the user’s data is displayed.
6.6 Testing the Prototype
The middle-tier (business-logic) and the back-end (database tier) of the system were housed
physically on the same machine, while still being logically and functionally separated. The
client-side interaction with the system could take place on the same machine or on a remote
machine with Internet access.
61
Besides doing much personal testing, the author asked several friends to help with the testing
of the system. One was based in Johannesburg and the others in Grahamstown both on and
off campus.
The response to the
prototype was positive and minimal changes were made to the
implementation according to the constructive feedback provided. The prototype has proven to
be quite self-explanatory and easy to use. This is largely due to the standardised appearance
of all screens in the system and the fact that the author limited the functionality of the system.
R.E.X. provides the core functionality of an auction site, and these core functions have been
tested successfully. They are:

Registration of a new user

Login and Logout of a user account

The ability to update user information

Deletion of a user account

The ability to put a good on auction
A user can only bid on goods put on auction by other users. The system will then let
other users who have bid on that good know via e-mail that a bid higher than their
own has been placed and that they can bid again on the good if they wish.

A user can view:
o All bids that they have made on goods currently on auction
o All bids made on goods that they own and have put on auction

Once the expiry date for bidding on a user’s good has been reached, the owner of
that good can notify the user with the highest bid and arrange for the payment and
exchange of the good. The system will then e-mail all other bidders on that good
and let them know that the good has been sold.
The system communicates with the user in two equally important ways:
1. Via the interface- in the form of data displayed and visual confirmations.
2. Using e-mail.
62
6.7 Scalability
and
Practical
Full-scale
Implementation
Considerations of R.E.X.
In a full-scale implementation of R.E.X. the developer would need to cater for both client-side
form data validation and server-side data validation. Client-side JavaScript validation is only
effective on information that has been provided via a web browser. Information submitted via
command line actions would not be subject to JavaScript validation. Invalid data could only
be successfully and effectively picked up in this instance, by server-side validation.
Furthermore, there is “no guarantee that your JavaScript screens will catch everything. Users
might have old browsers or disabled JavaScript. Also, since many of the [JavaScript]
validations [used] only” verify that “something is input, [the system cannot tell] if the user
entered useful information or junk.” Therefore, once data is received as a request from the
client, it needs to be checked for a second time by the server to ensure its validity. [Capili,
1999]
The R.E.X. prototype was not designed to support a multitude of users.
The iPlanet
FastTrack web server, as was shown in chapter 4, is a deployment testing tool, rather than a
full scale web server. In order to make R.E.X. accessible to multiple users the iPlanet Web
Server Enterprise Edition or an alternate full-scale Java supporting web server would need to
be used. At the time of writing this report, iPlanet had reduced its price on the iPlanet
Enterprise Edition web server by 37% until March 2002, to make it accessible and more
attractive to a wider market of web server users [ServerWatch, 2001]. Furthermore, if a fully
implemented R.E.X. system was being accessed by hundreds of clients daily, a simple access
solution would be the addition of a second web server to help balance the request load on the
system. This is known as load balancing and was discussed more fully in chapter 4 [Chaffee,
2000].
The InterBase Open Source Database Server can comfortably accommodate multiple users
and large data sets. This means that it would not be necessary to change the database used
should the system be extended to support multiple users.
63
A connection pooling approach to database connection establishment and usage would greatly
benefit a large-scale or fully implemented version of R.E.X. Servlets and JSPs would simply
get connections to the database from an existing pool of connections when needed and return
them to the pool once they were finished with them.
Database access time would be
significantly improved and users would be impressed with a noticeably faster and more
efficient system. Connection pooling was discussed in greater detail in chapter 4.
The R.E.X. prototype provides the core functionality of a medium-scaled auction site. A
developer could easily build upon this core functionality to provide new and richer ecommerce capabilities. Examples of this could be:

The addition of an item picture feature, that is, the user could add a picture of the
good along with the description of the good.

A user account personalisation feature in which the user could specify their
display and menu preferences.
Java’s object-orientation allows code to be reused. Every class is simply a building block in
the system that can be utilised by, and used for the creation of, new classes or features.
6.8 Conclusions
The author found that the development of R.E.X. was kept manageable due to the benefits of
Java. Code, especially that found in the utilities classes, could be re-used again and again in
function
specific
Registration.class
REXdbUtils.class).
classes
(for
example,
the
UserInfoBean.class
and
the
(servlet) made use of many of the same database utilities found in the
It is this author’s opinion that using larger, more complicated
programming modules would have greatly increased the complexity of the system and
decreased the manageability of the development of such a system by a single developer.
Small, manageable and concise functional classes, each with a specific purpose, facilitate
easier debugging and faster development by decreasing conceptual complexity. A real world
analogy serves to clarify the author’s point of view- building a house one brick at a time is
much simpler than building it an entire room at a time. If a single brick is faulty, it can easily
be replaced or fixed whereas if there is a problem with an entire room, determining which part
of the room is causing the problem is much more complex.
64
Appendix A includes the prototype file hierarchy and an extensive screen dump catalogue of
the R.E.X. prototype in action. As such, it forms a fitting practical addendum to this chapter
by providing R.E.X. prototype specific information and examples.
65
Chapter 7: Conclusion
7.1 Overview
This project has fulfilled its two primary objectives. Firstly, this report details the results of
the investigation of Java related technologies in the development of an affordable, dynamic,
small to medium scaled e-commerce system. Secondly, the R.E.X. prototype system
practically illustrates and performs the functions of a medium-scaled auction site utilising the
Java technologies investigated.
The advantages of the use of Java technologies in an e-commerce development and
deployment environment have been defined and discussed. The main advantage is that Java
provides a platform independent solution ideally suited to the heterogeneity of the Internet
environment. Furthermore, good and reliable open source and free software can be found to
support a system such as R.E.X. Motivation for the functionally, logically and/or physically,
separated tiers provided by a three-tiered architecture was discussed in detail in chapter 2
“The E-commerce Environment”. Java supports the three-tiered client-server architecture
through business-logic processing and presentation technologies such as servlets and JSPs on
the server-side and JDBC drivers for database communication with the database server. The
three-tiered architecture also greatly improves the simplicity of a system such as R.E.X. and
this is particularly important when the number of developers is limited.
The R.E.X. prototype could be implemented and used successfully on campus to supply a
central, interactive repository of goods for sale. Furthermore, the technologies used are
developer-friendly and allow for easy maintenance by just a few (even a single) programmer.
As a proof of concept, R.E.X. has, in the author’s opinion, succeeded excellently!
66
7.2 Future Directions
The author suggests that the following areas be considered as possible extensions to the
project:

The extension of the R.E.X. prototype into a fully implemented and practically used
system.

A practical comparison between a system such as R.E.X. being implemented using
Java technologies and the same system being implemented using Microsoft
technologies(for example, ASPs).

The deployment of a large-scaled R.E.X. system using J2EE and Enterprise JavaBeans
to service client requests.
7.2.1 Security
Another extension to the project could be the inclusion and investigation of security issues
specific to e-commerce and Java. This might involve a study into the practical level of
security required by a system such as this functioning at an institutional level.
7.2.2 Payment Options
Much of large-scaled e-commerce deals with payment issues (for example, credit cards, bank
transfers etc.) and how to provide payment services securely. Such an investigation would be
particularly useful if a small to medium-scaled system such as R.E.X. were to be used across
multiple institutions, for example, Rhodes and a number of other South African universities,
where clients may not easily be able to physically meet to settle payment and delivery issues.
67
References
[Allamaraju et al, 2001]
Allamaraju, S, Ashri, R, Darby, C, Flenner, R, Karsjens, T, Kerzner, M, Krotov,
A, Linde, A, MacIntosh, J, McGovern, J, Mirchandani, T, Plaster, B, Reamy, D,
Sarang P,G and Writz, D., Professional Java E-Commerce, Wrox Press Ltd,
Canada, 2001, pp. 1, 12, 21 , 24, 29-46, 49-50, 71-73, 112-114, 133-143, 253314, 318-365, 667-398, 501.
[Amazon, 2001]
Amazon.com., The place to find and discover anything you want to buy online,
http://www.amazon.com, Amazon.com, Inc., 2001
[Bergsten, 2001]
Bergsten, H., JavaServer Pages™ Pocket Reference, O’Rielly & Associates Inc.,
United States of America, pp. 1-4, 2001.
[Brown et al, 2001]
Brown, S, Burdick, R, Falkner, J, Galbraith, B, Johnson, R, Kim, L, Kochmer, C,
Kristmundsson, T and Sing, L., Combining Servlets, JSP, and JavaBeans,
http://stardeveloper.com:8080/comments/b-060501-1.shtml, Wrox Press,
Stardeveloper.com, 2001.
[Capili, 1999]
Capili, R., Webmonkey: Cool Forms with ColdFusion,
http://hotwired.lycos.com/webmonkey/99/17/index1a_page4.html?tw=programm
ing, Lycos, Inc., 1999.
[Carnegie, 2001]
Carnegie., CERT® Advisory CA-2001-19 "Code Red" Worm Exploiting Buffer
Overflow In IIS Indexing Service DLL, http://www.cert.org/advisories/CA-200119.html, Carnegie Mellon University, 2001.
[Chaffee, 2000]
Chaffee, A., One, two, three, or n tiers?,
http://www.javaworld.com/javaworld/jw-01-2000/jw-01-ssj-tiers_p.html,
JavaWorld, 2000.
[Computing Alternatives,
Computing Alternatives, Computing Alternatives Methodology,
2000]
http://www.computing-alt.com/windowsdna/windowsdna.htm, Computing
Alternatives, Inc., 2000.
[Curtin, 1998]
Curtin, M., Write once, run anywhere™: Why it matters,
http://java.sun.com/features/1998/01/wora.html, Sun Microsystems, Inc., 1998.
[eBay, 2001]
eBay Inc., The World’s Online Marketplace™, http://www.ebay.com/, eBay Inc.,
2001
68
[Eckel, 2000]
Eckel, B., Thinking in Java, Prentice-Hall Inc., United States of America, 2000
(second edition), pp. 927-930.
[FastTrack Docs, 2001]
FastTrack Documentation, iPlanet Web Server, FastTrack Edition 4.1,
http://docs.iplanet.com/docs/manuals/enterprise.html#ft41, Sun Microsystems
Inc., 2001.
[FastTrack Overview, 2001]
iPlanet FastTrack., Overview,
http://www.iplanet.com/products/iplanet_web_fasttrack/home_2_1_1l.html, Sun
Microsystems, Inc., 2001
[Fields and Kolb, 2001]
Fields, D,K and Kolb, M, A., Scalability in JSP,
http://www.webreview.com/2001/02_16/developers/index04.shtml,
WebReview.com, 2001.
[Gupta, 2001]
Gupta, R.K., Exploring the World of Application Servers,
http://serverwatch.internet.com/articles/appservers/, INT Media Group,
Incorporated., 2001.
[Hall, 2000]
Hall, M., Core Servlets and JavaServer Pages, Sun Microsystems Press,
Prentice-Hall Inc., United States of America, 2000, pp. 5-12, 21-38,65-86, 179192, 199-208, 231-278, 287-307, 353-364, 385-411, 433, 461-483, 519-556.
[Hamilton et al, 1997]
Hamilton, G, Cattell R and Fisher, M., JDBC™ Database Access with Java™: A
Tutorial and Annotated Reference, Sun Microsystems Inc., Addison Wesley
Longman Inc., United States of America, 1997, pp. 5, 343-345.
[Hogarth, 2001]
Hogarth, M., Java Servlets: A Novel Framework for Web Programming,
http://informatics.ucdmc.ucdavis.edu/Mike/myarticles/servlets.pdf, UC Regents,
2001.
[Hughes and Birznieks,
Hughes, C. and Birznieks, G., Serving Up Web Server Basics.
2001]
http://webcompare.internet.com/webbasics/index.html, INT Media Group,
Incorporated., 2001.
[InterBase Docs, 2001]
InterBase Documentation, InterBase 6.0 Beta Documentation Set,
http://www.borland.com/techpubs/interbase/ or
ftp://ftpc.inprise.com/pub/interbase/techpubs/ib_b60_doc.zip (for download),
Borland Software Corporation, 2001.
69
[InterBase Features, 2001]
InterBase Features, InterBase Feature and Benefit Matrix,
http://www.borland.com/interbase/ib6/ib6_featureandbenefits.html, Borland
Software Corporation, 2001.
[J2EEvs.NET, 2001]
J2EEvs.NET., Decisions, Decisions: J2EE™ vs. .NET,
http://java.sun.com/features/2001/08/j2eewrap.html, Sun Microsystems, 2001.
[Java Language White
Java Language White Paper, The Java™ Language: An Overview,
Paper, 2001]
http://java.sun.com/docs/overviews/java/java-overview-1.html, Sun
Microsystems, Inc., 2001.
[JDBC API, 1999]
JDBC API, Getting Started with JDBC API,
http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/GettingStartedTOC.fm.html
, Sun Microsystems, Inc., 1999.
[jGuru-JavaMail, 2001]
jGuru., Fundamentals of the JavaMail API Short Course,
http://developer.java.sun.com/developer/onlineTraining/JavaMail/contents.html,
Sun Microsystems, Inc., 2001.
[JSP_ASP, 2001]
JSP_ASP., Comparing JavaServer Pages™ and Microsoft® Active Server
Pages™ Technologies, http://java.sun.com/products/jsp/jsp-asp.html, Sun
Microsystems, Inc., 2001.
[Morrison and Morrison,
Morrison, M and Morrison J., Database Driven Web Sites, Course Technology,
2000]
Canada, 2000, pp.227-231.
[MS Access, 2001]
Microsoft Access, Microsoft Access 2000,
http://www.microsoft.com/catalog/display.asp?subid=22&site=769&x=46&y=14
, Microsoft Corporation, 2001.
[Ndinga, 2000]
Ndinga, S, S., An Investigation into Tools and Protocols for Commercial Audio
Web-site Creation, Master’s Thesis, Rhodes University, 2000, pp. 1-43.
[Netscape, 2001]
Netscape., Browser Central, http://browsers.netscape.com/browsers/main.tmpl,
Netscape, 2001.
[Opera, 2001]
Opera., The fastest browser on earth!, http://www.opera.com/, Opera Software,
2001.
70
[Poulton, 2001a]
Poulton, A., Introduction to Servlets,
http://www.cs.ru.ac.za/Honours/EJ/lectures/lecture2%20%20Introduction%20to%20Servlets.ppt, Rhodes University, 2001.
[Poulton, 2001b]
Poulton, A., Introducing JavaServer Pages,
http://www.cs.ru.ac.za/Honours/EJ/lectures/lecture5%20-%20JSP.ppt, Rhodes
University, 2001.
[Poulton, 2001c]
Poulton, A., Servlets and Databases,
http://www.cs.ru.ac.za/Honours/EJ/lectures/lecture6%20%20Servlets%20and%20Databases.ppt, Rhodes University, 2001.
[ServerWatch, 2001]
ServerWatch., Sun Slashes Prices on iPlanet Web Server,
http://serverwatch.internet.com/webservers.html, INT Media Group, 2001.
[Shneiderman, 1998]
Shneiderman, B., Designing the User Interface - Strategies for Effective HumanComputer Interaction, Addison Wesley Longman Inc., United States of Amercia,
1998 (third edition), pp.79-83.
[Sun JSP, 2001]
Sun JSP., JavaServer Pages Dynamically Generated Web Content,
http://java.sun.com/products/jsp/, Sun Microsystems, Inc., 2001.
[Thau, 2000]
Thau, D., The Book of JavaScript, No Starch Press, United States of America,
2000, pp 1-12, 226-229, 243-277.
[Thomas, 2001]
Thomas, M., Servlets vs. JSP,
http://island.isy.vcu.edu/mthomas/info462/Servlets-JSP.htm, Virginia
Commonwealth University, 2001.
[Tomcat, 2001]
Tomcat., Jakarta Tomcat, http://jakarta.apache.org/tomcat/index.html, Apache
Software Foundation, 2001.
[Tremblett, 1999]
Tremblett, P., What are JavaServer Pages?,
http://www.ddj.com/articles/1999/9912/9912k/9912k.htm, Dr. Dobb’s Journal,
1999.
[Tsang and Cannings, 2000]
Tsang, V and Cannings, R., JSP: The JavaServer Pages,
http://cannings.org/cpsc547/, Richard Cannings, 2000.
71
[Vawter and Roman, 2001]
Vawter, C and Roman, E., J2EE vs. Microsoft.NET A comparison of building
XML-based web services,
http://www.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET, The
Middleware Company, 2001.
[Webopedia, 2001]
Webopedia™., The only online dictionary and search engine you need for
computer and Internet technology, http://www.webopedia.com/, INT Media
Group, Incorporated., 2001
[whatis?com, 2001]
whatis?com., Definitions for thousands of the most current IT-related words,
http://whatis.techtarget.com/, TechTarget, 2001.
72
Appendix A
R.E.X. File Hierarchy
This section gives visual information about the practically implemented components in the
R.E.X. prototype. The diagrams here provide hierarchical structures composed of classes,
HTML files, JSPs etc. and their locations within the R.E.X. prototype. These files allow and
facilitate the client interaction and business-logic application handling of the R.E.X. system.
All files classified by the web server as content are either located in the docs directory, or a
sub-directory within the docs directory.
The following key specifies the meaning of symbols used on the following pages:
Key:
Directory/Folder
___.html
___.jsp
___.class or ___.jar
File
Hierarchical Diagram Listing
FILES and FOLDERS Diagram of all documents in the R.E.X. prototype system and their
physical locations in the docs folder.
FOLDERS
Listing of all directories (folders) in R.E.X. prototype system.
HTML
HTML specific to R.E.X. appearance (for example, the header
files, main page and registration form).
JSPs
All JavaServer Pages involved in R.E.X. system.
CLASSES
All other classes involved in R.E.X. system including utilities,
forms and beans.
73
74
75
76
77
78
A Look at R.E.X.
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
Practical Set-up of R.E.X. on Windows 2000
The following section gives instructions on how to set-up and configure the R.E.X. prototype
using Microsoft Windows 2000. These instructions are general and individuals who feel
comfortable with the software are free to make their own changes to the configuration of
R.E.X. and the code.
Code development of R.E.X. was done using UltraEdit (a code/HTML/all purpose editor) and
Microsoft FrontPage. A user wanting to implement R.E.X. on a machine first needs to make
changes to the R.E.X. code found in cd_root\REXSoftware\REXSpecific\docs\. All Java
classes (.java files) and JSPs (.jsp files) found in this folder, or its sub-folders, need to be
updated to reflect the system properties and configuration on which they are implemented.
Terms to look out for and change are:

All references to csh15.cs.ru.ac.za, particularly in JSPs. Change these
references to reflect the address of the machine on which the web server is
installed.

References to the e-mail address [email protected] particularly in the
REXmail

class.
The SMTP server address in the REXmail class, change this from mail.ru.ac.za
to the appropriate SMTP mail server used.

In the REXdbUtils class the database URL address needs to be modified to reflect
the
physical
location
at
which
the
jdbc:interbase://localhost/D:/REXdb/REXDB.GDB
database
is
stored.
 change the path in
bold to reflect the location at which the database is installed, and the database’s
filename.

In the REXdbUtils class the database username is “SYSDBA” and the password
“masterkey”. These are the default values present at the time of installation and
should be changed within the class if the developer/user uses a different username
and password to connect to the database.
Once these properties have been changed appropriately the class files need to be recompiled
before being used.
98
JDK 1.3
This should be installed first, before any development takes place. The JDK allows developers
to code and compile Java classes. Take note of the installation directory of the JDK. The
author used D:\JDK1.3\ as the installation path. Make sure that the following directory
cd_root\REXSoftware\REXSpecific\javax
is copied onto the installation machine and is
accessible by the class path. The files in this directory are used in the compilation of servlets.
The Web Server
After installing the JDK, the user is ready to install the iPlanet FastTrack web server. These
instructions give the basic configuration and set-up information for successful installation of
the web server using R.E.X.
1. Execute the file cd_root\REXSoftware\FastTrack Web Server\f41enu.exe. This
starts the web server installation process.
2. Read through the screens and make the appropriate selections. At the “Type of
Installation” screen select “Typical” and click on the next button.
3. Specify the appropriate installation directory in the system on which R.E.X.’s web
server will run. For example, D:\Netscape\Server4 (or which ever server
installation path is chosen).
4. At the “iWS Administration Server Authentication” screen, type in a username and
password for the administrator of the web server.
5. Leave the port addresses as they are.
6. Make sure that the content root (where documents are stored) points to
server installation path/docs.
7. Leave the LDAP section blank.
8. At the “JDK Configuration” screen select the “Use Custom Java Development Kit”
option and specify the “JDK path” as the installation directory of the JDK. For
example, D:\JDK1.3\. Leave the other choices blank.
9. Once installation is complete, the iWS Administration server can be started,
either via a short-cut or the start-menu. The “Administer web server” option can
then be selected and used to manage the server.
The following instructions are specific to R.E.X. and the docs folder:
1. Go
to
the
installation
D:\Netscape\Server4,
directory
of
the
web
server,
for
example
and delete the docs folder.
99
2. Now,
copy
the
docs
folder
cd_root\REXSoftware\REXSpecific,
from
the
CD,
in
the
directory
and save it in the server installation directory
where the previous docs folder was.
3. The web server can now be configured. Make sure that the Administration web server
is running (either via a short-cut or the start-menu) and that the administrator
username and password have been entered and verified.
4. Select the server name and click on the “Manage” button.
5. The first thing to do, is to set-up the directories as used by R.E.X.
a. Click on the “Content Management” tab.
b. Click on the “Additional Document Directories” item in the left-hand frame.
c. Make sure that the /servlet directory listed there is of type ServletByExt. If
not, then change its type.
6. Add the directories listed in the table below. At each step the administrator can save
the changes when prompted, or continue making changes.
Map to Directory
Apply Style
/forms
URL Prefix
ServerInstallationPath/docs/servlet/rex/forms
ServletByExt
/servlet/rex
ServerInstallationPath/docs/servlet/rex
ServletByExt
/rex
ServerInstallationPath/docs/rex
NONE
Remember to “Save and Apply” the changes once done.
The Database Server
1. First, copy the R.E.X. database and database directory, with sample records, from
cd_root\REXSoftware\REXSpecific\REXdb
to the desired directory on the
installation machine. For example, D:\REXdb. Make a note of the location of this
directory. It has to be specified in the R.E.X. code, REXdbUtils.
2. Execute the file
cd_root\REXSoftware\InterBaseDB Server\ib_server_6_0_1 –
InterBase\server\Setup.exe
3. At the InterBase “Component Selection” screen, deselect:
- Software Development Support
- Example Programs
- Example Databases
4. Select an appropriate destination directory.
Now it is time to register the R.E.X. database with the database server. In this installation
of R.E.X., both the middle and database tiers are housed physically on the same machine,
so a local server (as opposed to a remote server) is registered with the InterBase server.
100
1. Using a short-cut or the start-menu select “InterBase Server Manager” and ensure
that the InterBase server is running.
2. Now select the “IBConsole” from the start-menu.
3. Select ServerRegister. Register a local server and provide it with a
description. Specifying a username and password is not necessary at this point.
4. Now right click on local server and login using the default username “SYSDBA”
and password “masterkey” (make sure that the password is changed to something
less obvious).
5. Select DatabaseRegister (as the R.E.X. database already exists). Specify the
following information:
a. File: use the path (including filename) at which the REX database was
store (specified in step 1 of the previous section).
b. Alias: provide an alias. For example, “REX database”.
6. Click “Ok”.
InterClient JDBC Driver
1. Execute the file
cd_root\REXSoftware\InterClient JDBC\IC160000IWinJRE12.exe.
2. Specify a storage location.
3. Once the installation is complete, the administrator may choose to “Configure
InterServer” but no changes need to be made here in order for the system to function.
101
After the servers and JDBC driver are set-up:
1. RE-START the computer. This step is very important and specifically so that the
JDBC driver will be located once R.E.X. is live.
2. Now, make sure that the following are running:
a. The web server– check this via the “Administration web server”.
b. The InterBase server– check this via “InterBase Serve Manager”
c. The InterServer proxy (for the JDBC driver)– start this via “InterServer” under
the “InterBase InterClient” start-menu item.
3. That’s it! Now the user can access the R.E.X. system via a web browser.
A word of caution- if R.E.X. does not function properly after being set-up using these
instructions, check the class path in the Windows 2000 environment variables. Make sure that
the server installation path\docs\servlet is part of the class path.
102
Appendix B – Overview of Software Used
This Appendix provides links to documentation providing general overviews of the web
server and database server software used in the R.E.X. prototype.
iPlanet FastTrack Web Server
http://docs.iplanet.com/docs/manuals/fasttrak/41/FT41_FAQ.html
This provides a list of the most frequently asked questions pertaining to the FastTrack web
server.
InterBase Database Server
http://www.borland.com/interbase/ib6/ib6_featureandbenefits.html
This document provides a table listing all the features and benefits of using the InterBase
database server. It also lists which technologies are supported by InterBase such as, Java and
JDBC.
http://www.borland.com/interbase/ib6/overview.pdf
This document provides a slightly more detailed overview of how the InterBase database
server works.
InterClient JDBC Driver and InterServer
http://community.borland.com/article/0,1410,25919,00.html
This document provides detailed information on the functioning of the InterClient JDBC
driver.
103
Appendix C
Contents of the CD-ROM
The CD-ROM which accompanies this report includes the following:

A navigational interface to the CD-ROM found in the file “\index.html”

A text file listing the CD’s contents: \CDContents.txt

The report itself, in Microsoft Word 2000 .doc and .pdf format.
o Appendix A: “A Look at R.E.X.” is stored in a separate file due to its size.
o Appendix A: “R.E.X. File Hierarchy” is stored in a separate file due to the
landscape orientation of the diagrams used.

The following programs/software:
o Java Development Toolkit 1.3
o iPlanet FastTrack web server and documentation
o InterBase 6.0.1 Database Server and documentation
o InterClient JDBC Driver
o Microsoft Internet Explorer 6.0.26 for Windows 2000
o UltraEdit-32 8.10b Editor- Evaluation Edition
o R.E.X. Specific code and files:

The web server docs folder

The R.E.X. database

javax
files used in servlet compilation

R.E.X. Set-up Instructions on Windows 2000

The author’s research web page and project poster
104
Appendix D
Bibliography
[bid_or_buy, 2001]
bid_or_buy.co.za., http://www.bidorbuy.co.za/, bidorbuy.co.za, 2001.
[Deitel and Deitel, 1999]
Deitel, H, M and Deitel, P, J., Java™ How to Program, Prentice-Hall Inc., New
Jersey, 1999 (fourth edition).
[FastTrack FAQ, 2001]
iPlanet FastTrack., iPlanet Web Server, 4.1, FastTrack Edition FAQ,
http://docs.iplanet.com/docs/manuals/fasttrak/41/FT41_FAQ.html, Sun
Microsystems, Inc., 2001
[Hoffer et al, 1999]
Hoffer, J, A, George J, F and Valacich, J, S., Modern Systems Analysis and
Design, Addison Wesley Longman Inc., United States of America, 1999 (second
edition).
[Ince and Freeman, 1997]
Ince, D and Freeman, A., Programming the Internet with Java, Addison Wesley
Longman Inc., United States of Amercia, 1997.
[Rob and Coronel, 2000]
Rob, P and Coronel, C., Database Systems Design, Implementation and
Management, Course Technology, Cambridge, 2000.
105
Glossary
API
See Application Program Interface.
APPLET
“A program designed to be executed from within another application.
Unlike an application, applets cannot be executed directly from the
operating system. A well-designed applet can be invoked from many
different applications. Web browsers, which are often equipped with Java
virtual machines, can interpret applets from Web servers.” [Webopedia,
2001]
APPLICATION PROGRAM
INTERFACE
“a set of routines, protocols, and tools for building software applications. A
good API makes it easier to develop a program by providing all the
building blocks. A programmer puts the blocks together.” [Webopedia,
2001]
APPLICATION SERVER
“A program that handles all application operations between users and an
organization's backend business applications or databases. Application
servers are typically used for complex transaction-based applications”
[Webopedia, 2001]
CGI
See Common Gateway Interface.
CLIENT-SERVER
A term used to refer to a computer architecture or system in which a client
program or machine request a service from another machine or program
known as a server. For example, a user with a web browser requesting a
particular page from a web server.
COMMON GATEWAY
INTERFACE
“Abbreviation of Common Gateway Interface, a specification for
transferring information between a World Wide Web server and a CGI
program. A CGI program is any program designed to accept and return data
that conforms to the CGI specification. The program could be written in
any programming language, including C, Perl, Java, or Visual Basic.”
[Webopedia, 2001]
DATABASE SERVER
This type of server houses one or more databases and enables users to
connect to and interact with databases it houses.
DHTML
See Dynamic Hypertext Markup Language.
DYNAMIC HYPERTEXT
MARKUP LANGUAGE
“Refers to Web content that changes each time it is viewed. There are many
technologies for producing dynamic HTML, including CGI scripts, Serverside Includes (SSI), cookies, Java, JavaScript, and ActiveX.” [Webopedia,
2001]
E-BUSINESS
See electronic business.
E-COMMERCE
See electronic commerce.
ELECTRONIC BUSINESS
“the process of using electronic technology to do business.” [Allamaraju et
al, 2001]
ELECTRONIC COMMERCE
“Conducting business on-line [on the Internet]. This includes, for example,
buying and selling products with digital cash and via Electronic Data
Interchange (EDI) [e.g. using credit cards]”. [Webopedia, 2001]
106
EXTENSIBLE MARKUP
LANGUAGE
A W3C specification developed particularly for web documents. It allows
developers to create custom tag libraries “enabling the definition,
transmission, validation, and interpretation of data between applications
and between organizations” [Webopedia, 2001]
GRAPHICAL USER
INTERFACE
“Pronounce goo-ee: A program interface that takes advantage of the
computer's graphics capabilities to make the program easier to use”
[Webopedia, 2001]
GUI
See Graphical User Interface.
HTML
See Hypertext Mark-up Language.
HTTP
See Hypertext Transfer Protocol.
HYPERTEXT MARK-UP
LANGUAGE
Handles the formatting and display of web pages.
[Webopedia, 2001]
HYPERTEXT TRANSFER
PROTOCOL
“The underlying protocol used by the World Wide Web. HTTP defines how
messages are formatted and transmitted, and what actions Web servers and
browsers should take in response to various commands. For example, when
you enter a URL in your browser, this actually sends an HTTP command to
the Web server directing it to fetch and transmit the requested Web page.”
[Webopedia, 2001]
IMAP
See Internet Message Access Protocol.
INTERNET
An enormous, global network linking of millions of computers.
[Webopedia, 2001]
INTERNET MESSAGE
ACCESS PROTOCOL
“a protocol for retrieving e-mail messages. The latest version, IMAP4, [and
supports features such as allowing] you [to] search through your e-mail
messages for keywords while the messages are still on mail server. You can
then choose which messages to download to your machine.
IMAP was developed at Stanford University in 1986.” [Webopedia, 2001]
J2EE
See Java 2 platform enterprise edition.
JAVA 2 PLATFORM
ENTERPRISE EDITION
“is a platform-independent, Java-centric environment from Sun for
developing, building and deploying Web-based enterprise applications
online. The J2EE platform consists of a set of services, APIs, and protocols
that provide the functionality for developing multi-tiered, Web-based
applications.” [Webopedia, 2001]
JAVABEAN
“type of object…used to encapsulate a program’s methods and variables,
and provide a public interface that is accessible from …JSPs.” [Allamaraju
et al, 2001]
JAVAMAIL
“The JavaMailTM API is an optional package (standard extension) for
reading, composing, and sending electronic messages” [jGuru-JavaMail,
2001].
JDBC
The JDBC API enables Java programs to execute SQL statements. In this
way Java applications and programs can interact with SQL-accommodating
databases. [Webopedia, 2001]
107
JSP
The technology provided by JSPs enables the developer to combine
“regular, static HTML with dynamically generated content from servlets”
[Hall, 2000].
LOAD BALANCING
Making use of multiple web servers to minimise the performance
hampering bottle-neck experienced by a single web server serving too
many clients.
MIDDLEWARE
“Software that connects two otherwise separate applications.” [Webopedia,
2001]
PHP
See PHP Hypertext Pre-processor.
PHP HYPERTEXT
PREPROCESSOR
“PHP Hypertext Pre-processor is a server-side, HTML embedded scripting
language used to create dynamic Web pages. In an HTML document, PHP
script (similar syntax to that of PERL or C ) is enclosed within special PHP
tags.” [Webopedia, 2001]
REQUEST-RESPONSE
Synonymous with client-server architectures. This term refers to the request
made by a client for a service and the response to that request given by the
server upon completion or attempted completion of that request.
SERVLET
A servlet is a program that runs on a server and acts as a middle layer
between a request from a web browser and databases or other
applications/drivers residing on the server. A servlet can generate HTML
programmatically and return it to the client via the response object.
[Allamaraju et al, 2001]
SESSION TRACKING
HTTP is a stateless protocol, that is, state is not maintained from one
request to the next. In many applications, particularly e-commerce ones, it
is crucial that state information be maintained. The time in which a
particular state must be maintained may be referred to as a session. For
example a shopping cart between requests has to know which items it has
in it, and to who the items belong. The process of maintaining state when
appropriate is known as session tracking.
SIMPLE MAIL TRANSFER
PROTOCOL
“protocol for sending e-mail messages between servers.” [Webopedia,
2001]
SMTP
See Simple Mail Transfer Protocol.
SQL
See Structured Query Language.
STRUCTURED QUERY
LANGUAGE
“standardized query language for requesting information from [and
maintaining information in] a database” [Webopedia, 2001]
THIN CLIENT
A thin client is a small client-side from which most, or all, of the data
processing work has been removed and allocated to the server-side of the
system. [Webopedia, 2001]
THREE-TIER CLIENTSERVER ARCHITECTURE
A client-server architecture in which three functionally distinct layers are
maintained. These layers are logically separated and can be housed on
physically different machines. The three functions include a client-side
(presentation layer), a server-side (business-logic processing) and a
database server (persistent data layer).
TIER
“a row or layer in a series of similarly arranged objects. In computer
108
programming, the parts of a program can be distributed among several tiers,
each located in a different computer in a network. Such a program is said to
be tiered, multi-tier, or multi-tiered.” [whatis?com, 2001]
UNIFORM RESOURCE
LOCATOR
“the global address of documents and other resources on the World Wide
Web.” [Webopedia, 2001]
URL
See Uniform Resource Locator.
WEB SERVER
Traditionally “a computer that delivers (serves up) Web pages.”
[Webopedia, 2001]
WORLD WIDE WEB
A global heterogeneous collection of connected networks and computers.
WWW
See World Wide Web.
XML
See Extensible Markup Language.
109
Project Poster
The next page of this report is a fold-out A3 version of the author’s project poster. This
poster visually summarises the investigation, report and the R.E.X. prototype system.
110