INTERNET WARRANT SEARCH TOOL



INTERNET WARRANT SEARCH TOOL

by

HARI KRISHNA RAJU SANGARAJU

B. Tech., Jawaharlal Nehru Technology University,

Hyderabad, India, 2002

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

2004

Approved by:

Major Professor

Daniel Andresen, Ph.D.

ABSTRACT

The report describes the design, coding, implementation and performance analysis of a website that is designed for apprehending a person with an outstanding warrant at large in society and who comes under the United States’ jurisdiction.

The website presents a sequence of steps through which citizens can search for the details of a person with an outstanding warrant. This can be done by entering any of the required information associated with the warrant holder, which can be their first name, last name, date of birth, sex, last known address, zip code, county or a particular crime. The main purpose of this website is to help citizens provide tips about a warrant holder to any law enforcement agency. These tipsters are also rewarded by the website for any information provided about the suspect. They can also choose to be anonymous while providing information to the law enforcement agency. These tips are helpful in apprehending the warrant holder.

Wanted persons would now be encouraged to turn themselves in before the community does it for them. The partnership between the community and the law enforcement agencies will most certainly make the legal system that serves us all more effective and, more importantly, make our community a much safer place to live.

This website is implemented using Microsoft Visual on an IIS server with ORACLE server as the backend. It is analyzed at various points, and its performance is evaluated so that the site is clearly visible in any size window and any browser.

TABLE OF CONTENTS

TABLE OF CONTENTS………………………………………………….I

LIST OF FIGURES………………………………………………………III

ACKNOWLEDGEMENT…………………………………………….…..V

1. INTRODUCTION………………………………………………..…… 1

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

1.2 Architecture…………………………..……………………………….2

2. CLIENT TIER………………………………………………………….3

2.1 Web Pages…………………………………………………………....3

2.1.1. Description of first set of Web Pages…………………………………3

2.1.2 Description of Second set of Web Pages………………………………..4

2.2 Why .Net? ........................................................................................................5

3. SERVER ANALYSIS…………………………………………………….6

3.1 IIS Web Server……………………………………………………….6

3.2 Oracle Database Server……………………………………………... 7

4. IMPLEMENTATION ISSUES……………..………………………….8

4.1 Class Diagram and Description………………………………………11

4.1.1 Class Diagram of admin page…………………………………..........11

4.1.2. Description of the methods used for client pages………………………12

2 Class Diagram of the Client Pages…………………………………14

4.1.4. Class Diagram of page…………………………………...................15

5. DATABASE DESCRIPTION………………………………………….18

6. FEATURES OF OUR SITE…………………………………………...22

6.1 Cool Features………………………………………………………..22

6.2 ADA Compatible……………………………………………………24

6.3 Security Aspects……………………………………………………..24

7. SCREEN SHOTS……………………………………………………....26

8. LOAD TESTING AND PERFORMANCE…………………………..30

8.1 Issues regarding performance………………………………………...38

8.1.1 Scalability………………………………………………………...38

8.1.2 Repeatability…………………………………………………….....39

8.1.3 Analysis…………………………………………………………..39

9. ENHANCEMENTS AND REFLECTIONS………………………...44

9.1 Enhancements………………………………………………………..44

9.2 Reflections…………………………………………………………....45

10. CONCLUSIONS………………………………………………………46

11. REFERENCES………………………………………………………...47

LIST OF FIGURES

Figure 1. System Architecture………………………………………………………………2

Figure 2. Detailed System Architecture……………………………………………………..8

Figure 3. Class Diagram of the admin page………………………………………………..11

Figure 4. Class Diagram of the client page………………………………………………...14

Figure 5. Table Warrant_info_hari………………………………………………………...19

Figure 6. Table Alias_info………………………………………………………………....20

Figure 7. Table ChargeLiteral……………………………………………………………...21

Figure 8. Table Charge_Equivalency……………………………………………………....21

Figure 9. Table EmailHits…………………………………………………………………22

Figure 10. Disclaimer Page………………………………………………………………..26

Figure 11. Warrant Search Page…………………………………………………………...27

Figure 12. Results Page……………………………………………………………………28

Figure 13. Administrator Page…………………………………………………………….29

Figure 14. Load testing of index page for local client for 400 users………………………..31

Figure 15. Load testing of index page for local client for 10000 users……………………..32

Figure 16. Load testing of the search page for local client for 900 users…………………...33

Figure 17. Load testing of the search page for local client for 10000 users………………...34

Figure 18. Load testing of index page for remote client with 5000 users…………………..35

Figure 19. Load testing of index page for remote client with 10000 users…………………36

Figure 20. Load testing of search page for remote client for 5000 user……………………37

Figure 21. Load testing of search page for remote client for 10000 user…………………..38

Figure 22. Analysis Graph of a local client with no database access……………………….40

Figure 23. Analysis Graph of a local client with database access…………………………..41

Figure 24. Analysis Graph of a Remote client with no database access……………………42

Figure 25. Analysis Graph of a Remote client with database access……………………….43

Figure 26. Comparison Graph of both local and remote clients…………………………...44

ACKNOWLEDGEMENTS

This project is by far the most significant accomplishment of my academic life and none of this would have been possible without the support and encouragement of some special individuals who have taken their rightful places in my life.

I owe my success to my advisor and mentor Dr. Daniel Andresen without whose wisdom and vision I probably would have been lost a long time back. His advice and guidance has helped me understand and evaluate my work.

I would like to thank Dr. Masaaki Mizuno and Dr. Mitchell Neilsen for serving in my committee.

I am grateful to my colleagues in the Computer Science Department, for helping me out with some of the problems I have faced during the course of this work and also helping me start up when I first took up the project.

I can’t end without thanking some of the most important people in my life, my parents, my brother and especially Madhavi. I am deeply indebted to my parents, who have always been by my side when it has mattered the most to me, who have helped me see a vision for my future and who have made me what I am today; and to Madhavi who always believed in me even when I stopped believing in myself, and stood by my side to always encourage me when things weren’t going my way.

Finally I would like to thank every person who has ever touched my life, as each one of them has taught me and has made me better in some way or the other.

Introduction

1 Purpose

The Warrant Search website is more than an on-ramp to the Internet. It represents a long term commitment and communication campaign that makes it easy for a partnership between the community and the law enforcement agencies. This partnership would make our community a much safer and a better place to live. The website presents a sequence of steps through which citizens can search for the details of a person with an outstanding warrant. This can be done by entering any of the required information associated with the warrant holder which can be their first name, last name, date of birth, sex, last known address, zip code, county or a particular crime. The main purpose of this website is to help citizens provide tips about a particular warrant holder to any law enforcement agency. These tipsters are also rewarded by the website for any information provided about the suspect. They can also choose to be anonymous while providing information to the law enforcement agency. These tips are helpful in apprehending a person with an outstanding warrant. The tipster’s information with the vast reach of the law enforcement agencies would in turn benefit the society. With the warrant search website, users are joining a communication network that cares about the lives of the citizens.

2 Architecture

Figure 1: System Architecture

The client tiers consist of users who would like to browse through the site in order to help the law enforcement agencies in apprehending a person with an outstanding warrant. The web pages at the client side are written using Microsoft Visual

IIS; Internet Information Services is used as the web server. IIS has integrated, reliable, scalable, secure and manageable web server capabilities over an intranet, an internet or even an extranet.

ORACLE server is used as the database server for manipulating and retrieving the records. Structured Query Language is used to manipulate the contents of the tables. A set of five tables is used to store the information about the warrant holders, their alias names and their charges.

Client Tier

1 Web Pages

There are two sets of web pages in the system.

The first set of pages is accessible by citizens and used for searching of the information about a warrant holder.

The second set of web pages is used internally by the administrators of the website to make any changes to the existing warrants or add new warrants as and when they are issued.

1 Description of First Set of Web Pages

The web pages that constitute the first set are:

1) Search page

2) Tip submission page

3) Mission statement page

4) Disclaimer page

5) Individual warrant holder’s information page

6) Sheriff’s alliance page

7) Frequently Asked Questions page

8) Print page

The most important page in the first set of web pages is the disclaimer page without reading which citizens are advised not to use this site. The first set of web pages gives a brief description about the mission and also gives citizens access to search for the warrant files, holding those persons wanted by the legal system accountable, thereby making our community safer.

The web pages provide the ability to view warrants issued to a particular person either by entering the name of the person, address, sex, race, date of birth or the type of crime committed. There is also an individual warrant holder’s information page which gives all the information about an individual warrant holder along with his/her picture. If the information available from the tipster matches the information about the suspect, then a tip about that individual can be submitted with the help of a tip submission page. In the tip submission page citizens can submit their tips to the law enforcement agencies, thereby preventing a new crime from happening.

The first set of pages also has information about the contact number, names and pictures of the Sheriffs who have had close association with this website. These pages also have links to other useful sources of information such as various police departments/contact information.

The final page is a print page, which is useful if anyone wants to take a printout of any warrant holder’s information that he might consider useful.

2 Description of Second set of Web Pages

The second set of web pages is used by the administrators of the website. These pages can be used to update data about a warrant holder, such as adding new warrants, deleting the warrants that have been outdated and also adding information about person with new or outstanding warrants. A link from the first set of pages to the second set of pages has not been purposefully provided as it was felt that there was no need for a citizen or a tipster to even know that the administrator pages were located at the particular URL. The administrators of the website are provided with a username and password with which they can log in to the site and modify the data. The administrator pages do not have a mission statement and disclaimer because being the administrator of this website one would be having all the information about the site like its functionality and the mission page and the disclaimer page would be of no use.

2 Why .Net?

The advantages for choosing .Net include the following:

1) It is object-oriented and has many programming tools that allow for faster development and more functionality.

2) Two aspects of .NET that make it fast are compiled code and caching. With .NET the code is compiled into machine language before the visitor ever comes to the site, making it faster.

3) .NET automatically recovers from memory leaks and errors to make sure that the website is always available to the visitors.

4) Programmers can actually write their code in more than 25 .Net languages (including , C#, and ). This allows programmers to develop the site in the language they know best and programmers are more easily found to support the work on your site.

5) .NET gives language neutrality when developing new e-Business applications.

6) NET benefits from being strongly interweaved with the underlying operating system.

7) was tested and found to be over 10 times faster for the average user than other technology. While there have been some debates about the methods of the testing, it is interesting to note that this has been validated by third parties.

8) As compared to ASP application the deployment is easy as in .NET there is no need of DLL registration.

9) In .NET view control, user control and data grid control can be used to Add/Edit/Delete in the grid itself. These also have the advantage of inbuilt sorting and paging logic.

Server Analysis

The two servers that were used for our website are IIS, web server and ORACLE, database server. The reason for choosing these servers is explained in detail in this section.

1 IIS Web Server

The reasons for choosing IIS are as follows:

1) The primary reason for choosing the IIS web server was because of its fault- tolerant architecture and intelligent queuing.

2) IIS, (Internet Information Services) provides integrated, reliable, scalable, secure, and manageable web server capabilities over an intranet, the Internet or an extranet.

3) The management of IIS is much easier compared to other web servers and has XML based configuration; IIS also provides remote administration and command-line administration.

4) IIS is easily scalable and easily scaled out and in without any trouble, and it also provides dynamic caching.

5) IIS is secure by design, secure by default and secure in deployment.

6) It adheres to the latest standards which expand the security features. Configuration and maintenance are much easier compared to that of other prevailing web servers.

7) IIS 6.0 has been redesigned with the goal of ensuring that a failure in an application does not damage other applications or the entire web server itself.

2 ORACLE Database Server

The main reasons for using ORACLE server include:

1) SCALABILITY

ORACLE supports the largest databases. Since we are maintaining our own database of warrant holders, we might need to support large amounts of data regarding the various offenses committed by the warrant holders along with their alias names and last seen address.

2) RELIABILITY

Since our website is a public domain, we might have huge number of hits every day from all the intended users who come to our site either to provide a tip to the law enforcement agencies, or to learn about a warrant holder.

ORACLE supports large numbers of concurrent users executing a variety of database applications operating on the same data. It minimizes data contention and guarantees data concurrency. In the future, even though users increase, there would be no problem overall.

3) SECURITY

One of the major concerns regarding our database was the security issues as we would be maintaining tables to store warrant holders information like his name, address and personal information like SSN and driving license details. We had this extra overhead of maintaining all this information securely.

4) OTHER REASONS

Based upon the functionality of our website, it is obvious that we have to be in a position to handle requests from users accessing our website from various different types of computers and operating systems. ORACLE software enables different types of computers and operating systems to share information across networks. Apart from these reasons, ORACLE supports replication of both data- and schema-level changes to multiple sites.

Implementation Issues

[pic]

Figure 2: Detailed System Architecture

The source code is compiled and run in the .NET Framework using a two-stage process. First, source code is compiled to Microsoft intermediate language (MSIL) code using a .NET Framework–compatible compiler, such as that for Visual Basic .NET or Visual C#. Second, MSIL code is compiled to native code.

When the page request is sent through the browser, the page is run through a series of events during its creation and disposal.

The first step in processing the page is object initialization. During object initialization the page’s controls and the page itself are initialized in the raw form. Since the objects are declared the page know what types of objects and how many to create.

After the controls are initialized, they receive their first properties: viewstate information that was persisted back to the server on the last submission. The page viewstate is managed by and is used to persist with the information over a page roundtrip to the server. After the viewstate is persisted with, the form data that was posted to the server is processed against each server that requires it. After this the Load event of a page is called in which Objects take their true form and they are free to retrieve the client side properties set in the HTML such as width, value or visibility.

After all the controls are updated with their correct postback data, each control is flagged with a Boolean value, on whether its data was actually changed or remains the same since the previous submit. then sweeps through the page looking for flags indicating that any object's data has been updated and fires RaisePostDataChanged. The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred.

After the server-side events fire on data that was changed due to postback updates, the object which caused the postback is handled at the RaisePostBackEvent event. The offending object is the search form submit button that is clicked to do the search for warrant holders.

After all changes to the page objects have occurred viewstate is saved. Object state data is persisted in the hidden object and object state data is prepared to be rendered to HTML.

The Render event commences the building of the page by assembling the HTML for output to the browser. During this the page calls on the objects to render themselves into HTML. The Render method takes an HtmlTextWriter object as a parameter and uses that to output HTML to be streamed to the browser.

After the page's HTML is rendered, the objects are disposed of. During the Dispose event, you should destroy any objects or references you have created in building the page. At this point, all processing has occurred and it is safe to dispose of any remaining objects, including the Page object.

The following classes from the .NET class library were extensively used:

1) Datagrid: A data bound list control that displays the items from data source in a table. The DataGrid control allows you to select, sort, and edit these items. The DataGrid control supports selection, editing, deleting, paging, and sorting. Different column types determine the behavior of the columns in the control. The following table lists the different column types that can be used.

2) DataAdapter: Represents a set of data commands and a database connection that are used to fill the DataSet and update the data source. The DataAdapter serves as a bridge between a DataSet and a data source for retrieving and saving data.

3) DataSet: Represents an in-memory cache of data. The DataSet, which is an in-memory cache of data retrieved from a data source, is a major component of the architecture. The DataSet consists of a collection of DataTable objects that you can relate to each other with DataRelation objects.

1 Class Diagrams and Description

The class diagrams of the various classes that are used in the implementation of the project and the various methods that were used in these classes are as follows:

1 Class Diagram of the admin page

[pic]

Figure 3: Class Diagram of the admin pages

The arrows don’t mean any inheritance but the flow of control from one class to the other.

2 Description of the methods used for client pages

Class: login

Methods:

i) Button1_Click(): This method is used to verify the login name and password, if the login name or password is incorrect then JavaScript is used to alert the user that the information is wrong.

Class: edit10

Methods:

i) Button1_Click(): This method is used to store the information entered by the user in the textboxes present on the web form, i.e., the MNI number or the Lastname and the Warrant number information is stored in session variables. The control is transferred to the edit.aspx page.

Class: edit10

Methods:

i) page_load(): This method is called when the form loads, here we get the values of the session variables from the previous page and assign them to new variables declared in this page. The populatetext() method is called from this method.

ii) populatetext(): This method is used to populate the textboxes present on the web form. A SQL query is executed and the corresponding data is retrieved from the warrant_info_hari table depending on the information transferred from the previous page and a dataset is created and the values are taken into a string array (ex txtFName.text is assigned str(4) since value firstname is stored in that index.).

iii) Getquery( ): This method is used for building a dataset that contains the rows that are returned by the SQL query executed by the user. Here an oledb connection is created, the connection string is declared and a data adapter is used to fill the dataset. The SQL query is passed as an argument to the function.

iv) Button1_Click(): All the values in the text boxes are taken into session variables and the control is transferred to the save_edit.aspx.

Class: edit1

Methods:

i) page_load(): this method is called when the form loads , here we get the values of the session variables from the previous page and assign them to new variables declared in this page. The update query is used to update the values in the warrant_info_hari table and set them to the new values changed by the user.

3 Class Diagram of the Client Pages

[pic]

Figure 4: Class Diagram of the Client Pages

4 Description of the methods used for client pages

Class: Search_the_database

Methods:

i) btnSearch_Click(): This method is used to transfer the information from the search page to the results_new page, this method handles the job of storing all the user entered information into session variables.

ii) btnReset_Click(): This method is used to reset all the values that have been entered by the user in the text boxes. This feature is useful in case when the user has typed wrong information.

Class: Results_new

Methods:

i) getdata(): This method is the most important method of this class as every important job of this page is performed here. This method does the function of retrieving all the session variables that were passed from the previous page. The SQL statements are executed here such that the datagrid contains all the necessary information that the user requested. There are two different SQL statements based on the fact whether the user chose offense as a choice or not, these statements retrieve information from the warrant_info_hari table. The reason for writing two different SQL statements is due to the reason that when offense is chosen by the user as a search criteria the where clause of the SQL will have to be built by choosing a concatenated string from the tables of chargeliteral and charge_equivalency. The datagrid shows a tooltip of felony warrant when the user places the cursor on any felony warrant then the tooltip shows that it is a felony warrant. Also incase a particular warrant has a photo a camera is shown on the datagrid for the corresponding column. These features are achieved in this function.

ii) Createdatasource(): This method handles the function of creating a datatable such that a dataview can be created by which sorting functionality can be achieved. This method builds a datatable and then uses the dataset that was built earlier to populate its columns.

iii) detailsclicked(): This method is invoked when onitemCommand method of the dataGridComamndEventArgs class is invoked which occurs when the user hits on any link button in the datagrid. Here we check whether the command name of the link clicked matches “lastname” if so we pass the values of MNI and the Warrant number in the corresponding row. These values are passed through the URL to the next page.

iv) sortcommand(): This method is called when the onsortcommand event of the System.Web.UI.WebControls.DataGridSortCommandEventArgs class is raised. This event is invoked when the user tries to sort the values in the datagrid by clicking on the links available for sorting the columns, here the function createdatasource() is called and a datatable is created, this datatable is then used to make a dataview and it is sorted depending upon the sort command chosen by the user. This new dataview created is made the datasource for the datagrid.

v) Onpageindex(): This method is called when the user tries to move to the next page on the datagrid, the page numbers are displayed at the bottom of the datagrid when the allowsorting property of the datagrid is chosen, when OnPageIndexChanged event of DataGridPageChangedEventArgs is raised. Here the datagrid pageindex is changed to the pageindex chosen by the user and the data grid source is rebounded.

vi) Getquery(): This method is used for building a dataset that contains the rows that are returned by the SQL query executed by the user. Here we create a oledb connection, the connection string is declared and a data adapter is used to fill the dataset. The SQL query is passed as an argument to the function.

vii) Pageload(): This method is called when the page loads, here we call the getdata() function.

Class: SI

Methods:

i) page_load(): This method is called when the form loads, here we get the values of the session variables from the previous page and assign them to new variables declared in this page. A SQL query is executed and the corresponding data is retrieved from the warrant_info_hari table depending on the information transferred from the previous page. A dataset is created and the values are taken into a string array, the labels that are declared on the webform are assigned the corresponding values from the string array (ex lableFName is assigned str(4) since value firstname is stored in that index).

ii) search(): This method is used for building a dataset that contains the rows that are returned by the SQL query executed by the user. Here we create an oledb connection, the connection string is declared and a data adapter is used to fill the dataset. The SQL query is passed as an argument to the function.

iii) LinkButton2_Click(): This method transfers the target to a new page which shows an enlarged image of the suspect’s picture.

iv) ImageButton1_ServerClick(): This method transfers the target to a new page which shows an enlarged image of the suspect’s picture.

v) LinkButton1_Click(): This method is used to transfer the control to the tip sending page.

vi) Button1_Click(): This method is used to transfer the control to search.aspx.

Class: Send_your_tip1

Methods:

i) page_load(): This method is called when the form loads, here we get the values of the session variables from the previous page and assign them to new variables declared in this page. There are labels declared on the form which are initialized from the data in the session variables.

ii) btSearch_Click(): This method is invoked when the user wants to send the information to the corresponding law enforcement agencies. This method creates an HTML e-mail by using an STMP server.

Database Description

ORACLE is used to maintain the tables. The database is updated as and when new warrants are issued or updated. The tables used are:

1) Warrant_info_hari

2) Alias_info

3) Charge_Equivalency

4) ChargeLiteral

5) EmailHits

The table schema for each of the following is as follows

1) Warrant_info_hari table: This table holds the information about a warrant holder. The schema of this table is as follows:

| desc warrant_info_hari; | |

|Name |Type |

|------------------------------------ |-------- |

|MNI |VARCHAR2(50) |

|WARRANTNUMBER |VARCHAR2(50) |

|WARRANTDATE |VARCHAR2(50) |

|SURNAME |VARCHAR2(50) |

|FIRSTNAME |VARCHAR2(50) |

|LASTNAME |VARCHAR2(50) |

|MIDDLENAME |VARCHAR2(50) |

|ADDRESSAPARTMENT |VARCHAR2(50) |

|ADDRESSSTREETNO |VARCHAR2(50) |

|ADDRESSSTREET |VARCHAR2(50) |

|ADDRESSTYP |VARCHAR2(50) |

|ADDRESSDIR |VARCHAR2(50) |

|ADDRESSSUFFIX |VARCHAR2(50) |

|CITY |VARCHAR2(50) |

|STATE |VARCHAR2(50) |

|ZIP |VARCHAR2(50) |

|COUNTY |VARCHAR2(50) |

|DOB |VARCHAR2(50) |

|EYECOLOR |VARCHAR2(50) |

|HAIRCOLOR |VARCHAR2(20) |

|WEIGHT |VARCHAR2(10) |

|HEIGHT |VARCHAR2(5) |

|BONDAMT |VARCHAR2(10) |

|CHG |VARCHAR2(10) |

|CHG_LITERAL |VARCHAR2(10) |

|RACE |VARCHAR2(10) |

|SEX |VARCHAR2(10) |

|PHONE |VARCHAR2(50) |

|PHONETYPE |VARCHAR2(50) |

|SSN |VARCHAR2(50) |

|DL |VARCHAR2(50) |

|IDSTATE |VARCHAR2(50) |

|WARRANTS_LEVEL |VARCHAR2(50) |

|RESERVEDFORPARSING |VARCHAR2(50) |

|WARRANTENTRYDATE |VARCHAR2(50) |

|TYPE |VARCHAR2(50) |

|IMAGE |VARCHAR2(50) |

|NEWADDRESS |VARCHAR2(50) |

Figure 5: Table: Warrant_info_hari

2) Alias_info table: This table contains all the alias information for a particular warrant holder, such as his alias name, date of birth, etc. The schema of this table is as follows:

|desc alias_info; | |

|Name |Type |

|----------------------------------------- |-------- |

|AA_ID |VARCHAR2(50) |

|A_WR_ID |VARCHAR2(50) |

|A_MNI |VARCHAR2(50) |

|FIRSTNAME |VARCHAR2(50) |

|LASTNAME |VARCHAR2(50) |

|SURNAME |VARCHAR2(50) |

|MIDDLENAME |VARCHAR2(50) |

|DOB |VARCHAR2(50) |

|SEX |VARCHAR2(50) |

|RACE |VARCHAR2(50) |

Figure 6: Table: Alias_info

3) ChargeLiteral: This table contains the charge literals for a particular crime. These literals are numerical values that have been assigned to a particular charge. The schema for this table is as follows:

|desc chargeliteral; | |

|Name |Type |

|----------------------------------------- |-------- |

|CHARGE |VARCHAR2(50) |

|LITERAL |VARCHAR2(50) |

Figure 7: Table: ChargeLiteral

4) Charge_Equivalency: This table contains the keyword that has been assigned to a particular charge. The schema for this table is as follows:

| desc charge_equivalency; | |

|Name |Type |

|----------------------------------------- |-------- |

|CHARGE |VARCHAR2(50) |

|EQUIVALENCY |VARCHAR2(50) |

Figure 8: Table Charge_equivalency

5) EmailHits: This table contains the information about a tip that was reported. When a tipster sends a tip to the law enforcement agencies, the details including who sent the tip, for whom the tip was sent, etc will be recorded in the table. The schema for this table is as follows:

| desc emailhits; | |

|Name |Type |

|----------------------------------------- |-------- |

|DATESENT |VARCHAR2(50) |

|EMAILTO |VARCHAR2(30) |

|COUNTY |VARCHAR2(25) |

|WARRANTNUMBER |VARCHAR2(30) |

|SUSPECTNAME |VARCHAR2(30) |

|SENDERSNAME |VARCHAR2(30) |

|SENDERSPHONE |VARCHAR2(30) |

Figure 9: Table EmailHits

Features of Our Site

1 Cool Features

Some of the features which our site provides are as follows

1) Search on preference option: Visitors to our site can search for persons with outstanding warrants based on their preferences. They can search based on the warrant holder’s first name, last name, sex, race, date of birth, offense committed, street address, city, county, zip, their street name, or any combination of these.

2) Sort on preference option: After a search has been done based on the user’s preference, a sort on preference option is provided to the user. In the grid that is displayed to show all the warrant holders whose information matches the data specified by the user, he can sort based on their last name, bond amount, county or even warrant holder’s offense by just clicking on the links provided for the column names.

3) Distinction between felony and misdemeanor warrants: Once the results have been retrieved from the database based on the options provided by the user, he can just place the mouse cursor on the last name of the person and know whether the person he is looking for is wanted on a felony or a misdemeanor warrant. So, even before going to the individual page provided for a warrant holder to know about his crime, the user can distinguish whether the warrant holder is wanted for based on a felony or a misdemeanor.

4) Dynamic layout: The site is designed in such a way that it adjusts itself to be visible clearly in any modern-day browser of any size. It adjusts itself in such a way that the menus are clearly visible even when the size of browser window decreases or increases.

5) Minimal user input: The site is designed so that the visitor can just enter the minimum amount of information required and search for warrant holders. Just by making one selection from a drop down menu or by entering any part of the name of address, the search for warrant holders can be done. This makes our site more accessible to the citizens.

2 ADA Compliant

ADA (Americans with Disabilities Act) prohibits discrimination on the basis of disability in services provided, so we have taken the utmost care to provide our site with special features through which users with disabilities can easily access our website without any difficulty. These features are included:

1) Lack of Frames: Some handicapped users may have screen readers enabled on their computers, so frames were deliberately avoided as using frames prevents the screen readers from functioning properly. This makes our site accessible to handicapped users also. To encrypt data, enter the data ("plaintext") and an encryption key to the encryption portion of the algorithm. To decrypt the "ciphertext," a proper decryption key is used at the decryption portion of the algorithm.

2) Alt-Tags: Alt-Tags, “alternative text tags” have been provided for all the images and other multimedia content. This can be used when the image is not being displayed properly. Alt-text also enables the handicapped person to know about the images that were provided in the site with the help of screen reader. Also, search engines are unable to view graphics or distinguish text that might be contained within them. For this reason, most search engines will read the content of the image’s Alt tags to determine the purpose of a graphic.

3 Security Aspects

Security of the data is one of the primary requirements of this kind of a website. Good care has been taken for the secure transmission of data from the web pages to the database and vice-versa. The features that were incorporated are

1) Use of Encryption Algorithm: RSA algorithm was used to save the data in an encrypted form in the database. RSA is a public-key cryptosystem developed by MIT professors: Ronald L. Rivest, Adi Shamir, and Leonard M. Adleman in 1977 in an effort to help ensure internet security. To encrypt data, enter the data and an encryption key to the encryption portion of the algorithm. To decrypt the "ciphertext," a proper decryption key is used at the decryption portion.

2) Use of SSL: For the secure transmission of data SSL, (Secure Sockets Layer) was used. SSL is a protocol that transmits private documents through the Internet. SSL creates a secure connection between a client and a server over which any type of data can be sent securely. SSL works by using a private key to encrypt data transferred over the SSL connection. The addresses (URLs) of web pages that require an SSL connection start with https: rather than the conventional http:. Permission was obtained from the system administrator for https, and thus secure transmission of data from the administrator page to the database was provided.

3) Http Session: Session tracking was implemented using HTTP sessions. A new session is created every time a user searches for the warrant holder’s information. Since data is transferred only from the search page, sessions are maintained only for this page. The session state is lost once the data has been retrieved from the database and displayed at the client side. A new session is created if the user wants to search on a different option.

Screen Shots

There are two sets of web pages for our website. The first set is accessible to the general public and the second set of web pages is accessible only to the administrators.

[pic] Figure 10: Disclaimer Page

[pic]ges are the general public where as teh table is as follows

llows

Figure 11: Warrant Search Page

People browsing our site can view the warrants by entering at least one of the required fields in the warrant search page

The results page after the data is retrieved is as shown

[pic]Figure 12: results page

This search was done by giving a first name of “sindy” and leaving the rest of the text boxes blank.

The administrator page where the administrator enters and edits the information about a warrant holder is as follows:

[pic]

Figure 13: Administrator Page

Load Testing and Performance

There was a problem with the debugger provided in Visual , and even NUnit did not work the way it was expected to. In order to overcome this HarnessIt, a premier unit testing software was used to debug the application.

Our website does not involve high bandwidth-occupying images or bitmaps which could unnecessarily take lot of time to load. The loading time for these pages is quite decent and fast.

To load test functional behavior and test performance Apache JMeter was used. It can be used to simulate a heavy load on a server or object to test its strength or to analyze overall performance under different load types. The test was performed on pages, which did not need any database access and also on pages which needed database access. The graphical results obtained during the load performance test are shown and throughput number in the graph is the number of request the server handled per minute. The data obtained from the JMeter tests are used to analyse the performance of the individual pages in the section 8.2

[pic]

Figure 14: The load testing of index page for local client for 400 users

Index page does not involve any data access it is a plain html page with information such as the disclaimer and various links to other sites on the web. This page contains a link to the search page such that the user can search through the database. This test was performed for a user size of 400 on the local client.

[pic]

Figure 15: The load testing of index page for local client for 10000 users.

Index page does not involve any data access it is a plain html page with information such as the disclaimer and various links to other sites on the web. This page contains a link to the search page such that the user can search through the database. This test was performed for a user size of 1000 on the local client.

[pic]

Figure 16: The load testing of the search page for local client for 900 users.

Search page has text boxes such that the user can enter the various search criteria such that he can query the information from the database. The search retrieves the information such and displays the corresponding information on the screen. This test was performed for a user size of 900 on the local client.

[pic]

Figure 17: The load testing of search page for local client for 10000 users.

Search page has text boxes such that the user can enter the various search criteria such that he can query the information from the database. The search retrieves the information such and displays the corresponding information on the screen. This test was performed for a user size of 1000 on the local client.

[pic]

Figure 18: The load testing of index page for remote client with 5000 users.

Index page does not involve any data access it is a plain html page with information such as the disclaimer and various links to other sites on the web. This page contains a link to the search page such that the user can search through the database. This test was performed for a user size of 5000 on the remote client.

[pic]

Figure 19: The load testing of index page for remote client for 10000 users

Index page does not involve any data access it is a plain html page with information such as the disclaimer and various links to other sites on the web. This page contains a link to the search page such that the user can search through the database. This test was performed for a user size of 10000 on the remote client.

[pic]

Figure 20: The load testing of search page for remote client for 5000 user.

Search page has text boxes such that the user can enter the various search criteria such that he can query the information from the database. The search retrieves the information such and displays the corresponding information on the screen. This test was performed for a user size of 5000 on the remote client.

[pic]

Figure 21: The load testing of search page for remote client for 10000 users.

Search page has text boxes such that the user can enter the various search criteria such that he can query the information from the database. The search retrieves the information such and displays the corresponding information on the screen. This test was performed for a user size of 10000 on the remote client.

1 Issues regarding performance

1 Scalability:

There are two bottle necks in the system and as the system is extended and new regions and counties are added to make this site a nation wide one, we can employ two methods.

1) Use of a global connection string: Each time the dataset is to be created the database is accessed using a connection string. Instead of using a connection string in every data access page we could declare the connection string in the web.config file of the project. This way the connection string is cached in the memory and it need not be cached again for every page with data access.

2) Query Optimization: Instead of using complex SQL queries, query optimization techniques can be used in order to simplify these queries. Using these techniques we could perform selection operations earlier so that we could minimize the number of tuples and then perform the join operations there by making the whole combined operation faster.

2 Repeatability

The performance of the website has been tested against a variety of test cases. These tests have been performed for both local and remote clients with the number of clients varying from 400 to 10000. Pages which needed database access and also pages without any database access were tested. The requests to the website were at a random basis and also at a uniform basis. These tests were performed on a client with a Pentium 4 Processor with a speed of 1.8 GHz and 512 MB RAM. These clients are connected to a 100 Mbps LAN. The OS on the client side is Windows XP and on the server side is Windows 2000. The JMeter 1.9.2 version and the HarnessIt version 1.4.0.3 were used for the performance testing and debugging respectively.

3 Analysis

In order to perform the analysis of the web pages, a graph was built with throughput (number of requests processed per minute) on the Y-axis and number of users scaled on the X-axis. These analyses are made on the data obtained from the JMeter test results. The graphs obtained are as follows.

[pic]

Figure 22: Analysis Graph of a local client with no database access

This chart shows that as the number of users increases the throughput decreases. With the number of users equal to 5000 the throughput was around 5000 per minute but as the number of users increased to 10000 the throughput dropped to 4500 per minute. With the increasing number of users the network is overloaded and this decreases the performance of the site.

[pic]

Figure 23: Analysis Graph of a local client with database access

This chart shows that as the number of users increases the throughput decreases. With the number of users equal to 5000 the throughput was around 2740 per minute but as the number of users increased to 10000 the throughput dropped to 2209 per minute. The database becomes a bottleneck when the number of users increases beyond certain number and so the performance drops.

[pic]

Figure 24: Analysis Graph of a Remote client with no database access

This chart shows that as the number of users increases the throughput decreases. With the number of users equal to 5000 the throughput was around 3655 per minute but as the number of users increased to 10000 the throughput dropped to 3175 per minute. The throughput observed is more than that of the local client with data access. This implies that web pages with no data access have a greater throughput. With the increasing number of users the network is overloaded and this decreases the performance of the site.

[pic]

Figure 25: Analysis Graph of a Remote client with database access

This chart shows that as the number of users increases the throughput decreases. With the number of users equal to 5000 the throughput was around 600 per minute but as the number of users increased to 10000 the throughput dropped to 544 per minute. The throughput observed is the lowest when compared to the other three graphs. The database becomes a bottleneck when the number of users increases beyond certain number and so the performance drops.

[pic]

Figure 26: Comparison Graph of both local and remote clients

This chart shows that local client is with no data access is fastest when compared to other three graphs. Also the web pages that have data access are very slow when compared to the pages that have no data access.

Enhancements and Reflections

1 Enhancements

With the current investigation on topics such as what fields are necessary to search for a warrant holder, information that a person would need to enter in order to provide a tip; a base has been established, which can be enhanced in future as follows,

This website is created for apprehending people with outstanding warrants and currently supports only those warrant holders who are held responsible for crimes in Manhattan, Kansas. This website can be extended to hold the information of all warrant holders and who come under the United States’ jurisdiction.

Another enhancement that can be done is to make this website a WAP-enabled one so that citizens can access the website from their cell phones, PDA’s or pocket PC. The existing pages need not be modified, as their performance has been good; however the options provided need to be changed. For example the current options for searching on the basis of race are only black, white or Hispanic, with the increase in the number of warrant holders, options like these will not be sufficient to classify all the categories of people and there might be more options available.

2 Reflections

The project has helped me gain an understanding of the working of a web portal and ways of developing applications upon it. The usage of Visual Studio .Net has given me an opportunity to explore the options in .Net. I have explored various services that Visual Studio .Net offers and I am enthusiastic to use them in my upcoming projects. The usage of the various tools that Visual Studio .Net offers would drastically reduce the development time of the projects and would be a primary choice in RAD applications.

Conclusions

This system will reduce the burden of bookkeeping for the departmental staff of law enforcement agencies. The use of Visual and IIS will make the application faster and more reachable to the user. Moreover being language independent any person who has developed applications on windows based platform can be used to add any more features to this site. The use of Oracle database server will enhance the security of the vital information about a warrant holder. This system is more reachable to the people around the world, thus eliminating the geographical constraints and time-zone constraints. This system involves a common man in the process of apprehending people with outstanding warrants at large in the society. From the society’s point of view, the combined effort of the citizens and the law enforcement agencies would make this world a better place to live. Moreover this project has been done in a very general way. Its design allows for easy enhancements in the future, and adding other options would be very easy

REFERENCES

1] Jesse Liberty, Dan Huruwitz, Programming , O’Reilly Windows.

2] Chris Ullman, John Kaufmann, Chris Hart, David Sussman, Beginning with , Wrox Publications, 2003.

3] Scott Mitchell, Data Web Controls Kick Start, SAMS; 1st edition December 2002.

4] J .Mintert, D. Andresen, T.Schroeder, “Improving Efficiency in Business-to-Business Information Transfers: A Web-Based Solution in the Beef Sector,’’ in the International Journal of Information Management, August, 2003.

5] tutorial and tutorial for making dynamic web pages



6] Sample examples and a quick guide to various features of the .NET framework

7] Datagrid sorting and paging instructions

8] Binding datareader to a datagrid using ORACLE server

vbnet.aspx

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

Browser

Database - ORACLE

Browser

Browser

IIS

Client Tier

Web Server

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

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

Google Online Preview   Download