People | Computer Science | Kansas State University



Java Web Services and JSP based Credit Card System

By

DEEPAK REDDY CHITTOORNALLAPAREDDY

B.Tech, J.N.T.U, India, 2003

[pic]

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

2005

Approved By

Major Professor

Dr. Daniel Andresen, PhD

ABSTRACT

The main objective of building a credit card website using Apache SOAP and JSP is to provide the user with a set of web services that save valuable time in processing his requests to it. It involves developing web services using Apache SOAP and invoking them from the client using JSP technology. This enables the user with a convenient and easier to use graphical based interactive interface. Primarily it allows the user to utilize its online facilities in applying for a credit card, changing the user profile, paying the credit card balance using a bank account and all other basic services expected in such systems.

TABLE OF CONTENTS

LIST OF FIGURES ..………………………………… iii

ACKNOWLEDGEMENT …………………………… iv

1. INTRODUCTION

1.1 Objective & Overview ………………………………………. 1

1.2 Back Ground ………………………………………………… 1

1.3 Target Audience ……………………………………………... 1

2. PROJECT DESCRIPTION

2.1 Tools & Technologies ………………………………………. 1

2.2 System Requirements ……………………………………….. 3

2.3 System Architecture ………………………………………… 3

2.4 Data/Control Flow Diagrams ……………………………….. 4

2.5 Use-Case Diagrams …………………………………………. 6

2.6 SOAP Architecture ………………………………………….. 7

2.7 Database Schema ……………………………………………. 16

2.8 Functionalities ……………………………………………….. 17

3. SPECIAL FEATURES

3.1 SSL Implementation ………………………………………… 18

3.2 Handicapped Access ………………………………………… 18

3.3 Oracle Procedure …………………………………………….. 18

4. SESSION MANAGEMENT

4.1 User Sessions …………………………..……………………. 19

5. SECURITY

5.1 Security using SSL ……………………………………………19

5.2 Client side Validation …………………………………………19

6. TESTING

6.1 Browser Compatibility ……………………………………….. 20

6.2 Unit Testing (Test cases) ………………………………………20

6.3 Performance Testing (JMeter) …………………………………21

7. SNAPSHOTS OF THE SITE

7.1 Admin view ……………………………………………………24

7.2 Admin card approve...………………………………………..... 24

7.3 Admin card details ….…………………………………………. 25

7.4 Admin card summary ….……………………………………… 26

7.5 Admin change profile ………………………………………..... 27

7.6 Admin unbilled activity ……………………………………….. 27

7.7 Admin online enroll …………………………………………….28

7.8 Admin online bill pay …………………………………………..29

7.9 Admin card activation…………………….……………………..29

7.10 Client index...…………………………….…………………….30

7.11 Client card apply ……………………….……………………...31

7.12 Client register … …………………………………………..…...31

7.13 Client card details ……………………………………….….......32

7.14 Client card summary …………………………………….….…..33

7.15 Client contact company ………………………………..……….33

8. FUTURE WORK …………………………………..…….......34

9. IMPACT OF THE PROJECT

9.1 Lessons Learnt ……………………………………….………….. 34

9.2 Problems Encountered ……………………………….………….. 35

9.3 Options that can be Different ……………………………………..35

10. CONCLUSION ………………………..………….………….36

11. REFERENCES …………………………..……….………….36

LIST OF FIGURES

Figure 1: System Architecture……………………………...................... 4

Figure 2: Data/Control Flow Diagrams …………………………………5

Figure 3: Use Case Diagram……………………………………………. 6

Figure 4: SOAP Architecture ……………………………………………7

Figure 5: Database Schema ……………………………………………...17

Figure 6: JMeter Test Result……………………………………………..21

Figure 7: Snapshots of the application…………………………………...23

ACKNOWLEDGEMENTS

I would like to thank Dr. Daniel Andresen for his valuable guidance in the development of this project. I would also like to thank my committee members Dr. Bill Hankley and Dr. Mitchell Neilsen for supporting me to work in this project.

1. INTRODUCTION

1.1 Objective & Overview

The Objective of my project, credit card service system, an online service website is to provide the client with several options that facilitate him to quickly access his account, apply for a credit card and use the other basic account services saving his time and energy.

The application allows the administrator/client to perform various operations like change user profile, enter account bill activity, enroll in online bill pay, apply for a credit card and other services. A client can logon to the website and change his profile like address, password, phoneno, email etc. He can also view his account summary as well as his unbilled activity. He can apply for a credit card before logging into the online services. He can also contact the company using the default mail service for the particular project.

The website also provides Administrator functionality where the administrator can change the user profile, enter unbilled activity for a particular account, accept or reject card applications and finally enroll in online bill pay as well as pay from a bank account for a particular client.

1.2 Back Ground

The prime reason for choosing this project was to achieve experience and detailed understanding of building a website with various online transactions using web tools like HTML, JSP, Apache SOAP and other technologies relevant to the application. Credit card Services is currently becoming an efficient application for any well established credit companies that want to save money and time in processing client requests.

1.3 Target Audience

This website is addressed towards credit card clients who are reluctant towards spending time to walk to bank office and perform various services like changing their address, paying from an account, contacting the company and applying for a credit card.

2. PROJECT DESCRIPTION

2.1 Tools & Technologies

J2EE

I used J2EE designed by Sun Micro Systems [1] as platform for developing my website. Java 2 Platform Enterprise Edition defines the standard for developing component-based multi-tier enterprise applications.

J2EE capitalizes on many features of the Java 2 Platform, Standard Edition (J2SE) which include:

• Platform independent achieving portability

• JDBC API for database access

• CORBA technology for interaction with existing enterprise applications

• A security model that protects data even in internet applications.

I have chosen J2EE as the platform for development of this website because it provides the flexibility of platform independence, its Message driven beans technology delivers a component model for inter application messaging and its end-to-end architecture provides us with a programming model that uses Servlets, Java Server Pages (JSP) and Enterprise JavaBeans (EJB) to implement and deploy business logic so that I get to choose the most appropriate model for my application.

JSP

Java Server Pages (JSP) technology [3] provides a simplified, fast way to create dynamic Web content. It’s an extension of the Java Servlet technology. JSP technology separates the user interface from content generation, enabling designers to change the overall page layout without altering the underlying dynamic content.

SOAP

SOAP is an XML-based messaging protocol. It defines a set of rules for structuring messages that can be used for simple one-way messaging but is particularly useful for performing RPC-style (Remote Procedure Call) request-response dialogues. It is not tied to any particular transport protocol though HTTP is popular [5]. Nor is it tied to any particular operating system or programming language so theoretically the clients and servers in these dialogues can be running on any platform and written in any language as long as they can formulate and understand SOAP messages. As such it is an important building block for developing distributed applications that exploit functionality published as services over an intranet or the internet

HTML

HTML is a format for publishing hypertext on the World Wide Web .HTML uses special tags or codes that a web browser knows how to interpret the document and display on the screen.

JavaScript

JavaScript is a compact object based scripting language for developing client side applications [2]. Netscape Navigator interprets JavaScript statements embedded in a HTML page.

Oracle 8i

The database server I used is Oracle 8i. Oracle 8i makes database implementation easier and it is very highly scalable. Powerful and complex applications can be built on Oracle server with high security [4]. I currently have around 100,000 entries in my database which contains searchable dynamic information. I have used an oracle procedure for a purpose.

Others

Other tools used for my website development are Tomcat Apache server which supports Servlets, JSP and JavaBeans. I also used SSL from the Tomcat server settings to implement security for my website.

2.2 System Requirements

A typical system configuration for the client could be:

• A processor with a speed of atleast 900Mhz

• Memory of 256 MB or more

• Dial-up/Broadband connection (56 kbps)

• Internet Explorer/Netscape Navigator / Mozilla

The main purpose of having a dial-up connection as the minimum requirement for accessing the website is to have faster access in opening the main page and then the subsequent pages after logging in. if this is not the case then the user will get annoyed at the page being displayed. Internet Explorer was chosen as the primary display browser for the website, but the website has been made compatible for other browsers like Mozilla and Netscape Navigator. On the Server side having a minimum RAM of 256 MB and processor speed of 900 Mhz will help in creating multiple threads for accessing the website by various clients and as the website involves interacting with the database the speed matters in computing the various database operations.

2.3 System Architecture

The architecture is divided into four-tier. The Front End tier is at the client side implemented in HTML and JavaScript where User and Administrator sessions as well as client side computing are done in this tier. The Middle-tier is the Business layer where the entire business logic is implemented. This layer contains logic for client interface and administration activities. This logic is implemented in JSP on the J2EE server.

The third tier contains the SOAP services that take the request from the JSP’s in the form of SOAP messages and call the necessary functions for accessing the database. Then the SOAP service sends the response back to the second tier logic. The last layer is the data layer where the data relevant to my website is stored and query processing is done .This layer is built on Oracle 8i database server.

The system architecture of my website is as shown below:

User Admin

[pic]

Figure 1

2.4 Data/Control Flow Diagrams

The below data flow diagrams explain the various phases the client passes from one page to another and the different operations associated with each page. First the user has to register himself with the credit card no he received. After that he enters the userID and password, then he is taken to his account page which gives him various options. If he presses account summary he is shown the basic details associated with his account. If he chooses change profile then he can change his address and other fields. If he chooses unbilled activity then he is shown the various unbilled transactions on his account. If he chooses enroll then he can enroll in online bill pay from a particular account and if he chooses pay now then he can pay the credit card in real time. If he chooses Contact Company then he will find various ways in which he can contact the company.

Some of the data/control flow diagrams are shown below:

1) Customer Registration: The below diagram shows how the control flows when a customer registers with the received credit card

[pic]

Figure 2A

2) Customer Login: The below diagram shows how the control flows when a client logs into the credit card website.

[pic]

Figure 2B

3) User Profile: The below diagram shows how the control flows when the user wants to check and update his profile

[pic]

Figure 2C

2.5 Use-case Diagram

The below Use-Case diagram describes the functions a user can perform when he logs on to my website. The basic functions include Registration (if new user), login to view his Account, view his account summary, change the user profile, enroll in online bill pay, pay the credit card in real time and contact the company.

Figure 3

2.6 SOAP Architecture

The SOAP developer's approach to a problem is to encapsulate the database request logic for the service in a method in C or Java etc, then set up a process that listens for requests to the service; such requests being in SOAP format and containing the service name and any required parameters. The transport layer might be HTTP or it could just as easily be SMTP. Then the listener process, which is typically written in the same language as the service method, decodes the incoming SOAP request and transforms it into an invocation of the method. It then takes the result of the method call, encodes it into a SOAP response message and sends it back to the client [6].

A valid SOAP Message is a well-formed XML document. The XML prolog can be present but, if present, should contain only an XML Declaration that is it should not contain any DTD references or XML processing instructions. It should use the SOAP Envelope and SOAP Encoding namespaces and have the following form: An XML Declaration (optional), and a SOAP Envelope (the root element) which is made up of a SOAP Header (optional) and a SOAP Body [7].

In my project the default Apache XML registry took care of the XML mapping between the SOAP request and SOAP response. That is when I specify in the settings provided by the SOAP Admin, I mention that the services use the default Apache XML encoding (org.apache.SOAP.encoding.SOAPMappingRegistry ) then the SOAP request and response are mapped using the default settings and retrieved.

As an example of how the SOAP works from the high level view let us have the database system as Oracle. The developer writes the service method in Java and connects to the database using an Oracle implementation of JDBC. The listener process is a Servlet running within a Server such as Tomcat. The Servlet has access to some Java classes capable of decoding and encoding SOAP messages such as Apache SOAP for Java and is listening for those messages as an HTTP POST. The transport is HTTP over TCP/IP. The client is an excel spreadsheet. It uses a VB Macro which in turn exploits the Microsoft SOAP Toolkit to encode a SOAP request and decode the response received. The diagram below shows a schematic of what that specific implementation looks like:

Figure 4

For my project the SOAP architecture looks similar except that the client and listener are embedded in one place, which is the JSP page providing the client with the necessary service. Hence the JSP page calls the appropriate SOAP method using the request message and stores the corresponding response message to display to the client.

Let us look at how the SOAP works from the client side. Client code makes a service call by invoking the appropriate method in the SOAP package. The package's SOAP serializer converts this invocation into a SOAP request and sends that to the HTTP encoder. The HTTP encoder wraps the SOAP message in a HTTP request and sends it to the SOAP server. The response is received from the SOAP server by the HTTP encoder/decoder module which decodes it and extracts the SOAP response which it hands to the SOAP deserializer. The SOAP deserializer deserializes the message and passes the result to the client code as the return value to the original invocation [8].

The client code written in my project invokes various services based on their need. It typically is divided into the following steps

It first creates a URL referencing the rpcrouter on the HTTP server of the local host. This is done in the following code URL url = new URL (“");

The next step performed by the client application is to parse the arguments from the command line. These values will be passed to the SOAP service in a subsequent method. The values created will be integers. After the client has parsed to command-line arguments, it creates an instance of an org.apache.SOAP.rpc.RPCMessage.Call. The Call object is the main interface used when executing a SOAP RPC invocation [5].

To use the Call object, we first tell it which service we want to use. We do this by calling the setTargetObjectURI, passing it the name of the service that we want to execute. We then set the name of the service method we want to execute using the setMethodName() method, with the name of the method we want to execute. The next step is to set the encoding style used in the RPC call. The final step is to add the parameters that are expected when executing the named method. This is done by creating a Vector of Parameter objects and adding them to the Call object using the setParams() method. All of these steps are completed using the following code snippet:

Call call = new Call();

call.setTargetObjectURI("urn:methodname");

call.setMethodName("methodname");

call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);

Vector params = new Vector();

params.addElement(new Parameter("p1", List.class, p1, null));

params.addElement(new Parameter("p2", List.class, p2, null));

call.setParams (params);

The next step performed by the client application is to call the service method that we are interested in. This is done using invoke() with the URL we created earlier. Here is the snippet of code calling the invoke() method:

Response resp = call.invoke(url, "" );

You will notice the return value of the invoke() method is a Response object. The Response object returns two very important items -- an error code and the value returned from the executed service method. You check for an error by calling the generatedFault() method. This method will return true if there was an error returned; then you can check the getFault() method. If generatedFault() returns false, you can then get the value returned in the Response object, using the Response.getReturnValue() method[6]. The following code snippet shows how you should process the response of an invoke():

if ( resp.generatedFault() ) {

Fault fault = resp.getFault();

System.out.println("The call failed: ");

System.out.println("Fault Code = " + fault.getFaultCode());

System.out.println("Fault String = " + fault.getFaultString());

}

else {

Parameter result = resp.getReturnValue();

System.out.println(result.getValue());

}

The next step in creating a new SOAP service is to create a deployment descriptor. The deployment descriptor describes the SOAP service. This description is required for the service to be published as an Apache SOAP service. The general body of a descriptor is shown below:

org.apache.SOAP.server.DOMFaultListener

The first line is similar to a URL, and is required for a client to connect to any SOAP server. The second is lists of methods letting the client know what allowable artifacts are for a SOAP client. It also lets the SOAP server, know what requests to accept. And the third is a means of letting the SOAP server know how to handle any custom parameters;

The final step is writing the services that run on the server. In the above section it has been described how the methods of a class are passed parameters and invoked from the client program. Creating a SOAP service is the simplest step of the entire SOAPifying process. A SOAP service can be just about any Java class that exposes public methods for invocation. The class does not need to know anything about SOAP, or even that it is being executed as a SOAP service[6]. The only restriction is that the method parameters of a SOAP service must be serializable. For example a java class that adds and subtracts two numbers is shown below:

public class CalcService {

public int add(int p1, int p2) {

return p1 + p2;

}

public int subtract(int p1, int p2) {

return p1 - p2;

}

}

The services I have written in my project are described in detail as below:

1) providing the admin with the capability of entering account summary information by invoking a service called adaccsum. In this service the admin account summary page invokes the service method display of adaccsum initially that displays information regarding the account such as last balance, last pay, last statement date and other things. The admin can also increase the credit line of the client by invoking the service method update of adaccsum. This method is invoked only when the update value is one. The service method then takes the cardno as one of the parameters and credit line amount as another parameter and updates the database accordingly. Since the update method is present before the display, the display method is invoked again and it extracts the various details from the database and shows it to the admin.

The JSP page contains the following logic besides the normal method call format:

if(update.equals("1"))

{

call.setMethodName ("update");

params.addElement (new Parameter("cardno", String.class,cardno, null));

String creditline = (String) request.getParameter("crline");

params.addElement (new Parameter("creditline", String.class,creditline, null))

}

call.setMethodName ("display");

params.addElement (new Parameter("cardno", String.class,cardno, null));

The class file which provides the methods to the JSP page contains the logic for display and update as shown below:

String sqlstmt = "select * from CREDITSUMMARY where CARDNO="+cardno;

java.sql.Statement stmt = conn.createStatement();

rs = stmt.executeQuery(sqlstmt);

while(rs.next())

{

result[0] = rs.getObject("CURRBALANCE").toString();

result[1] = rs.getObject("LASTBALANCE").toString();

result[2] = rs.getObject("LASTPAY").toString();

result[3] = rs.getObject("NEXTSTATDATE").toString();

result[4] = rs.getObject("MINPAY").toString();

result[5] = rs.getObject("CREDITLINE").toString();

result[6] = rs.getObject("DUEDATE").toString();

}

String sqlstmt = "update CREDITSUMMARY set creditline="+creditline+" where CARDNO="+cardno;

Then the JSP page collects the returned value of various fields and displays them.

2) providing the admin with the capability of changing the client profile by invoking a service called adchpro. In this service the admin change profile page invokes the service method display of adchpro initially that displays information regarding the client such as name, address, phoneno and other things. The admin can also change various fields of the client by invoking the service method update of adchpro. This method is invoked only when the update value is one. The service method then takes the cardno as one of the parameters and all changeable fields as other parameters and updates the database accordingly. Since the update method is present before the display, the display method is invoked again and it extracts the various details from the database and shows it to the admin.

The JSP page contains the following logic besides the normal method call format:

if(update.equals("1"))

{

call.setMethodName ("update");

params.addElement (new Parameter("cardno", String.class,cardno, null));

String password = (String) request.getParameter("passwd");

params.addElement (new Parameter("password", String.class,password, null))

String address = (String) request.getParameter("address");

params.addElement (new Parameter("address", String.class,address, null))

String phoneno = (String) request.getParameter("phno");

params.addElement (new Parameter("phoneno", String.class,phoneno, null))

String email = (String) request.getParameter("email");

params.addElement (new Parameter("email", String.class,email, null))

String secq = (String) request.getParameter("secq");

params.addElement (new Parameter("secq", String.class,secq, null))

String seca = (String) request.getParameter("seca");

params.addElement (new Parameter("seca", String.class,seca, null))

}

call.setMethodName ("display");

params.addElement (new Parameter("cardno", String.class,cardno, null));

The class file which provides the methods to the JSP page contains the logic for display and update as shown below:

String sqlstmt = "select * from USERPROFILE where CARDNO="+cardno;

java.sql.Statement stmt = conn.createStatement();

rs = stmt.executeQuery(sqlstmt);

while(rs.next())

{

result[0] = rs.getObject("PASSWORD").toString();

result[1] = rs.getObject("FIRSTNAME").toString();

result[2] = rs.getObject("LASTNAME").toString();

result[3] = rs.getObject("ADDRESS").toString();

result[4] = rs.getObject("PHONENO").toString();

result[5] = rs.getObject("EMAIL").toString();

result[6] = rs.getObject("SECQUESTION").toString();

result[7] = rs.getObject("SECANSWER").toString();

}

String sqlstmt = "update USERPROFILE set password = '"+ password +"', email = '"+ email +"', address= '"+address+"', phoneno = "+phoneno+", secquestion = '"+secq+"', secanswer = '"+seca+"' where CARDNO = "+ cardno;

Then the JSP page collects the returned value of various fields and displays them.

3) providing the admin with the capability of entering unbilled activity for a particular client by invoking a service called adbillact. The admin can enter fields such as the date of unbilled activity, the amount and the description of the transaction of the client by invoking the service method update of adbillact. This method is invoked only when the update value is one. The service method then takes the cardno as one of the parameters and all entered fields as other parameters and updates the database accordingly.

The JSP page contains the following logic besides the normal method call format:

if(update.equals("1"))

{

call.setMethodName ("update");

params.addElement (new Parameter("cardno", String.class,cardno, null));

String date = (String) request.getParameter("date");

params.addElement (new Parameter("date", String.class,date, null))

String desc = (String) request.getParameter("desc");

params.addElement (new Parameter("desc", String.class,desc, null))

String amount = (String) request.getParameter("amount");

params.addElement (new Parameter("amount", String.class,amount, null))

}

The class file which provides the methods to the JSP page contains the logic for update as shown below:

String sqlstmt = "INSERT into UNBILLEDACC (cardno, description, dateofacc, amount, checked) values ("+ cardno +",'"+ desc +"',to_date('"+ date +"','mm/dd/yyyy'),"+ amount +",'no')";

This way the JSP page inserts values for various fields.

4) providing the admin with the capability of enrolling the client in online bill pay program by invoking the service adenroll. The admin can enter fields such as the bank name, the account no, the routing no and the account holder name of the client by invoking the service method update of adenroll. This method is invoked only when the update value is one. The service method then takes the cardno as one of the parameters and all entered fields as other parameters and updates the database accordingly.

The JSP page contains the following logic besides the normal method call format:

if(update.equals("1"))

{

call.setMethodName ("update");

params.addElement (new Parameter("cardno", String.class,cardno, null));

String bname = (String) request.getParameter("bname");

params.addElement (new Parameter("bname", String.class,bname, null))

String baccno = (String) request.getParameter("baccno");

params.addElement (new Parameter("baccno", String.class,baccno, null))

String brouteno = (String) request.getParameter("brouteno");

params.addElement (new Parameter("brouteno", String.class,brouteno, null))

String baccholdname = (String) request.getParameter("baccholdname");

params.addElement (new Parameter("baccholdname", String.class,baccholdname, null))

}

The class file which provides the methods to the JSP page contains the logic for update as shown below:

String sqlstmt = "INSERT into BANKDETAILS (cardno, bankname, accholdername, bankaccno, bankrouteno) values ("+ cardno +",'"+ bankname +"','"+ accholdname +"',"+ accountno +","+ routingno +")";

This way the JSP page inserts values for various fields.

5) providing the admin with the capability of paying the clients balance from the bank account provided by invoking a service called adbillpay. In this service the admin pay card page invokes the service method display and display1 of adbillpay initially that displays information regarding the client such as the banks enrolled in and the minimum amount to be paid of the balance. The admin can specify the minimum amount of the balance or an amount in between the minimum pay and the total balance by invoking the service method update of adbillpay. This method is invoked only when the update value is one. The service method then takes the cardno as one of the parameters and the amount entered by the user (min pay or user specified) as other parameter and updates the database accordingly. Since the update method is present before the display, the display method is invoked again and it shows that the balance has been paid to the admin.

The JSP page contains the following logic besides the normal method call format:

if(update.equals("1"))

{

call.setMethodName ("update");

params.addElement (new Parameter("cardno", String.class,cardno, null));

String bankname = (String) request.getParameter("bank");

params.addElement (new Parameter("bankname", String.class,bankname, null));

String pay = (String) request.getParameter("pay");

if(pay.equals("pay1"))

params.addElement (new Parameter("pay1", Float.class,pay1, null));

else if(pay.equals("pay2"))

params.addElement (new Parameter("pay2", Float.class,pay2, null));

call.setMethodName ("display");

params.addElement (new Parameter("cardno", String.class,cardno, null));

call.setMethodName ("display1");

params.addElement (new Parameter("cardno", String.class,cardno, null));

The class file which provides the methods to the JSP page contains the logic for display, display1 and update as shown below:

String sqlstmt = "select * from CREDITSUMMARY WHERE CARDNO = "+ cardno;

String sqlstmt = "select * from BANKDETAILS WHERE CARDNO = "+ cardno;

java.sql.Statement stmt2 = conn2.createStatement();

rs2 = stmt2.executeQuery(sqlstmt);

int i=0;

while(rs2.next())

{

result[i] = rs2.getObject("BANKNAME").toString();

i++;

}

String sqlstmt1 = "update ACCSUMBANK1 set dateofacc = to_date('"+ acdate1 +"','mm/dd/yyyy'), transno ="+transactionno+", description='Credit Card : "+cardno+"', debit = "+pay.floatValue()+", checkingbal = "+amountdiff+" where bankname = "+ bankname;

Then the JSP page collects the returned value of balance left and displays it.

In this manner the process of creating clients that access services run on the server is structured. All the JSP files in my project call the services running on the server so that they display the required information to the client and admin.

2.7 Database Schema

The main tables in my database schema are userprofile which stores data about the various users having accounts in the credit card company. It generally contains the entire profile of the credit card clients including their registered user name, password. The credit summary table contains the basic account details like current balance, last balance, last pay, next statement date, due date and other things. The unbilled acc table contains transaction details for a particular account showing the date of activity and the amount.

The card apply table contains all the details concerning credit card application including firstname, lastname, address, email and other things. A field called new indicates whether this application is new or old and a field called accepted indicates whether the card is accepted or not.

The main table entities in my project database schema are shown using an ER Diagram below:

[pic]

Figure 5

2.8 Functionalities

The functionalities provided by the website are listed below:

Client

• The client can Register in the website and Login.

• The client can view various types of cards available in the company.

• The client can view his account summary by calling a SOAP service.

• The client can enroll in online bill pay by calling a SOAP service.

• The client can change his profile including his address and other fields by calling a SOAP service.

• The client can apply for a card using the application page.

• The client can pay the credit card using online bill pay by calling a SOAP service.

• The client can contact the company using the browser built in mail service.

Administrator

• The Administrator can reject or accept credit card applications.

• The Administrator can change the account summary for a particular client by calling a SOAP service

• The Administrator can enter the unbilled activity details for each account by calling a SOAP service.

• The Administrator can also enroll in online bill pay for a client and pay the card using that by calling a SOAP service.

• The Administrator can change the user profile by calling a SOAP service.

• Above all the Administrator can update the account statements for all the clients in the company using the Oracle procedure.

3. SPECIAL FEATURES

3.1 SSL Implementation

I added security to the website using SSL. SSL enables secure data communication for my website using the 128-bit strong SSL encryption and digital certificates. It authenticates and encrypts data sent and received using SSL2, SSL3, PCT or TLS. Both Internet Explorer and Mozilla browser support SSL.

3.2 Handicapped Access

A website should be made accessible to all type users especially to people who are physically handicapped. For example a blind person should be able to access the website using screen readers so that they can hear description of the content in the website.

To implement accessibility in my website I tried using Access Keys for

accessing various options. I also used ALT tags for images using which the screen reader, if available, can read out the description of an image to a physically handicapped (blind) user.

3.3 Oracle Procedure

I have written an oracle procedure that updates the statements of all the clients of the credit card company. It functions by going through each cardno and when the system or current date is more than 30 days the last statement date it updates account by first adding all the unbilled activity, then updates the current balance as sum of unbilled amount and the subtraction of the last balance and last payment. It sets the min pay as fifteen percent of the current balance, last balance as the original current balance, the next statement date as addition of 30 days to the current statement date and due date as addition of 20 day to the current statement date.

In this way the oracle procedure virtually updates all the account statements of card holders whose account dates have passed 30 days since the last statement. It updates the appropriate tables to reflect the new balances and dates.

4. SESSION MANAGEMENT

4.1 User Sessions

One of the challenges in developing a web application is maintaining user information over the cymes of a visit, or session as the user travels from page to page in an application. In my website sessions are implemented for user logins. A session specific identifier or variable is created afresh at the start of each session. The session automatically ends when the user closes all

the browser windows or logs out of the website. I implemented user sessions using HTTPSession Object.

5. SECURITY

5.1 Security using SSL

As mentioned above I added security to my website through the SSL protocol. SSL enables authentication and encrypts data sent and received by the website.

5.2 Client Side Validation

Client side validation is one of the simple client side security feature my website has. I implemented client side validation for new user registration module using JavaScript. During registration if the user enters invalid information like email id without ‘@’ symbol and missing characters after the symbol then the browser alerts the user to enter valid email id. In the same way every page contains valid JavaScript so that the client can’t enter invalid information into a field which desires a certain type of character.

6. TESTING

6.1 Browser Compatibility

A website contains lot of static and dynamic content displayed by a browser. Since different users may use different browsers the content, the menus and tables may be rearranged depending on the browser. So I am supposed to make my website browser compatible with all types of browsers available in the market today. I tested, verified and did some modifications to my website’s content organization with the following browsers:

Internet Explorer 5.0 and higher, Mozilla FireFox 1.0 and higher,

Netscape 6.0 and higher and Opera 6.0, Maxthon 1.2 .0 and higher.

6.2 Unit Testing (Test cases)

Since my web pages generate lot of dynamic content using JSP as the logic, I tested the functionality of my website using various test cases. Some of the test cases are shown below:

Test case for checking if the session variable has been set: In this test case the session variable logged is checked. If it is set to yes then the button with the HOME tag is set to a particular value. This value ensures that the client gets to see the actual home page of the card details. If the user has not logged then the variable will contain the value no, then the HOME button will have a different url attached to it and the system is maintained in a secure state.

Test case for checking duplicate users: In this test case users who want to register for the same user Id are checked. When ever the user enters a user ID without a password, the Java Script will give an error. If he enters a user ID and password with a incorrect card details, the system will generate error. So the test case will check the condition that he enters the correct card details but is entering an user ID that already exists in the database. In that case the system checks all the rows containing user ID’s and displays an error message that the same user ID already exists and please register with a different ID.

Test case for checking if the web service is consistent: In this test case when the client sends a request to the server for invoking a web service method, it is expected to give an error response if the client sends the parameters in the wrong order or in the wrong quantity. Then the response will contain a SOAP error saying that the parameters are not matching.

I tested whether the web services are working correctly or not manually which means sending the web services some defined parameters and then checking the returned response from the services. The returned response either contained the right values to be displayed to the admin or client or contained the error generated. The normal errors are indicated by the error code defined by the Apache SOAP so when I try to enter random data as input to the web services they returned error code saying that the cardno does not exist. In this manner I checked whether the web services returned the right values or wrong ones based on the input parameters.

6.3 Performance Testing (JMeter)

my website is developed using JSP. So whenever the a page is opened for the first time in the browser it takes quite a bit of time to compile and run the JSP’s. But for subsequent accesses the browser will not compile, just runs it. For my website the response time dropped whenever I open any of the pages for the first time. But for the later accesses the response time was very good, around .054 seconds.

The web services were also tested using apache JMeter using the SOAP request option present in the tool and the results are displayed in the graph below

I used Apache JMeter[9] for testing my website for performance. Below are the snapshots of JMeter performance test results:

[pic]

Figure 6A

Apache JMeter results:

Graph Result:

Throughput = 1033.6001/minute.

The green curve above showing the throughput that is 1033 requests per minute.

[pic]

Figure 6B

Table Result:

Response time = 54 ms = ~ .054sec. which means that 1111 requests will be processed within a second

This table shows the response time for each thread and in average how much it takes before it gets a connection. It shows how many threads get the services of the website or get access with the website.

The below snap shot shows testing of the web services using JMeter. JMeter provides us the option where we can test the SOAP services by providing SOAP request message and entering the web service details. The above graph shows that by using the web services the throughput of the system as a whole has increased to 4700 request per minute out of 10000 requests.

[pic]

[pic]

The above snapshot shows the results of the web service testing in a table. The figure shows that both the http requests as well as the SOAP requests are interlaced between each other. From the table we can infer that the response time is 11 milliseconds which means that 5200 requests will be processed with in a second.

I have tested the system as a whole by providing the server address. That is the port on which the application is running. I have populated the database with 10000 values such that the JMeter gives a realistic curve of the web application when it is running. The part of my project that I tested was the login page or the client’s index page which is accessed the most with in the application.

Though I did not test the other pages of the application, it is apparent that the other pages will take the same amount or a little more time in getting displayer. Since some pages call the Web Services and some pages access the data base for verification, they might take a little extra time than the regular static pages.

7. SNAPSHOTS OF THE SITE – Figure 7

7.1 Admin view

[pic]

The above snapshot shows the various card details that the admin will view once he logs into the system. On the left hand side are the active credit cards in the company and on the right side are the various card applications to the company. In the bottom is the oracle procedure that updates all the accounts whose current date is 30 days from the previous statement date.

7.2 Admin card approve

[pic]

The above page shows the admin each card application individually. In this way he can approve or reject each application. If he presses the accept button then he is taken to the card activation page.

7.3 Admin card details

The below snapshot shows the credit card overview details of a particular account. Here the admin has been given several options like change account summary, enter unbilled activity, change user profile, enroll in online bill pay and finally pay the card balance.

[pic]

7.4 Admin card summary

[pic]

The above snapshot shows the credit card holder account summary. The admin has the right to increase the credit line.

7.5 Admin user profile

[pic]

The above snapshot shows the user profile page of a particular account. The admin has the right to change several fields except the first name and last name.

7.6 Admin unbilled activity

The below snapshot shows the unbilled activity page for the admin. The admin can enter each unbilled activity for a particular card by entering the fields such as the date of activity, amount and the description of the activity.

[pic]

7.7 Admin online enroll

[pic]

The above snapshot shows the online enroll page where the admin can enroll in online bill pay by giving the account no, routing no and other details for a particular card.

7.8 Admin online bill pay

[pic]

The above snapshot shows the online bill pay for a particular card. The viewer is presented with the current minimum payment and the banks in which he has enrolled for online bill pay. Then the viewer can choose any online account and select the amount he wants to pay and press the button.

7.9 Admin card activation

The below snapshot shows the card activation page for the admin. This page is entered when the admin approves a particular card. The admin has to enter the credit card no as well as the panel digits for activate a particular account.

[pic]

7.10 Client index

[pic]

The above snapshot shows the client index for the credit card company. The client can apply for credit cards, register for an online account for a particular card, view different cards available at the company and finally login into his online account.

7.11 Client card application

[pic]

The above snapshot shows the credit card application for a particular type of card. It shows the various fields needed in order to apply for a new card. The card application will be stored in a data base and show to the admin.

7.12 Client register

The below snapshot shows the client registration page for an online account. Once the client has been approved of a credit card, he is sent a card through the mail. Then he can register for an online account for that card through this page.

[pic]

7.13 Client card details

[pic]

The above snapshot shows the credit card overview details to the client. It contains various online services that help facilitate the client with several features.

7.14 Client card summary

[pic]

The above snapshot shows the account summary for the client. It shows various details like current balance, last balance, last pay, next statement day, minimum pay, due date and the amount of credit line available.

7.15 Client contact Co

The below snap shot shows the credit card company details that the client can use to communicate with the company. There is contact company page after logging in and there is one access from the index page. The logged in attribute differentiates between these two contact pages. So when the used is not logged in then the contact company page takes the index as the home page and when the used has logged in then the contact company page takes the client overview page as the home page.

[pic]

8. FUTURE WORK

Some of the improvements that can be added to the project are stated below:

• Develop a transaction server between the bank and credit card companies that handle all the requests

• Provide the admin with automated statement generation option.

• Provide the client with the ability to add other account users(multiple users)

• Provide the client with a credit line increase request option

• Provide the client with reward activity on his account

• Provide the client the service of transferring balances online from other accounts

• Provide support for mobile applications

• To make the site ADA compliant

• Provide more security using server side validation and encryption

• Provide custom built personal outlook for each user based on his needs

• Provide a search option so that user can search for a particular activity or for a particular statement

9. IMPACT OF THE PROJECT

9.1 Lessons Learnt

The main purpose of taking up this project was to enhance my web developing skills based on J2EE technologies and web services. My ability to solve web based problems has increased after the completion of this project since the modern web based application are more or less based on the MVC architecture and I have fulfilled each part of the architecture in solving this project. Some of the important lessons learnt are

• Using J2EE technologies like servlets and JSP

• Using web services like Apache SOAP

• Using XML for intermediate storage between the requests and responses

• Writing stored procedures for oracle database

• Testing tools for J2EE based applications like Tomcat

• Using MS Visio for modeling my database designs

9.2 Problems Encountered

• I thought of implementing server side caching using special jsp tags. But I was unable to configure my server. Hence I was unable to implement server side caching.

• Initially my website content when opened in Mozilla was jumbled and unorganized. So I modified the HTML and JavaScript in my website and organized properly using tables for each element of the page.

• There was a null pointer exception for most of the JSP pages when the session variable was set. So had to comment out the session code in the JSP and use the server settings for maintaining a session

• Web service was sending garbage data as response since the default XML registry mapping was not set

• Tomcat server had lot of difficulties accessing the oracle database and kept on giving class null and path null error

• The Apache needed lot of library files with out which the web services didn’t work so took lot of time in configuring Tomcat for Apache SOAP

9.3 Options that can be different

• I could have used Servlets and Java Beans instead of using JSP in accessing the web services

• I could have designed the front end in Adobe Photoshop instead of plain HTML.

• I would have liked to implement server side validation as it would prevent any kind of malice.

• I would have liked to Make the website more customized for the users.

• I would have liked to add more web services for the client and admin.

• I would have liked to use commercial J2EE servers like weblogic or websphere

• I would have liked to write more database applications like automated triggers and other functions.

10. CONCLUSION

The evolving technologies clearly lay in the development of better web services based sites. My initial interest was to develop a website that could provide the client with a set of facilities that will help in accessing his credit card account easily. As we know the real growth of a system lies in portability and being robust in nature. This can be achieved by using web services to provide the user with various options. Since the web services are platform independent they can be called by any user working on any system.

The credit card service web site is a user friendly system that helps in maintaining modularity, better user interface thus saving time taken for the clients in accessing their accounts, paying their balances using online pay, changing their profiles, applying for credit cards and other basic necessities.

The system is built using J2EE and Apache SOAP which helps in building web applications faster by reducing the amount of code required to build large applications. It makes development easier to maintain and expand. Thus credit card service system is robust extensible online entity helping the credit clients in understanding and using the various options provided by it.

11. REFERENCES

[1] Eric Armstrong, “The J2EE 1.4 Tutorial”, June 2005,

[2] “Java script tutorial”, 2001,

[3] “Servlets and JavaServer Pages (JSP) 1.0: A Tutorial”, 2000,

[4] MichaelGertz, “Oracle/SQLtutorial”, 2001,

[5] Glen Daniels, “Using the SOAP Protocol with Java”, 2003,

[6] “Server-Side SOAP tutorial”, 2002,

[7] “Using SOAP with Tomcat”, 2002,

[8] “Web Services – SOAP”, 1999,

[9[“JMeter Tutorial”, 1998,

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

User session

Admin session

Client activities

Admin activities

Database

Front End

HTML & JavaScript

MiddleWare

JSP or Servlet

Backend

Oracle 8i

Customer Registration page with Java Script

yes

yes

no

submit

Login page – you are registered

Register the user in database

Does the used Id exist

Is the credit card no correct

Enroll in online bill pay

Register for a the account

*

1

*

*

1

1

Pay credit card in real time

Login into user account

1

1

*

1

*

1

Apply for a new card

1

1

View account summary

*

*

[pic]

[pic]

Change user profile

Contact bank

SOAP JAR

SOAP JAR

SOAP Services

Apache SOAP

no

redirect

yes

yes

yes

no

no

Client card details/index page

Any error in invoking

Is the password correct

Check if the user exists

Customer Login page with Java Script

Wrong card no

Wrong user id

Wrong user id

Wrong password

yes

Data

base

no

Display the fields

Valid entries entered

Customer user profile page with Java Script

Wrong fields

Client

such as excel sheet

submit

submit

Update database using web service

update

no

Display the error

yes

Listener such as a Servlet

SOAP service methods

SOAP request

SOAP response

Method call

Method response

Database response

Database call

Oracle JDBC JAR

Oracle JDBC JAR

XML parser JAR

XML parser JAR

Service method

Service method

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

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

Google Online Preview   Download