Java Web Services and JSP based Credit Card System
By
DEEPAK REDDY CHITTOORNALLAPAREDDY
B.Tech, J.N.T.U, India, 2003
A REPORT
Submitted in partial fulfillment of the
Requirements for the degree
MASTER OF SCIENCE
DEPARTMENT OF COMPUTING AND INFORMATION SCIENCES
COLLEGE OF ENGINEERING
KANSASSTATEUNIVERSITY
Manhattan, Kansas
2005
Approved By
Major Professor
Dr. Daniel Andresen, PhD
1
ABSTRACT
The main objective of building a credit card website using ApacheSOAP 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 ApacheSOAP 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.
1
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
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, ApacheSOAP 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 Tomcatserver 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
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
Figure 2A
2) Customer Login: The below diagram shows how the control flows when a client logs into the credit card website.
Figure 2B
3) User Profile: The below diagram shows how the control flows when the user wants to check and update his profile
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 SOAPresponse 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 SOAPBody [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 SOAPrequest and response are mapped using the default settings and retrieved.
As an example of how the SOAP works from the high level viewlet 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 ApacheSOAP 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();