An Introduction to E-commerce - RU
Acknowledgements
I would like to thank the following people for their contribution to this research project:
▪ My supervisors, Dr George Wells and Dr Greg Foster, for their support, guidance, and advice.
▪ My team member, Farisai Mabvudza. I thank him very much for his help and support throughout the year and most importantly, for his friendship.
▪ The lecturing staff of the Computer Science Department for always being approachable.
▪ The Honours class of 2002 for their friendship and help.
▪ My parents for their everlasting support.
▪ And most importantly of all, I would like to thank God for everything in my life.
Abstract
E-commerce is one of the major concerns playing on the minds of business individuals the world over. Inspired by the success of mass-market on-line e-commerce sites such as , this report presents a feasibility study into developing such a site at an institutional level.
An analysis of the various technologies used and investigated includes Java, JSP, JDBC and the Apache Tomcat web server. The objective of the analysis is to determine the benefits of using these technologies towards the development of e-commerce endeavours. The deployment of an Internet based webshop application, which facilitates the sales of memorabilia; named RUM (Rhodes University Memorabilia) was developed and implemented. In this report both the physical and the logical component elements of RUM are explored so as to provide an insight into the inherent problems of creating such a system, as well as the overriding benefits derived from the creation of such a system.
Contents
CHAPTER 1 – Introduction 1
1.1 An Introduction to E - commerce 1
1.2 Advantages of E - commerce 2
1.3 The Project 3
1.3.1 Motivation 3
1.3.2 Objectives 4
1.3.3 Scope 4
1.3.4 Division of Work 4
1.3.5 Deliverables 5
1.3.6 Thesis Overview 6
CHAPTER 2 – The Design of RUM and its Architecture 7
2.1 Designing for Scalability 7
2.1.1 Analysing Web Application Requirements 7
2.1.2 Determining Web Application Functionality 8
2.1.3 Choosing Web Architecture 8
2.1.4 Designing the Web Application 8
2.1.5 Conclusion 9
2.2 The RUM Infrastructure 9
2.2.1 A Brief Overview 9
2.2.2 Limitations of the 2-tier Architecture 9
2.2.3 Greater Flexibility with the n-tier Architecture 10
2.2.4 Maximum Efficiency with the 3-tier Architecture 10
2.2.4.1 The 3-Tiered Approach 12
2.3 Technologies used in the implementation of RUM 13
2.3.1 .NET vs. J2EE 13
2.3.2 Java 15
CHAPTER 3 – THE Client Tier (Front-end) 17
3.1 Architectural Approaches for Web Design 17
3.1.1 Servlet Centric Approach 17
3.1.2 Page Centric Approach 18
3.1.2.1 Page View Design 19
3.1.2.2 Page View with Bean 20
3.2 The Thin Client Approach 21
3.2.1 Thin Client versus Thick Client 21
3.2.1.1 Performance 22
3.2.1.2 Maintenance and Cost 22
3.2.1.3 Resource Requirements 23
3.3 Applets versus Form Elements 23
3.4 Design of Visual Content 24
3.5 Discrepancies between Netscape Navigator and Internet Explorer 27
3.5.1 RUM’s Multi-Platform Compatibility Problems - Web Page Cosmetics 27
3.5.2 Web Page Scripting 29
3.6 Technologies used in the RUM Client Tier 29
3.6.1 Browser 29
3.6.2 Hypertext Mark-up Language (HTML) & Cascading Style Sheets (CSS) 29
3.6.3 JavaScript 30
CHAPTER 4 – Application Server Tier (Middle tier) 32
4.1 Session Tracking 32
4.2 Security in RUM using SSL 33
4.3 Technologies used in the RUM Application Server Tier 33
4.3.1 JavaServer Pages (JSPs) 33
4.3.1.1 Advantages of JSPs 34
4.3.1.2 JSP Vs. Common Gateway Interface (CGI) 35
4.3.1.3 JSP Vs PHP Hypertext Pre-processor 35
4.3.1.4 JSP Vs. Active Server Pages (ASP) / 35
4.3.1.5 JSP Vs. Pure Servlets 35
4.3.1.6 JSP Vs. Server-Side Includes (SSI) 36
4.3.1.7 JSP Vs. JavaScript 36
4.3.1.8 JSP Vs. Static HTML 36
4.3.2 JSP Tags 36
4.3.2.1 Declarations 37
4.3.2.2 Scriptlets 37
4.3.2.3 Expressions 38
4.3.2.4 Directives 38
4.3.2.5 Comments 39
4.3.2.6 Actions 39
4.3.2.7 JSPs and Enterprise JavaBeans (EJBs) 40
4.3.2.8 jsp:useBean Tag 41
4.3.2.9 jsp:setProperty Tag 41
4.3.2.10 Jsp:getProperty Tag 42
4.3.3 The Web Server 42
4.3.3.1 Apache Tomcat Web Server 43
4.3.3.2 How JSP Requests are handled by the Tomcat Web Server 44
4.3.4 JavaMail 44
CHAPTER 5 – Data Tier (Back-end) 46
5.1 Technologies used in the RUM Data Tier 46
5.1.1 Microsoft Access Database (MS Access) 46
5.1.2 Structured Query Language (SQL) 46
5.1.3 The Java Database Connectivity (JDBC) and the JDBC Driver 47
CHAPTER 6 – The Practical Implementation of RUM 49
6.1 The RUM Infrastructure 49
6.1.1 Client tier 49
6.1.2 The Middle Tier 50
6.1.3 Data Tier 50
6.1.4 The Interaction between the three tiers 51
6.2 The Design of the RUM Website 51
6.2.1 Flow Diagram showing a user’s typical shopping process traversal in RUM 52
6.2.2 RUM’s Design Concepts 53
6.2.3 Logging into RUM 54
6.2.3.1 Registering as a new user 55
6.2.3.2 Existing user logging into RUM 57
6.2.3.3 Forgotten password 59
6.2.4 Product Categories - Stationery 59
6.2.4 Checkout Process - Shopping Cart 62
6.2.5 Checkout Process - Shipping Details 64
6.2.6 Checkout Process - Delivery Details 65
6.2.7 Checkout Process - Payment Details 66
6.2.8 Checkout Process - Confirmation Details 67
6.2.9 The Context Sensitive Help System 70
6.2.10 Logging out of RUM 72
6.2.11 Security in RUM using SSL 72
6.2.12 An Overview of the JavaBeans used in RUM 73
6.2.12.1 ConnectionBean 73
6.2.12.2 CountryBean 73
6.2.12.3 CustomerBean 73
6.2.12.4 EmailBean 74
6.2.12.5 OrderBean 74
6.2.12.6 ShoppingCart 74
6.2.12.7 ProductBean 74
6.2.12.8 ProductDisplay 74
6.2.12.9 SearchBean 75
6.2.12.10 Result 75
6.2.12.11 ValidationBean 75
6.3 Implementation Problems 75
CHAPTER 7 – Conclusion and Possible Enhancements 77
7.1 Conclusion 77
7.2 Possible Enhancements 77
7.2.1 Automatic Stock Control 77
7.2.2 Implementing Connection Pooling 78
7.2.3 Implementation of real time credit card transaction processing 78
7.2.4 Dynamic recommendations 78
References 79
Appendix A : RUM’S File Hierarchy 82
Appendix B : Installing and Configuring RUM under Windows 83
1. Copying the Files 83
2. Setting up the Environment Variables 84
3. Configuring RUM 84
Appendix C : Glossary 86
RUM Poster 92
CHAPTER 1 – Introduction
1.1 An Introduction to E - commerce
The Internet is not a ‘faddish technology’. It is a new communications platform, which can connect people and organizations together in any way the individual components require. The Internet will twist, turn, re-evaluate, and re-engineer every single logistic process that affects our lives [Reynolds, 2000].
“E-commerce can be defined as the attainment of a business vision supported by advanced information technology to improve efficiency and effectiveness within the trading process” [Wayner, 1997]. In its simplest form, it allows a product catalogue to be hosted on a web server so that potential customers can visit the site, see what is on offer and then place orders. [] is the leader of this industry. It is famous for bringing the concept of e-commerce into the mainstream. It epitomizes e-commerce survival and is arguably one of the most famous retailers [Reynolds, 2000].
E-commerce is changing rapidly, and its trends can come and go just as quickly. Stipp [2001] states the point that “the recent decline of new media stocks, the demise of dot-com companies, and the slow growth of the Internet as advertising medium have raised questions about the future of the new medium, especially as a viable business. Analysts have also revised their optimistic projections and are forecasting much slower growth than anticipated just a year ago”.
However, despite the setbacks e-commerce is still surviving (Figure 1.1).
1.2 Advantages of E - commerce
Online shopping offers many advantages for webshop owners and customers:
Advantages to a webshop owner:
▪ The owner is able to sell to any country over the world.
▪ Customers chooses products on their own and orders via email or by form submission, thus cutting costs for the owner.
▪ Always up to date - products and prices can be easily maintained and can be up to date.
▪ Easy maintenance - updates are easily done.
▪ Number of products - thousands of products can be offered without much more costs.
▪ Product categories - you can freely define any number of product categories and subcategories.
▪ Orders - all orders and communication takes place via email.
Advantages to a customer:
▪ User-friendly interaction.
▪ Customers are able to shop around the clock without leaving the house.
▪ Secure transactions via a secure server. Payments can be made via credit card.
▪ User profile - customers have the possibility to generate an individual profile.
▪ Confirmation via email - immediately after ordering the customers receive an email confirmation about the order.
It is known that a major shift towards e-commerce is happening, so all that has to be done is to work out how to make the most of this wealth of new opportunity [Reynolds, 2000]. Successful on-line shops are usually large-scale commercial endeavours. The implementation of such a system outside the arena of well-known e-commerce businesses such as [] is feasible, beneficial and practically achievable. The author will attempt to enlighten this fact with the implementation of an innovative online webshop known as RUM (Rhodes University Memorabilia).
1.3 The Project
1.3.1 Motivation
At present, memorabilia at Rhodes University is currently being bought by means of traditional purchasing methods. A catalogue with photographs and a brief description of the various memorabilia available for sale is sent to all Rhodes alumni. The order form enclosed within the catalogue is then completed by the customer and sent to the Alumni Department at Rhodes via the postal service or it is delivered physically. Obviously there are various problems inherent with this method of service.
Firstly, there is a chance that the catalogue may never reach the respective alumni, due to alterations of their postal address or, because of the unreliable postal services. The mail may never reach its destination. Secondly, brochures need to be reproduced when prices change or when new products are made available. Thirdly, it is naturally unsafe to send credit card information via postal services, as there is a likelihood of the postal mail being intercepted by malicious individuals. Fourthly, communication, whether due to erroneous orders, or merely additional inquiries between the two parties is expensive and also is prolonged, as the customers have to wait for their orders to reach the university before they are processed. Finally, customers do not get instant feedback and so are not aware of their order status.
Existing students can only purchase memorabilia during the Alumni department’s office hours. Moreover, promotion of memorabilia at Rhodes occurs through ‘word of mouth’ and so is not prominent. There is a need for the Alumni Department to effectively let prospective customers know about the memorabilia available for sale, and at the same time resolve the other issues mentioned above.
The solution to this is an online shop for the purchase of memorabilia. The webshop, which would be available at any time, will potentially attract the attention of existing Rhodes students and alumni, who are currently unaware about this service. They will be able to shop from the comfort of their homes and can efficiently search the central repository of memorabilia available, locate the exact item that they are looking for and purchase it online via a secure server.
1.3.2 Objectives
There are two primary objectives to this project. The first objective is the deployment of a Internet based application for the sale of memorabilia. It has been built using the latest web technologies, with Java Server Pages (JSPs) as the main underlying technology in order to rapidly develop and easily maintain, information-rich, dynamic web pages. The second objective is this research report detailing the results of the investigation of Java related technologies that are used in the development of the above-mentioned system.
Customers interact with the system using an interface accessible via the Internet. They can register with the system resulting in the creation of their user profile, which they can alter at any time. Thereafter, they can browse the central repository of memorabilia available by category or using the search engine provided. Purchases can then be made by following each of the steps involved in the checkout process, which assures that personal details are handled with the utmost security via a secure Apache Tomcat web server. The order information is then emailed to the Alumni Department for processing and customers also receive an email confirming their order. The prototype system will from hereon be referred to as RUM, an acronym for Rhodes University Memorabilia.
1.3.3 Scope
RUM’s functionality is very similar to that of famous webshops like . The developers have not explored issues such dynamic recommendations of products to enforce customer relationships by means of advertising and marketing memorabilia. Automatic stock control matters and connection pooling are also not focused on. Since RUM is not required to be as large and complex as , the above-mentioned features have not been implemented as they are beyond the scope of this project and have not been highlighted explicitly, except as possible future enhancements of the system. Section 8.1.4 consists of a detailed description of the possible enhancements that can be made to this system.
4 Division of Work
By working in a team, a solution can often be reached quicker and with more efficient results than working alone as there is a larger pool of ideas and solutions available to choose from. Two heads are better than one when it comes to finding the best solution. Since this project is a small to medium scale e-commerce endeavour, which cannot be completed by a single person in the time allotted, the author has decided to work with another individual to find the best solution to this project. The division of work for the project is highlighted below. It must be noted that a number of tasks have overlapped throughout the duration of this project; hence, a clear division of work could not be allotted, so certain tasks had to be undertaken by both members of the team.
The Author (Uma Rudraraju) : Front-end
▪ Development of RUM user interface using Hyper-Text Mark-up Language (HTML), Cascading Style Sheets (CSS), JavaScript and Java Server Pages (JSP).
▪ Form Validation and Error Handling.
▪ Context sensitive help system.
▪ Development of the supporting JavaBeans for the above tasks.
▪ Documentation for the above mentioned tasks of the project.
Team Member (Farisai Mabvudza) : Back-end
▪ Database setup and validation.
▪ Linking the RUM interface to database using Java Database Connectivity (JDBC) and the Tomcat web server.
▪ Implementation of security features into RUM.
▪ Product search engine.
▪ Development of the supporting JavaBeans for the above tasks.
▪ Documentation for the above mentioned tasks of the project.
1.3.5 Deliverables
The primary deliverable is this research report, which highlights the design and implementation concerns pertinent to the functionality of this system, which can also be used in the future to assist in the deployment of a dynamic, database-driven web site environment. Additionally, the development of RUM, a small to medium scaled e-commerce application for use by anyone intending to purchase memorabilia from Rhodes University through the Internet.
1.3.6 Thesis Overview
The remainder of this thesis is structured as follows:
Chapter 2 “The design of RUM and its architecture”
Explores the process of web site design, and the various architectures available towards the development of a specific system. It also examines the two technical environments available for deploying an e-commerce application.
Chapter 3 “The Client Tier (Front-end)”
Chapter 4 “The Application Server Tier (Middle tier)”
Chapter 5 “Data Tier (Back-end)”
These three chapters individually describe each of the logical tiers in the 3-tiered client-server architecture, and the technologies that can be implemented within each of the tiers.
Chapter 6 “Practical Implementation of RUM”
Provides a detailed description into the implementation of the RUM, on a page-by-page basis. Various issues are discussed that may help future web developers in building simple, yet extremely dynamic web pages.
Chapter 7 “Conclusion and Future Enhancements”
Concludes the thesis and illustrates the possible enhancements that can be made to this project.
CHAPTER 2 – The Design of RUM and its Architecture
2.1 Designing for Scalability
Reynolds [2000] states that in the case of e-commerce applications, scalability is the capacity to serve additional users or transactions, and maintain a website’s availability, reliability and performance without fundamentally altering the application's architecture or program design.
“A website's architecture almost always includes limiting factors that may affect its scalability at all usage levels. When designing website architecture, the developer should consider the speed and size of expected website growth to estimate when limits to scalability and performance might occur” [Infoworld Media Group, 2001]
The Infoworld Media Group describes a process for scaling an e-commerce application based on website requirements and the selection of a website’s architectures (Figure 2.1). This design process is used to explain how the infrastructure of RUM was achieved.
Figure 2.1: A Web sites Design Process [Adapted from Infoworld Media Group, 2001]
2.1.1 Analysing Web Application Requirements
The designer should assess the website's requirements and demands before implementing the web application. Following the above process will ensure that the best performance and scalability is achieved, to meet these requirements and demands when designing the web application.
RUM’s functionality falls into the category of ‘Shopping and transaction-oriented web sites’. To avoid expensive re-engineering of a web application, it is critical when first designing the application to identify the functionalities it needs to provide. RUM provides functionalities such as a shopping cart, user registration, checkout process, automatic session tracking and database interaction.
2.1.2 Determining Web Application Functionality
There is a vast range of operations or functionality that a web application should provide. Some key factors that can affect the scalability and performance of a system are [Infoworld Media Group, 2001]:
▪ Executions of data transactions - Analysis of the application’s data requirements, such as read, write and update operations must also be considered.
▪ Web page caching - A user's wait times are typically more directly correlated with a site's performance hence, caching facilitates the maximization of data access speed while maintaining data integrity.
▪ Session integrity requirements - Session integrity ensures that any information captured during a user's session is not lost after a web application failure. This eliminates the need to re-authenticate usernames or passwords, or re-enter transaction information.
Since these issues are associated with the back-end features of RUM, they will be discussed in depth by my team member, Farisai Mabvudza, and thus, will not be further discussed in this section.
2.1.3 Choosing Web Architecture
RUM has adopted a 3-tiered architecture. The author believes that by separating the business tier away from the presentation and database roles, business objects that work smarter and scale better can be built. The reasons for choosing a 3-tiered model for RUM are also discussed in section 2.2.4.
2.1.4 Designing the Web Application
By evaluating the performance and scalability characteristics of individual vendor products used in each of the tiers, the designer can make selections about specific vendor products, which can be tailored for the web application and its requirements. Vendor components to match the architecture should be selected, keeping in mind the growth potential of the site and its ability to scale to meet future demand [Infoworld Media Group, 2001]. The developers chose a number of software products that were best suited to RUM’s 3-tiered architecture. The technologies selected for each tier and their advantages are discussed in Chapters 3, 4 and 5.
2.1.5 Conclusion
When designing web applications it is apparent that scalability is an essential issue. Careful planning and execution will result in a website that can easily cope with a drastic increase in web traffic and allow cost-effective expansion to accommodate for future growth. Designing scalable web applications can also reduce or even eradicate the need to completely redesign the website architecture if the business exceeds its highest expectations [Infoworld Media Group, 2001]. It is predicted that no more than five users will access RUM at a given time. However, there is always a need to cater for potential increases in the number of users and thus, the developers have considered scalability as a crucial matter during the design of RUM.
2.2 The RUM Infrastructure
2.2.1 A Brief Overview
According to Reynolds [2000], “E-Business transactions are putting new pressures on the corporate computing environment.” Functionality and stability are no longer sufficient to provide a competitive advantage. Businesses must be able to deploy and adapt applications quickly. The highest levels of performance and availability must be maintained to support business-critical processes [Intel Corporation, 2001]. The developer must select the architecture that best meets the needs of the specific system in development. This choice involves identification of the advantages and disadvantages of a particular architecture in terms of the system being developed.
2.2.2 Limitations of the 2-tier Architecture
Corezon Corporation [2001] emphasizes that the 2-tier model does not scale incrementally. When usage exceeds capacity, the entire system usually needs to be replaced. The software structure of the 2-tier architecture is equally inappropriate to the volatility of the e-business environments. Business logic is essentially integrated with the presentation logic and with the back-end. This is more suited to stable, isolated applications, but lacks the flexibility required for e-business agility. Business logic also has to be overhauled if new user interfaces are redesigned or if the application is to be integrated with other applications [Corezon Corporation, 2001]. Hence, this architecture was not used for an e-commerce site such as RUM. RUM also relies on a database tier for persistent data storage. The 2-tiered architecture does not explicitly define a storage tier and relies on the developer to build one into the server tier if needed. [Chaffee, 2000]
2.2.3 Greater Flexibility with the n-tier Architecture
Intel Corporation [2001] illustrates that an n-tier design divides the application into three functional layers, enabling easier integration with core business systems and other e-business applications. Effectively, an independent application layer is added to the traditional 2-tier architecture. This layer has the affect of decoupling business logic from presentation and database functions, both physically and in the software architecture. The implications for software development and maintenance are particularly compelling. Standardized APIs can replace customized code to interface business logic with presentation code as well as the back-end. The hardware and software for each of the layers can be scaled and upgraded separately, when properly implemented. This division also makes it easier to incorporate new applications into the existing environment. Application code no longer has to be rewritten when a new user interface is added, or when changes are made to the back-end components. [Intel Corporation, 2001]
The n-tier model extends the 3-tier architecture by allowing multiple application objects in the business logic layer.
2.2.4 Maximum Efficiency with the 3-tier Architecture
The 3-tiered model has been found to be an extremely efficient development approach. It allows the main application functions to be divided into much more efficient and well-defined layers. This model provides ‘functional modularity’. Using three tiers keeps a relatively simple and uncomplicated system from becoming unmanageable. Chaffee [2000] reviews the advantages and disadvantages of 3 and n-tiered architectures in Table 2.1:
|Architecture |Pros |Cons |
|Three tiers |Can separate user interface, logic and storage |Need to buy database product |
| |Reliable, replicable data |Need to hire database administrator |
| |Concurrent data access via transactions |Need to learn new language (SQL) |
| |Efficient data access |Object-relational mapping is difficult |
|n tiers |Support multiple applications more easily |Quite inefficient |
| |Common protocol/API |Must learn API (CORBA, RMI, etc.) |
| | |Expensive products |
| | |More complex; thus, more potential for bugs |
| | |Harder to balance loads |
Table 2.1: 3-tier Architecture versus n-tier Architecture [Chaffee, 2000]
Most of the disadvantages pertaining to the 3-tiered model can be disregarded, as they do not relate to RUM for the following reasons:
▪ Database products such as MS Access are already available in most academic institutions - MS Access is readily available and licensed within all Rhodes Departments, including the Alumni Department
▪ Anyone can maintain RUM - RUM is a small system that can be managed by anyone with an understanding of its database design and the website’s functionality.
▪ Knowledge of SQL not required - Since the MS Access database includes an easy-to-use graphical user interface (GUI) for managing the data, there is no need for the maintainers of the system to learn SQL.
▪ Relationships between objects are easily established - This is achieved by making use of the Java object-oriented language.
Chaffee [2000] states that using an n-tiered application “opens a huge can of worms, creating new problems in design, implementation, and performance.” RUM, as a whole, is a single application, with a single task. This study aims to create a manageable system, which only incorporate the tiers necessary to the successful functioning of the system. It is therefore apparent that the 3-tiered architecture is best suited towards a system like RUM.
2.2.4.1 The 3-Tiered Approach
Figure 2.2: RUM’s 3-tiered Client-Server Architecture [Adapted from Sun Microsystems, 2002]
RUM is based on the modern, robust, state-of-the-art, 3-tiered architecture [tikSystems, 2002] shown in Figure 2.2. The RUM architecture defines a way of dividing application services into three distinct roles (presentation, business rules and data), which are arranged so that each can operate at the maximum efficiency. This model adds enormous flexibility to the design of the application. The three logical layers are defined as follows [Sun Microsystems, 2002]:
▪ Client Tier - presents the user interface to the user usually by means of a web browser.
▪ Application Server Tier - Normally hosts a combination of presentation logic (web tier) and business logic (business tier) to support client requests.
▪ Web Tier - The web components present in this tier provide presentation logic, which is supported via JSP pages.
▪ Business Tier - processes the business rules for the application.
▪ Data Tier - queries and manipulates the database under instruction from the business tier.
The three tiers, and the associated implementation/investigative decisions made concerning these layers, are discussed in greater detail in Chapters 3, 4 and 5.
4 Technologies used in the implementation of RUM
The e-commerce environment can be divided into two categories [Naude, 2001]:
1. The environment in which an e-commerce application is developed.
2. The environment in which an e-commerce application is deployed.
The development environment describes the technologies used in the designing a system. The deployment environment, on the other hand, refers to the environment in which a system operates and is used.
|Technologies Used |Client Tier |Application Server Tier |Data Tier |
|Hyper-text Markup Language (HTML) & Cascading Style Sheets | | | |
|(CSS) | | | |
|JavaScript | | | |
|Java | | | |
|Java Server Pages (JSP) & JavaBeans | | | |
|JavaMail | | | |
|Tomcat Web Server | | | |
|Structured Query Language (SQL) | | | |
|Java Database Connectivity (JDBC) | | | |
|Microsoft Access Database (MS Access) | | | |
Table 2.2: Technologies utilized in each of the tiers pertaining to the RUM Architecture
2.3.1 .NET vs. J2EE
There are two environments that have been considered for deploying an e-commerce application. One of these is the Microsoft environment known as the .NET platform. The other is the Sun environment known as the Java 2 Enterprise Edition (J2EE). The key difference between the two platforms is that “J2EE is Java-centric and platform neutral, while .NET is Windows-centric and language-neutral. This means developers are restricted to Java language in the J2EE and Windows in the .NET framework.” [Hameed, 2002]. There are similarities between certain aspects of the technologies employed by both these development options. For example, Microsoft’s Active Server Pages () and Sun’s functionally similar JavaServer Pages (JSP), and Microsoft’s Open Database Connectivity (ODBC) for database access and Sun’s Java Database Connectivity (JDBC) [Naude, 2001]. The comparison show in Table 2.3 provides a basic sense of the similarities, and the advantages and disadvantages carried by both platforms in various areas [Vawter and Roman, 2001].
|Similarities between J2EE and .NET |
| |
|Regardless of which platform you pick, new developers will need to be trained |
|Both platforms offer a low system cost |
|Both platforms offer a single-vendor solution. |
|The scalability of both solutions is theoretically unlimited. |
|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 |
|Only J2EE lets you deploy web services today |
|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 lets you take advantage of existing hardware you may have |
|J2EE gives you platform neutrality, including Windows. You also get good (but not free) portability. This isolates you from heterogeneous|
|deployment environments. |
|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. |
|J2EE lets you use Java, which is better than C# due to market-share and maturity. |
|Arguments for .NET and against J2EE |
| |
|. NET is language-neutral |
|. NET released their web services story before J2EE did, and thus has some mind-share |
|. NET has a good tool set with Visual |
|. 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 e-commerce applications, whereas J2EE makes you treat other languages as separate|
|applications |
|. NET benefits from being strongly interweaved with the underlying operating system |
Table 2.3: Comparing J2EE with .NET [Adapted from Vawter and Roman, 2001]
Neither platform has an overall advantage sufficient to make it the obvious, exclusive choice for an e-commerce application. Both .NET and J2EE target the enormous market for applications and web services. The author has highlighted in bold the points that she considers to be most applicable to this report and discusses some of these in the next section which describes why Java was chosen as the platform for RUM. RUM aims to capitalize on some of the factors supporting J2EE since these factors directly emphasize the advantages of the Java language itself.
2.3.2 Java
Java is a general purpose programming language with a number of features, a few of them listed below, that make the language well suited for creating web based applications [Naughton and Schildt, 1999].
▪ Java's simplicity, allows a developer to write more code in less time and it is less prone to program failure or bugs than other languages due to its robustness. Java’s simplicity made the coding of RUM quicker and simpler than other languages such as C++.
▪ Java is an object-oriented language. This helps simplify e-commerce application development as it assists in the production of clearly defined functional components. This helped the developers of RUM to encapsulate the business logic of the system using JavaBeans as the functional components.
▪ Java, being a multithreaded language, was designed to meet the real-world requirement of creating interactive, networked programs. Effective server-side applications serving multiple users need to make use of threading in order to respond to requests efficiently. JSPs make use of threads to handle client requests. Using Java for RUM meant that multiple users could access the system simultaneously.
▪ Java aims to be a platform-independent development language. The Internet is heterogeneous- made up of many different computers, networks and platforms. This means that RUM can be moved to any platform with little or no modification. 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.
Dumermuth [2000] states “J2EE is a key piece of the end-to-end Java solution: the technology engine for end-to-end e-commerce.” The developers were attracted to Java's time and cost-saving abilities, its selling attributes and economies, its ‘write once, run anywhere’ promise, and its other advantages highlighted in bold. Thus, it was decided that a Java based solution had evolved into the best solution for well-specified server-side applications like RUM.
Each of the technologies used by RUM as shown in Table 2-2, will be discussed and defined more specifically in chapters 3, 4 and 5, which discuss the system tier by tier, and in chapter 7, which shows the practical implementation of RUM.
CHAPTER 3 – THE Client Tier (Front-end)
The client tier can also be referred to as the front-end of a system. Its core function is to display data in a manner that is meaningful to the user [Computing Alternatives, 2000]. It is responsible for forwarding requests for services to the middle tier. Additionally, it receives and interprets responses from the web server and displays the results on the user’s machine.
3.1 Architectural Approaches for Web Design
Possibly the biggest choice a developer faces in designing a JSP application is determining how to separate the application high-level architecture into logical areas for simpler code design. There are two basic approaches to take when architecting a JSP application: the servlet centric approach or the page centric (page-view design or page view-with bean design). By discussing the ideas of Fields and Kolb [2000], and the author’s own knowledge and experience, these various approaches will be discussed and contrasted below.
3.1.1 Servlet Centric Approach
This model is roughly based on the Model-View-Controller (MVC) programming construct. MVC programming basically breaks up applications into three primary parts [Fields and Kolb, 2000]:
1. Controller - The Controller controls the flow of data, and determines where to direct requests both into and out of the system.
2. Model - The Model is the processing and data layer. This includes processing business logic, storing data, and performing functions. This layer is where the real work is done.
3. View - The View is the layout of the program and what the user actually sees - the user interface.
The servlet centric approach is best illustrated in Figure 3.1. The control flow starts when the web container (the environment in which a web applications is deployed and run) receives a request from the client application. All requests are passed to the controller, which can be a servlet (or JSP page) that decides which view it will pass the request to. Although Figure 3.1 shows only one view, in practice there are normally multiple views. The view, which receives the forwarded request, invokes methods in a JavaBean, and the response is sent to the web container, which then passes it to the client application [Fields and Kolb, 2000].
Since the servlet acts as the controller, the servlet has control on the request, and forwarding of pages is centralized. A fine role separation, between the lower level coding in the servlet and the JSP coding, is formed. This approach loosens the coupling between the pages thus, allows them to interact without them being directly aware of each other, thereby improving the abstraction between presentation and application logic. The approach also strives to minimize the amount of work being done in the pages themselves and instead, relies on application-dedicated servlets to handle such aspects. Complexity is also eliminated from the front-end JSP code, reducing them to pure data display and input collection activities. The need for embedding presentation information inside the servlets is eliminated. The servlets in this case should be only concerned with application flow and generating the data needed by JSP pages for presentation to the user. Finally, coding a system using this approach would prove difficult for new developers since there is a lower level of abstraction and hence, an experienced Java developer would be required. For this reason, this approach was not used in the design of RUM.
3.1.2 Page Centric Approach
Applications implementing this approach have a series of interrelated JSP pages where the user proceeds from one page to another. In this approach, client requests are serviced by JSPs or servlets, which directly access resources such as a database. The JSP page is where the request is received and processed, and the response sent back to the client; in this scenario, JSPs differ from servlets by providing cleaner code. This separates the code from the content because data access is handled by JavaBeans.
One of the main advantages of such an approach is that it is simpler to program, allowing the page developer to generate dynamic content with ease, depending on the request and the state of the resources. Despite the fact that application development is easier, there are scalability issues associated with this method. When a large number of clients access the application simultaneously, the web server will have to process many requests, and each request will have to create a potentially scarce and expensive connection to the database or resource in question. There are two types of page centric models to web development, the Page View and the Page View with Bean models.
3.1.2.1 Page View Design
This basic architecture involves “direct request invocations to a server page with embedded Java code, and mark-up tags that dynamically generate output for substitution within the HTML” [Fields and Kolb, 2000]. This design possesses a number of benefits. It is straightforward and is a low-overhead approach from a developer’s point of view. All the Java code may be embedded within the HTML, so changes are confined to a small area, thereby reducing complexity (Figure 3.2).
Figure 3.2: Page View Design
However there are disadvantages inherent in this approach. The developer is limited to mostly ‘cut-and-paste’ reuse, which results in duplicate code and a more error-prone environment that is harder to maintain and debug. The other big trade-off here is in the level of complexity. If this design is used carelessly, then substantial amounts of Java code (business logic) will be embedded in the JSP page. Although this does not affect the Java developers, it is certainly an issue for the designers who maintain the JSP pages: the code tends to get in designer’s way, and the Java developers may find that their code gets corrupted when the designer makes changes to the look and feel of the page. Since this would have created unnecessary problems for the developer and the designer of RUM, this approach was not used. It is evident that incorporating JavaBeans helps the division of labour and improves the potential for code reuse.
3.1.2.2 Page View with Bean
This design pattern is used to solve the problems associated with cluttering of the business logic and data access code in the JSP page. The Java code for the business logic and data access is simply transferred from the JSP page to a JavaBean. This redesign results in much cleaner JSP with less Java code, which can be maintained comfortably by the page designer since it encapsulates mostly mark-up tags. This design also promotes the division of labour due to the introduction of JavaBeans within the model (Figure 3.3).
Figure 3.3: Page View with Bean Design
The author decided to chose the Page View with Bean approach, towards the design of RUM due to the advantages mentioned. Reynolds [2000] says, “this is the model to always employ when first learning JSP because it's simple and easy.” In addition, because there were few logical layers, this approach was good for a small team of developers like the author and her team member. Using this approach was also more intuitive to understand from a browser and developer’s perspective. This is because each page had a function and there was a clear connection between the page and the type of information it contained or the functionality it would deliver. For example, in RUM a page called ShoppingCart.jsp, to serve the function of displaying the user’s shopping cart, was easy to understand.
Furthermore, a less technical individual could be provided with a property sheet for the each JavaBean, providing a listing of properties that are made available to the JSP page by the particular bean, and the desired property may simply be plugged into the JSP getProperty action via the mark-up tag in order to obtain the attribute value. An example of a potential property sheet, used in RUM, is shown in figure 3.4. The convention and format used in the property sheet were agreed upon by the author and her team member, thus providing a clear separation of work between the logical components of the system. Moreover, the functionality of this bean may be refined and modified without the need for changes to the HTML code within the JSP source page.
|JavaBean Name: |
|OrderBean.java |
|Properties: |
| |
|SName cardType |
|saCost sCountry |
|sAdd1 expiryDate neighbourCost payment |
| |
|sAdd2 cardNumber otherCost ordered |
| |
|sCity ccvsError cardName delivery |
| |
|sPostcode cardNumberLeft |
|cardNumberRight |
|Recommended Scope: |
|Session |
|Template code to include in JSP code: |
| |
|Example Usage: |
| |
| |
| |
Figure 3.4: Example of a Property Sheet – The OrderBean used in RUM
3.2 The Thin Client Approach
An additional advantage of the 3-tier architecture is that it allows clients and servers to become either ‘thin clients’ or ‘thick clients’ [Ndinga, 2000].
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 the data processing on the client side and if needed, stores data on the server-side. [Webopedia, 2001]
3.2.1 Thin Client versus Thick Client
The following comparisons between the thick and thin client architectures were adapted from Naude [2001]:
3.2.1.1 Performance
Thin Client – Thin client computing is about minimizing the amount of processing that takes place on the client and minimizing the amount of data transmitted between the client and the server. Using this approach for RUM would mean that there is no major download time involved on the client-side as the middle tier handles the bulk of the processing.
Thick Client - This approach of ‘download it before you work with it’ is undesirable. Clients will have to download an applet before they can interact with the system. This could be slow, unreliable and time-consuming particularly when using modems connected to the Internet via phone lines. Waiting and download failures can, and often do, lead to client frustration.
3.2.1.2 Maintenance and Cost
Thin Client - Using this approach can reduce maintenance time and expense because the primary focus of activities is at the server and not at the client workstations so no software needs to be loaded or maintained at the client’s workstation other than the client operating system and browser.
Less workstations => less maintenance
Less maintenance => less money spent for labour
It highlights the fact that the responsibility of the client-side developer is the design of the visual aspects of the front-end, and they do not need to be concerned about the business logic responsible for processing client requests. The author could easily establish what visual aspects are required to access the server-side functions and integrate them with the front-end HTML code development by communicating with the server-side developer. The code on the client-side is kept to a minimum and hence, the interface of a thin client is not as rich and flexible as the thick client. In RUM, these limitations were overcome by the use of technologies such as JavaScript, CSS etc. which provided richer, thin client front-end visual functionality.
Thick Client - Changes to the code or functionality of a system require that the applet be recompiled and the updated version be reloaded onto all the client workstations. This complicates coding because the applet developer needs to be aware of the platforms and software residing on the client workstations so as to achieve software compatibility.
The server-side developer must liase 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 client and server is not clear because the client-side and server-side are so closely coupled. This overlapping of the 2-tiers makes the system more complex to manage.
3.2.1.3 Resource Requirements
Thin Client - The thin client needs very little client-side resources in order to function. 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. Using this approach towards the development of RUM would place less of a strain on the client machine.
Thick Client - Since a lot of the data processing is done on the front-end each process needs processor time and resources, such as the Java Virtual Machine (JVM), in order to fulfil its function.
RUM is accessed predominantly via the Internet or the Rhodes intranet, and should be convenient, transparent, quick and easy to use. Due to the problems mentioned above regarding the thick client architecture, the thin client application architecture was the development paradigm of choice for RUM’s front end.
3.3 Applets versus Form Elements
The author investigated two options for displaying the user interface by means of the thin client architecture. These were:
▪ Applets: Using an applet in the context of a thin client architecture would provide for the front-end to a servlet, not fulfil the function of a servlet. It would only be responsible for [Naude, 2001]:
- 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.
However, applets require a JVM to be installed on the client machine and the applets have to be downloaded before they are used.
▪ HTML Form Elements: HTML form elements are objects like input text areas, text boxes, combination boxes, selection lists and buttons. They are created using static HTML tags in web pages, and provide control points for user interaction. Users can enter input data into forms as well as view the data in forms. This approach was used by RUM because of the simplicity associated with form elements and the drawbacks associated with applets mentioned above. An example of an HTML form is illustrated using RUM’s Change Password form in Figure 3.5. A user would enter their old password, their new password, and then confirm their new password by retyping it. The user would then click on the change button to change their password, and the data would be passed to a JSP page for processing.
Figure 3.5: HTML Form Elements example taken from RUM
3.4 Design of Visual Content
[2002] illustrate the aspects related to successful website design listed below. The author will now describe how these design aspects were taken into consideration when designing the visual content of RUM. They can be verified by viewing the screen shots of RUM given in Appendix A or by accessing the RUM website itself.
Usability is an important aspect to web design.
▪ The author ensured that the RUM website downloads quickly, ideally within 7-15 seconds. The developers calculated this range from performing tests by users with slower computers and by users from outside of South Africa, who accessed RUM.
▪ To decrease file size and increase download speed the author used as few graphics as possible that were optimised with clear, concise HTML. The width and height attributes in the tag were specified so that the browser could download the rest of the page while waiting for graphics to download. The text was specified in the tag so that the page made sense before the graphics downloaded. The graphics were also stored as .gif for images that require transparency, and .jpg for the other images as these formats compress images well.
Navigation helps users find their way around, and tells them where they are and where they can go within the site. It provides a visual means for demonstrating the hierarchy of information to be found. At any one time, the user should be able to reach any level of the site and clearly see where they are in the site's hierarchy.
▪ RUM’s navigation panel was situated on the top area of every page in a consistent form, and took up as little space as possible, without losing legibility, as maximum space should be allocated for the content.
▪ Important links within the RUM appeared higher on the page so users could locate them quickly without having to scroll down.
▪ The hyperlinks within the website did not open in a new window as users get confused or irritated by this. This feature also destroys the functionality of the back button, which is used as a common means of back tracking.
▪ Some users choose a search facility before using any other navigation feature. Other users will use a search facility as a last resort. Anyhow, the author decided to have a search facility present within RUM and this would be situated in a prominent position on every page. Its usage was kept as simple as possible.
▪ A custom error page was also provided for each type of error that could occur in RUM. These error pages were provided with the layout and site navigation as the other pages, and included a brief description of why the user obtained this error page and possible solutions to avoid this error.
▪ Using images as links or navigation was performed carefully. As there is no obvious way for the user to tell that a graphic tag is a link, the developer also provided textual links to the same information at the bottom of every page within RUM.
Writing for the web is very different to writing for print. Time is of the essence to most people using the Internet, so users do not like to read reams of text on-line. Research has shown that people tend to scan text on screen. It is also harder to read from a computer screen than it is from paper.
▪ Short, simple and straightforward sentence structures were used within RUM as convoluted writing and complex words are even harder to understand online.
▪ It was taken into consideration that the reading pattern of a web page starts at top left and zigzags down the page to the bottom right, and web pages were designed accordingly for simpler reading ability to a user.
▪ Meaningful headings and subheadings were clearly visible.
▪ Centring of text and using all capitals was avoided, as this is harder to read for the user.
▪ It was also ensured that normal text, that were not links, were not underlined as this would confuse the user.
▪ Important points were written in red to attract the user’s attention and to request them to follow the correct steps when completing the checkout process within RUM
▪ Content was also clearly separated from style.
‘Keep it Simple’ is another vital rule of web design. As the designer makes decisions about what elements will make up a website, the concept of simplicity must be brought to the planning table and applied to both the look and content. Users should not be overwhelmed with too much information or too many graphics.
▪ White space was used carefully within RUM. It should not be wasted by having fixed width tables as the screen becomes blank in a wide browser window.
▪ RUM ensured that its web pages did not have any horizontal scrolling as users find this annoying.
▪ Gratuitous animated graphics, scrolling text and other means of advertising were avoided as they draw attention away from the content.
▪ It was made sure that each page was not overcrowded with too much information and too many links, as the user would not know what to look at first.
The layout and design of a site from page to page should be kept consistent throughout. This will give the user a better experience, as they will come to expect certain aspects of the site appearing in the same places each time.
▪ The colour scheme of purple and yellow, and text links were situated in the same place from page to page. Important points during the checkout process were stated in red to attract the users attention.
▪ Items that were repeated across the website, such as the logo, navigation and search box, were situated in a consistent position on all pages.
▪ Links were standardised so RUM would be simpler to use for users and they would know which links they have visited. Blue was used for unvisited links and purple was used for visited links.
Accessibility to everyone, regardless of browser, platform, operating system, is probably the most important factor to consider when designing a website. The designer should endeavour not to shut any web user out. Having an accessible web site, makes using the website much easier for everyone.
▪ RUM was tested at the development stage to ensure that it worked on various operating systems, such as Linux, with different browsers.
▪ RUM was designed so that it is usable on the main browsers, namely Microsoft Internet Explorer and Netscape Communicator. The issues related to the successful functioning of RUM under these two browsers are discussed in next section.
Good design is not just about a website looking great, it is about helping the site communicate its goal with as little effort as possible on the part of the user. If the site has strong usability, more users will notice how great the design is because they will not be wasting time trying to figure out how the site function.
3.5 Discrepancies between Netscape Navigator and Internet Explorer
JavaScript can be a problem when trying to develop a website with cross-browser compatibility. Schneiderman [1998] emphasize that HTML that looked ‘good’ in one browser did not look ‘good’ at all in the other, forcing the ‘de-construction’ of the web pages until they rendered acceptably on the desired browsers, namely Netscape Navigator and Internet Explorer. Conceptually, when creating a multi-platform web page, it is helpful to divide the task into two separate processes: Cosmetics and Scripting. Provided below is a list of some of the discrepancies between the two browsers which the author had encountered during the design of RUM.
3.5.1 RUM’s Multi-Platform Compatibility Problems - Web Page Cosmetics
1. Problem - By default, Netscape Navigator and Microsoft Internet Explorer displayed a margin around RUM’s web pages. This was not easily noticeable. The author should remove this margin so that the images are flushed against the browser's window. Unfortunately, each browser uses it's own tag attributes to accomplish this and neither are compatible with the other.
Solution - The author added in the attributes for both browsers. Netscape ignored Internet Explorer’s attributes, and vice-versa. Netscape recognized the attributes: marginwidth="x" and marginheight="x", where x is the number of pixels. Internet Explorer recognized the attributes: leftmargin="x", topmargin="x", rightmargin="x", and bottommargin="x".
2. Problem - If a form had only one tag, Netscape allowed the form to be submitted by pressing the return key. But if the form contained more than one tag, Netscape disabled this behaviour, forcing the user to explicitly press the submit button. Internet Explorer allowed the return key to submit a form regardless of the number of tags contained within.
Solution - After research, there was no known solution to the problem yet, except for the author to be aware of this behaviour when designing large forms. It was helpful to place multiple submit buttons throughout large forms to reduce the amount of scrolling the user would have to do in order to submit the form.
3. Problem - The element (list items) in Netscape did not appear same the way as in Internet Explorer.
Solution - The author created an inline style for each tag by using and tags. This displayed the correct style for both Netscape and Internet Explorer.
4. Problem - Some of the links did not work in Netscape because the link name was not in the correct case.
Solution - In Internet explorer, the name of the link could either be upper or lowercase letter. However, in Netscape, if the name of the HTML file was in lowercase and the link name is combination of lower and uppercase, then the link would not work. The link name was to be exactly the same as file name.
5. Problem - The background colour covered differently on each browser. In Netscape, the background colour covered only the text in the blockquote and in Internet Explorer, it covered entire blocks of text.
Solution - After research, there was no known solution to the problem yet.
3.5.2 Web Page Scripting
Once a developer embarks on the challenge of adding client-side scripting to a web page, some decisions have to be made before the first line of code can be written. Dynamic web pages generally make considerable use of client-side scripting to manipulate the layout and content of a web page in real-time. This is now commonly referred to as Dynamic HTML (DHTML). Schneiderman [1998] states that the ability of a scripting language to alter settings of a web page is provided by the inclusion of the Document Object Model (DOM) in Netscape's and Internet Explorer's newer browsers. This resulted in a problem, because both Netscape and Internet Explorer implemented their own proprietary DOMs, neither of which is entirely compatible with the other. This, of course, is troublesome for designers who strive to create platform independent web pages. For this reason, the author chose to limit the amount of client-side scripting in RUM.
3.6 Technologies used in the RUM Client Tier
3.6.1 Browser
All the implementation and testing of RUM was mainly performed using Microsoft Internet Explorer 6.0. However, the system was also tested and implemented to function under Netscape Communicator 4.7.2. Microsoft FrontPage 2000 was also used to correct a few visual bugs within the web pages.
3.6.2 Hypertext Mark-up Language (HTML) & Cascading Style Sheets (CSS)
HTML is the encoding scheme used to create and format a web document. It can be used to display any type of document on the host computer, which can be geographically at a different location. Being platform-independent, HTML indicates the manner in which the document is to be read by the interpreter using a set of HTML elements and it provides tags to layout the document [Holyer, 1997]. There is no limit to the kind and type of information that can be disseminated through the web pages by using this versatile language.
Cascading Style Sheets (CSS) is a simple mechanism for adding style (fonts, colours, spacing) to web documents. CSS offer efficient control over large document sets and provides a clear separation of content and design [Holyer, 1997]. In addition, they offer more formatting options than plain HTML tags and extensions.
The visual appearance of RUM is important. Hence, technologies like HTML and CSS are essential in the implementation of RUMs front-end. CSS was only used for the interactive help menu within RUM.
3.6.3 JavaScript
JavaScript, developed by Netscape [], is an extension to HTML that allows web site designers to add additional functionality in their web pages, and has a number of advantages and disadvantages:
|Advantages of JavaScript |Disadvantages of JavaScript |
|Interactive forms without CGI |More complex language than HTML |
|Off-line interactive pages |Adds file ‘weight’ to HTML files |
|No creation software required |Cross-platform issues - some browsers did not support JavaScript, |
|Fast test and modify cycle |e.g. Lynx |
|Handles repetitive tasks well | |
|Built-in feature in modern browsers | |
|Many free resources/code on JavaScript available for use to anyone | |
Despite the disadvantages, the usage of JavaScript within RUM was justified. Firstly, although complex, there are many code snippets freely available on the Internet to add almost any functionality into a web page using JavaScript. Secondly, RUM uses short, uncomplicated JavaScript snippets and so the download time of its HTML pages is affected minimally. Finally, RUM has been designed for best viewing on Internet Explorer and Netscape Communicator, two of the most widely used platforms.
JavaScript was used within RUM for the following tasks:
▪ Client side interactive forms (remove button, radio buttons).
▪ Dynamic content for pages (context sensitive help menu).
▪ Opening specific sized web browser windows (change password window).
▪ In-page animation (fading effect of the images of products).
As an example, this code segment from RUM illustrates the use of JavaScript (in bold) and how it aids in opening a specific sized web browser window (Listing 3.1)
Update my Profile
...
function win() {
topx = (screen.width - 400) / 2;
topy = (screen.height - 370) / 2;
msg=window.open("changepass.jsp","msg","height=370,width=400,
top="+topy+",left="+topx);
}
CHAPTER 4 – Application Server Tier (Middle tier)
As previously stated, the middle tier, also known as the application server tier, is divided into the web tier and the business tier. It services client requests by taking the appropriate action such as passing requests on to the data tier; this is done using JavaBeans. It also manages the presentation of the responses to client requests through the use of JSPs.
4.1 Session Tracking
An important function of the middle tier, predominantly in a system like RUM, which needs to keep track of user logins, and personalised content generation, is session tracking. Fields and Kolb [2000] emphasize that the Hypertext transfer protocol is a ‘stateless’ protocol, which means that each request is independent of the previous one. While this makes for a very simple and reliable protocol, it also makes advanced web applications, such as personalised content generation, more difficult. In order to customize content for an individual user, that user must first be identified. For example, a client using RUM logs in to their account and browses the products using forms to select the products they wish to purchase from the multiple category pages for addition to their shopping cart. Once the user has finished shopping, they can proceed through the checkout process that includes the delivery information, shipping costs, payment details and confirmation of their order. Throughout this process, the contents of the shopping cart, and its association to with a specific user to RUM, must be maintained.
Session tracking ensures that all of the user’s requests for pages from a web server during a given period of time are actually part of the same interactive session. JSPs include built-in support for session management; this support is hidden at the JSP level. From the perspective of JSP development, the availability of session tracking can simply be assumed.
Session tracking within RUM is conducted using an object provided by JSP called the session object. This object represents and individual user’s interactive session with the web server. Any JSP page that participates in session management can store items in this session object, and subsequently retrieve or remove them later, based on the user’s interaction with RUM. For example, the session object could be used to store login information or the contents of a shopping cart, and this stored data can then be accessed by any of the JSP pages within RUM, that are stored on the server.
Each session object keeps track of the last time it was requested by a JSP page. After, the predetermined period of time has elapsed in which no requests were made, the user’s session is considered to have expired, and is no longer valid. Hence, the next time the user returns to RUM, an empty session object will be created; no information is carried over from sessions that have expired.
4.2 Security in RUM using SSL
When users accesses RUM, there will be situations where sensitive information needs to be transferred from the client machine to the web server and vice-versa. This includes information such as credit card numbers, customer details, and passwords. Security is crucial for e-commerce applications and hence, secure communications in RUM have been achieved via Secure Socket Layer (SSL) technology. This is a method for hiding the information a web browser and a web server send to each other. An SSL-enhanced browser uses encryption to scramble the data a client sends to a website into an unintelligible string of seemingly random characters [Addy & Associates, 2000]. SSL-secured pages are accessed with the prefix https rather than the standard http.
It would be inefficient to make every web page in RUM secure since the SSL security scheme is slow and causes major performance strain on a web server, so the developers ensured that only pages that involved the exchange of sensitive information, such as the credit card details page, were made secure. There was also a need for each page to check that the users had not manually typed in the incorrect URL prefix. The developers placed code, at the top of each page, to automatically redirect the page to the correct URL, if the original URL was incorrect.
4.3 Technologies used in the RUM Application Server Tier
4.3.1 JavaServer Pages (JSPs)
JSPs provide a simplified, fast way to create web pages that display dynamically generated content. The JSP specification, developed through an industry-wide initiative led by Sun Microsystems, defines the interaction between the server and the JSP page, and describes the format and syntax of the page.
4.3.1.1 Advantages of JSPs
JSP offers several benefits as a system for dynamic content generation [Fields and Kolb, 2000].
▪ Performance - As a Java based technology, JSPs enjoys all the advantages that the Java programming language provides with respect to development and deployment. So, as Java performance continues to improve, performance of JSPs continues to improve. Furthermore, because all servlet and JSP requests are handled by the same process (the JVM), it is very easy for them to share resources, and thereby improve overall performance.
▪ Reusable Components - JavaBeans are objects whose implementations conform to a set of conventions designed to promote modularity and reusability. If an object is already available to perform some task, that is one less piece of code that needs to be written, debugged and maintained.
▪ Separating presentation and implementation - By taking advantage of JSPs built-in support for Enterprise JavaBeans, it becomes possible to maintain a strict separation between data presentation and program implementation. The benefit in decoupling these two aspects is that changes to one can be made without requiring changes to the other.
▪ Achieving Division of Labour - As a side effect of the above-mentioned advantage, a clear division of labour can be achieved so the need to coordinate work between team members is minimized. This was most beneficial to the developers of RUM as they could work independently to refine their contributions to the application (Figure 4.1).
Naude [2001] describes certain advantages that JSPs have over other technologies used for similarly combined static and dynamic content generation purposes.
4.3.1.2 JSP Vs. Common Gateway Interface (CGI)
CGI programs launch a new process for every request to the CGI program. This method is very inefficient as process creation is rather expensive. However, JSP pages are actually compiled into a Java servlet. Servlets start once and merely launch lightweight threads to process each request. In addition, servlets can cache previous results to improve performance and can maintain database connections between requests.
4.3.1.3 JSP Vs PHP Hypertext Pre-processor
PHP is an open-source, free scripting language that is embedded in HTML and used in a similar way to JSPs. JSPs, however also have two major advantages over PHP. Firstly, the dynamic portion of JSPs is written in Java, and thus is more versatile than PHP. Also, 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’.
4.3.1.4 JSP Vs. Active Server Pages (ASP) /
ASP is a similar technology from Microsoft. The advantages of JSP are twofold. First, the dynamic part is written in Java, not Visual Basic or other MS-specific language, so it is more powerful and easier to use. Second, it is portable to other operating systems and non-Microsoft Web servers.
4.3.1.5 JSP Vs. Pure Servlets
JSP doesn't give you anything that you couldn't in principle do with a servlet. But it is more convenient to write and modify regular HTML than to have a numerous ‘println’ statements that generate the HTML. Also, by separating the look from the content you can put different people on different tasks: your Web page design experts can build the HTML, leaving places for your servlet programmers to insert the dynamic content.
4.3.1.6 JSP Vs. Server-Side Includes (SSI)
SSI is a widely supported technology for including externally defined pieces into a static Web page. JSP is better because it lets you use servlets instead of a separate program to generate that dynamic part. Besides, SSI is really only intended for simple inclusions, not for ‘real’ programs that use form data, make database connections, and the like.
4.3.1.7 JSP Vs. JavaScript
JavaScript can generate HTML dynamically on the client. This is a useful capability, but only handles situations where the dynamic information is based on the client's environment. With the exception of cookies, HTTP and form submission data is not available to JavaScript. And, since it runs on the client, JavaScript can not access server-side resources like databases, catalogues, pricing information, and the like.
4.3.1.8 JSP Vs. Static HTML
Regular HTML, of course, cannot contain dynamic information. JSP is so easy and convenient that it is quite feasible to augment HTML pages that only benefit marginally by the insertion of small amounts of dynamic data. Previously, the cost of using dynamic data would preclude its use in all but the most valuable instances.
4.3.2 JSP Tags
JSP tags are scripting elements that allow the developer to insert code into the servlet that will result from the translated JSP. JSP tags can be divided into four different types [Fields and Kolb, 2000]:
1. Scripting Elements - These are used to embed programming instructions written in Java, which are to be executed each time the page is processed for a request.
▪ Declarations - This tag is used for defining the functions and variables specific to a JSP page.
▪ Scriptlets - In this tag the developer can insert any amount of valid java code and these codes are placed in _jspService method by the Tomcat web server’s JSP engine.
▪ Expressions - These tags can be used to output any data on the generated page. This data is automatically converted to a string and printed on the output stream.
2. Directives - In the directives the developer can import packages, define error handling pages or the session information of the JSP page.
3. Comments - These are used for adding documentation strings to a JSP page.
4. Actions - These are processed for each request received by a page. They provide JSP pages with run time behaviour. For example, the jsp:useBean action loads a JavaBean so that it can be used in a JSP page. JavaBeans are discussed in depth in the next section.
3.
4.
5.
4.3.2.1 Declarations
JSP Declarations explicitly define the entities that are used in a program [Fields & Kolb, 2000]. The general syntax for a JSP declaration is as follows:
JSP declarations are normally used in conjunction with JSP expressions or scriptlets, since they do not generate any output. An example of a JSP declaration is shown below:
Variables that are declared in this way can be accessed by all servlet instances. Since there was no need for such variables in RUM, JSP declarations were not used.
4.3.2.2 Scriptlets
Scriptlets allow Java code to be inserted into the servlet method that builds the page. The Java code is executed, whenever the JSP page is invoked. A scriptlet cannot generate HTML by itself. The basic format of a JSP scriptlet is as follows:
JSP scriptlets were combined with HTML in RUM to add dynamic content in the pages. An example of this usage is shown below:
New to RUM? Register Here
4.3.2.3 Expressions
JSP Expressions allow the values of Java expressions to be outputted. The Java expressions are evaluated at run-time and converted to a string before being inserted into the web page. The basic format of a JSP expression is:
An example of a JSP expression from RUM is shown below:
Welcome !
4.3.2.4 Directives
A JSP directive provides global information to the page It usually has the following form:
There are two main types of JSP directives which were used in RUM were the page directive and the include directive. A third directive was available for using custom tag libraries in JSP pages. Since RUM did not make use of custom tag libraries, this directive will not be discussed.
▪ Include directive
The include directive allows developers to include files at the time the JSP page is translated into a servlet. The line of code with the include directive is effectively replaced with the code from the file being included. The author found this feature useful for code, which appeared on every page in the system, such as the code for the text menu at the bottom of each page. Instead of copying and pasting the code for the menu, a file with this code was simply included in each page using the directive. The code for including the menu is shown on the following page:
▪ Page directive
The page directive allows attributes to be provided for the JSP page. There are numerous attributes that can be specified, but they are beyond the scope of this discussion. The only attribute which the author made use of is the import attribute. The import attribute allows JSP pages to make use of other Java classes, and has identical functionality to the Java import statement. An example of its use in RUM is shown below:
4.3.2.5 Comments
All programming languages allow commenting within their code and JSP is no exception. There are three types of commenting that can be used:
▪ Content comments allow comments to be included in the output of a JSP page that is generating web content. The syntax is as follows:
▪ JSP comments are independent of the type of content being produced by the page. These comments can only be viewed by examining the original JSP file. They take the following form:
▪ Scripting language comments allow the use of the native comment syntax of the scripting language. In the case of Java, the comments would take the form: or
4.3.2.6 Actions
JSP Actions encapsulate common behaviour into simple tags for use from any JSP page.
▪ Forward Action
This action is used to forward a client request to an HTML file, JSP file, or servlet for processing. Processing of the current page is immediately halted. An example of its use in RUM is shown below:
▪ JavaBean related Actions
Objects such as JavaBeans can be accessed as built-in variables via scripting elements using the jsp:usebean, jsp:setProperty and jsp:getProperty tags. These are described in the next section.
4.3.2.7 JSPs and Enterprise JavaBeans (EJBs)
One of the most powerful features of JSP is that you can access JavaBean components from a JSP file. 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 JSPs within which they are used [Naude, 2001]. Some of the advantages of pursuing a Beans solution are:
▪ Give developers architectural independence.
▪ Follows the ‘write once run anywhere’ paradigm for server-side components.
▪ Establish roles for application development.
▪ Take care of transaction management.
▪ Help create portable and scalable solutions.
JSP provides a set of Bean tags as described earlier, which can be used to place Beans into a page, and then access or alter their properties. The usage of JavaBeans is perhaps best illustrated with an example (Listing 4.3 and 4.4). In RUM, the author makes use of a bean called CustomerBean, which stores and validates the details of the customer currently using RUM. The jsp:useBean action is a very useful capability because it allows the reusability of JavaBean classes without sacrificing the convenience that JSP adds over servlets alone.
public class CustomerBean {
private String email= new String();
private String passwd= new String();
public CustomerBean() {} //constructor
public String getEmail()
{ return email; } //returns email attribute
public void setEmail(String email)
{ this.email = email; } //sets email attribute
…
4.3.2.8 jsp:useBean Tag
This jsp:useBean tag is a simple syntax for specifying that a bean should be used.
This line mean ‘instantiate an object of the class CustomerBean, and bind it to a variable with the name specified by id customer’ (Listing 4.3). The jsp:useBean specifies that a new object is instantiated only if there is no existing one with the same id and scope. The attributes presented in this tag are defined below [Fields & Kolb, 2000]:
▪ id - the name of the object instance referring to the object. The name is case sensitive.
▪ scope - this attribute controls a beans accessibility and life span (Table 4.1).
|Scope |Accessibility |Life Span |
|Page |Current page only |Until page is displayed or control is forwarded to a new |
| | |page |
|Request |Current page and any included or forwarded pages |Until request has been completely processed and response |
| | |has been sent to the user |
|Session |current request and any subsequent request from the same |Life of the user’s session |
| |browser window | |
|Application |Current and any future request that is part of the same |Life of the application |
| |web application | |
▪ class - the fully qualified name of the class that defines the implementation of the JavaBean.
4.3.2.9 jsp:setProperty Tag
Once a bean is present, its properties can be modified using the jsp:setProperty method. This method gives value to the properties of the beans that have been referenced earlier.
This line means ‘set the value of the email instance variable in the customerBean class by calling the setEmail(String email) function in this class’. The attributes presented in this tag are defined below:
▪ name - this attribute designates the JavaBean instance whose property will be set.
▪ property - this defines the name of the bean property whose value must be set.
▪ value - the value to assign to a specified property.
4.3.2.10 jsp:getProperty Tag
The jsp:getProperty action retrieves properties from a JavaBean, converts them to a string and places them into the output buffer.
This line means ‘get the value of the email instance variable in the CustomerBean class by calling the getEmail() function in this class’. The attributes presented in this tag are defined further:
▪ name - this attribute designates the JavaBean instance whose property will be obtained.
▪ property - the name of the bean property whose value should be printed.
4.3.3 The Web Server
A web server is a software program that is dedicated to retrieval of web pages upon request. The web server is responsible for interpreting the clients’ requests and sending back or ‘serving’ the requested information to the client. Web servers and web clients use the Hypertext Transfer Protocol (HTTP) to send and receive information. Essentially, HTTP consists of a ‘send me this file’ request from the Web Client, and a ‘here it is’ reply from the web server [Consulting Company, 1999] as shown in Figure 4.2.
There are many things to consider when the developer begins the web server selection process. Being able to weigh the advantages and disadvantages of available technologies, and being able to determine which one provides the best support is an important aspect of the selection process. It is up to the developer to answer the following questions when choosing a web server [Hughes & Birznieks, 2001]:
▪ The purpose (and functions) of the site and what technologies must be supported by it.
▪ The traffic expected by the site.
▪ How to meet the above two requirements in terms of the available budget.
4.3.3.1 Apache Tomcat Web Server
Apache Tomcat is a commercial-quality server solution based on the Java Platform. It is an Open Source project (making it free and providing access to the source code if necessary) and works reasonably well [Garbagnati, 2000]. Tomcat's appeal in the enterprise is growing due to its cost and flexibility advantages. Table 4.2 lists some of the advantages and disadvantages associated with using the Apache Tomcat web server [Schultz, 2001]:
|Advantages |Disadvantages |
|Active open-source development effort |Good documentation not available |
|Free |Does not scale well |
|Very current in terms of JSP support and Servlet API compliance | |
|Uses less system resources | |
|Platform Independent | |
The developers wanted to employ a web server that would support the rich and flexible dynamic applications and services that are built using JSPs provided within RUM. RUM was not designed to support a multitude of users, however scalability of the system should be taken into consideration, and if its traffic was to increase, then Tomcat which does not scale well, could be integrated with another web server to balance the request load on the system. Furthermore, the developers wanted to use a free web server to lower the costs incurred in developing the system. Therefore, it was decided that Apache Tomcat was used as the web server for RUM.
4.3.3.2 How JSP Requests are handled by the Tomcat Web Server
The sequence of steps highlighting how Tomcat handles JSP requests is described below [Andy, 2000]:
1. A browser requests a page with a .jsp file extension from the Tomcat Server.
2. The Tomcat Server reads the request.
3. Tomcat converts the JSP file into a servlet class using the JSP compiler known as Jasper. The JSP file is compiled only when the page is first requested, or when the JSP file has been changed. Otherwise, the previously compiled JSP servlet class is re-used, making subsequent responses much quicker.
4. Finally, the generated servlet class is invoked to handle the browser request.
4.3.4 JavaMail
The developers implemented interaction between the client and the business events in RUM by means of form elements (described in section 3.3) and email.
“The JavaMail API provides a set of abstract classes that model a mail system” [Dedieu, 1997]. It allows the ‘transparent’ sending and receiving of email from within Java applications. A connection to the mail server must be made for sending and receiving the messages because the JavaMail API is not a mail server, but the API does provide the framework for making that connection. JavaMail is inherently platform independent and is royalty-free.
In RUM, the JavaBean that was used by all the JSP pages, which required either the mail sending or receiving utility, was called the EmailBean. This Bean was used in order to:
▪ Send a personalised welcome email when a new user registered with the RUM system.
▪ Automatically send a user’s username and password if they clicked the ‘Lost Email’ button.
▪ Send a confirmation email, showing the products ordered and their costs, once a user had placed an order for memorabilia.
▪ Send an email to the Alumni Department showing the user’s order details and payment details.
CHAPTER 5 – Data Tier (Back-end)
The data tier handles the storage of persistent data. The interaction between the middle tier and the database is handled via the JDBC driver. The JDBC driver is also used to service the requests made by the middle tier, which can include querying and/or updating the database.
5.1 Technologies used in the RUM Data Tier
5.1.1 Microsoft Access Database (MS Access)
Microsoft Access 2000 was chosen as the database component of the data tier in RUM to store, organize, and share data. MS Access offers a set of tools rich enough for the most experienced database developer, yet accessible enough for first-time users and so maintenance of the database would be simple for the Alumni Department at Rhodes University. The other benefits towards the use of this database in RUM were:
▪ Rhodes University has a site license for the product.
▪ It includes an easy-to-use graphical user interface (GUI) for managing data hence, there is no need to learn SQL to maintain the system.
▪ It can be used to build applications rapidly.
5.1.2 Structured Query Language (SQL)
SQL may be regarded as a powerful programming language. Within an e-commerce environment, one collects and deploys information in a truly dynamic environment. SQL provides a means of retrieving information from a database via queries. However, SQL is not limited to just the retrieval of information. It can create tables and modify their structure. It can also insert, update and delete data. The term ‘query’ is simplistic compared to the actual power of SQL. “Part of its power lies in its ability to use a relatively simple set of commands and keywords in a variety of combinations that build on one another and provide a means of manipulating data in almost any way you can imagine, all customized to the web page user's needs” [eprogress Inc, 2000]. A simple example of a SQL statement, highlighted in bold, used in the SearchBean of RUM to retrieve details of all the products in the database is shown below:
StringBuffer check = new StringBuffer("SELECT * FROM PRODUCTS");
5.1.3 The Java Database Connectivity (JDBC) and the JDBC Driver
JDBC is a set of programming APIs, which allows Java applications to communicate with a variety of databases without having to write platform specific code [, 2002]. To use JDBC with a database management system such as MS Access, a JDBC Driver is required to mediate a connection between JDBC and the database. A JDBC driver is platform-specific and represents the layer of software that maps the JDBC specification to a database proprietary API specification. JDBC drivers are recognized and managed by the JDBC Driver Manager. The Driver Manager locates and assigns the appropriate JDBC driver for the application. Applications must call the Driver Manager and use JDBC calls to connect and access data. The JDBC drivers must conform to these calls and return data and messages to the client application according to the JDBC specification [Fields & Kolb, 2000].
Java applications can use any of the four JDBC driver types (these types are discussed in the team member’s thesis) that are available in order to access a database. RUM uses the ‘Type 1 - JDBC-ODBC Bridge plus ODBC driver’. This driver enables JDBC access via existing ODBC drivers to any ODBC database such as MS Access, which is the database used in RUM and thus, the type 1 driver had to be the choice for the RUM system. JDBC was used in RUM to facilitate the steps mentioned below:
1. Establish a connection with a database.
2. Send SQL statements.
3. Process the results.
The following code fragment from RUM gives a basic example of these three steps:
Class.forName(driver); //Establising a connection with the database
connection=DriverManager.getConnection(dbURL, login, password);
statement=connection.createStatement();
...
StringBuffer query = new StringBuffer("SELECT * FROM PRODUCTS WHERE [Category] = '"); //Sending SQL statements
query.append(type);
query.append("'");
try
{ ResultSet rs = statement.executeQuery(query.toString());
while(rs.next()) //Processing the results
{ String name = rs.getString("Name");
String prodID = rs.getString("Product ID");
double price = rs.getDouble("Price");
...
The JDBC API supports RUM’s 3-tiered model for database access very efficiently. JDBC is important in allowing database access from a Java ‘middle tier’. Commands are sent to the middle tier of services in RUM, which then send SQL statements to the database. The database processes the SQL statements and sends the results back to the middle tier, which then sends them to the user. The author found the 3-tier model very attractive because the middle tier makes it possible to maintain control over access and the kinds of updates that can be made to business data.
CHAPTER 6 – The Practical Implementation of RUM
6.1 The RUM Infrastructure
Figure 6.1: Lower-Level Infrastructure of RUM
The practical implementation of RUM was divided amongst the author and her team member as shown in Section 1.3.4. The next Section reviews the physical and logical layout of RUM in detail.
6.1.1 Client tier
The approach taken towards the design of RUM’s front end was the Page View with Bean approach (Section 3.1.2.2) as this promoted the division of labour due to the clear separation of the presentation and business logic within the system, thus providing cleaner JSP code. The actual application logic has been moved to the application server-tier and hence, this results in a ‘thin’ client front-end (Section 3.2). The front end of the system was accessed via a web browser. RUM was designed to be cross browser compatible and work with Internet Explorer and Netscape Communicator, two of the most common browser flavours. RUM’s GUI was designed using:
▪ HTML and HTML form based components for the static content of RUM.
▪ CSS for the special effects in RUM’s context sensitive help system.
▪ JavaScript for client side scripting.
▪ JSPs for the dynamic content of RUM.
6.1.2 The Middle Tier
All the business processing required by RUM was performed in this tier. Some of main the tasks handled by this tier are listed below:
▪ Validation of all form data.
▪ Sending and receiving email using the JavaMail API.
▪ Establishing a connection to RUM’s MS Access database.
▪ Session Tracking using JSP.
▪ RUM’s search engine.
▪ Securing sensitive information using SSL.
▪ The checkout process.
This tier implemented the following technologies:
▪ The Apache Tomcat Web server to process client requests and send responses.
▪ JSPs and JavaBeans for business processing and presentation logic.
▪ The JDBC API to connect to the data tier.
6.1.3 Data Tier
The primary goal of database design was to create a database that could be easily maintained and updated. This tier was used to house the MS Access database that had an easy-to-use graphical user interface (GUI) for managing data hence, was simple to use and maintain by the Alumni Department. Other reasons for this choice are discussed in Section 6.1.1. The database contained three tables:
▪ Customer: Stored user details.
▪ Products: Stored information describing each of the products available for sale.
▪ Delivery: Stored delivery costs according to three regions that were South Africa, Neighbouring Countries, and Other Countries.
6.1.4 The Interaction between the three tiers
As shown in Figure 6.1, users interact with RUM via a web browser over the Internet. 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. The middle tier communicates with the database in the data tier via SQL queries. The middle tier then processes the data it receives from the database and sends it back to the front-end as a response. Interaction flows linearly, tier by tier as shown in Figure 6.1.
Despite the fact that there is a logical separation between the three tiers, there is some overlap between them. Although JSP components reside in the middle tier, they play a major part in the presentation of the dynamic front-end data. Accordingly, middle tier objects need to access the database and also take care of some of the validation and interpretation of results gathered from the database. Similarly, the JSP components need to access the database and process the data that is obtained from the database. The JDBC driver enables this interaction and hence plays a role between these two layers.
6.2 The Design of the RUM Website
The author will now demonstrate a progressive analysis of the main web pages within RUM and their functionality. From this one can easily grasp the structure and implementation techniques used to create the website.
The author would like to re-iterate that a team of two members have implemented this project. It is to be noted that this report concentrates on the front-end of the RUM system and a brief summary on the back-end components, based on the division of work stated in Section 1.3.4. Please consult the team member’s report for a more detailed discussion
6.2.1 Flow Diagram showing a user’s typical shopping process traversal in RUM
The flow diagram (Figure 6.2), best illustrates the RUM’s site structure. The options available to the user when traversing through a typical shopping process in RUM are displayed. The functionality of the JSP pages will now be discussed and unique aspects that may help JSP developers in building simple, yet extremely functional JSP web sites will be explained.
6.2.2 RUM’s Design Concepts
The screen that appears when a user first accesses RUM is index.jsp (Figure 6.3). Here, users can look at an overview of RUM, and can also register as a new user using the Register Here link. The navigation bar at the top, as well as the text menu at the bottom of the page, is used to navigate around RUM. The following code shows how the text menu (bottom.jsp) was appended to each page of RUM using JSP:
These navigation bar, the text menu, and RUM’s search engine, appear on every page in the system for consistency, and to ensure that every page is easily accessible within the website. The design issues taken into consideration when designing the visual content of RUM were described in detail in section 7.6.
When a user logs on to RUM, the Log In link on the navigation bar of every page is automatically changed to Log Out. Additionally, the My Profile link is enabled when a user is logged in so he/she will be able to change their profile at any time. The opposite occurs when a user is not logged on to the system (Listing 6.1).
6.2.3 Logging into RUM
As its name suggests, this form allows a user to log into RUM. It has two form fields that need to be filled in, as well as three buttons (Figure 6.4). The Register link uses its own form, whereas the Login and the E-mail links are part of the same form. In order for this form to accommodate multiple submit buttons, JavaScript had to be used. An example of the code for the E-mail button is shown:
The Javascript’s onClick handler (Listing 6.2) is used to submit the form to the correct JSP page. In this case of the above example, if the E-mail button is clicked, the lostpasswd.jsp page is invoked.
6.2.3.1 Registering as a new user
The Register link is simply a normal image link to the register.jsp page (Listing 6.3)
When this link is clicked, a secure session is established between the user and the web server using SSL. Details about how secure sessions were implemented in RUM are contained in Section 4.2, hence it is sufficient to mention that the user is able to submit personal information via an encrypted session that provides a secure environment for sending and retrieving sensitive data across the Internet. The register.jsp page contains a form where a user is prompted to fill out the relevant form fields and submit his/her information. The information being collected is shown in Figure 6.5.
When the form is submitted by clicking the create account button, the data on the form is processed using the processreg.jsp page. This page uses the ValidationBean to validate the form data. These validation checks ensure that:
▪ All the mandatory fields are completed.
▪ All the fields that have been completed have the correct data.
▪ The user has entered a valid email address.
▪ The user password in greater than 6 characters long, and the user’s password and confirm password fields match.
All the errors that are caught during this validation process are stored in an error vector datatype. If the error object is found to be non-empty by the processreg.jsp page, the browser is redirected to the register.jsp page again to display the errors to the user. The validation process is explained in detail the next section.
If the registration process is successful and there are no further validation errors, the information collected is stored as a new record within the Customer table, and the processreg.jsp page informs the user that an email containing their log in details has been sent to their email address using the EmailBean (bean id=emai). All the database interactions within RUM occur using the ConnectionBean (id=connect) (Listing 6.4). The ConnectionBean maintains a connection to the database throughout the user’s session.
The customer is now ready to shop with RUM. At any point after registration, a user can update their existing profile using the update.jsp page, which has similar functionality to the register.jsp page.
6.2.3.2 Existing user logging into RUM
If a user is already registered with RUM, they can fill in their login details (email address and password) in the form provided (Figure 6.4). When the form is submitted by clicking the Log In link, the data on the form is processed using the processlog.jsp page. This page uses the CustomerBean to validate the form data. These validation checks ensure that:
▪ The two form fields do not contain empty strings.
▪ The email address exists in the customer table.
▪ The password entered is valid.
Again, all the errors that are caught during this validation process are stored in an error vector. If this error vector is found to be non-empty by the processlog.jsp page, the browser is redirected to the login.jsp page, which then displays the errors using the code similar to listing.
Figure 6.6 shows an example of how errors are displayed using the processlog.jsp page, which performs the validation for the Log In page if an incorrect email address is entered. The validation errors are displayed using the code snippet shown in Listing 6.3. If log in is successful, then the browser is forwarded to the index.jsp page and the user can begin shopping with RUM.
6.2.3.3 Forgotten password
If a user has forgotten their password, they can enter their email address and click on the e-mail link, which calls the lostpasswd.jsp page. This page is responsible for sending an email to the user’s email address, containing their log in details. This is done using the EmailBean (bean id=email). The lostpasswd.jsp page checks whether the email address exists in database and then, obtains the user’s password and name from the database, and uses this information to send a personalised e-mail to the user’s email address (Listing 6.6):
6.2.4 Product Categories - Stationery
The other category screens are similar in appearance and functionality so will not be discussed.
Users can browse through a categorized list of products available for sale by clicking on any of the category tabs in the navigation bar. For example, Figure 6.7 shows the Stationery page, stationery.jsp. The products displayed on this page, using the ProductBean (id=product) and ProductDisplay (id=prodview) beans, are dynamically retrieved from the products table in the database and each of the product prices are formatted to two decimal places (Listing 6.7):
For each of the displayed products in the stationery category, users can:
▪ Select the product they wish to purchase and add it to their shopping cart by clicking the Add To Cart link.
▪ Update the quantity of a product in the cart by clicking on the Update Quantity link.
▪ Remove a product from the cart by clicking on the Remove Items(s) link.
An example of the functionality of the Add To Cart link will be discussed now. The Remove Items(s) and Update Quantity links function similar to this.
For each product within the page a separate form is dynamically generated (Listing 6.8). The form does not allow more than two digits to be entered for the quantity field, thereby limiting the maximum desired quantity for each product to 99. The JSP link that processes the form is also dynamically generated. This is so that the page can identify which product’s Add To Cart link was clicked, and thus process the relevant product. The same JSP page, stationery.jsp, is used to process the Add To Cart button in each of the forms. An extract describing how a product is added to the shopping cart is shown below:
This code retrieves the desired quantity of the product from the form and creates a new ProductBean object, which is then added to the shopping cart via the ShoppingCart (id=cart) bean.
A user can also locate an item from the products table in the database, by using RUM’s search engine. The results obtained from the search are processed using the search.jsp page, which generates a list of the search results found. The dynamic generation of this list is similar to the code used to display the products in the category pages (Listing 6.7).
6.2.4 Checkout Process - Shopping Cart
After the user has finished adding items to their cart, they can click on the My Cart link to view the contents of their shopping cart. This is step 1 of the checkout process. From this screen, a user can:
▪ Update the quantity of their products by altering the quantity and clicking the Update Items link.
▪ Remove products by clicking on the remove link next to each of the products.
▪ Remove all the products in their shopping cart by clicking on the Remove All link.
It should be noted that each of these buttons are associated with their own form. The code used for the dynamic generation of the shopping cart displayed on this page is almost identical to the display of the products in the stationery.jsp page (Listing 6.7).
In addition, the Update Items link, and the Remove link next to each product both have similar functionality to the Add To Cart and Remove Item(s) links shown in the Stationery page. However, the Remove All link is processed using JavaScript. The JavaScript displays a dialogue box requesting the user to confirm the deletion of all the products in their shopping cart (Listing 6.10):
If the user wishes to clear their shopping cart, by clicking the Ok button, the form for the Remove button, rem, is submitted. The rem form invokes the processcart.jsp page, which contains the following code extract to handle this deletion:
After making the necessary adjustments to their shopping cart, the user can then click on the Proceed link to move to step 2 of the checkout process.
6.2.5 Checkout Process - Shipping Details
This is step 2 of the checkout process. Here, the user can verify their delivery details and can make changes to them if necessary. The details shown in the form are retrieved from the Customer table in the database. An interesting aspect of this form is demonstrated by the country field, which is also used in the update profile form and the new user registration form. In order to code the pull down list, the CountryBean (id=cbean) had to be modelled. This allowed the pull down menu to be dynamically generated and to show the country selected by the user (Figure 6.9):
The form elements are validated and the user can click on the Proceed link to move to step 3 of the checkout process. The user’s shipping details are stored in the OrderBean so they can be used further on in the other stages of the checkout process.
6.2.6 Checkout Process - Delivery Details
This is step 3 of the checkout process. In this page, the user can view their delivery cost according to the country they have selected within their shipping details. The delivery cost is retrieved from the delivery table in the database by means of the calcdelivery() function present in the Orderbean (id=order), and stored in the bean as well:
The user can then click on the Proceed link to move to step 4 of the checkout process.
6.2.7 Checkout Process - Payment Details
This is step 4 of the checkout process. Here the user can see a summary of the total cost of the products they have ordered including the delivery cost. They can select the payment method they wish to use to purchase the products they have ordered. JavaScript is used to automatically select the credit card radio button if any credit card details are entered in the form. There is also JavaScript code to automatically clear the credit card details if the cheque/postal order radio button is selected (Listing 6.13)
The jsp:getProperty tag shown above, is used to make the form remember the previous value which are entered into the textbox when the form is redisplayed after any validation errors. Validation of the credit card form details is done using the OrderBean. It checks if:
▪ All the fields are completed.
▪ The date entered in the date field is of a valid format.
▪ The credit card number is valid. This is performed using a check digit calculation algorithm on the number.
After successful completion of the payment details, the user can then click on the Proceed link to move to step 5 of the checkout process.
6.2.8 Checkout Process - Confirmation Details
This is step 5, the final step of the checkout process. Here the user is informed that their order has been submitted for processing. This page sends an email to the user, confirming their order with a summary of the products that they have ordered (Figure 6.12). It also sends an email to the Alumni Department with the user’s order summary and payment details. It then performs some housekeeping to clear any sensitive information immediately from the server for security purposes, and also empties the shopping cart. This is illustrated in Listing 6.14.
The developers have ensured that the system is as robust as possible. As shown in the housekeeping code (Listing 6.14), the ordered property of the OrderBean has been set to true. The confirmation page checks the status of this ordered property and if it found to be true, then the user is forwarded to an error page, error2.jsp (Listing 6.15). Therefore, a customer cannot place the same order multiple times.
Naturally, the ordered property is reset to false at the beginning of the checkout process, i.e., in the mycart.jsp page to allow the user to place a new order if the wish to do so.
The developers have also ensured that manual typing of the URL of any of the stages in the checkout process cannot be done. Each page in the checkout process has been assigned a sequence number. This sequence number is embedded as a hidden form field and submitted to the next page in the process. Each of the checkout pages has code to check that the correct sequence number is submitted from the previous page:
Listing 6.16 is taken from the payment.jsp, which is the fourth stage in the checkout process and hence should check that the sequence number submitted from the previous page was 3. Thus, manually typing in the URL will result in the sequence parameter being null and the browser will be forwarded to error.jsp error page.
6 The Context Sensitive Help System
At any point within RUM, a user can access the context sensitive help system, by clicking the Help link on the navigation bar or the text menu, and can browse through any of the help topics as shown in figure 6.13. An example illustrating this feature is shown using update.jsp, which is used to update a user’s profile. When the help link on this page is clicked, the JavaScript hlp function (Listing 6.17) is called. The name of the help page, in this case update.html, which needs to be invoked, is passed to the hlp function as a parameter (listing 6.18):
The hlp function (Listing 6.17) performs the following tasks:
▪ A new browser window is opened with the specified height and width attributes, and is automatically centred to the screen.
▪ The HTML for the window is dynamically generated by the msg.document.write function.
▪ Two frames are created:
▪ The right frame points to the parameter (wn) that is passed to this function and this displays the correct help page. In this example, the update.html page will appear in the right frame.
▪ The left frame always opens the menu.html page, which contains a list of all the help topics available.
The menu.html page in the left frame uses CSS to add a rollover effect to the list of help topics available. The CSS code (Listing 6.19) describes which colour is used for each of the various states of the links.
6.2.10 Logging out of RUM
A user can log out of RUM at anytime using the logout page, logout.jsp. As detailed in Section 4.1, a session object is automatically created for each user. Its default session timeout property is set to 30 minutes meaning that if the user does not traverse any of the JSP pages within a 30 minute time period, the user’s session information is discarded from the web server. However it is possible to destroy the user’s session explicitly, before the session timeout occurs by using the session.invalidate() method. Therefore if a user clicks the Log Out link, this method is called and the user’s session is released from memory.
6.2.11 Security in RUM using SSL
As mentioned in Section 4.2, when sensitive information needs to be transferred from the client’s machine to the web server and vice-versa, this information is encrypted using SSL. It would be inefficient to make every web page in RUM secure since the SSL security scheme is slow and causes major performance strain on a web server, so the developers ensured that only certain pages that involved the exchange of sensitive information were made secure. This was done using the following code which was embedded using the include directive, in every page of RUM:
This code checks the URL for the current page being displayed, and if the page does not have the required prefix, in this case https, the browser is forwarded to the page with the correct prefix. The example illustrated in Listing 6.20 effectively forces pages to be secure by using the https prefix. Similarly, pages that were not required to be secure have been forced to have an http prefix.
6.2.12 An Overview of the JavaBeans used in RUM
This section provides information about the JavaBean components, which have been used in RUM. They form the core of the business logic within the system and are discussed in detail in my team member’s thesis.
6.2.12.1 ConnectionBean
As the name suggests, this bean is responsible for connecting to the database. An instance of this object is created, each time a user accesses RUM, and remains active for the duration of the user’s session.
6.2.12.2 CountryBean
This bean holds an array of all the possible countries, which can be selected, when the user needs to enter his/her details. This array was used to dynamically generate the pull-down menus in the relevant forms. It was also used to enable the forms to ‘remember’ which pull down option was selected, when the forms are redisplayed in the event of an error.
6.2.12.3 CustomerBean
The CustomerBean maintains all the details of the customer who is currently logged onto the system. Like the ConnectionBean, an instance is also created each time a customer accesses the system. The bean also performs additional functions being:
▪ Validating customer logins,
▪ Adding new customers to the database, and
▪ Updating customer details in the database
6.2.12.4 EmailBean
The EmailBean handles all the confirmation e-mails, which need to be sent. The bean dynamically constructs the e-mail messages and then sends them using the local e-mail server.
The bean sends:
▪ A Welcome e-mail for new customers,
▪ Order confirmation e-mails to customers who have just ordered,
▪ Order details to the Alumni Department, and
▪ Customer login details to customers who have lost them
6.2.12.5 OrderBean
The OrderBean holds the details of the order currently being placed. It also validates the credit card information using a mathematical formula.
6.2.12.6 ShoppingCart
The ShoppingCart bean holds the contents of the customer’s shopping cart in the Vector datatype. The Vector holds elements of type ProductBean (which is explained below). It basically allows products to be added, updated and removed from the cart.
6.2.12.7 ProductBean
The ProductBean merely describes the details of a product. It is used in the ShoppingCart bean described above.
6.2.12.8 ProductDisplay
This bean is responsible for retrieving the products from the database so that they can be dynamically displayed in each of the product pages.
6.2.12.9 SearchBean
The SearchBean forms the core of RUM’s product search engine. It receives input from the search form and performs a sequential search through the database for the required product(s). The results are returned in an array of Result objects (described below), which are then used by the search.jsp page.
6.2.12.10 Result
Result is a Java class, which describes details of a single product that has been found in a product search.
6.2.12.11 ValidationBean
The ValidationBean is the most complex bean in the entire system. Its responsibility is the validation of each of the HTML form elements in RUM. The forms that this bean validates include:
▪ Customer registration form,
▪ Profile Update form, and
▪ Shipping details form
▪ Date in the Payment details form
6.3 Implementation Problems
The implementation problems that were encountered during the design of RUM’s front-end are discussed below:
▪ Cross-browser compatibility
The author experienced some problems when designing RUM to be cross-browser compatible. These were discussed in detail in Section 3.5. The system was tested and implemented to function under Netscape Communicator and Internet Explorer. However, certain visual aspects, such as the rollover effect of the Help menu in RUM (Figure 6.10), do not work in Netscape Communicator.
▪ Spacing of Images using HTML
It was found that the browser would space adjacent images incorrectly if the code for each image was placed on separate lines. This had to be solved by placing the code for each image on the same line in the file. This adversely affected the readability of code, however it was the only known solution to the problem.
▪ Memorabilia out of stock
The author could not obtain images of memorabilia to use in the system and so was forced use a limited set of images provided by the university.
▪ jsp:setProperty Tag issue
The author found that the jsp:setProperty tag with the wildcard character, ‘*’, did not set the bean properties corresponding to blank form elements. This means that if for example, a user entered a value in an optional form field and a validation error occurred, and then the user decided to clear the value from that field, the bean property for that field would still retain the original value. This problem was solved by manually clearing all the bean properties before calling the setProperty tag.
CHAPTER 7 – Conclusion and Possible Enhancements
7.1 Conclusion
This project has fulfilled its primary objectives. Firstly, the production of RUM, a small to medium scaled e-commerce application for use by anyone intending to purchase memorabilia from Rhodes University, through the Internet. Secondly, this research report, which highlights the design and implementation concerns pertinent to the functionality of the developers’ system. The layout of this report reflected the chronological development of the project.
Putting together an enterprise-level application such as RUM involves design consideration issues and integration of various technologies. The benefits of using Java technologies, particularly its platform independence advantage, makes it ideally suited for Internet-based applications and provides an attractive alternative to other closed and proprietary systems. JSPs and JavaBeans have been proven to be advantageous as they promote the division of labour. This allowed the system to be completed productively by a team of two developers.
RUM can be implemented successfully by the Rhodes University Alumni Department to facilitate the sales of memorabilia via the Internet. Furthermore, the system consists of a thin client web-based application modeled using a combination of free and developer friendly software. Its modular structure enables the Alumni Department to upgrade and maintain it with relative ease.
7.2 Possible Enhancements
The following points constitute some of the areas that could be considered as possible enhancements to this project:
7.2.1 Automatic Stock Control
Keeping track of stock levels of the memorabilia currently available for sale would be a useful extension to RUM. This would help with the maintenance of the Alumni Department’s stock records automatically. The customer would also be informed of any products that are out of stock, thereby removing the possibility of the customers ordering items that are unavailable. This feature will also ensure that the product catalogue is always up-to-date.
7.2.2 Implementing Connection Pooling
A connection pooling approach to database connection establishment and usage would greatly benefit this system. JavaBeans would simply get connections to RUM’s database when needed and return them to the pool once they are finished with them so that they could be reused. Database access time would be significantly improved if this approach can be implemented, resulting in RUM being faster and more efficient.
7.2.3 Implementation of real time credit card transaction processing
With the current system, only validation of the credit card number, provided by the user, is performed using a mathematical algorithm. Real time credit card transactions cannot be made to purchase products, as this requires what is known as a merchant account to process credit card transactions, and this must be obtained from a bank. Another enhancement to this project would then be to configure RUM so that it would process shopping cart orders automatically by charging the customers credit card and depositing the funds into the Rhodes University bank account.
7.2.4 Dynamic recommendations
According to Reynolds [2000] “This is the process of attempting to sell additional goods to customers, that they are likely to desire, based on their shopping habits.” Such an investigation would be useful towards improving the marketing of RUM. The first stage in the recommendation process would be to take a snapshot of the orders currently in the system, and pass them over to a recommendation processor. The recommendation processor would then aggregate all of the orders ever placed for each individual item in the product catalogue. The results obtained are ordered and written to a recommendations database. This database would then be used to examine the real world buying habits of RUM’s customers.
References
|[Addy and Associates, 2000] |Addy and Associates, What is SSL?, , Addy and Associates, |
| |Inc., 2000. |
|[Amazon, 2002] |, The place to find and discover anything you want to buy online, , |
| |, Inc., 2001. |
|[Andy, 2000] |Andy. L, JSP via the Web server, .au/support/hosting/jsp/faq.html, Netregistry, |
| |2000. |
|[, 2002] |, Java Database Connectivity, |
| |, , 2002. |
|[Chaffee, 2000] |Chaffee. A, One, two, three, or n tiers?, |
| |, JavaWorld, 2000. |
|[Computing Alternatives, 2000] |Computing Alternatives, Computing Alternatives Methodology, |
| |, Computing Alternatives, Inc., 2000. |
|[Consulting Company, 1999] |Consulting Company, Web Servers, technical/netserv/servers/web-server.pdf, Consulting|
| |Company, 1999. |
|[Corezon Corporation, 2001] |Corezon Corporation, Corezon Application Architecture, |
| |, Corezon Corporation Ltd, 2001. |
|[Dedieu, 1997] |Dedieu. O, Introduction to the Java Mail API, |
| |, Java-, 1997. |
|[Dumermuth, 2000] |Dumermuth. R, Brand New: J2EE, |
| |, Sum Microsystems, 2000.|
|[Fields and Kolb, 2000] |Fields. D. K and Kolb. M. A., Web Development with JavaServer Pages, Manning Publications Co., |
| |United States of America, 2000. |
|[Garbagnati, 2000] |Garbagnati. A. A, Tomcat FAQ Homepage, , jGuru, 2000. |
|[Hameed, 2002] |Hameed. I, Comparing J2EE with .NET, , |
| |About, Inc., 2002. |
|[Holyer, 1997] |Holyer. A, HTML in easy steps, Comdex Publishing, India, 1997. |
|[Hughes and Birznieks, 2001] |Hughes. C and Birznieks. G., Serving Up Web Server Basics. |
| |, INT Media Group, Incorporated., 2001. |
|[Hughes and Birznieks, 2001] |Hughes. C. and Birznieks. G., Serving Up Web Server Basics. |
| |, INT Media Group, Incorporated., 2001. |
|[Infoworld Media Group, 2001] |Infoworld Media Group, Designing high performance scalable applications, |
| |, Infoworld Media Group, Inc., 2001. |
|[Intel Corporation, 2000] |Intel e-business whitepaper, Building a better e-business infrastructure, |
| |, Intel Corporation, 2001. |
|[, 2002] |, Creating a Web Site - a step by step guide, |
| |, , 2002. |
|[Levine, 1999] |Levine. A, About Javascript, , Maricopa |
| |Community Colleges, 1999. |
|[Naude, 2001] |Ndinga. R, R.E.X., Rhodes E-commerce Exchange, Honour’s Thesis, Rhodes University, 2001. |
|[Naughton and Schildt, 1999] |Naughton. P and Schildt. H, The Complete Reference Java2, Tata McGraw-Hill, India, 1999 (third |
| |edition). |
|[Ndinga, 2000] |Ndinga. S. S, An Investigation into Tools and Protocols for Commercial Audio Web-site Creation, |
| |Master’s Thesis, Rhodes University, 2000. |
|[PacificOnline, 2002] |Deitel. H, Annual online spending climbs, , PacificOnline |
| |Internet Access, 2002. |
|[Reynolds, 2000] |Reynolds. M, Beginning E-commerce, Wrox Press Ltd., United Kingdom, 2000. |
|[Schultz, 2001] |Shultz. C, Advantages and disadvantages between Tomcat, JRun, and JServ for Apache Web Server, |
| |, jGuru, 2001. |
|[Shneiderman, 1998] |Shneiderman. B, Designing the User Interface - Strategies for Effective Human-Computer Interaction,|
| |Addison Wesley Longman Inc., United States of Amercia, 1998 (third edition). |
|[Stipp, 2001] |Stipp. H, Research on Media Use and the Internet, |
| |, University of Maryland, 2001. |
|[tikSystems, 2002] |tikSystems, Multi-tier Architecture (3 tier) |
| |, tikSystems Ltd, 2002. |
|[Vawter and Roman, 2001] |Vawter. C and Roman. E., J2EE vs. A comparison of building XML-based web services, |
| |, The Middleware Company, 2001. |
|[Wayner, 1997] |Wayner. P, Digital Cash, Academic Press Ltd, United Kingdom, 1997. |
|[Webopedia, 2002] |Webopedia, The only online dictionary and search engine you need for computer and Internet |
| |technology, , INT Media Group, Incorporated., 2002. |
|[eprogress Inc, 2000] |eprogress, Enabling Technologies, , eprogress Inc, 2000. |
Appendix A : RUM’S File Hierarchy
Appendix B : Installing and Configuring RUM under Windows
This Appendix provides instructions on how to install and configure RUM under all flavours of the Microsoft Windows Operating System. Individuals are free to modify the code and/or configuration if they so wish. It is assumed that the user has some intermediate knowledge about their version of the Windows Operating system, as well as a little programming knowledge.
1. Copying the Files
The author has included a batch file on the CD that will automatically copy the required files to the user’s hard drive. The batch file installs:
▪ JDK 1.3
▪ JavaMail 1.3
▪ Apache Tomcat 4.0
▪ Java Secure Socket Extensions 1.0.3
Before installation, the user must ensure that there is at least 100Mb of free space on the destination drive. To install the system, the user must open a DOS Window and type the following command:
D:\install C:
Where D is the drive letter of the user’s CD-ROM drive and C is the drive letter of the hard drive that the user wishes to install RUM
The user will also need to install a licensed version of the Microsoft Access 2000 Database. He or she should then consult the documentation, which came with Access 2000 for more details.
2. Setting up the Environment Variables
After the files have been copied, the user must create and modify the following environment variables as follows:
CLASSPATH =
C:\jdk1.3\bin;.;C:\jdk1.3\jre\lib;C:\jdk1.3\lib;C:\javamail-1.3\mail.jar
CATALINA_HOME = C:\jakarta-tomcat-4.0
JAVA_HOME = C:\jdk1.3
JSSE_HOME = C:\jsse1.0.3
PATH = %PATH%; C:\jdk1.3\bin
Where C is the drive where RUM is installed, and %PATH% is the existing path.
3. Configuring RUM
All of the coding in RUM was done using the UltraEdit text editor. The user is free to use any other text editor such as Notepad. RUM is currently configured to run under the machine that was used to develop it. Users wanting to implement RUM will need to edit some of the JavaBean files (with a .java extension) in order to run it on their machines. The following changes will need to be made:
EmailBean.java
▪ The e-mail address frokwon@rucus.ru.ac.za needs to be changed to the address of the user
▪ The SMTP server address, for sending e-mails, (mail.ru.ac.za) needs to be changed to the address of the user’s SMTP server
ConnectionBean.java
The database is currently configured without a username and password. If the user sets up a username and password for the DBMS, then the corresponding variables in the JavaBean must be set.
Once the above-mentioned changes have been made, the JavaBeans must be compiled again before they can be used.
In order for the JavaBeans to access the database, the ODBC drivers need to be set up. The following steps briefly outline the process:
1. Open the ODBC Data Source Administrator in the Windows Control Panel
2. Select ‘MS Access Database’ under User Data Sources, and click Configure
3. Click the Select button to choose the database
4. The database must then be selected. It should be located in the C:\jakarta-tomcat-4.0\webapps\ROOT\database folder
RUM is now ready to be accessed via a web browser! To start the web server, the user should type C:\jakarta-tomcat-4.0\bin\startup. The user may want to create a shortcut to this batch file for convenience. The web server may be shut down at any time by pressing Ctrl-C while the Tomcat window is in focus.
Appendix C : Glossary
|. NET |“A Microsoft operating system platform that incorporates applications, a suite of tools and |
| |services, and a change in the infrastructure of the company's Web strategy.” [Webopedia, |
| |2002] |
|ACTIVE SERVER PAGES |“A specification for a dynamically created Web page with a .ASP extension that utilizes |
| |ActiveX scripting - usually VB Script or Jscript code. When a browser requests an ASP page, |
| |the Web server generates a page with HTML code and sends it back to the browser.” [Webopedia,|
| |2002] |
|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, 2002] |
|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, 2002] |
|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, 2002] |
|ASP |See Active Server Pages. |
|BROWSER |See Web Browser. |
|CASCADING SYTLE SHEETS |This is a “new feature being added to HTML that gives both Web site developers and users more|
| |control over how pages are displayed.” [Webopedia, 2002] |
|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, 2002] |
|COOKIE |This is “message given to a Web browser by a Web server. The browser stores the message in a |
| |text file. The message is then sent back to the server each time the browser requests a page |
| |from the server. |
| |The main purpose of cookies is to identify users and possibly prepare customized Web pages |
| |for them.” [Webopedia, 2002] |
|CSS |See Cascading Style Sheets. |
|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 Mark-up 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, Server-side Includes (SSI), cookies, Java, |
| |JavaScript, and ActiveX.” [Webopedia, 2002] |
|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, 2002] |
|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, 2002] |
|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, 2002] |
|GUI |See Graphical User Interface. |
|HIDDEN FORM FIELDS |These are used as a way to support session tracking. Because Hidden fields are 'hidden' they |
| |can contain useful information which as web page developers we can use to hide information |
| |from the visitor. When a form is submitted, the value of the hidden field is passed along |
| |with the other form values. |
|HTML | |
| |See Hypertext Mark-up Language. |
|HTTP |See Hypertext Transfer Protocol. |
|HTTPS |See Hypertext Transfer Protocol Secure. |
|HYPERTEXT MARK-UP LANGUAGE |Handles the formatting and display of web pages. |
| |[Webopedia, 2002] |
|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, 2002] |
|HYPERTEXT TRANSFER PROTOCOL SECURE |“The secure version of HTTP using certificates that can uniquely identify the server and |
| |client, and encrypt all communication between them.” [, 2002] |
|IMAP |See Internet Message Access Protocol. |
|INTERNET |An enormous, global network linking of millions of computers. [Webopedia, 2002] |
|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, 2002] |
|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, 2002] |
|JAVA DATABASE CONNECTIVITY |The Java Database Connectivity, JDBC, API enables Java programs to execute SQL statements. In|
| |this way Java applications and programs can interact with SQL-accommodating databases. |
| |[Webopedia, 2002] |
|JAVA DEVELOPMENT KIT |“This is a software development kit (SDK) for producing Java programs.” [Webopedia, 2002] |
|JAVA SERVER PAGES |The technology provided by JSPs enables the developer to combine “regular, static HTML with |
| |dynamically generated content from servlets.” [Hall, 2000] |
|JAVA VIRTUAL MACHINE |This is “an abstract computing machine, or virtual machine, JVM is a platform-independent |
| |execution environment that converts Java bytecode into machine language and executes it.” |
| |[Webopedia, 2002] |
|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 |See Java Database Connectivity. |
|JDBC DRIVER |A JDBC driver allows a Java application to communicate with a SQL database. |
|JDK |See Java Development Kit. |
|JSP |See Java Server Pages. |
|JVM |See Java Virtual Machine. |
|LOAD BALANCING |Making use of multiple web servers to minimise the performance-hampering bottleneck |
| |experienced by a single web server serving too many clients. |
|MIDDLEWARE |“Software that connects two otherwise separate applications.” [Webopedia, 2002] |
|ODBC |See Open database connectivity. |
|OPEN DATABASE CONNECTIVITY |ODBC “is a standard database access method developed by Microsoft Corporation. The goal of |
| |ODBC is to make it possible to access any data from any application, regardless of which |
| |database management system (DBMS) is handling the data.” [Webopedia, 2002] |
|PAGE CENTRIC APPROACH |Applications implementing this approach have a series of interrelated JSP pages where the |
| |user proceeds from one page to another. In this approach, client requests are serviced by |
| |JSPs or servlets, which directly access resources such as a database. The JSP page is where |
| |the request is received and processed, and the response sent back to the client. |
|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, 2002] |
|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. |
|SECURE SOCKET LAYER |This is “a protocol developed by Netscape for transmitting private documents via the |
| |Internet. SSL works by using a public key to encrypt data that's transferred over the SSL |
| |connection. Both Netscape Navigator and Internet Explorer support SSL, and many Web sites use|
| |the protocol to obtain confidential user information, such as credit card numbers. By |
| |convention, URLs that require an SSL connection start with https: instead of http.” |
| |[Webopedia, 2002] |
|SERVER SIDE INCLUDES |“A type of HTML comment that directs the Web server to dynamically generate data for the Web |
| |page whenever it is requested.” [Webopedia, 2002] |
|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] |
|SERVLET CENTRIC APPROACH |This model is roughly based on the Model-View-Controller (MVC) programming construct. The |
| |Controller controls the flow of data, and determines where to direct requests both into and |
| |out of the system. The Model is the processing and data layer. The View is the layout of the |
| |program and what the user actually sees - the user interface. |
|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, 2002] |
|SMTP |See Simple Mail Transfer Protocol. |
|SQL |See Structured Query Language. |
|SSI |See Server Side Includes. |
|SSL |See Secure Socket Layer. |
|STRUCTURED QUERY LANGUAGE |“Standardized query language for requesting information from [and maintaining information in]|
| |a database.” [Webopedia, 2002] |
|THICK CLIENT |“In a client/server architecture, a thick client is a client that performs the bulk of the |
| |data processing operations.” [Webopedia, 2002] |
|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, 2002] |
|THREE-TIER CLIENT-SERVER 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 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, |
| |2002] |
|URL |See Uniform Resource Locator. |
|URL REWRITING |This is the term used to refer to the process of modifying (or rewriting) a URL within Web |
| |content such that the resulting URL points to a different location than the original URL. |
| |This can be used as a way to support session tracking. |
|WEB BROWSER |This is a “software application used to locate and display Web pages. The two most popular |
| |browsers are Netscape Navigator and Microsoft Internet Explorer.” [Webopedia, 2002] |
|WEB SERVER |Traditionally “a computer that delivers (serves up) Web pages.” [Webopedia, 2002] |
|WORLD WIDE WEB |A global heterogeneous collection of connected networks and computers. |
|WWW |See World Wide Web. |
|XML |See Extensible Mark-up Language.. |
RUM Poster
The next page of this research report is a foldout A3 version of the author’s project poster. This poster visually summarises the investigation, report and the RUM system
-----------------------
Implementation
Presentation
HTML &
JSP tags
Author
Enterprise
JavaBeans
Team Member
Listing 4.3: Sample code defining part of ‘CustomerBean.java’
Listing 4.2: Example of a JSP Scriptlet Tag
JSP
Business
Processing
Request
Response
Response
Request
Business
Data
JSP
Bean
Servlets or JSPs
(CONTROLLER)
Presentation specific JSP (VIEW)
JavaBeans
(MODEL)
Database
(MODEL)
Client
Figure 3.1: The Servlet Centric Approach
Listing 4.1: Example of a JSP Declaration Tag
Data Tier (Server PC)
Application Server Tier (Server PC)
Client Tier (User PC)
Query
Request
Request
HTML
MS Access
Database
JDBC
API
JavaBeans &
Java Classes
Tomcat Web Server
JSP
Technologies
Web Browser
Internet Explorer / Netscape
Query Request
Table 3.1: Advantages and disadvantages of JavaScript [Adapted from Levine, 1999]
Listing 6.19: The rollover effect in the Help System using CSS
A:link {color:"#FFFFCC";text-decoration:none;}
A:visited {color:"#FFFFCC";text-decoration:none;}
A:active {color:"#B4B6B0";text-decoration:none;}
A:hover {color:"#E8B055";text-decoration:none;}
Listing 6.18: Sending the correct link to the hlp function to create a context sensitive help
Figure 1.1: Annual online spending climbs [PacificOnline, 2002]
Listing 6.17: Context Sensitive Help System using JavaScript
function hlp(wn) {
topx = (screen.width - 720) / 2;
topy = (screen.height - 400) / 2;
if (screen.width == 640)
{
topx = 610;
}
msg=window.open("","","height=400,width=720,top="+topy+",left="+topx);
msg.document.write("");
msg.document.write("");
msg.document.write("RUM Help");
msg.document.write("");
msg.document.write("");
msg.document.write("");
msg.document.write("");
msg.document.write("");
}
Listing 6.13: RUM’s Context sensitive help system
CSS used for rollover effect
Context Sensitive help system
Listing 6.16: Error page generated in user types URL manually into broswer’s address bar
Listing 6.15: Error page generated if the same order is made more than once
Listing 6.12: Confirmation of order, confirmation.jsp
Listing 6.14: Sending emails to the user and the Alumni in confirmation.jsp
Listing 6.13: JavaScript to automatically clear credit card details and select correct radio button
//function automatically selects correct radio button when credit card //details entered & clears credit card details when cheque option is chosen
function auto()
{
document.creditcard.payment[1].checked = true;
}
//clears shipping details textboxes
function clr()
{
document.creditcard.cardname.value = "";
document.creditcard.expirydate.value = "";
document.creditcard.cardnumber.value = "";
}
...
Credit Card
...
Figure 6.11: Method of Payment, payment.jsp
Form validation, including Credit Card No validation using mathematical algorithm
JavaScript to detect selected radio button
Summary of order made by user
Figure 6.10: User’s delivery cost details, delivery.jsp
Delivery cost is dynamically generated according the country chosen in the shipping details
Listing 6.12: CountryBean used to retrieve a country and dynamically generate the pull-down menu
Figure 6.9: User’s shipping details, details.jsp
Dynamically generated pull down list modelled using CountryBean
User’s shipping details dynamically retrieved from CustomerBean
Listing 6.11: Function used to process the Remove All link
...
if(request.getParameter("action").equals("all"))
{ %>
0) {cart.addToCart(toAdd);}
}
catch (NumberFormatException e) {}
Listing 6.8: The dynamic generation of the Add to Cart link for each product in stationery.jsp
Desired quantity :
Update items in Cart
Max = 99
Listing 6.7: The Stationery category page, stationery.jsp page
Remove item from Cart
Stationery products
Add items to Cart
...
...
R
...
Listing 6.7: Dynamic display of products in stationery.jsp
Listing 6.7: Displays of the products dynamically on stationery.jsp
Listing 6.6: Sending an email to a user with their log in details, lostpasswd.jsp
...
String passwd = email.retrievePassword(connect); //retrieve password
String name = email.retrieveName(connect); //retrieve first, last name
email.sendPassword(name,passwd); //send personal email with login details
Listing 6.5: Display of validation errors due to incorrect log in details
0) {
%>
Unable to log In. Please correct the following errors :
Figure 6.6: Validation Errors In RUM, processlog.jsp
[pic]
Validation errors displayed
...
String fstname = request.getParameter("fstname"); //get first name
String passwd = request.getParameter("passwd"); //get password
String email = request.getParameter("email"); //get email address
...
if the customer is an existing member
{
//process an update profile function
}
else //process new user registration
{
customer.addCustomer(connect); //add the new record to the database
emai.sendWelcome(fstname,passwd);//send welcome email to new user
} //with first name and log in details
Listing 6.4: Emailing user and creating user record in database after successful registration
Figure 6.5: New User Registration Form, register.jsp
Listing 6.3: Form for the Register link in login.jsp
Listing 6.2: Functionality of the Multiple submit buttons in login.jsp
Figure 6.4: RUM’s Log In Page, login.jsp
Request for an email containing their username and password details, in the case of a lost password
3
Log in if they are already registered
2
1
Register as a new user
Listing 6.1: Dynamic changes with links and images according to whether the user in logged in to RUM
Figure 6.3: RUM’s Main Page, index.jsp
Text Menu
Search
Navigation Bar
logout.jsp
Figure 6.2: Flow Diagram showing a typical shopping process in RUM
Context Sensitive Help pages
are accessible from any of the pages in the system
mycart.jsp
register.jsp
index.jsp
details.jsp
delivery.jsp
payment.jsp
confirmation.jsp
Shop - Search OR Categories
login.jsp
lostpasswd.jsp
Existing User
New User
update.jsp
Listing 6.20: Forcing pages with sensitive information to be secure
Listing 3.1: JavaScript Example showing the creation of a ‘400 x 370’ web browser window
Listing 4.4: Sample code from RUMs processlog.jsp to set and get properties from CustomerBean
Table 4.1: Possible Bean Scopes
Figure 4.2: How a Web Server Functions [Consulting Company, 1999]
Figure 4.2: Advantages and Disadvantages of the Apache Tomcat Web Server
Listing 5.1: Example describing the usage of JDBC within RUM
Submitted in partial fulfillment of the requirements of the degree
Bachelor of Science (Honours)
of Rhodes University
(Joint Project)
By Uma Rudraraju
Computer Science Department
November 2002
ROOT
index.jsp
products
All the image files of the memorabilia for sale
images
All the image files used in the RUM Website
templates
http.jsp, https.jsp, bottom.jsp
steph.html, aboutush.html, carth.html, changeh.html, confirmationh.html, contacth.html, deliveryh.jsp, detailsh.html, help.html, loginh.html, menuh.html, mycarth.html, navigateh.html, orderh.html, paymenth.html, privacyh.html,, registerh.html, returnh.html, searchh.html, abouth.html, termsh.html, updateh.html, welcomeh.html, help.js
help
changepass.jsp, login.jsp, logout.jsp, lostpasswd.jsp, processlog.jsp, processreg.jsp
register.jsp, update.jsp
customer
glassware.jsp, clothing.jsp, search.jsp
stationery.jsp, accessories.jsp
shopping
checkout
confirmation.jsp, delivery.jsp, details.jsp
mycart.jsp, payment.jsp, processcart.jsp
errors
error.jsp, error2.jsp
database
Products.mdb
WEB-INF
web.xml
ValidationBean.class, ConnectionBean.class
CustomerBean.class, Result.class, EmailBean.class, CountryBean.class
ShoppingCart.class, ProductBean.class
ProductDisplay.class, SearchBean.class
OrderBean.class
classes
Figure 4.1: Achieving Division of Work with JSP
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- an introduction to marketing pdf
- an introduction to moral philosophy
- an introduction to business
- an introduction to r pdf
- an introduction to an essay
- an introduction to linguistics
- an introduction to formal logic
- an introduction to information retrieval
- an introduction to hazardous materials
- an introduction to literature pdf
- an introduction to community development
- chapter 8 an introduction to metabolism key