Dynamic Service Composition and Selection through an Agent Interaction Protocol

PROJECT REPORT
Submitted in partial fulfillment of the requirements for the award of the degree of

MASTER OF COMPUTER APPLICATION

ABSTRACT Dynamic Service Composition And Selection Through An Agent Interaction Protocol is a web-based system, designed for Propest Co. ltd, which gives information relating to the clients and dealers of the company with respect to its pesticides product launches. This product develops a system that can be used by the company management to keep track of the sales, dealers and its clients. In the existing method tracking of all the details are tedious and time consuming. Any product survey and launching of the area carried out manually by representatives, is a time consuming task. It fulfills different requirements of management, client and dealers of the company. The specific purpose of the system is to automate the communication between the management, clients and the dealers of the organization.

The key entities of this system are company management or administration department, employees, dealers and clients. The activities relating to this system are listing of various dealers of the company, its branches, its clients and providing expertise

suggestion on the usage of the product, update product, providing instructions to the dealers and many additional tasks which supplement the above functions.

LIST OF NOTATIONS API CGI DHTML EJB GUI HTML HTTP J2EE JDBC JSP ODBC SQL URL XHTML XML ---------------------------------------------Application Programming Interface Common Gateway Interface Dynamic HyperText Markup Language Enterprise Java Beans Graphical User Interface HyperText Markup Language HyperText Transfer Protocol Java 2 Enterprise Edition Java DataBase Connectivity Java Server Pages Open DataBase Connectivity Structured Query Language Uniform Resource Locator Extensible HyperText Markup Language Extensible Markup Language.

CHAPTER 1
INTRODUCTION This is portal based automation project, which provides communication between the various users for the company products. Any queries related to the product usage can be raised, and obtain experts suggestion from the company expertise group. Various dealers can instruct their client and in response the client can order product from specific dealer of their wish. In turn the management and the client can directly communicate with each other and help the company to provide efficient service.

This web application cum automation system has been developed to be implemented as a follow up system for current existing system. This project would automate the operations of the management and would retain the present functionality available in the current system. The specific purpose of this system is to gather and process information about different clients, dealers their interests and queries through the LAN/Internet. The administrator is responsible for the maintenance of this system. Based on the category of the user i.e. employee or management, dealer or client the various parts of the system are made available to the users.

CHAPTER 2
ORGANIZATION PROFILE CERT TECHNOLOGIES evolved in 2003 as a dream to provide the corporate world with innovative and complete solutions for their needs. Over the years, CERT TECHNOLOGIES being a Software Developer and Projects Consultant to a complete solution provided for the industry. CERT TECHNOLOGIES has gained remarkable reputation not only for its unique approach to developing solutions and timely delivery of the same, but also for providing total customer satisfaction. In an age where software companies are mushrooming by the millions, CERT TECHNOLOGIES promises stability and reliability built over the past five years, the proof of which is evident in the continuing relationship we share with all our clients.

At CERT TECHNOLOGIES, we gain a total understanding of our clients business processes and design the necessary enterprise solutions to fit seamlessly into our clients business models. We work in a disciplined development environment to ensure an efficient and effective product, thus making it easy to implement and highly cost effective, the benefit of which we pass to our clients. This, with a significantly lower turnaround time compared to competition.

At CERT TECHNOLOGIES, it is the client who is the most important and therefore, the mission of our company is also evolved around the client. We are dedicated to providing total satisfaction to our clients through cost effective and complete enterprise solutions achieved through building dynamic models and developing leading edge technologies.

Philosophy CERT TECHNOLOGIES follows a three-point philosophy of Providing total client satisfaction Pursuing excellence in every field Working towards developing unique and innovative solutions for the industry.

Services Offered A dynamic range of expertise makes it possible for CERT TECHNOLOGIES to provide solutions to diverse vertical segments such as Transportation, Financial services, Healthcare and Manufacturing, and also the Defense sectors. Our range services varies from developing customize software packages to participation in corporate strategic planning and facilitation of processes like restructuring and reengineering. Our core competency lies in e-commerce and Internet based services like: Web page designing and development Setting up intranet systems for organizations Database and WebPages integration Network Architecture services

Future of CERT TECHNOLOGIES

CERT TECHNOLOGIES will enhance its position as a premier provider of effective business solutions by Maintaining the very high standards of quality and service for our customers Providing cost effective solutions with measurable results Utilizing emerging and existing technologies in a creative and synergistic way

Our Resources

CERT TECHNOLOGIES has a sound resource base in the following segments: Human Resources People are behind the success of CERT TECHNOLOGIES. We have a vast team of software and management personnel drawn from various fields of specialization bringing with them cross-industry knowledge, valuable experience and strong technical expertise. CERT TECHNOLOGIES employs MIT professionals who lend their special expertise to every project. We also work closely with consultants and business specialists around the world to build up a knowledge base of the best business practices in different regions. Technical Resources CERT TECHNOLOGIES has a vast pool of technical resources ranging from the latest Pentium machines to the newly developed software languages. We also ensure that our personnel are continuously upgraded to operate on these platforms. Physical Resources Our physical resources include two classrooms, two labs with 20 Pentium machines, a huge library equipped with a large variety of books on a subjects, a discussion room, etc.

CHAPTER 3
DESCRIPTION OF THE PROBLEM General Description: This application is for fulfilling the different requirements of the management and dealers and clients for an organization. With this application client should be in a position to do the following things: 1. Obtain General information about the Company. 2. Login into the Distribution Channel Management System. 3. Select a product and place an order. 4. Provide Feedback to the company. 5. Obtain details regarding various dealers for specific product or area. Management can perform the following functionalities: 1. Track Dealer specific Sales 2. Obtain the clients area of interest 3. Update Product List 4. Obtain Clients Feedback 5. Obtain Dealers Feedback 6. Provide Instructions to the client. 3.1 Proposed System: In order to avoid unnecessary delay and minimize the flaws that existed in the previous system a follow up module for the existing system has been designed called the Distribution Channel Management System which takes concern for the customer service and the distribution of products to the various dealers and clients.

The main intention of the proposed and designed system is to automate the communication and distribution channel between the company management, dealers and the clients of the company. The newly designed system mainly aims at the following tasks Automate the communication between the clients and the company. Obtain feed back from the clients and dealers Generate reports from dealers with specific requirement Provide updated details of the company products Generate and report the sales data in accordance with the specific dealers and product. Obtain workshop details. Attain each and every query of the user. Additonal functions of the system are to generate the report for the management of the company to keep track of sales and the product distribution. To update the product and price of the company product. The system also gives instruction to the client and to the dealers if there is any change in the regulation policies and rules of the company. The system also updates the dealers list of the company so that the client can access the latest updating of the company. Sometimes the client can directly interact with the company management in procuring the products. Every query pertaining to the company products and the services offered by the system is being responded. 3.2 Software Requirement Specification 3.2.1 Introduction Purpose A pesticide is any substance or mixture of substances intended for preventing, destroying, repelling, or mitigating any pest. Though often misunderstood to refer only to

insecticides, the term pesticide also applies to herbicides, fungicides, and various other substances used to control pests. Under United States law, a pesticide is also any substance or mixture of substances intended for use as a plant regulator, defoliant, or desiccant.The purpose of the product, Distributed Channel Management System is to automate the interaction between the end user, company management, authorized dealers for the company which promotes crop and pesticides product. It provides a full-fledged system for the communication with dealers and end users. This system also promotes new products launched by the company. The scope of this product includes three areas of the company, which are marketing department, sales department, and accounting department. It forms a module in the entire system which includes a limited functionality of the above given departments. Document Conventions: The typological conventions followed are as following:Every heading of the main sections of the document are written in Century Gothic font, bold , and with font size 14. Every sub topic of the main section of the document are written in verdana font , bold , with font size 12. The detail description of each subtopic is presented in verdana font, with a font size of 12. And to emphasis on the important points bulleted lists have been used. Intended Audience and Reading Suggestions: Since this application mainly deals with crop and pesticides based product the users will be of the same category. The main users of this application are End users Dealers Company Management

In addition to the above three users there are other readers or users of the application such as Marketing staff Accounting staff Sales staff Testers of the System Developers of the System. Each reader or user will communicate for a different purpose with the system End user communicates with system for company details its products, dealers for the product and to provide feed back for the system. Dealers communicates for the new products, their regulatory policies, pricing, entitled discounts , quotation deadlines, workshop strategies used by the dealers and so on. Company management for sales data, modification of dealer specification details, updation of their products, deletion of any old product , update their regulatory and safety policies regarding their product or any other specific managerial task. The marketing staff may use the application for interaction with the dealers regarding the product marketing strategies, workshop results, obtaining dealer specific details and so on. Accounting and Sales staff keep an eye on the sales data and the accounting details so that it can debit or credit the dealers account whenever necessary. Company also keeps track of the pricing and contract policies of the product. The software requirement specification will guide through a series of topics which describe the software product developed, its scope, its users, operating environment, software and hardware requirements needed for product designing, functions of the product and System features.

For new dealers/ clients :Company profile, its branches, product categories, dealers and their details, recent updating in company product. For existing dealers/ clients :Regulatory and safety policies of the company, contract terms and conditions, specific marketing strategy if any, product categories and their pricing, entitled discounts for specific dealerships, product updates.

For management :Dealers and their recorded sales track, workshop results , dealers and client feed back reports, updation of dealers details.

For sales and accounting staff Reports regarding the sales of specific product or specific dealer, pricing of the product.

Benefits of the System Cost effective implementation of the system Elimination of unnecessary delay in processing of clients requests. Effective promotion of the new product. Effective utilization of time.

Objectives of the System Ease in use of the system. Providing prompt services to the clients. Tracking the company sales . Providing details of the product, suggestions of the expertise and area wise dealer information. Provide up to date information about the company products. Obtain feedback reports from the dealers and clients who are geographically dispersed. Goals of the System

Ma

Sales dept.

Clients

To be a reliable source of information to the dealers and clients of the company. To automate the communication between clients , dealers and the management.

3.4.2 Overall Description Product Perspective diagram

Product Functions: Automate the communication between the clients and the company. Obtain feed back from the clients and dealers Generate reports from dealers with specific requirement Provide updated details of the company products

Generate and report the sales data in accordance with the specific dealers and product. Obtain workshop details. Attain each and every query of the user.

User classes and Classification There are 3 different classes of users for this application .They are as following Clients Clients can purchase products of the company through a secured purchasing system. The are provided with the information about different products of the company . They can know about dealers of the company and their location in the country and all of their information. They can know the usage of the product and also about the material to be used in the usage of the specific product. Clients can get valuable suggestions from experts and professors about the usage of the product and in other issues. Clients can send queries and can solve their problems. Clients can send their feedback reports about the products and services provided to them. Clients can send suggestions to the company. Clients can interact with the dealers near to their location so that they can know information about the product and can get best product for their need. Clients can know about the company and also about their branches located at different places.

Clients can know about the different services provided by the organization.

Dealers
Dealers can know information about the product that their company provides, so that they can market their products effectively. They can know costs and discount information of the products. They can get the company information and also about the branches of the company located through out the country. They can interact with the clients by knowing their information and can market their products to the clients individually. They can interact with other dealers and can know the latest situation in the market. They can send their daily reports to the company. They can get assistance from experts on the different marketing strategies by communication with the company. They can send feedback reports to the company about sales of their products and also about the present situation of the market. Company Management The sales dept. interacts with dealers of the company and make transactions with them. They can send information about the products and therir cost and discount information to their dealers whenever necessary. They can inform latest updates of their products to their dealers. They can locate the authorized dealers and can know their information. They can maintain individual accounts for each dealer. The sales dept. can interact with inventory dept. so that it can know up-todate inventory levels. That is this sales dept. takes updated inventory levels as input and process the transactions.

The sales dept. will interact with the accounting dept. so that it can debit or credit the dealers accounts whenever necessary. It can generate weekly reports on sales and sends it to management.

CHAPTER 4
SYSTEM ANALYSIS

4.1 FEASIBILITY STUDY The feasibility study is an evaluation of proposed system regarding its workability, organizational ability to meet user needs and effective use of resources. When a new application is proposed, it should go through the feasibility study before it is approved for the development. There are three aspects of feasibility study. Technical Feasibility Economical Feasibility Operational Feasibility

Technical Feasibility The consideration that is normally associated with the technical feasibility includes where the project is to be developed and implemented. The proposed software should have the security for data and should be very fast in processing the data efficiently. A basic knowledge to operate a computer is sufficient to handle the system, Since the system is designed to provide user-friendly access. Economical Feasibility One of the important factors, which affect the development of a new system, is the cost it would incur. Since the system is developed by the student as project work, there is no manual cost but the cost for hardware and software is negotiable. Economical justification is generally the Bottom Line consideration for most systems. It includes a

broad range of concerns that include the Cost-benefit analysis. The cost-benefit analysis delineates costs for project development and weights then against tangible and development of the system. Hence, there are tangible and intangible benefits the project development. Operational Feasibility The new system must be accepted by the user. In this system, the administrator is one of the users. As users are responsible for initiating the development of a new system, this is rooted out.

4.2 REQUIREMENTS SPECIFICATION SOFTWARE SPECIFICATION Web Server : Tomcat Server Front End Script Back End OS : JSP,HTML : Java Script : Oracle : Windows XP

Middle Tier : Servlets

HARDWARE SPECIFICATION Processor Hard Disk RAM CD Drive : Intel inside Pentium III : 80 GB : 512 MB : 52 X SAMSUNG

Floppy Drive : 1.44 MB SAMSUNG

4.3 ABOUT THE SOFTWARE DBMS-independent Java API for executing SQL (Structured Query Language) statements. JDBC allows Java programs to Establish a connection with a database. Send SQL statements to server. Process the results from the statement.

Fig 4.1 JDBC Client-Server Architecture 4.3.1 JDBC n-tier Architecture Web server components connect to the database, not clients. Database connections are pooled to increase performance. Clients are isolated from database changes. System can scale to support more users

JDBC n-Tier architecture

4.3.2 JDBC DRIVERS The java.sql.package provides the JDBC API.JDBC drivers which connect the API to the database fall into four categories. 4.3.3 JDBC-ODBC bridge plus ODBC driver ODBC and client binary code must be loaded on each database client machine.

4.3.4 Native API partly Java Driver JDBC calls are converted into calls on the client API for specific database

Requires binary code be loaded on each database client machine.

JDBC-Net all Java driver JDBC calls are translated into a DBMS-independent net protocol which is then translated to a DBMS protocol by server.

Native protocol all Java driver JDBC calls are converted into the network protocol used by DBMS directly.

JSP AND SERVLETS SERVLET ARCHITECTURE OVERVIEW

The central abstraction in the Servlet API is the Servlet interface. All Servlet implement this interface, either directly or, more commonly, by extending a class that implements it such as HttpServlet. The Servlet interface provides for methods that manage the Servlet and its communications with clients. Servlet writers provide some or all of these methods when developing a Servlet. When a Servlet accepts a call from a client, it receives two objects one is a ServletRequest and the other is a ServletResponse. The ServletRequest class encapsulates the communication from the client to the server, while the ServletResponse class encapsulates the communication from the servlet back to the client. The ServletRequest interface allows the servlet access to information such as the names the parameters passed in by the client, the protocol (scheme) being used by the client, and the names of the remote host that made the request and the server that received it. It also provides the servlet with access to the input stream, ServletInputStream, through which the servlet gets data from clients that are using application protocols such as the Http POST and PUT methods. Subclasses of ServletRequest allow the servlet to retrieve more protocol-specific data. For example, HttpServletRequest contains methods for accessing Http-specific header information. The ServletResponse interface gives the servlet methods for replying to the client. It allows the servlet to set the content length and mime type of the reply, and provides an output stream, ServletOutputStream, and a Writer through which the servlet can send the reply data. Subclasses of ServletResponse give the servlet more protocol-specific capabilities. For example, HttpServletResponse contains methods that allow the servlet to manipulate Http-specific header information. The classes and interfaces described above make up a basic Servlet. Http servlets have some additional objects that provide session-tracking capabilities. The servlet writer can use these APIs to maintain state between the servlet and the client that persists across multiple connections during some time period. SERVLET LIFE CYCLE

Servers load and run servlets, which then accept zero or more requests from clients and return data to them. They can also remove servlets. These are the steps of a servlets lifecycle. The next paragraphs describe each step in more detail, concentrating on concurrency issues. When a server loads a servlet, it runs the servlet's init method. Even though most servlets are run in multi-threaded servers, there are no concurrency issues during servlet initialization. This is because the server calls the init method once, when it loads the servlet, and will not call it again unless it is reloading the servlet. The server cannot reload a servlet until after it has removed the servlet by calling the destroy method. Initialization is allowed to complete before client requests are handled (that is, before the service method is called) or the servlet is destroyed. After the server loads and initializes the servlet, the servlet is able to handle client requests. It processes them in its service method. Each client's request has its call to the service method run in its own servlet thread the method receives the client's request, and sends the client its response. Servlets can run multiple service methods at a time. It is important, therefore, that service methods be written in a thread-safe manner. For example, if a service method might update a field in the servlet object, that access should be synchronized. If, for some reason, a server should not run multiple service methods concurrently, the servlet should implement the Single Thread Model interface. This interface guarantees that no two threads will execute the servlet's service methods concurrently. Servlets run until they are removed from the service, for example, at the request of a system administrator. When a server removes a servlet, it runs the servlet's destroy method. The method is run once; the server will not run it again until after it reloads and reinitializes the servlet. When the destroy method runs, however, other threads might be running service requests. If, in cleaning up, it is necessary to access shared resources (such as network connections to be closed), that access should be synchronized. During a servlet's lifecycle, it is important to write thread-safe code for destroying the servlet and, unless the servlet implements the Single Thread Model interface, servicing client requests.

INTERACTING WITH CLIENTS

Servlet writers are developing HTTP servlets that specialize the HttpServlet class should override the method or methods designed to handle the HTTP interactions that their servlet will handle. The candidate methods include, doGet, for handling GET, conditional GET and HEAD requests . doPost, for handling POST requests . doPut, for handling PUT requests . doDelete, for handling DELETE requests .

By default, these methods return a BAD_REQUEST (400) error. An example HTTP servlet that handles GET and HEAD requests follows it specializes the doGet method. The HttpServlet's service method, by default, also calls the doOptions method when it receives an OPTIONS request, and doTrace when it receives a TRACE request. The default implementation of doOptions automatically determines what HTTP options are supported and returns that information. The default implementation of doTrace causes a response with a message containing all of the headers sent in the Trace request. These methods are not typically overridden. Whatever method you override, it will take two arguments. The first encapsulates the data from the client, and is an HttpServletRequest. The second encapsulates the response to the client, and is an HttpServletResponse. The following paragraphs discuss their use. An HttpServletRequest object provides access to HTTP header data, such as any cookies found in the request and the HTTP method with which the request was made. It, of course, allows to obtain the arguments that the client sent as part of the request to access the client data might depend on the HTTP method of the request. For any HTTP method, the getParameterValues method, which will return the value of a named parameter. (The method getParameterNames provides the names of the parameters.) and also manually parse the request. For requests using the HTTP GET method, the getQueryString method will return a String to be parsed.

For HTTP methods offer POST, PUT, and DELETE,

choice between two

methods. If we want expect text data, then it can be read using the BufferedReader returned by the getReader method. to expect binary data, then it should be read with the ServletInputStream returned by the getInputStream method.

Note that,use either the getParameterValues method or one of the methods that allow you to parse the data yourself. They can not be used together in a single request. For responding to the client, an HttpServletResponse object provides two ways of returning the response data to the user. You can use the writer returned by the getWriter method or the output stream returned by the getOutputStream method. You should use getWriter to return text data to the user, and getOutputStream for binary data. Before accessing the Writer or OutputStream, HTTP header data should be set. The HttpServletResponse class provides methods to access the header data, such as the content type and encoding, and content length of the response. After you set the headers, you may obtain the writer or output stream and send the body of the response to the user. Closing the writer or output stream after sending the response to the client allows the server to know when the response is complete. Once this class file is loaded within the servlet container, the jspService() is responsible for replying to a client request. By default the jspService() is dispatched on a separate thread by the servlet container in processing concurrent client requests.

separate thread by the servlet container in processing concurrent client requests, as shown below:

init event

jspInit()

jspService()
request response

jspDestroy()
destroy event

JSP Life Cycle

JSP Access Models The processing is divided between presentation and front components. Presentataion components are JSP pages that generate HTMl/XML response determines user interface. Front components (Controller) process all the HTTP requests. It is responsible for creating any bean or objects used by the presentation components and depending on users actions which presentation component to forward the request to Front components are implemented as Servlets or JSP page. Benefits No processing logic within the presentation component itself. The front components application state, security and presentation uniform and easier to maintain.

BROWSER

presents a single point of entry into the application making the management of

(Controller)
111

request

Servlet

(View)
JSP

Model 4 Bean

EIS

response

4.4 DATAFLOW DIAGRAM LEVEL 0

DATAFLOW DIAGRAM LEVEL 1

DATAFLOW DIAGRAM LEVEL 2

CHAPTER 5
SYSTEM DESIGN
Java Connector Architecture The Connector architecture is a J2EE SPI that allows resource adapters that support access to Enterprise Information Systems to be plugged in to any J2EE product. The Connector architecture defines a standard set of system-level contracts between a J2EE server and a resource adapter. Security Services The Java Authentication and Authorization Service (JAAS) enables services to authenticate and enforce access controls upon users. It implements a Java technology version of the standard Pluggable Authentication Module (PAM) framework, and extends the access control architecture of the Java 2 Platform in a compatible fashion to support user-based authorization. The Java Authorization Service Provider Contract for Containers (JACC) defines a contract between a J2EE application server and an authorization service provider, allowing custom authorization service providers to be plugged into any J2EE product. Web Services J2EE provides full support for both clients of web services as well as web service endpoints. Several Java technologies work together to provide support for web services. The Java API for XML-based RPC (JAX-RPC) provides support for web service calls using the SOAP/HTTP protocol. JAX-RPC defines the mapping between Java classes and XML as used in SOAP RPC calls. The SOAP with Attachments API for Java (SAAJ) provides support for manipulating low-level SOAP messages. The Web Services for J2EE specification fully defines the deployment of web service clients and web service

endpoints in J2EE, as well as the implementation of web service endpoints using enterprise beans. The Java API for XML Registries (JAXR) provides client access to XML registry servers. Deployment The Java 2 Platform, Enterprise Edition Deployment Specification defines a contract between deployment tools and J2EE products. The J2EE products provide plug-in components that run in the deployment tool and allow the deployment tool to deploy applications into the J2EE product. The deployment tool provides services used by these plug-in components.

J2EE Architecture

Web Applications and Exploded Directory Format (EDF)

Overview of Web Applications

A Web application contains an applications resources, such as servlets, JavaServer Pages (JSPs), JSP tag libraries, static resources such as HTML pages and image files. A Web Application can also define links to outside resources such as Enterprise Java Beans (EJBs). Web applications deployed on WebLogic Server use a standard J2EE deployment descriptor file and Web Logic-specific deployment descriptor file to define their resources and operating attributes. JSP and HTTP servlets can access all services and APIs available in Web Logic Server. These services include EJB, database connections via Java Database Connectivity (JDBC), Java Messaging Service (JMS), XML, and more. A Web archive (WAR file) contains the files that make up a Web application (WAR file). A WAR file is deployed as a unit on one or more Web Logic Server instances. A Web archive on Web Logic Server always includes the following files: One servlet or Java Server Page (JSP), along with any helper classes. A web.xml deployment descriptor, which is a J2EE standard XML document that describes the

contents of a WAR file. A weblogic.xml deployment descriptor, which is an XML document containing Web Logic Server-specific elements for Web applications. A Web archive may also include HTML or XML pages and supporting files such as image and multimedia files. The WAR file can be deployed alone or packaged in an enterprise application archive (EAR file) with other application components. If deployed alone, the archive must end with a .war extension. If deployed in an EAR file, the archive must end with an .ear extension. BEA recommends that you package and deploy your stand-alone Web applications as part of an enterprise application. This is a BEA best practice, which

allows for easier application migration, additions, and changes. Also, packaging your applications as part of an enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure. Note: If you are deploying a directory in exploded format (not archived), do not name the directory .ear, .jar, and so on.

Web Application Directory Structure

Web applications use a standard directory structure defined in the J2EE specification. You can deploy a Web application as a collection of files that use this directory structure, known as exploded directory format, or as an archived file called a WAR file. BEA recommends that you package and deploy your WAR file as part of an enterprise application. This is a BEA best practice, which allows for easier application migration, additions, and changes. Also, packaging your Web application as part of an enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure. Web application components are assembled in a directory in order to stage the WAR file for the jar command. HTML pages, JSP pages, and the non-Java class files they reference are accessed beginning in the top level of the staging directory. The WEB-INF directory contains the deployment descriptors for the Web application (web.xml) and weblogic.xml) and two subdirectories for storing compiled Java classes and library JAR files. These subdirectories are respectively named classes and lib. JSP taglibs are stored in the Web Applications Basics WEB-INF directory at the top level of the staging directory. The Java classes include servlets, helper classes and, if desired, precompiled JSP. The entire directory, once staged, is bundled into a WAR file using the jar command. The WAR file can be deployed alone or as part of an enterprise application (recommended) with other application components, including other Web applications, EJB components, and Web Logic Server components. JSP pages and HTTP servlets can access all services and APIs available in Web Logic Server.

These services include EJBs, database connections through Java Database Connectivity (JDBC), Java Message Service (JMS), XML, and more.

Main Steps to Create a Web Application

The following is an example of a Web application directory structure, in which myWebApp/ is the staging directory:

Web Application Directory Structure

e b

p p lic a t io n M y W e b W w w A E B

t r u c t u r e

( E

F )

o r m

a t

p p - I N F l l

e b . x m

e b lo g i c . x m l i b / m

y l ib . j a r

c l a s s e s / m y p a c k a g e m * . h t m l , * .h t m * . j s p y s e r v l e t. c l a s s , i m a g e f i l e s

5.3 Normalization Normalization is a technique that logically groups the data over the number of tables, which are in depended and contain no duplicate data. After normalization, the table contains only simple data items. The process of normalization involves three steps. After each step, the database confirms to a certain termed as normal form. Generally the third normal form is required for database to be said as fully normalized. The fourth and fifth normal forms are also exists but are not used in the database design. First Normal Form (1NF) A table is said to be in the First Normal Form when each cell of the table contains precisely one value. Second Normal Form (2NF) A table is said to be in the Second Normal Form when it is in the First Normal Form and every attribute in the row in functionally depended upon the whole key, and just part of the key. Functional Dependency Given a relation R, attribute A is functionally depended on attribute B if each value of A in R is associated with precisely one value of B. Third Normal Form (3NF) A table is said to be in Third Normal Form if it is in Second Normal Form and every non-key attribute is functionally depended only on the primary key. This normalization process is applied to this system. Fourth Normal Form (4NF) A table is said to be in Fourth Normal Form if it is in Third Normal Form and every non-key attribute is functionally depended only on the super key. This normal form is also called Boyce Code Normal Form (BCNF). Fifth Normal Form (5NF) A table is said to be in Fifth Normal Form if it is in Fourth Normal Form and every non-key attribute is multi valued functional depended only on the super key of the table.

5.4 Table Design 1. Client_login Field Name Client_id Password First_name Last_name Sex DOB Phone Country Location T_address P_address Email Credit_no Data Type varchar varchar varchar varchar Char Date varchar varchar varchar varchar varchar varchar varchar Size 15 15 15 15 1 Date format 14 15 15 30 30 35 15 Constraints Primary key

2.Dealer_login Field Name Dealer_id Password Sex Location Reg_date Data Type varchar varchar char varchar date Size 8 15 1 15 Date format Constraints Primary key

Area Address Phone Mail 3.Sales_dept Field Name Emp_id Empname Dob Sex Address Email Phone Password 4. product_price Field Name Product_id Price ProductName

varchar varchar varchar varchar

15 30 14 35

Data Type varchar varchar Date Char varchar varchar varchar varchar

Size 8 15 Date dormat 1 30 35 14 15

Constraints Primary key

Data Type varchar number varchar

Size 4 6,2 60

Constraints Primary key

5. Client_fbk Field Name Client_id Subjects Comments Doc Data Type varchar varchar varchar date Size 15 15 20 date format Constraints Foreign key

6.dealer_fbk Field Name Dealer_id Comment_dl Data Type varchar varchar Size 8 60 Constraints Foreign key

Doc 7.Sales_fbk Field Name Emp_id Subjects Comments Doc 8.Instruction_dl Field Name Dealer_id Doi Instruction

date

Date format

Data Type varchar varchar varchar date

Size 8 20 60 Date format

Constraints Foreign key

Data Type varchar date varchar

Size 8 date format 60

Constraints Foreign key

9.Instruction_sales Field Name emp_id Doi Instruction 10.Instruction_client Field Name Client_id Doi Instruction Data Type varchar date varchar Size 15 Date format 60 Constraints Foreign key Data Type varchar date varchar Size 8 date format 60 Constraints Foreign key

11.Product_tans Field Name Dot Dealer_id Client_id Product_id Quantity Data Type date varchar varchar varchar number Size Date format 8 15 4 3 Constraints Foreign key Foreign key Foreign key

12.Service_survey Field Name Service_provider Service_name Staff_courteous Acuurate_info Timely_response Positive_experience Understandable_regulations Understandable_instructions Understandable_conditions Staff_name Comment_on_staff Situation Improvement Customer_id Data Type varchar varchar varchar varchar varchar varchar varchar varchar varchar varchar varchar varchar varchar varchar Size 6 4 20 20 20 20 20 20 20 16 50 50 35 25 Constraints

CHAPTER 6 SCREENSHOTS 1. Input and output screens

Client Login

Client feedback form

Feedback acknowledgement form

Products list:

Product information:

Purchase bill:

Dealer Information:

CHAPTER 7
Conclusion
The fundamental problem in managing and maintaining the work by the administrator is hence overcome. Prior to this it was a bit cumbersome for maintaining the library and also keeping track of the users who were using it. But by developing this web-based application the administrator can enjoy the task , doing it with and also by saving the valuable time . The storage facility will ease the job of the operator. Thus the system developed will be helpful to the administrator by easing his/her task.

BIBLIOGRAPHY
1. Deitel ,Deitel and Nieto ,Internet and World Wide Web how to program.

2. Ian Somerville, Principles of Software Engineering ,4 Edition . 3. Roger S. Pressman ,Software Engineering A Practitioners Approach . 4. Patrick Naughton and Herbert Schildt , Complete Reference Java 2 , 3 Edition ,Tata McGraw Hill ,1999. 5. Er. V.K.Jain , Programming Java Server Pages & Servlets.

TABLE OF CONTENTS

S.NO

TITLE ACKNOWLEDGEMENT ABSTRACT( English) ABSTRACT( Tamil) LIST OF NOTATIONS

PAGE NO. i. ii iii

INTRODUCTION

ORGANIZATION PROFILE

DESCRIPTION OF THE PROBLEM 3.1 Existing System 3.2 Proposed System 8 8

SYSTEM ANALYSIS 4.1 Feasibility Study 4.2 Requirements Specification 4.3 About the Software 4.4 Data Flow Diagrams 10 11 11 25

SYSTEM DESIGN 5.1 Database design 26

5.2 System Architecture 5.3 Normalization 5.4 Table Design

30 30 32

OUTPUT DESIGN 6.1 Screen Design 37

CONCLUSION

50

BIBLIOGRAPHY

51