ORDERING STONES - People



ORDERING STONES

FOR THE SENIOR SIDEWALK OF

KANSAS STATE UNIVERSITY

By

PRADEEP KUMAR TALLOGU

B.E., Karnatak University, Hubli, India, 2001

A REPORT

submitted in partial fulfillment of

the requirements for the degree

MASTER OF SCIENCE

Department of Computing and Information Sciences

College of Engineering

KANSAS STATE UNIVERSITY

Manhattan, Kansas

2003

Abstract

The report describes the design, coding, implementation and performance analysis of a website that is designed for the KSU Foundation.

The KSU Foundation has implemented the Senior Sidewalk project as one of its programs for the alumni of KSU. It accepts orders for stones on the Senior Sidewalk. The website presents a sequence of steps through which the alumni can enter the required information for the transaction including student’s graduation date, ID number, credit card information etc, and order a stone.

A B2B portal, Stoneware, drives the web pages of the KSU Foundation. The Java APIs that Stoneware provides for login, authentication, database connectivity etc, are used and two utility packages edu.ksu.util and edu.ksu.beans have been created. These packages incorporate all the required functionality needed for the Senior Sidewalk project. The JSPs at the front end import the required classes and use them appropriately during the transaction. The website is analyzed at various points and its performance is evaluated.

TABLE OF CONTENTS

List of Figures…………………………………………………………….……………..ii

Acknowledgements ……………………………………………………………………. iii

1. Introduction…………………………………………………………………………. 1

1.1 Purpose………………………………………………………….. ………........1

1.2 Architecture………………………………………………………………........1

2. Client Tier …………………………………………………………………………...2

2.1 JSP Pages ……………………………………………………………………..2

2.2 Why JSPs? .…………………………………………………………………...4

3. Web Services Container …………………………………………………………….5

3.1 Stoneware Design …………………………………………………………….6

3.2 Auto-Login …………………………………………………………………...8

3.3 Development ………………………………………………………………....11

4. Java Beans ………………………………………………………………………….12

4.1 Package edu.ksu.util ………………………………………………....12

4.2 Package edu.ksu.beans…………………………………………………14

4.3 Class diagram ………………………………………………………………..17

5. Database ……………………………………………………………………………18

5.1 Database Connection ………………………………………………………..18

5.2 Table Schema ……………………………………………………………….18

6. Screen shots ………………………………………………………………………..21

7. Testing and Performance …………….……………………………… ……………23

7.1 Client/Server Configuration.……..…………………………………………. 23

7.2 Throughput …………………………………………………………………. 24

7.3 Latency ………………………………………………………....................... 25

7.4 Testing for different values of inputs ………………………………………. 26

8. Enhancements …………………………………………………………………….. 26

9. Reflection …………………………………………………………………………. 27

10. Conclusion ……………………………………………………….......................... 27

11. References ………………………………………………………….. ……………28

LIST OF FIGURES

Figure 1: Architecture diagram ……………………………………………….. 1

Figure 2: Stoneware Architecture …………………………………………….. 6

Figure 3: Relay/Server Communications………………………………………. 9

Figure 4: package edu.ksu.beans……………………………………………….17

Figure 5: package edu.ksu.util………………………………………………….17

Figure 6: Table: Audit …………………………………………………………19

Figure 7: Table: CreditCard …………………………………………………... 19

Figure 8: Table: Gifts …………………………………………………………. 20

Figure 9: Table: Donor ……………………………………………………….. 20

Figure 10: Table: StoneOrder ..……………………………………………….. 21

Figure 11: Order Form …..…………………………………………………….. 22

Figure 12: Confirm Order ………………………………………………………23

Figure 13: Network Topology..…………………………………………………24

Figure 14: Throughput ………………………………………………………… 24

Figure 15: Latency ..…………………………………………………………… 25

ACKNOWLEDGEMENTS

I would like to express my sincere gratitude to Dr. Daniel Andresen for his constant support and suggestions throughout the whole project. I would also like to thank Dr. Mitchell Neilsen and Dr. Gurdip Singh, for their cooperation and for being on my graduate committee.

I wish to thank Mr. Reid Raile who has helped me with the configuration problems with the Stoneware Portal and Mr. Lynn Frick who has helped me setup the database tables. I would like to thank Mr. Joe Montgomery for the pick up lines on the home page for the website. I would like to thank Mr. Glenn Gillihan for giving me the opportunity to work for this project.

I would like to thank all the staff and students who have helped me during the project and during the course of my study at Kansas State University.

1. Introduction

1.1 Purpose

The Senior Sidewalk offers graduates an opportunity to commemorate their walk and build a pathway for future generations. When KSU Foundation first started accepting orders for stones on Senior Sidewalk, it did through written forms that were to be mailed along with a check for the stone. This form of accepting orders carried with it the unavoidable burden of book-keeping. Also, it was not as reachable to alumni as a website would be. This prompted the KSU Foundation to host a website that would be more accessible to the graduates and that would make the processing much simpler.

1.2 Architecture

Figure 1: Architecture diagram: System for accepting online orders for stones on the Senior Sidewalk

The client tier consists of users who would order the stones on the Senior Sidewalk. The WebPages at the client tier are Java Server Pages (JSPs) that import the packages edu.ksu.beans and edu.ksu.util and other classes that offer functionality required for the transaction. The menus on the WebPages are due to JavaScript files. These menus are free scripts provided by coolmenus..

The Web Services Container is the Stoneware Portal that provides its own set of Java APIs for logging into the portal, maintaining a session, using the reporting services, etc. Using these APIs a set of Java Class files are created that are used for the online transactions. These files are packaged into edu.ksu.beans and edu.ksu.util.

The database DB2 is used for the maintaining and retrieving the records as needed. SQL is used to manipulate the contents of the DB2 tables. A set of five tables are used to store the orders’ details.

2. Client Tier

2.1 JSP pages

There are two sets of JSP pages in the system.

➢ The first set deals with taking the orders from the graduates.

➢ The second set of JSP pages are used internally by the processing department to look into the details of the transactions and mark them as processed when they are done.

Description of the first set of JSPs:

The first JSP Page gives a brief introduction to the concept of the stones on the Senior Sidewalk and provides a link to the online ordering. When users click on this link it logs them into the Stoneware Portal as a stoneorder user. The users are redirected through the stoneware system to the page seniorSidewalk.jsp. This page gathers information in four sections:

i. Student’s Information

ii. Donor’s Information

iii. Payment Information

iv. Certificate (Optional)

The first part – student information pertains to the student’s name, ID, year of graduation, college to be engraved on the stone etc.

The next section collects information of the donor, which could be different from the student. The contact address, and optional information like the employer, spouse etc. is gathered.

The next step is to collect the details of the credit card.

If the contribution is made by someone other than the graduate, a certificate suitable for presenting to the graduate is provided. In this case, an optional section, specifying what name should be printed on the certificate, is filled in.

The next page shows the information that the user typed in the previous page and asks the user to proceed if everything is correct. When the user confirms the order, an object containing all the details of the order is created and it is sent to the Web Services Container. This object is recognized inside the container and further processing is done.

A final Thank You page is displayed, acknowledging the receipt of the order and giving the contact information for further inquiries or questions.

Description of Second set of JSPs:

These pages display all the details of the transactions. The processing department person has to log in to the Stoneware portal and access these pages in order to look into the details. The person is provided with a list of all the pending orders. A link from the Order ID will take the person to the details of the transaction. This page gives the user an option to mark the order as processed. When the order is processed one can mark this as processed from this page.

These pages provide various options to the user to look at different kinds of transactions. For e.g., he can choose to see all the transactions with a status such as processed, not processed or both, and choose the date range during which it is ordered.

2.2 Why JSPs ?

➢ The more static part of page can be taken care of using HTML while the dynamic content can be managed using JSP coding.

➢ The Web Developer creates and maintains the static part, while the Java Programmer takes care of the dynamic content and the business logic.

➢ Encourages the use of JavaBeans.

➢ The Stoneware portal, that is used to drive the web pages, provides Java Beans that can be imported into the JSPs and the functionality can be used.

JSP is a programming model from SUN that is developed to separate the dynamic content of pages with more static HTML content. It looks like HTML but allows access to component objects (Java beans) and execution of Java from within the HTML file.

The Stoneware portal provides Java Beans that can be used for various purposes for the transaction. Some of them include providing functionality for database connections, maintaining sessions, etc.

3. Web Services Container

Stoneware Inc.'s web portal software is designed for organizations that wish to provide employees, partners, and customers with a single point of access to all organizational web content. Stoneware's Web Portal consolidates all of an organization's web applications, web servers, databases, reports, file systems, and content into a unified web portal that provides security, access control, and content management. Stoneware’s web portal provides a rich set of features and services. Some of them include SSL Gateway Services, Consolidated Authentication, SwIFT (Stoneware Internet File Technology), Stoneware Components, Registration Services, Stoneware Wizard, Personalization, Maps, Navigation, Development, Content Management, Profiles, WebAdmin, Stoneware MMC Snapin, LockBox, PortManager, Stoneware Data Exchange, Communities etc.

In our case, we are making the most of the Development aspect of the portal. Stoneware provides a rich set of development tools for corporations that would like to build their own portal services. Microsoft developers that wish to integrate their applications into the web portal can do so through the Stoneware COM object. Java developers can also access all portal information through the use of Stoneware Java beans. Stoneware provides an admin, file service, and user bean for development of portal applications and Java Server Pages.

Our Java Server Pages import these Java beans and manage the content flow during the transaction.

3.1 Stoneware Design

[pic]

Figure 2: Stoneware Architecture

There are three components of Stoneware.

➢ Stoneware Loader (Server)

The Stoneware Loader provides authentication, session, development, database, file, and directory services for all Stoneware users and applications. It is the responsibility of the Stoneware Loader to provide the link between the directory services database and all portal services. What the Stoneware Loader does NOT do is communicate directly with portal clients (browsers). Because the Stoneware Loader has access to many critical data sources, it would be a security risk to provide client access to any of its processes.

➢ Stoneware Relay (Stoneware Entry Point)

The Stoneware Relay is the entry point into the Stoneware web portal. As its name suggests, the Stoneware Relay passes portal requests between the Stoneware Client (browser) and the Stoneware Server (loader). Based on this architecture, portal users never communicate directly with the Stoneware Server and therefore do not need access inside the corporate firewall. The Stoneware Relay job functions are to provide portal login and registration pages, apply personalization, and enforce access control lists provided by the Stoneware Server. By design, the Stoneware Relay does not access directory, database, file, or other portal services.

➢ Stoneware Client (Browser)

The Stoneware Client is nothing more than a standard industry browser. All portal resources are exposed through HTML and accessible from any web browser that supports SSL and java script. In addition, the Stoneware Client (browser) is treated much like a network client. When users authenticate to the web portal, they are required to meet network login and password restrictions.

3.2 Auto-Login

A set of username and password is created in the eDirectory that can be used for all the users that want to log into Stoneware to order a stone. However, the user is unaware of this username or password. It is solely for the Portal’s identification that this set of username and password is used. When a user clicks on the URL to order a stone he is automatically logged into Stoneware as a stoneorder user.

The process of logging in a user undergoes the following steps:

➢ Pre-Authentication

The steps for pre-authentication include:

o User is presented with the index.html

▪ In our case, we will do an auto-login, which means the user is not aware of the username and password to log into the Stoneware, and he is redirected to the destination page of the ordering form with the authentication being done on the background.

▪ When the user clicks the URL to order a stone, he is redirected to the further pages in the authentication process, with the username and password attached to the URL.

o Relay communicates with the Stoneware server and validates the users account.

[pic]

Figure 3: Relay/Server Communications

o Errors are returned if any.

o If the user is authenticated, Stoneware moves to the Post-Authentication process.

➢ Post-Authentication

After the Stoneware server validates the user’s credentials and verifies all password and login restrictions, it will continue on to the FinishLoginProcess.

During the FinishLoginProcess the Stoneware Relay:

o Sets a session ID.

o Determines user’s access.

▪ This is done for a specific user who is recognized by the Portal (E.g. Admin). In our case, the user is not given access to any resources.

o Builds automatic navigation.

▪ This navigation refers to the links that a specific user can access. In our case, there are no links to which the user is given access.

o Presents the user with a web page.

▪ At this point the user is logged into Stoneware.

▪ This will be the first page of the order form into which the user types in the required information for the transaction.

3.3 Development

Stoneware Java beans

The portal provides a Java bean for inserting Stoneware, File System, and Directory Services information into Java Server Pages. Retrieving and setting Directory Services information can be done from within a Java Server Page when the Stoneware Bean has been registered. In order to utilize the Stoneware Bean within a JSP, we should register the StonewareBean. This is done in the following way:

After this has been completed, we can extract or update information in the directory. We can even make use of the functionality that the swBean provides. For e.g, the function sendMail (…) that is provided by swBean can be used in our JSPs like this:

This bean is also used to check if a user is authenticated into Stoneware. Another bean provided by Stoneware, ReportServicesBean, is used for retrieving SessionID etc.

4. JavaBeans

The two packages that the JSPs use are edu.ksu.beans and edu.ksu.util. These classes make use of the Stoneware APIs and other Java APIs to provide the functionality required for the transactions.

4.1 Package edu.ksu.util

The classes within edu.ksu.util are:

i. Donor

ii. Gift

iii. Rounding

iv. StoneOrder

i. Class Donor

The objects of class Donor hold the data relevant to the person ordering the stone. It provides functions to get and set the values of the various variables inside the object. It holds the information of the donor’s name, address, spouse’s information, employer, payment information. This object provides functions like addCreditCardInformation (…), addStoneOrder (…), addGift (…) etc, that can be used by the JSPs to enter the details of the Stone order, payment information, etc.

ii. Class Gift

The objects of class Gift hold the information specific to the gift – the gift amount, which is the cost of the stone, the method of payment, whether it is a telefund gift and the designation of the gift as in what department should the funds go to. The object holds the getter and setter functions to these values. The JSP pages can use an object of this class add it to the object of class donor using the function addGift (…).

iii. Class Rounding

The objects of this class provide a function to round off the gift amount to the required precision.

iv. Class StoneOrder

These objects hold the following information: the name to the engraved on the stone, the college to engrave, and the student’s ID, graduate month and year, and by whom the honor is provided (if other than student). The object provides functions to set and get the values. When all the values of this object are set, it is added into an object of class Donor using the function addStoneOrder (…) provided by the Donor object.

During the transaction, the objects of all the four classes above, take the appropriate information and an object of Donor is created that contains all the required information.

This object is used with the object of class edu.ksu.beans.ksuBean that provides the functions for inserting the data into the database tables.

4.2 Package edu.ksu.beans

This package contains one class ksuBean. This class extends the CoreServicesBean provided by Stoneware. It imports classes in edu.ksu.util and other classes provided by Stoneware and SUN. Among other functions the important functions that this class provides are addDonor (…), markProcessed (…).

❖ Function addDonor (…):

When this function receives the Donor object, it does the following things:

➢ Inserting into DONOR table

o Establishes a connection with the DONOR table.

This is done using the reportBean that is provided by the Stoneware.

o An object of SQLCriteriaTable (com.stoneware.report.SQLCriteriaTable) is created.

o A unique ID for the donor is created based on the time at which the order is made; this is used as the DonorID.

o The SQLCriteriaTable is filled with all the attributes of the DONOR table; these values are retrieved from the getter functions of the Donor object.

o The record for this donor is inserted into the DB2 table.

➢ Inserting into GIFT table and AUDIT table

o Establishes connection with the GIFT table.

o An object of SQLCriteriaTable is created and the values of Gift are filled into it.

o This record is inserted into the GIFT DB2 table.

o A similar record is generated and inserted into the AUDIT table that shows the order as not processed yet.

➢ Inserting into STONEORDERS table

o Establishes connection with the STONEORDERS table.

o An object of SQLCriteriaTable is created and the data stored in the StoneOrder object is retrieved and filled into it.

o This record is inserted into the DB2 table.

➢ Inserting into CREDITCARD table

o Establishes connection with the STONEORDERS table.

o An object of SQLCriteriaTable is created and the payment information that is stored in the object of class Donor is retrieved and filled into it.

o This record is inserted into the DB2 table.

❖ Function markProcessed (…):

When this function receives a DonorID along with a SessionID, it does the following:

➢ Updating the AUDIT table

o Establishes connection with the AUDIT table.

o An object of SQLCriteriaTable is created.

o A record corresponding to that DonorID is created that shows that the order has been processed.

o This record is used to update the previous record in the AUDIT table.

4.3 Class diagram

[pic]

Figure 4: package edu.ksu.beans

[pic]

Figure 5: package edu.ksu.util

5. Database

5.1 Database Connectivity

We can make use of the Java Bean, ReportServicesBean that Stoneware provides to connect to the required database. The Bean returns an object of the type ConnectionConfiguration which can be used with the ReportServiceBean for updating, inserting, modifying the database.

For an instance cc, of type ConnectionConfiguration and reportBean of type ReportServicesBean, we can connect to the database like this:

cc = reportBean.getConnectionConfiguration ( sessionID,

DBLocation, UserName, Password, true );

where sessionID is the session ID of the transaction, DBLocation is the URL to the database location, Username and Password are used for authentication to access the database.

After the connection is established, records can be inserted into the database like this:

reportBean.updateDataRows( sessionID, cc, tableName, SQLCriteriaTable1, SQLCriteriaTable2 );

where SQLCriteriaTable1, SQLCriteriaTable2 describe the data type, name and the value of the first and second columns of the record respectively.

5.2 Table Schema

DB2 database is used to maintain the tables. The tables used are:

• Audit

• Creditcard

• Gifts

• Donor

• StoneOrder

The table schema for each of these is as follows:

• AUDIT table: This table is used to mark the transactions as processed when these are done.

[pic]

Figure 6: Table: Audit

• CREDITCARD table: This table is used to store credit card information of the user.

[pic]

Figure 7: Table: Creditcard

• GIFTS table: Gifts table stores the information like the method of payment (credit card), the amount in dollars that should be billed etc.

[pic]

Figure 8: Table: Gifts

• DONOR table: This table stores the information of the donor. It stores the information like the donor’s name, address, employer and spouse’s information etc.

[pic]

Figure 9: Table: Donor

• STONEORDER table: This table stores the information of the name to be engraved on the stone, the student’s ID, the graduate’s college to engrave on the stone, the year of graduation, and the name of the person who has ordered the stone for the graduate.

[pic]

Figure 10: Table: StoneOrder

Every transaction has one corresponding record in each of the five tables listed. These records have their primary key as the DonorID which is generated when a stone is ordered.

6. Screen shots

Ordering a stone on the website is a two step process:

• Information of the graduate, donor and the credit card details is typed into the order form in the first page.

[pic]

Figure 11: Order Form

• The details are confirmed in the second page and a final submit button is hit.

[pic]

Figure 12: Confirm Order

7. Load Testing and Performance

Apache JMeter has been used to test performance of the website. It is used to simulate a heavy load on the website and test its strength and analyze overall performance under different loads. We have used it to make a graphical analysis of performance and test the server behavior under heavy concurrent load.

7.1 Client/Server Configuration

The Client and Server were in a network which had a limiting bandwidth of 100 Mbps. The application was run across this network and Apache JMeter was used to measure the changes in the rate of handling the requests with increasing loads on the server.

Figure 13: Network Topology

7.2 Throughput

The following graph shows the throughput of the server with different loads:

[pic]

Figure 14: Throughput

The throughput is measured as the number of requests handled per minute. The graph shows us that as the number of requests increased the throughput decreased. With the throughput as much as 1490 requests/min for 500 simultaneous requests, it decreased to 670 requests/min for 10000 simultaneous requests.

The increase in load can drain server processor resources. For example, it adds the network communication overhead. In addition to the normal tasks like logging in the users, accepting the orders, etc., the CPU takes the overhead of maintaining the communication in the network. Therefore, as the load increases, there is a decrease in the Throughput of the system. The CPU utilization was found to be 82%.

7.3 Latency

[pic]

Figure 15: Latency

The graph above shows the increasing latency in serving the requests when the number of requests is increased. With an average latency time of 11 ms per request when there are 500 simultaneous requests, the latency increases to 18 ms per request with 10000 simultaneous requests.

With the increase in load, the number of database connections and retrievals also increase. Since all these connections are handled by the processor, there is an increase in latency. This increase is reflected in the graph shown in Figure 15.

7.4 Testing for different values of inputs

There are various fields in the order form that a user has to fill in, and these inputs should be in the form that the underlying database tables expect. Every input field of the order form has been verified to ensure that the type of input matches with the type that the database expects. A JavaScript file checks whether every mandatory field in the ordering form is filled in. In the case where the submit button is hit without filling in those fields, an alert is thrown which specifies that a required field was left blank.

A JavaScript file is used to verify that fields like phone number, zip code etc., provided by the donor consists only of numbers. A routine is used to verify that the credit card information entered is valid for the card type (VISA, MasterCard,…) and the date of expiry. A successful insertion of a record into a database table returns a Boolean value true. In the case that a false is returned, the values of all the fields are shown to the user and asked to verify them. The user can change the values and re-submit them.

8. Enhancements

The Java beans created in edu.ksu.util and edu.ksu.beans can be extended to include other types of online donations. One of the extensions is already underway; another form of online donation, Pet Trust Donation, for the college of Veterinary Medicine at Kansas State University is being developed. Another java class called PetTrustDonation is being created which holds the information specific to the donation. The existing beans are used to hold the data related to the credit card information, the Donor information etc. A set of JSPs can be designed that will import these classes and accept the Pet Trust Donation in the same way.

9. Reflection

The project has helped me gain an understanding of the working of a B2B web portal and ways of developing applications upon it. I have explored various services that the portal provides and hopefully I will use them in my upcoming projects. Some of them include the Stoneware Components, the Java Beans, etc. The usage of these would dramatically reduce the development time for the projects. Also, the usage of JSPs has given me a good opportunity to explore the programming options in JSPs.

10. Conclusion

This system has reduced the burden of book-keeping for the KSU Foundation staff. It has also made it more reachable to the alumni across the world, thus eliminating the geographical constraints. The front office will no longer have to worry about the distribution of the order forms for the alumni. From a graduate’s perspective the accepting credit cards for the transaction should come as a welcome development. The software has also been written in a very general way and its design allows easy enhancements so that other types of online donations can be developed using the same Java Beans.

11. References

[1] Java Servlets and JSP by Andrea Steelman and Joel Murach.

[2] Java Server Pages Documentation –

[3] Stoneware 3 – Pinnacle Computer Services.

[4] Stoneware Web Portal API Documentation – stone- /support

/developerzone/ java/javadocs/

[5] Apache Jakarta Project - Apache JMeter:

-----------------------

Approved by:

Major Professor

Dr. Daniel Andresen

Browser

Database - DB2

Browser

Browser

Java Beans

Client Tier

Web Services Container -

Stoneware Portal

Web Servers and Applications

File Systems

Directory Services

Databases

Stoneware Server

Stoneware Relay

Portal Users

Portal Users

Portal Users

Stoneware Relay

Stoneware Server

Directory

User Name Password Account Status

2. Server locates username, Verifies Password and account status

1. Relay sends User Name and Password

3. Server returns status code to Relay

ksuBean

addDonor(..)

….

package edu.ksu.beans

Donor

addGift()

addStoneOrder()

…..

Gift

getGiftAmount()

getDesignation()

PetTrustDonation

getPetName()

getGiftSource()

Rounding

round(..)

StoneOrder

getStudentId()

getNameOnStone()

…

package edu.ksu.util

Switch

Switch

100 Mbps

Server

Relay

Client

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download