[attachment=1209]

DISTRIBUTED COMMUNICATIONS

1.1.2 Objective:-
The Distributed Communications 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 of tracking of all the details are tedious and time consuming. Any product survey and launching of the area carried out manually by representatives, which is a time taking 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 / 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 task which supplement the above functions.
An application has to be developed which would minimize the flaws of the existing system. This project would automate the operations of the management and would retain the present functionality available in the current system.
The scope of this project is to enable the user of an organization to view the issues through the LAN/Internet. Based on the category of the user i.e. employee or administrator, the various parts of the system are made available to the users.

1.2. Need of Project/Problem Specifications
Software Technologies Used:
Visual Interface : HTML
Container : Any Java Enabled Web Browser
Database : Oracle
Web Server : Any Java Enabled Web Server,
Database-Connectivity : JDBC
Server-side Programming : Servlets, JSP.
Hardware Used :
PC Processor : P III
Operating System : Windows-2000
Hard Disk : 40 GB
RAM : 128 MB









2. FEASIBILITY STUDY

After a thorough study of the existing system we have come to the conclusion that we require a refinement of the system for smooth functioning of the system and its intended functionalities. The proposed system will minimize all the problems of the existing system and most requirements of the near future.
The technical aspects of the system required as per the functionalities of the system are platform independent execution of tasks and dynamic content generation feature. And these features can be best incorporated with the use of j2ee technology in implementation of the project. J2ee specifications have incorporated within itself many task oriented technologies which are quiet useful for the proposed system. Though the implementation of the project may be little expensive for the company to hold on, but the benefits of the system may over rule its costs.
As far as the user interface is concerned it should be with hypertext markup language, which has been proved as very user friendly and is also compatible with the j2ee technology. And the system designed on the above platform will be available easily with the help of the browser. Once the software is installed on to the main system the user can access it without any additional software.







3. SOFTWARE REQUIREMENT SPECIFICATION
3.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 sections 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:-
Distributed channel Management System is an application, which is used to track the different users of the system and provide them a variety of informations.
It also provides different services to the users such as quotation details to the dealers, pricing discounts entitled to specific dealers, valuable suggestions from experts and professors about the usage of the product, different product information, up to date information on latest products and so on.
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 feedback for the system.
Dealers communicate 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 and 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.
Area of reading suggested (classified according to the user type)
For new dealers/ clients :-
Company profile, its branches, product categories, dealers and their details, recent updations 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 feedback reports, updation of dealers details.
For sales and accounting staff :-
Reports regarding the sales of specific product or specific dealer, pricing of the product.
Product Scope:-
Distributed channel management system provide proper channel for the client, dealer and the company management to communicate among themselves. This software product has been designed to provide specific services to the end user.
The scope of the system includes three areas of the company that are Marketing department, Sales department and accounting department. The main intention of this system is to automate the services of the company which will reach the clients and dealers easily besides being advantageous to the company itself.
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:-
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.1.1 Overall Description: -
Product Perspective:-
This product has been mainly designed to overcome some of the problems faced with the previous system. The main problem faced was unnecessary delay in information processing and expensive.
The previous system in use was also expensive and time consuming.
Suppose if the company has to promote its new product then it has to appoint an area wise representative to interact the product features to the client or dealers. This is a time taking and expensive task.
This product is a follow-on member of the product family and it also replaces some of the tasks of the existing system.

Product Functions: -
Automate the communication between the clients and the company.
Obtain feedback 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.
¢ They 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 about their clients and their detailed information.
¢ They can get the company information and also about the branches of the company located throughout 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 their 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-to-date 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.
Other users such as the marketing staff, sales staff and others more or less use the same information. Whereas the system developer, system tester and the project manager would be pre implementation and maintenance users of the system

3.2. Selection of Technology and Specific Requirements
Operating Environment:-
Operating System: windows 9x and above
Database Support: oracle 7i and above
Language used : J2EE technology (Servlets, Jsp);
GUI Design : Microsoft Front Page, Html, Javascript.
Design and Implementation Constraints: -
The factors given below may restrict the developer from usage of certain resources:-
Regulatory and Safety Policies :-
Sometimes the regulatory policies applied in accordance with the Governmental policies may not be cooperative to the Company which in turn may affect the limits of the developer.
Hardware and software restrictions :-
According to the developer the features required by the company may be best implemented by certain software and hardware resources. But the company may not allow him to effectively act upon the situations.
These limitations may also sometimes affect the overall performance of the system.
Companyâ„¢s policies may itself sometimes limit the resources of the developer.
In addition to the above limitations the developer may also face constraints on the total memory requirements
Security concerns
Design conventions of the interfaces and so on.
User Documentation: -
This section gives us the details about the user documentation components which help the user in the usage of the application.
They are:-
Online help document.
FAQâ„¢s
Contact address.
Assumptions and Dependencies: -
Factors that affect the requirements stated in specifications document are:
Government policies and regulatory conditions.
Change of management of the company
Change in the business strategy of the company
Unexpected banning on the material used in major products of the system.
Request for change in system design by the management.
Sudden change in technology.
Dependency factors of the system:-
Vision document of the system
Software and hardware requirement
User perspective.
Companyâ„¢s policy and business strategy.
Government policies.
Prevailing demand for the companyâ„¢s product.
Compatiblity issue with regard to the other modules of the overall system.







4. DESIGN

4.1 ER Diagram:-

































4.2 Data Flow Diagrams




`











4.3 Modules:-



4.4 Database:-
1. Client_login

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


2. Dealer_login
Field Name Data Type Size Constraints
Dealer_id varchar 8 Primary key
Password varchar 15
Sex char 1
Location varchar 15
Reg_date date Date format
Area varchar 15
Address varchar 30
Phone varchar 14
Mail varchar 35

3. Sales_dept
Field Name Data Type Size Constraints
Emp_id varchar 8 Primary key
Empname varchar 15
Dob Date Date dormat
Sex Char 1
Address varchar 30
Email varchar 35
Phone varchar 14
Password varchar 15

4. product_price
Field Name Data Type Size Constraints
Product_id varchar 4 Primary key
Price number 6,2
ProductName varchar 60

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

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

7. Sales_fbk
Field Name Data Type Size Constraints
Emp_id varchar 8 Foreign key
Subjects varchar 20
Comments varchar 60
Doc date Date format


8. Instruction_dl
Field Name Data Type Size Constraints
Dealer_id varchar 8 Foreign key
Doi date date format
instruction varchar 60

9. Instruction_sales
Field Name Data Type Size Constraints
emp_id varchar 8 Foreign key
Doi date date format
Instruction varchar 60

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

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


12. Service_survey

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


4.5 Input-Output Form (Screen Layout):-
1. Client Login





































5. CODING

Java coding standards:-
Why Coding Standards are Important
Coding standards for Java are important because they lead to greater consistency within your code and the code of your teammates. Greater consistency leads to code that is easier to understand, which in turn means it is easier to develop and to maintain. This reduces the overall cost of the applications that you create. You have to remember that your Java code will exist for a long time, long after you have moved on to other projects. An important goal during development is to ensure that you can transition your work to another developer, or to another team of developers, so that they can continue to maintain and enhance your work without having to invest an unreasonable effort to understand your code. Code that is difficult to understand runs the risk of being scrapped and rewritten “ I wouldn™t be proud of the fact that my code needed to be rewritten, would you If everyone is doing their own thing then it makes it very difficult to share code between developers, raising the cost of development and maintenance. Inexperienced developers, and cowboys who do not know any better, will often fight having to follow standards. They claim they can code faster if they do it their own way. Pure hogwash. They might be able to get code out the door faster, but I doubt it. Cowboy programmers get hung up during testing when several difficult-to-find bugs crop up, and when their code needs to be enhanced it often leads to a major rewrite by them because they™re the only ones who understand their code. Is this the way that you want to operate I certainly do not.

The Prime Directive:-
No standard is perfect and no standard is applicable to all situations: sometimes you find yourself in a situation where one or more standards do not apply. This leads me to introduce what I consider to be the prime directive of standards:
When you go against a standard, document it. All standards, except for this one, can be broken. If you do so, you must document why you broke the standard, the potential implications of breaking the standard, and any conditions that may/must occur before the standard can be applied to this situation. The bottom line is that you need to understand each standard, understand when to apply them, and just as importantly when not to apply them.
Important Instructions to maintain standards
Use full English descriptors that accurately describe the grandtotal, or CorporateCustomer variable/field/class/¦ For example, use names like first Name. Although names like x1, y1, or fn are easy to type because they™re short, they do not provide any indication of what they represent and result in code that is difficult to understand, maintain, and enhance (Nagler, 1995; Ambler, 1998a).
Use terminology applicable to the domain. If your users refer to their clients as customers, then use the term Customer for the class, not Client. Many developers will make the mistake of creating generic terms for concepts when perfectly good terms already exist in the industry/domain.
Use mixed case to make names readable. You should use lower case letters in general, but capitalize the first letter of class names and interface names, as well as the first letter of any non-initial word (Kanerva, 1997).
Use abbreviations sparingly, but if you do so then use them intelligently. This means you should maintain a list of standard short forms (abbreviations), you should choose them wisely, and you should use them consistently. For example, if you want to use a short form for the word number, then choose one of nbr, no, or num, document which one you chose (it doesnâ„¢t really matter which one), and use only that one.
Avoid long names (< 15 characters is a good idea). Although the class name
PhysicalOrVirtualProductOrService might seem to be a good class name at the time this name is simply too long and you should consider renaming it to something shorter, perhaps something like Offering (NPS, 1996).
Avoid names that are similar or differ only in case. For example, the variable names
persistentObject and persistentObjects should not be used together, nor should anSqlDatabase and anSQLDatabase (NPS, 1996).
Avoid leading or trailing underscores. Names with leading or trailing underscores are usually reserved for system purposes, and may not be used for any user-created names except for pre-processor defines (NPS, 1996). More importantly, underscores are annoying and difficult to type so I try to avoid their use whenever possible.

Good Documentation:-
We will also be discussing documentation conventions, so letâ„¢s discuss some of the basics first:
Comments should add to the clarity of your code. The reason why you document your code is to make it more understandable to you, your coworkers, and to any other developer who comes after you (Nagler, 1995).
If your program isnâ„¢t worth documenting, it probably isnâ„¢t worth running (Nagler, 1995). What can I say, Nagler hit the nail on the head with this one.
Avoid decoration, i.e. do not use banner-like comments. In the 1960s and 1970s COBOL programmers got into the habit of drawing boxes, typically with asterisks, around their internal comments (NPS, 1996). Sure, it gave them an outlet for their artistic urges, but frankly it was a major waste of time that added little value to the end product. You want to write clean code, not pretty code. Furthermore, because many of the fonts used to display and print your code are proportional, and many arenâ„¢t, you canâ„¢t line up your boxes properly anyway.
Keep comments simple. Some of the best comments I have ever seen are simple, point-form notes. You do not have to write a book, you just have to provide enough information so that others can understand your code.
Write the documentation before you write the code. The best way to document code is to write the comments before you write the code. This gives you an opportunity to think about how the code will work before you write it and will ensure that the documentation gets written. Alternatively, you should at least document your code as you write it. Because documentation makes your code easier to understand you are able to take advantage of this fact while you are developing it. The way I look at it, if you are going to invest the time writing documentation you should at least get something out of it (Ambler, 1998a).
Document why something is being done, not just what. Fundamentally, I can always look at a piece of code and figure out what it does. For example, I can look at the code in Example 1 below and figure out that a 5% discount is being given on orders of $1,000 dollars or more. Why is this being done Is there a business rule that says that large orders get a discount Is there a limited-time special on large orders or is it a permanent program Was the original programmer just being generous I do not know unless it is documented somewhere, either in the source code itself or in an external document (Ambler, 1998a).






6. IMPLEMENTATION AND TECHNOLOGICAL ENVIRONMENT

An Overview of J2EE:-
The following topics describe the J2EE Platform requirements for each kind of J2EE platform element.
J2EE Application Components
The J2EE runtime environment defines four application component types that a J2EE product must support:

Application clients are Java programming language programs that are typically GUI programs that execute on a desktop computer. Application clients offer a user experience similar to that of native applications, and have access to all of the facilities of the J2EE middle tier.
Applets are GUI components that typically execute in a web browser, but can execute in a variety of other applications or devices that support the applet-programming model. Applets can be used to provide a powerful user interface for J2EE applications. Servlets, JSP pages, filters, and web event listeners typically execute in a web container and may respond to HTTP requests from web clients. Servlets, JSP pages, and filters may be used to generate HTML pages that are an application™s user interface. They may also be used to generate XML or other format data that is consumed by other application components. A special kind of servlet provides support for web services using the SOAP/HTTP protocol. Servlets, pages created with the Java Server Pages„¢ technology, web filters, and web event listeners are referred to collectively in this specification as web components. Web applications are composed of web components and other data such as HTML pages. Web components execute in a web container. A web server includes a web container and other protocol support, security support, and so on, as required by J2EE specifications. Enterprise JavaBeans„¢ (EJB) components execute in a managed environment that supports transactions. Enterprise beans typically contain the business logic for a J2EE application. Enterprise beans may directly provide web services using the SOAP/HTTP protocol.
J2EE Server Support for Application Components
The J2EE servers provide deployment, management, and execution support for conforming application components. Application components can be divided into three categories according to their dependence on a J2EE server:
Components that are deployed, managed, and executed on a J2EE server. These components include web components and Enterprise JavaBeans components. See the separate specifications for these components.
Components that are deployed and managed on a J2EE server, but are loaded to and executed on a client machine. These components include web resources such as HTML pages and applets embedded in HTML pages.
Components deployment and management is not completely defined by this specification. Application Clients fall into this category. Future versions of this specification may more fully define deployment and management of Application Clients.
J2EE Containers
Containers provide the runtime support for J2EE application components. Containers provide a federated view of the underlying J2EE APIs to the application components. J2EE application components never interact directly with other J2EE application components.
J2EE Servers
Underlying a J2EE container is the server of which it is a part. A J2EE Product Provider typically implements the J2EE server-side functionality using an existing transaction processing infrastructure in combination with Java 2 Platform, Standard Edition (J2SE) technology. The J2EE client functionality is typically built on J2SE technology.
Resource Adapters
A resource adapter is a system-level software component that implements network connectivity to an external resource manager. A resource adapter can extend the functionality of the J2EE platform either by implementing one of the J2EE standard service APIs (such as a JDBC„¢ driver), or by defining and implementing a resource adapter for a connector to an external application system.
Java„¢ Transaction API (JTA)
The Java Transaction API consists of two parts:
An application-level demarcation interface is used by the container and application components to demarcate transaction boundaries. An interface between the transaction manager and a resource manager used at the J2EE SPI level (in a future release).
RMI-IIOP
The RMI-IIOP subsystem is composed of APIs that allow for the use of RMI-style programming that is independent of the underlying protocol, as well as an implementation of those APIs that supports both the J2SE native RMI protocol (JRMP) and the CORBA IIOP protocol. J2EE applications can use RMI-IIOP, with IIOP protocol support, to access CORBA services that are compatible with the RMI programming restrictions (see the RMI-IIOP spec for details).
JDBC„¢ API
The JDBC API is the API for connectivity with relational database systems. The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the J2EE platform. Support for the service provider interface is not required in J2EE products.
Java„¢ Message Service (JMS)
The Java Message Service is a standard API for messaging that supports reliable point-to-point messaging as well as the publish-subscribe model. This specification requires a JMS provider that implements both point-to-point messaging as well as publish-subscribe messaging.
Java Naming and Directory Interface„¢ (JNDI)
The JNDI API is the standard API for naming and directory access. The JNDI API has two parts: an application-level interface used by the application components to access naming and directory services and a service provider interface to attach a provider of a naming and directory service.

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 applicationâ„¢s 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


Graphical User Interface:-
An Overview of JSP
The Java Server Pages„¢ Technology
Java Server Pages„¢ technology is the Java„¢ technology in the J2EE platform for building applications containing dynamic Web content such as HTML, DHTML, XHTML and XML. The Java Server Pages technology enables the authoring of Web pages that create dynamic content easily but with maximum power and flexibility.
The Java Server Pages technology provides a textual description for the creation of a response from a request. The technology builds on the following concepts:
Template Data
Substantial portions of dynamic content is actually fixed. The JSP technology allow for the natural manipulation of this data.
Addition of Dynamic Data
The JSP technology allows the addition of dynamic data to the template data in a way that is simple yet powerful.
Encapsulation of Functionality
The JSP technology provides two related mechanisms for the encapsulation of functionality: the standard Java Beans component architecture and the tag library mechanism.
Good Tool Support
The JSP technology has features that enable the creation of good authoring tools. The result is a flexible and powerful server-side technology.
Benefits of the Java Server Pages Technology
The Java Server Pages technology offers a number of benefits:
Write Once, Run Anywhere„¢ properties
The Java Server Pages technology is platform independent, both in its dynamic Web pages, Web servers, and its underlying server components. You can author JSP pages on any platform, run them on any Web server or Web enabled application server, and access them from any Web browser.

High quality tool support
The Write Once, Run Anywhere properties of JSP allows the user to choose best-of-breed tools. Additionally, an explicit goal of the Java Server Pages design is to enable the creation of high quality portable tools.
Separation of Roles
JSP supports the separation of roles: developers write components that interact with server-side objects.
Reuse of components and tag libraries
The Java Server Pages technology emphasizes the use of reusable components such as Java Beans„¢ components, Enterprise Java Beans„¢ components and tag libraries.
Separation of dynamic and static content
The Java Server Pages technology enables the separation of static content from dynamic content that is inserted into the static template.
Support for scripting and actions
The Java Server Pages technology supports scripting elements as well as actions. Actions permit the encapsulation of useful functionality in a convenient form that can also be manipulated by tools; scripts provide a mechanism to glue together this functionality in a per-page manner.
Web access layer for N-tier enterprise application architecture(s)
The Java Server Pages technology is an integral part of the Java 2 Platform Enterprise Edition (J2EE), which brings Java technology to enterprise computing.
An Overview of Servlets:-
What is a Servlet
A servlet is a web component, managed by a container that generates dynamic content. Servlets are small, platform independent Java classes compiled to an architecture neutral byte code that can be loaded dynamically into and run by a web server. Servlets interact with web clients via a request response paradigm implemented by the servlet container. This request-response model is based on the behavior of the Hypertext Transfer Protocol (HTTP).
What is a Servlet Container
The servlet container, in conjunction with a web server or application server, provides the network services over which requests and responses are set, decodes MIME based requests, and formats MIME based responses. A servlet container also contains and manages servlets through their lifecycle. A servlet container can either be built into a host web server or installed as an add-on component to a Web Server via that serverâ„¢s native extension API. Servlet Containers can also be built into or possibly installed into web-enabled Application Servers. All servlet containers must support HTTP as a protocol for requests and responses, but may also support other request / response based protocols such as HTTPS (HTTP over SSL). The minimum required version of the HTTP specification that a container must implement is HTTP/1.0. It is strongly suggested that containers implement the HTTP/1.1 specification as well.
A Servlet Container may place security restrictions on the environment that a servlet can executed In a Java 2 Platform Standard Edition 1.2 (J2SE) or Java 2 Platform Enterprise Edition 1.3 (J2EE) environment, these restrictions should be placed using the permission architecture defined by Java 2 Platform. For example, high end application servers may limit certain action, such as the creation of a Thread object, to insure that other components of the container are not negatively impacted.
An Overview of JDBC:-
JDBC drivers implement the interfaces and classes of the JDBC API. The following sections describe the JDBC driver options that you can use with WebLogic Server.
Types of JDBC Drivers
WebLogic Server uses the following types of JDBC drivers that work in conjunction with each other to provide database access: Standard JDBC drivers that provide database access directly between a WebLogic Server connection pool and the database. Web Logic Server uses a DBMS vendor-specific JDBC driver, such as the WebLogic jDrivers for Oracle and Microsoft SQL Server, to connect to a back-end database.
Wrapper drivers that provide vendor-neutral database access. A Java client application can use a wrapper driver to access any database configured in WebLogic server (via a connection pool). BEA offers three wrapper drivers”RMI, Pool, and JTS. The WebLogic Server system uses these drivers behind the scenes when you use a JNDI look-up to get a connection from a connection pool through a data source. A client application can also use these drivers directly to get a connection from a connection pool (You can use RMI from external clients and the pool and JTS from server-side clients only). However, BEA recommends that you use a data source to get a connection from a connection pool, rather than using these drivers directly. The middle tier architecture of WebLogic Server, including data sources and connection pools, allows you to manage database resources centrally in WebLogic Server. The vendor-neutral wrapper drivers make it easier to adapt purchased components to your DBMS environment and to write more portable code.
Using JDBC Drivers with WebLogic Server:-
Web Logic Server JDBC Drivers
WebLogic jDriver for Oracle
BEAâ„¢s WebLogic jDriver for Oracle is included with the WebLogic Server distribution. This driver requires an Oracle client installation. The WebLogic jDriver for Oracle XA driver extends the WebLogic jDriver for Oracle for distributed transactions.
Type 2 (requires native libraries):
¢ WebLogic jDriver for Oracle
¢ WebLogic jDriver for Oracle
XA
¢ Third-party drivers, such as the Oracle OCI driver and the IBM DB2 driver
Between WebLogic Server and DBMS in local and distributed transactions.
Type 4 (pure Java)
¢ WebLogic jDrivers for Microsoft SQL Server
¢ Third-party drivers, including: Oracle Thin and Oracle Thin XA drivers Between WebLogic Server and DBMS in local and distributed transactions.
Type 3
¢ WebLogic RMI Driver
Between an external client and WebLogic Server (connection pool).
An Overview of WebLogic Server 8.1
WebLogic Server provides essential features for developing and deploying mission-critical e-commerce applications across distributed, heterogeneous computing environments. These features include the following:
Standards leadership”Comprehensive enterprise Java support to ease the implementation and deployment of application components. WebLogic Server is the first independently developed Java application server to achieve J2EE certification. In addition, BEA actively participates in the development of J2EE and Web Services standards that drive innovation and advancement in Java and XML technology.
Rich client options”WebLogic Server supports Web browsers and other clients that use HTTP; Java clients that use RMI (Remote Method Invocation) or IIOP (Internet Inter-ORB Protocol); SOAP clients on any SOAP-enabled platform; and mobile devices that use (WAP) Wireless Access Protocol. Connectors from BEA and other companies enable virtually any client or legacy application to work with a WebLogic Server application.
Flexible Web services”WebLogic Server provides a solid platform for deploying Web services as components of a heterogeneous distributed application. Web services use a cross-platform, cross-language data model (XML) to provide interoperability among application components on diverse hardware and software platforms. Web services support user-defined data types and one-way asynchronous operations. A Web service can intercept SOAP messages for further processing. New Ant tasks automatically generate important components and package the service into a deployable EAR file.
WebLogic Server uses Web Services Description Language (WSDL) 1.1, an XML-based specification, to describe Web services. WebLogic Web services support Simple Object Access Protocol (SOAP) 1.1 and 1.2 as the message format and HTTP as a connection protocol.
WebLogic Web services accept both SOAP 1.1 and 1.2 incoming requests, but produce only SOAP 1.1 outgoing responses.
Enterprise e-business scalability”Efficient use and high availability of critical resources are achieved through Enterprise JavaBean business components and mechanisms such as WebLogic Server clustering for dynamic Web pages, backend resource pooling, and connection sharing.
Robust administration”WebLogic Server offers a Web-based Administration Console for configuring and monitoring WebLogic Server services. A command-line interface for configuration makes it convenient to administer WebLogic Servers with scripts.
E-commerce-ready security”WebLogic Server provides Secure Sockets Layer (SSL) support for encrypting data transmitted across WebLogic Server, clients, and other servers. User authentication and authorization for all WebLogic Server services are provided through roles and security providers. External security stores, such as Lightweight Directory Access Protocol (LDAP) servers, can still be adapted to WebLogic realms, enabling single sign-on for the enterprise. The Security Service Provider Interface makes it possible to extend WebLogic Security services and to implement WebLogic Security features in applications.
Maximum development and deployment flexibility” WebLogic Server provides tight integration with and support for leading databases, development tools, and other environments.
Bi-directional functional interoperability between Java/J2EE objects and Microsoft ActiveX components”BEA WebLogic jCOM provides a run-time component that implements both Component Object Model (COM)/Distributed Component Object Model (DCOM) and Remote Method Invocation (RMI) distributed components infrastructures. This makes the objects look like native objects for each environment.
Java Message Service (JMS)”An enterprise messaging system, also referred to as message-oriented middleware (MOM), enables applications to communicate with one another through the exchange of messages. A message is a request, report, and/or event that contains information needed to coordinate communication between different applications. A message provides a level of abstraction, allowing you to separate the details about the destination system from the application code.
The Java Message Service (JMS) is a standard API for accessing enterprise-messaging systems. Specifically, JMS enables Java applications sharing a messaging system to exchange messages, and it simplifies application development by providing a standard interface for creating, sending, and receiving messages.







7. TESTING AND RESULT

Testing is the major quality measure employed during the software engineering development. Its basic function is to detect error in the software. Testing is necessary for the proper functioning of the system.
Testing has to be done at four levels
1. Unit Testing:-
Unit testing focuses verification effort on the smallest unit of the software, design the module. Here, using the detail design as a guide, important control paths are tested to uncover errors within the boundary of the module. Unit testing is always white-box oriented, and the step can be conducted in parallel for multiple modules.
2. Integration Testing:-
Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors, associated with interfacing .The objective is to take the unit tested modules and build program structure that has been directed by the design.
3. Validation Testing:-
Validation testing demonstrates the traces the requirements of the software .This can be achieved through a series of black box tests.
4. System Testing:-
System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system. Although each test has a different purpose, all works should verify that all system elements have been properly integrated and perform allocated functions. The various tests include recovery testing, stress testing, perform testing.







8. ENHANCEMENT










9. LIMITATIONS










10. 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 ease and also by saving the valuable time. The amount of time consumption is reduced and also the manual calculations are omitted, the reports and bills can be obtained regularly and also whenever on demand by the user. The effective utilization of the work by proper sharing it and by providing the accurate results. 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.







11. 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 Practitioner™s Approach .
4. IEEE, IEEE Software Standards, IEEE Press ,1989 .
5. Patrick Naughton and Herbert Schildt, The Complete Reference “Java 2 , 3 Edition ,Tata McGraw “ Hill ,1999.
6. Er. V.K.Jain, Programming Java Server Pages & Servlets.
Company Profile
The ProPest Co. Ltd, an Executive Agency of the India's Department for Environment, Food and Rural Affairs, administers the regulation of agricultural, horticultural, forestry, food storage and home garden pesticides to supply throughout the world. The principal functions of ProPest are to evaluate and process applications for approval of pesticide products and can be used across the world and provide advice to Government on pesticides policy.
Our Aims are:
To ensure the safe use of pesticides for people and the environment
As part of the strategy for sustainable food and farming, to reduce negative impacts of pesticides, encouraging reductions in their use, taking account of best practice, and the development and introduction of alternative control measures.
To harmonize pesticide regulation within India and throughout the world, and provide a level playing field for crop protection
We will meet these aims by regulation and other means..
An exhaustive review of Federal government data shows that you can reduce your health risks from pesticides in fruits and vegetables by half, and still eat a diet rich in all the nutrients and benefits they supply. How Buy organic products whenever possible. But if you can't, another option is to minimize consumption of the twelve fruits and vegetables that consistently carry the most pesticides, and the most toxic pesticides.
The Distribution Channel Management system 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 of tracking of all the details are tedious and time consuming. Any product survey and launching of the area carried out manually by representatives, which is a time taking 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 / 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 task which supplement the above functions.
An application has to be developed which would minimize the flaws of the existing system. This project would automate the operations of the management and would retain the present functionality available in the current system.
The scope of this project is to enable the user of an organization to view the issues through the LAN/Internet. Based on the category of the user i.e. employee or administrator, the various parts of the system are made available to the users.

1. Introduction
1.1 Abstract of Project
1.1.1 Title of the Project
1.1.2 Objective
1.2 Problem Specification/Need of Project
2. Feasibility Study
3. Software Requirement Specifications
3.1 Introduction
3.2 Selection of Technology/Specific Requirements
4. Design
4.1 ER Diagram
4.2 Data Flow Diagram (0 & 1 Level)
4.3 Modules
4.4 Database
4.5 Input-Output form (Screen Layout)
5. Coding (if any)
6. Implementation/Technological Environment
7. Testing & Result
8. Enhancement
9. Limitations
10. Conclusion
11. Bibliography