Network Management Solutions Technical Manual

Home / About us / Contact us

Web Based Network Management System in Java

NMS1.0 TECHNICAL MANUAL

Project Supervisor:

Renaat Verbruggen

DCU -

Team Members:

David ReadeTim Kelly

CASE 4CASE4

9975562950221221

Table of Contents:

1.Introduction

1.1 Scope of the Document

1.2 Overview of the Project

2. Functional Description

2.1 System Architecture - Three Tier Web Application

2.1.1 GUI

2.1.2 Middleware code

2.1.3 Relational Databases

3. Subsystems

3.1 The Backend Database

3.1.1 The Helpdesk

3.1.2 Employee Database

3.1.3 ServerCheck Database

3.2 Middleware Components

3.2.1 Security - Form based Authentication

3.2.2 Config Area

3.2.3Client Area

3.2.4 Administrator Area

3.3 Web Based GUI

3.3.1 Type Checking -JavaScript

3.3.2 Stylesheets

4. Project Stages

5. References

6. Appendix:

6.1 Java Code

6.2 Project Diaries

6.3 Stylesheets – Home.css

1.Introduction

The NMS1.0 software package is a comprehensive all in one IT helpdesk tool which is designed to be easy to install and easy to use for both network clients and administrators. This first release is modelled loosely on the DublinCityUniversity network which runs Microsoft NT 4.0 but the system has been tested successfully on both Windows 98 and Windows 2000.

The NMS system is ideally aimed at medium to large scale non IT related companies who have many servers to maintain and a large client base. The system has been developed to be maintained by one or more network administrators or IT staff and to be easy to understand and implement by all.

The main aims of the system are

  • To improve helpdesk functionality and network uptime by facilitating quick and easy diagnosis of potential problems with automated notification via email or SMS.
  • To provide a Data store of IT problems and solutions which can be easily searched to facilitate problem diagnosis and repair.
  • To provide a template for maintaining network data through the use of the Client database which is linked to the interactive map.
  • To provide a means for quick and easy searching of all network clients and an easy way to maintain all related data.
  • To provide a live view of the network servers.
  • To reduce network calls relating to printer connection.
  • To be easy to use by both clients and administrators.

For any system of this nature to be viable and useful to a company it has to be secure, do exactly what it says it does, portable, efficient, easy to install and maintain and be visually sound with an easy to follow layout. The NMS1.0 is designed specifically to these requirements to ensure that the final product has the potential to be marketed and sold throughout the world or on a lesser scale to ensure that both participants in the project have developed the skills, confidence and technical base necessary to apply this type of system to any future area as Java programming is the area of software development that we both wish to enter post-graduation.

1.1Scope of the Document

This document covers all areas of project development from Architecture and component design to Database development and GUI design. All stages of the development process are detailed to provide a comprehensive analysis of the technicality involved in this system. It also details our research and our reasons for choosing specific techniques throughout the development cycle.

1.2Overview of the NMS1.0 software package

The NMS1.0 system is based on the three tier architecture common in many web based applications. This consists of an easy to use Web based Front end, a Tomcat Web server for running all the middleware Java components and a backend Data Store in the form of a MySQL database.

This system is developed entirely in Java and requires that the J2sdk1.4.0 or later is installed on the host machine. This version of the jdk is included on the NMS1.0 software disk. It also requires the installation of Tomcat4.0 or later and MySQL3.23 both of which are packaged with the NMS1.0 software disk.

2. Functional Description

The system is modelled on the Three Tier Architecture (see section 2.1) with some components being developed outside the system and then being integrated once they have been tested and are complete. Other components required internal development within the system as they involved developing all tiers of the component simultaneously.

This project was our first time using JSP’s, Tomcat and MySQL and we both had to get familiar with these before any development could be undertaken. We also had to keep in mind the portability issues related to developing software projects of this nature and for this reason we decided to set up all of the required software in DCU (Windows NT4.0) and at home (Windows 98 and 2000). This broadened our view of the system and allowed us to develop the application for three differing platforms simultaneously which ensured a good level of portability.

2.1 System Architecture

This application is modelled on the Three Tier Architecture which consists of a graphical user interface, middleware components such as JSP’s running on a web server (Tomcat) and a backend database (MySQL).

2.1.1Graphical User Interface

The GUI is an important part of any application because it is where users interact with the system. It is important to hide the complexity of a system behind the GUI and to make it visually pleasing and easy to use. Choosing a layout for our GUI was one of the first things that we decided on. We came up with a rough outline which would be further developed as the application was being built. While researching our GUI we had to familiarise ourselves with HTML and some of the features of JSPS. We opted for a relatively straight forward design which we felt would be quick, easy to use and effective.

This design relied on a constancy throughout the site with a logo on top and a bar for the date and time with links. Most pages also feature the sidebar which allows for easy use of the system. The sidebar provides links to each section of the system available to the user as well as providing the employee and server search facilities. The content of the pages is contained in the section outlined in the diagram below.

Tools used:

Microsoft FrontPage, Macromedia Dreamweaver and Adobe Photoshop 6.0

2.1.2JSP and Java Code

While researching JSP’s we discovered that there are two main types of architecture used in JSP development, Model 1 and Model 2 architectures. We decided to use Model 2 because it was more suited to the needs of our application. Model 2 involves using a controller to run the control logic and a presentation page to display the presentation logic. Model 1 is more highly coupled than Model 2 as it does not separate presentation logic from control logic and we believed that using Model 2 would allow us to present more readable and understandable code especially relating to the control logic which is used for database manipulation and more complex programming features.

MODEL 2 ARCHITECTURE DIAGRAM

Code Reuse and ComponentBuilding

During the analysis of any modern software project code reuse plays a vital part in the development process. We decided to break our application into its component parts and to develop them separately and then finally integrate them together. Breaking our code up into components allowed us to break down the more complex code into more manageable modules based on the functionality of the code. This made it easier when testing and debugging as we had smaller pieces of code to work with and not one large complex application.

Component building in JSP is done through the use of objects and JavaBeans which are first compiled and the class files stored in the Web-inf\classes\com folder. These objects are called throughout our application and actually perform the complex work done by the system. The reuse of code is made easy by using these objects as it allowed us to use the methods of one class over and over again which is necessary when using JDBC which constantly connects and disconnects from the database.

2.1.3Relational Database

The backend tier of our system is the datastore, in this case a MySQL database.

One of our main worries with developing this system was this backend database. Many students take database projects for the third year project but neither of us did and looking back it would have helped us greatly if we had. Our only real hand's on experience with database development was with Object relational databases in third year and we were not sure how the system would turnout. After researching relational databases and the JDBC we opted for a MySQL database which is fast and freely available. All of our tables are created using the JDBC and middleware Java code.

3. SubSystems

Each tier of the Web application breaks down into separate sections which in turn can be broken down further into the components which make up the system.

3.1 The Backend Database

The database is the backbone of many aspects of the system. It stores all the data relating to the helpdesk, the employees and the servers. We decided on using MySQL as our database for a number of reasons. MySQL is a highly rated fast relational database widely used throughout industry and we believed that gaining experience with MySQL development would improve our chances of securing employment in the area of Java based Web programming.Another key factor is that it is also available as a free download.This allowed us the chance to set up the system at home as well as in DCU which added to improving the portability of the system.

The database section which follows does not detail the workings of the application rather it outlines the storage mechanism which is used. The JDBC and more intricate workings of the system are detailed in section 3.2 Middleware Components and in the Java Code in the appendix.

3.1.1 The Helpdesk

The helpdesk database provides two main functions in the system. It acts as an IT helpdesk, storing data entered by clients which is viewable and amendable by administrators. Besides this it also stores the administrator data which is necessary to login to the system because of security constraints.

Design of the helpdesk involved research into what is required of the helpdesk and what is the best way to implement those requirements. The first step was to develop the Entity relationship diagrams which allowed us to model the system on paper.

From the model we developed three types of calls necessary for the helpdesk. These call types are:

  • Client_Call
  • Admin_Call
  • Historic_Call

Client Call:

We had to discuss and agree on whether or not to provide clients with a login to the system and ultimately we decided against it. The reason for this being that this was mainly an IT helpdesk tool and for clients it only facilitates entering data to the helpdesk or searching the employee database and network map. The only ill affect of clients not having a login id is that they must enter their details with each call to the helpdesk but from an administrators point of view it means much less maintaining of client accounts. The client_call is derived from the client entity and the call entity and the relationship between them.

Call_ID is the primary key which is used to identify each call in the helpdesk. The log date and time are automatically recorded in the database without any need for user input.

The client enters details such as name, email and phone to make them easily contactable.

The call type holds data relating to the call such as Software, hardware etc. This allows easy grouping of calls in the database relating to the problem area.

The keyword also helps to further group the calls in the helpdesk. The keyword should be concise and relate to the name of the problem e.g. If some software is not working correctly the name of that software would be entered into the database such as Tomcat and this allows future administrators to easily search closed calls to see if the solutions aid their current problems.

The priority field allows the administrators to know how urgent the problem is.

The client also enters the date on which they request the problem to be dealt with.

Finally is the description, this will contain full details of the client’s problems.

Admin Call:

From the administrator area of the system, administrators can view all calls entered into the helpdesk. From here they can commit to the calls entered by the client. When an administrator commits to a call the call is deleted from the Client_call queue and placed into the Admin_Call queue along with the details of the administrator. The call is from then on associated with the AdminID of the administrator who commit to the call. The Admin_Call is based on the client and call entities with the relationship between them and the administrator being added once the administrator has hit commit.

The only extra details on Admin call are the administrator details and the date on which the administrator commits to the call.

Historic Call

The historic call is the final type of call in the helpdesk database. This fully incorporates the client entity, the administrator entity and the call entity. Once the administrator has successfully completed a call they must enter the resolution and then close the call. The call is then deleted from the admin_call queue and stored in the Historic_call queue which can then be searched to display full details about the call including who entered the call, who closed the call, the problem and the resolution.

user role

This table contains two fields Username and role_name. This table is used by the j_security check which facilitates secure form based login in the application

3.1.2 Employee Database

The employee database provides one main function in the system. It stores data relating to all employees who are connected to the network. Each employee is identified by a unique Employeeid and a unique NetID which represents each network connection in relation to a desk. It also contains network and software licence data for easy maintainability and tracking. Finally it contains a photo of the employee. The purpose of this is again to aid the IT helpdesk (and be of benefit to clients) by providing a facility which they can check quickly when they are dealing with a clients call

3.1.3 ServerCheck Database

The ServerCheck database stores data relating to servers which run on the network. It contains two tables’ servercheck and serveradmin:

servercheck

Each server is identified by a unique ServerID and contains the following data

  • The IP address of the server , used for pinging
  • Server name in written English
  • Exact location of the server
  • Details about the software being run on the server
  • The status of the server – Online, Offline or Error.

serveradmin

This contains data about administrators who register for notification with the servercheck system. It stores a unique AdminID, the administrators name, email and sms number. The email address and sms number are then used for notifying the administrator when a server has gone down.

3.2 Middleware Components

The NMS1.0 system consists of Java and JSP middleware components. The code consists of JDBC and embedded SQL code for connecting to and manipulating the databases, session Objects for session tracking, core Java for running the ServerCheck system and JSP’s for interfacing with the more complex code behind.

3.2.1 Security – Form based Authentication, see appendix

In any web based application security and integrity are essential and need to be implemented correctly to ensure an efficient system. When deciding on the security for this system we researched the other options available with Tomcat such as basic authentication but opted for form based as it suited the needs of our system better. Form based allowed us to develop the login in accordance with the rest of our site and it also allowed dynamic addition of new administrators without the need for restarting the web server.

Tomcat provides Form based authentication through its

  • server.xml and web.xml files
  • use of a j_security check form in a JSP page which requires two parameters j_username and j_password.
  • Specifying roles within the database

Server.xml

This is the file stored in the c:\jakarta-tomcat-4\conf folder. The server.xml file specifies realms which get a realm stored that is stored in a database and accessed via JDBC. In the case of this application it specifies to look in the administrators table of the helpdesk database which is associated with the username and role specified in the user_role table.

RealmclassName="org.apache.catalina.realm.JDBCRealm" debug="99"

driverName="org.gjt.mm.mysql.Driver"

connectionURL="jdbc:mysql://localhost/helpdesk?user=root;

password=password12"

userTable="administrators" userNameCol="Username" userCredCol="Password" userRoleTable="user_role" roleNameCol="role_name" />

Web.xml

The web.xml file needs to be created and stored in the Web-Inf folder. The following file specifies the constraints and the authentication method.