Automation Process in Online Shopping

Published Date: 21 Feb 2018

1. INTRODUCTION

Online Shopping

1.1 About The Project

This project is developed for the automation process of shopping throw online i.e through web. In marchant module adding the catogories,products,itemSales, giving orders, stock maintenace, creating invoice (bill) for orders, shipping of items order given by customer. creation, details, and other transactions like automatic increment,decrement of stock, paid invoice(amount),shipping invoice

And all other transactions for large scale whole sale or retail sales, very big shops, or organizations.

This project mainly contains 3 modules like Marchant module, Customer module, and invoice module.

In customer module customers will give orders for items which are being available in that shop. In our project that order is processed and details are stored in data base. In invoice module total bill for ordered items will be created. In case if the ordered items are not being shipped at a time then the pending order details will be processed and the bill for the pending order will be created. In Marchant Module products are being maintained in category wise and product wise, item wise and up to date stock will be maintained in computerized manner. And up to date order given by the customer through online web status will be shown with help of dynamic web pages by getting data from database.

EXISTING SYSTEM

In existing system every thing is manual like customer will go to shop manually and he/she selects items which are available in shop and the marchant will calculate the bill for products selected by the customer and then shipping process will take place.

Existing System is manual, every thing we have to do manually

• displaying items
• Selecting items
• Billing process
• Shipping
• Problems in present system
• Could not synchronize the Outward information to shopping order details.
• No track of the complaints and replaced goods after ordering
• Order status is updated manually using Order Confirmation.
• Very high levels of effort for preparing invoices and dispatch related documents and routing them to relevant departments or locations and high levels of clerical activity on account of applicability of different customers and products.
• Increased levels of expectation from customers with respect to prompt delivery of items.
• Inability to accurately judge changing patterns of fast and slow moving items on account of large volumes of data, and inability to track goods in transit.
• Difficulties in handling customer queries pertaining to consignments in-transit and partial dispatches.
• Important orders not discriminated from others since all orders since all orders were processed on a FIFO basis-hence need to be able to prioritize and process orders on a preferential basis (for high value orders or important customers), if required.
• Increase in frequency of goods returned on account of damage leading to high stock levels of damaged goods in the factory.
• Discrepancy between ordered and invoiced quantities on account of either partial availability of stocks or clerical oversights.
• Insufficient checks in the current system for ensuring customer credit limits are not exceeded.
• Sales data not analyzed properly to streamline production volumes. This is primarily on account of varying sales patterns across the year and high volumes of transaction.
• Customers could communicate to the Sales people but no information is kept in track for future references.
• Marchant or Management couldn't not have any information regarding latest sales reports unless requested and taken it for Spreadsheet applications.

Marchant or Management requires the Quality information updates against the complaints and quality measures and metrics, which the current system couldn't provide such facilities.

The end user of this product is a departmental store where the application is hosted on the web and administrator maintains database.This application which is deployed at the departmental store will automate the following process.

• the customer details are appended to the customer database.
• The details of the items are brought forward from the database for customer's view based on the selection through the menu.
• Database of all the products are products are updated at the end of the each transaction.

1. MODULE

Marchant Module

Marchant will enter into the next form by entering username,password in this login page,after entering into next page marchant will add new products, categories, different different items what are all the items available in that store,and if he wants he will modify the things,he will delete things

And maintains everything by date wise.

1. Enhancing stores
2. update stores
3. delete from stores

Software and Hardware Requirements

The following software and hardware are recommended for the company.

Hardware Requirements:

Processor : Pentium

Speed : 233 MHz

Monitor : samtron

HardDisk : 4.2 GB

RAM : 128 MB

Software Requirements:

Operating : SystemWindows NT

Language : JAVA (JSP, JDBC).JDK 1.4

Backend : ORACLE

2.0 SYSTEM SPECIFICATION

2.1 Introduction

2.4 Advantages of the Proposed System

• Inter-Department Communication using Intranet Mailing Services (emails)Tracking the mails received from the customers as complaints and using them for appraisal and audit purpose purposes.
• Customized and adhoc reports for the MIS for decision-making.
• Order indent-automation from the direct sales dept.
• Shop Inventory Database updates.
• Stock in shop information

Communication with the customers regarding the orders and complaints and tracking them for the future purposes.

Application Portfolio

It is recommended that the organization takes up the following four functional areas for automation

• Marchant department
• customer department
• Stores department
• Billing, shipping Information System

The reasons for selecting the above are that firstly they directly address the problems enumerated. Secondly, together they forma cohesive set of well-integrated application with one system acting as the feeder system for the other.

System Architecture

DATA FLOW DIAGRAMS:

A data flow diagram is a logical model of a system. The model does not depend on hardware, software and data structures of the organization. There is no physical implication in a data flow diagram. Because the diagram is a graphic picture of the logical system, it tends to be easy for every non-technical user to understand and thus serves as an excellent communication tool. Finally a data flow diagram is a good starting point for system design.

To construct a data flow diagram it uses four basic symbols. They are given below.

Rectangle:

The above symbol is used to define source or destination of data.

Circle or Rounded Corners Rectangle:

The above symbols are defined to represent a process that transforms or modifies the data.

3.21 INTRODUCTION

UML is a notation that resulted from the unification

Of Object Modeling Technique and Object Oriented Software Technology .UML has been designed for broad range of application.

Hence, it provides constructs for a broad range of systems and activities.

An Overview of UML in five notations

1. use case diagrams

Use cases are used during requirements elicitation and analysis

To represent the functionality of the system.Use cases focus on the behaviour of the system from the external point of view.The actor are

Outside the boundary of the system,whereas the use cases are inside the boundary of the system.

2. class diagrams

Class diagrams to describe the structure of the system. Classes

Are abstraction that specify the common structure and behaviour of a set

Of objects.

Class diagrams describe the system in terms of objects, classes, attributes, operations and their associations.

3. Sequence diagrams

Sequence diagrams are used to formalize the behaviour of the system and to visualize the communication among objects. They are useful for identifying additional objects that participate in the use cases. A Sequence diagram represents the interaction that take place among these objects.

4. Statechart diagrams

State chart diagrams describe the behaviour of an individual object as a number of states and transitions between these states. A state represents a particular set of values for an object. The sequence diagram focuses on the messages exchanged between objects, the state chart diagrams focuses on the transition between states.

5.Activity diagrams

An activity diagram describes a system in terms of activities. Activities are states that represents the execution of a set of operations. Activity diagrams are similar to flowchart diagram and data flow.

Screens of online shopping

3. REQUIREMENTS SPECIFICATION

PURPOSE

The purpose of “Online Shopping” is to evaluate the performance of the various products, maintain stock details, product details, and customer details of “very big shops”.

SCOPE

This document is meant for the use of the organization and also will be the basis for clarifications. Alterations will not be made without the permission of the organization.

PRODUCT FUNCTIONS OVERVIEW

Online Shopping is mainly designed for the big shops to automate the maintenance of stock, maintaining customer details, manipulating product details and maintaining the payment details. It also promotes in monitoring the marketing strategy to be implemented depending on the performance of the various products.

3.1 Requirements

In system analysis the developer interacts with the customer/client and works with him in order to find out what he specifically needs. Later he sees the past system, which is in use, and tries to find out what is lacking in that system. This examination of past system is not mandatory. That helps the developer to dig in the problem of the client or the customer.

System Analysis is the study of gathering and interpreting facts, diagnosing problems, and using the recommended improvements to the system. Analysis specifies what the system should do whereas design states how to accomplish the objective. System Analysis is comprised of following things.

• Identify the customer's need.
• Feasibility study.
• Analyzing the system technically and economically.
• Resource allocation.
• Cost Estimations and Work schedule preparation.
• Defining the system, which forms the base of the following activities.

The success of a system depends largely on how accurately a problem is defined, thoroughly investigated and properly carried out through the choice of solution. User need identification and analysis are concerned with the user needs rather than what the customer wants. This step is intended to help the user and the analyst understand the real problem rather than its symptoms.

This package has been developed in order to overcome the difficulties encountered while using the manual system. Faster and timely generation of reports is another motivating factor for the development of this package.

The following requirements are identified.

3.1.1 Functional Requirements

Customer Order Processing

• New order (Order no auto generated).
• View Products in category Status.
• Log User Complaints.
• Order Search and Processing Status.
• Internal Mail.

Merchant's Inventory Processing

• Category wise prod Details.
• Department Orders.
• Internal Mails.

Management Information System Processing

• Adhoc Report.
• Internal Mails.
• Inter office Memos.

3.1.2 User Interfaces:

A LOGIN form is presented with three fields to be entered. When the Login button is pressed, based on the empid, department values in the login form, database the respective form gets displayed. After that the user can perform the required activities.

3.2.2 Analysis Objects

1. Interface Objects:

The interface object (also known as Boundary Object) is responsible for controlling access to the Enterprise Java Beans tier from any client. This includes other server-side components, such as Servlets and Jsp pages.An excellent example of interface object is the controller servlets for the web application's MVC architecture.

2. Control Objects:

Control objects provide services to the application. They model functionality that is not naturally associated with a particular entity or interface. Often, this is because more than one entity needs to be operated on at one time; an example might be determining if there is sufficient inventory to manufacture a product. Other times, it may be because a relevant entity was not identified in the model; an example might be charging someone's credit card.

3. Entity Objects:

Entity objects model those business objects that should maintain their state after the use case completes. Typically, this means that they represent data from the database. Some examples are Customer, product, and an order.

Entity objects should be represented by entity beans in the implementation model.

The Entity Objects:

1. Customer
2. Invoice
3. Order
4. Stock
5. Product

3.3 INPUTS

The following inputs are collected for proposed system during the requirements specification from the Industries.

1. Goods Inward Note (GIN)

The factory receives this document from the factory along with the finished goods. It consists of the details of items received .The warehouse in charge is supposed to physically verify the stock received against this document. Discrepancies are to be noted on the GIN and send back to the factory. It is use to enter details into the Goods inward register. It is also used to update stock book on weekly basis.

2. Goods received Confirmation

On receiving the goods the customer is supposed to send a letter or telephonically in form the receipt of the consignment. Having got this information, the relevant invoice from the in transit file is to be removed and destroyed is fixed format for this document.

3. Goods Returned Note

This is prepared based on the information send by the direct customer or dealer on goods that have been damaged in transit. It contains the details of the damaged goods. A copy of this is sent to the order-processing department, anther copy to the quality control department and third is field in the GRN file. The GRN details are entered into the damaged goods ledger.

4. Order

Company receives order from their direct customer and detailers. The dealers fill in the details on Flowell's order form itself. The orders from the direct customers are transcribed on the regular format. Orders can be sent by one warehouse to another. They are used for checking the availability of the stock. They are serialized and then filled. In is used to check the availability of the required stock in stock book and the goods inward register. The order could be serviced completely, partially or pending as the case may be.

3.5 Outputs

The following outputs are collected for proposed system during the requirements specification from the Shops.

1. Invoice

Once an order (either direct customer order or the dealer order) gets serviced partially or fully, an invoice for the same needs to be prepared. Most of the details are picked up from the order itself .An order may have multiple invoices. The discount for special customers is worked out. The rate is got form the product rate file. A copy of the invoice is sent to the direct customer, dealer, in-transit file, invoice file. The invoice details are entered into the issue register.

Once supplementary gets service partially or fully nil valued supplementary invoice for the same needs to be prepared. Most of the details are picked up from the supplementary order itself. A copy of the supplementary invoice is sent to the direct customer, dealer, in-tansit file, and supplementary invoice file. The supplementary invoice details are entered into the issue register.

2. Dispatch Instructions

The invoice department picks up dispatch instructions for the invoices that are prepared from the order form. This they send to the dispatch department. They prepare a packing slip.

This is a regular report being prepared, consisting of order that are pending as of a particular date. The details for this report are taken from the pending orders.

3. Weekly Stock Status Report

This is another weekly report prepared giving the details of the stock of each product. The details are obtained from the stock book.

This report is prepared on adhoc basis. Whenever the actual stock is compared with book stock, and discrepancies found, they are entered product wise in this report.

4. DESIGN SPECIFICATION

4.1 DATA DESIGN

Data objects

A data object is a thing about which you want to store information. It has independent existence and can be uniquely identified.

The following data objects are derived for the system.

• Customer
• Order
• Product
• Invoice
• category

Relationships

A relationship is a named association between agent and customer entity or more than entities we say that relationship exists between clerk and customer entity type. Similarly a relation between a clerk entity type and a manager entity type.

The following relationships are identified for the system.

For instance let us take the objects CUSTOMER, CATEGORY,PRODUCT, ORDER ,BILL the following relationships are identified.

• Customer “places” an Order.
• Order “contains” Product.
• Product “dispatched to” Customer.
• The relationships between the remaining entities are as follows :
• Customer “receives” Invoice.
• Invoice “has” Product.

E-R Diagram

E-R Diagram as a method to represent a Data model and was developed by Chen (1976). The main focus of a Data Model is to identify the required data and show it diagrammatically, which is called Entity Relationship Diagram. Its popularly is attributed to its simplicity. It has a top-down design approach to decide the minimum data that we would like to store for a given information system.

4.2 Screens

ONLINE SHOPPING SCREENS

TESTING

It is a process of establishing confidence that a program or system does what it is proposed of. Testing is the only way to assure the quality of software and it is an umbrella activity rather than a separate phase. This is an activity to be performed in parallel with the software effort and one that consists of its own phases of analysis, design, implementation, execution and maintenance.

5.1 Testing strategy

5.1.1 Unit Testing:

This testing method considers a module as single unit and checks the unit at interfaces and communicates with other modules rather than getting into details at statement level. Here the module will be treated as a black box, which will take some inputs and generate output. Outputs for a given set of input combination are pre-calculated and are generated by the module.

5.1.2 Integration testing:

Here all the pre-tested individual modules will be assembled to create the larger system and tests are carried out at system level to make sure that all modules are working in synchronous with each other. This testing methodology helps in making sure that all modules which are running perfectly when checked individually and are also running cohesion with other modules. For this testing we create test cases to check all modules once and then generated test combinations of test paths through out the system to make sure that no path is making its way into chaos.

5.1.3 Validation testing:

Testing is a major quality control measure employed during software development. Its basic function is to detect errors. Sub functions when combined may not produce than it is desired. Global data structures can represent the problems. Integrated testing is a systematic technique for constructing the program structure while conducting the tests. To uncover errors that are associated with interfacing the objective is to make test modules and built a program structure that has been detected by design. In a non-incremental integration all the modules are combined in advance and the program is tested as a whole. Here errors will appear in an endless loop function. In incremental testing the program is constructed and tested in small segments where the errors are isolated and corrected.

Different incremental integration strategies are top-down integration, bottom-up integration, regression testing.

5.1.4 High-order testing (a.k.a. System Testing)

Modules are integrated by moving downwards through the control hierarchy beginning with main program. The subordinate modules are incorporated into structure in either a Breadth First manner or in a Depth First manner.

This process is done in five steps:

• Main control module is used as a test driver and steps are submitted are all modules directly to main program.
• Depending on the integration approach selected subordinate is replaced at a time with actual modules.
• Tests are conducted.
• On completion of each set of tests another stub is replaced with the real module.
• Regression testing may be conducted to ensure that new errors have not been introduced.

This process continues from step 2 until entire program structure is reached. In top down integration strategy decision making occurs at upper levels in the hierarchy and is encountered first. If major control problems do exists early recognition's is essential.

If Depth First integration is selected a complete function of the software may be implemented and demonstrated.

Some problems occur when processing at low levels in hierarchy is required to adequately test upper level steps to replace low-level modules at the beginning of the top-down testing. So no data flows upwards in the program structure.

BOTTOM-UP INTEGRATION TESTING

Begins construction and testing with automatic modules. As modules are integrated from the bottom-up, processing requirement for modules subordinate to a given level is always available and need for stubs is eliminated.

The following steps implement this strategy:

• Low-level modules are combined in to clusters that perform a specific software sub function.
• A driver is written to coordinate test case input and output.
• Cluster is tested.
• Drivers are removed and moving upward in program structure combines clusters.

Integration moves upward, the need for separate test drover's lesions. If the top-levels of the program are integrated top-down, the number of drivers can be reduced substantially and integration of clusters is greatly simplified.

REGRESSION TESTING

Each time a new module is added as a part of integration as the software changes. Regression testing is an actually that helps to ensure changes that do not introduce unintended behavior as additional errors.

Regression testing may be conducted manually by executing a subset of all test cases and results for subsequent playback tools enables the software engineer to capture the test case and results for subsequent playback and compression. The regression suit contains different classes of test cases.

6. CONFIGURATION

7. FEATURES USED

7.1 About J2EE (Java™ 2 Platform Enterprise Edition, v1.3)

Today, more and more developers want to write distributed transactional applications for the enterprise and leverage the speed, security, and reliability of server-side technology. If you are already working in this area, you know that in today's fast-moving and demanding world of e-commerce and information technology, enterprise applications have to be designed, built, and produced for less money, with greater speed, and with fewer resources than ever before.

To reduce costs and fast-track enterprise application design and development, the Java™2 Platform, Enterprise Edition (J2EE™) technology provides a component-based approach to the design, development, assembly, and deployment of enterprise applications. The J2EE platform offers a multitiered distributed application model, the ability to reuse components, integrated Extensible Markup Language (XML)-based data interchange, a unified security model, and flexible transaction control. Not only can you deliver innovative customer solutions to market faster than ever, but your platform-independent J2EE component-based solutions are not tied to the products and application programming interfaces (APIs) of any one vendor. Vendors and customers enjoy the freedom to choose the products and components that best meet their business and technological requirements.

Distributed Multitier Applications

The J2EE platform uses a multitier distributed application model for both enterprise applications. Application logic is divided into components according to function, and the various application components that make up a J2EE application are installed on different machines depending on the tier in the multitier J2EE environment to which the application component belongs. The following Figure shows two multitier J2EE applications divided into the tiers described in the following list. The J2EE application parts shown in the Figure are presented in J2EE Components.

• Client-tier components run on the client machine.
• Web-tier components run on the J2EE server.
• Business-tier components run on the J2EE server.
• Enterprise information system (EIS)-tier software runs on the EIS server.

Although a J2EE application can consist of the three or four tiers shown in Figure, J2EE multitiered applications are generally considered to be threetiered applications because they are distributed over three different locations: client machines, the J2EE server machine, and the database or legacy machines at the back end. Three-tiered applications that run in this way extend the standard two-tiered client and server model by placing a multithreaded application server between the client application and back-end storage.

J2EE Architecture

The required relationships of architectural elements of the J2EE platform are shown in Figure. Note that this figure shows the logical relationships of the elements; it is not meant to imply a physical partitioning of the elements into separate machines, processes, address spaces, or virtual machines.The Containers, denoted by the separate rectangles,are J2EE runtime environments that provide required services to the application components represented in the upper half of the rectangle. The services provided are denoted by the boxes in the lower half of the rectangle. For example, the Application Client Container provides Java Messaging Service (JMS) APIs to Application Clients, as well as the other services represented. All these services are explained below.

The arrows represent required access to other parts of the J2EE platform. The Application Client Container provides Application Clients with direct access to the J2EE required Database through the Java API for connectivity with database systems, the JDBCTM API. Similar access to databases is provided to JSP pages and servlets by the Web Container, and to enterprise beans by the EJB Container. As indicated the APIs of the JavaTM 2 Platform, Standard Edition (J2SETM), are supported by J2SE runtime environments for each type of application component.

J2EE Architecture Diagram

J2EE Components

J2EE applications are made up of components. A J2EE component is a self-contained functional software unit that is assembled into a J2EE application with its related classes and files and that communicates with other components. The J2EE specification defines the following J2EE components:

• Application clients and applets are components that run on the client.
• Java Servlet and JavaServer Pages™ (JSP™) technology components are Web components that run on the server.
• Enterprise JavaBeans™ (EJB™) components (enterprise beans) are business Components that run on the server.

J2EE components are written in the Java programming language and are compiled in the same way as any program in the language. The difference between J2EE components and “standard” Java classes is that J2EE components are assembled into a J2EE application, verified to be well formed and in compliance with the J2EE specification, and deployed to production, where they are run and managed by the J2EE server.

J2EE Clients

A J2EE client can be a Web client or an application client.

Web Clients

A Web client consists of two parts: dynamic Web pages containing various types of markup language (HTML, XML, and so on), which are generated by Web components running in the Web tier, and a Web browser, which renders the pages received from the server.

A Web client is sometimes called a thin client. Thin clients usually do not do things like query databases, execute complex business rules, or connect to legacy applications. When you use a thin client, heavyweight operations like these are off-loaded to enterprise beans executing on the J2EE server where they can leverage the security, speed, services, and reliability of J2EE server-side technologies.

Applets

A Web page received from the Web tier can include an embedded applet. An applet is a small client application written in the Java programming language that executes in the Java virtual machine installed in the Web browser. However, client systems will likely need the Java Plug-in and possibly a security policy file in order for the applet to successfully execute in the Web browser.

Web components are the preferred API for creating a Web client program because no plug-ins or security policy files are needed on the client systems. Also, Web components enable cleaner and more modular application design because they provide a way to separate applications programming from Web page design. Personnel involved in Web page design thus do not need to understand Java programming language syntax to do their jobs.

Application Clients

A J2EE application client runs on a client machine and provides a way for users to handle tasks that require a richer user interface than can be provided by a markup language. It typically has a graphical user interface (GUI) created from Swing or Abstract Window Toolkit (AWT) APIs, but a command-line interface is certainly possible.

Application clients directly access enterprise beans running in the business tier. However, if application requirements warrant it, a J2EE application client can open an HTTP connection to establish communication with a servlet running in the Web tier.

JavaBeans™ Component Architecture

The server and client tiers might also include components based on the Java-Beans component architecture (JavaBeans component) to manage the data flow between an application client or applet and components running on the J2EE server or between server components and a database. JavaBeans components are not considered J2EE components by the J2EE specification.

JavaBeans components have instance variables and get and set methods for accessing the data in the instance variables. JavaBeans components used in this way are typically simple in design and implementation, but should conform to the naming and design conventions outlined in the JavaBeans component architecture.

J2EE Server Communications

The various elements that can make up the client tier. The client communicates with the business tier running on the J2EE server either directly or, as in the case of a client running in a browser, by going through JSP pages or servlets running in the Web tier.

Your J2EE application uses a thin browser-based client or thick application client. In deciding which one to use, you should be aware of the trade-offs between keeping functionality on the client and close to the user (thick client) and offloading as much functionality as possible to the server (thin client). The more functionality you off-load to the server, the easier it is to distribute, deploy, and manage the application; however, keeping more functionality on the client can make for a better perceived user experience.

Web Components

J2EE Web components can be either servlets or JSP pages. Servlets are Java programming language classes that dynamically process requests and construct responses. JSP pages are text-based documents that execute as servlets but allow a more natural approach to creating static content.

Static HTML pages and applets are bundled with Web components during application assembly, but are not considered Web components by the J2EE specification. Server-side utility classes can also be bundled with Web components and, like HTML pages, are not considered Web components.

Like the client tier and as shown in Figure 1–3, the Web tier might include a JavaBeans component to manage the user input and send that input to enterprise beans running in the business tier for processing.

Business Components

Business code, which is logic that solves or meets the needs of a particular business domain such as banking, retail, or finance, is handled by enterprise beans running in the business tier.Figure 1–4 shows how an enterprise bean receives data from client programs, processes it (if necessary), and sends it to the enterprise information system tier for storage. An enterprise bean also retrieves data from storage, processes it (if necessary), and sends it back to the client program.

There are three kinds of enterprise beans: session beans, entity beans, and message- driven beans. A session bean represents a transient conversation with a client. When the client finishes executing, the session bean and its data are gone. In contrast, an entity bean represents persistent data stored in one row of a database table. If the client terminates or if the server shuts down, the underlying services ensure that the entity bean data is saved.

A message-driven bean combines features of a session bean and a Java Message Service (“JMS”) message listener, allowing a business component to receive JMS messages asynchronously. This tutorial describes entity beans and session beans. For information on message-driven beans, see The Java Message Service Tutorial, available at http://java.sun.com/products/jms/tutorial/index.html

Enterprise Information System Tier

The enterprise information system tier handles enterprise information system software and includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. J2EE application components might need access to enterprise information systems for database connectivity, for example.

J2EE Containers

Normally, thin-client multitiered applications are hard to write because they involve many lines of intricate code to handle transaction and state management, multithreading, resource pooling, and other complex low-level details. The component-based and platform-independent J2EE architecture makes J2EE applications easy to write because business logic is organized into reusable components. In addition, the J2EE server provides underlying services in the form of a container for every component type. Because you do not have to develop these services yourself, you are free to concentrate on solving the business problem at hand.

Container Services

Containers are the interface between a component and the low-level platform specific functionality that supports the component. Before a Web, enterprise bean, or application client component can be executed, it must be assembled into a J2EE application and deployed into its container.

The assembly process involves specifying container settings for each component in the J2EE application and for the J2EE application itself. Container settings customize the underlying support provided by the J2EE server, which includes services such as security, transaction management, Java Naming and Directory Interface™ (JNDI) lookups, and remote connectivity. Here are some of the highlights:

• The J2EE security model lets you configure a Web component or enterprise bean so that only authorized users access system resources.
• The J2EE transaction model lets you specify relationships among methods that make up a single transaction so that all methods in one transaction are treated as a single unit.
• JNDI lookup services provide a unified interface to multiple naming and directory services in the enterprise so that application components can access naming and directory services.
• The J2EE remote connectivity model manages low-level communications between clients and enterprise beans. After an enterprise bean is created, a client invokes methods on it as if it were in the same virtual machine.

The fact that the J2EE architecture provides configurable services means that application components within the same J2EE application can behave differently based on where they are deployed. For example, an enterprise bean can have security settings that allow it a certain level of access to database data in one production environment and another level of database access in another production environment.

The container also manages non-configurable services such as enterprise bean and servlet life cycles, database connection resource pooling, data persistence, and access to the J2EE platform APIs described in the section J2EE APIs. Although data persistence is a non-configurable service, the J2EE architecture lets you override container-managed persistence by including the appropriate code in your enterprise bean implementation when you want more control than the default container-managed persistence provides. For example, you might use bean-managed persistence to implement your own finder (search) methods or to create a customized database cache. Container Types the deployment process installs J2EE application components in the J2EE containers illustrated in Figure 1–5.

J2EE server

The runtime portion of a J2EE product. A J2EE server provides EJB and Web containers.

Enterprise Java Beans (EJB) container

Manages the execution of enterprise beans for J2EE applications. Enterprise beans and their container run on the J2EE server.

Web container

Manages the execution of JSP page and servlet components for J2EE applications. Web components and their container run on the J2EE server.

Application client container

Manages the execution of application client components. Application clients and their container run on the client.

Applet container

Manages the execution of applets. Consists of a Web browser and Java Plug-in running on the client together.

Packaging

A J2EE application is delivered in an Enterprise Archive (EAR) file. An EAR file is a standard Java Archive (JAR) file with an .ear extension. The EAR file contains J2EE modules. Using EAR files and modules makes it possible to assemble a number of different J2EE applications using some of the same components. No extra coding is needed; it is just a matter of assembling various J2EE modules into J2EE EAR files.

A J2EE module consists of one or more J2EE components for the same container type and one component deployment descriptor of that type. A deployment descriptor is an XML document with an .xml extension that describes a component's deployment settings. An enterprise bean module deployment descriptor, for example, declares transaction attributes and security authorizations for an enterprise bean. Because deployment descriptor information is declarative, it can be changed without modifying the bean source code. At run time, the J2EE server reads the deployment descriptor and acts upon the component accordingly. A J2EE module without an application deployment descriptor can be deployed as a stand-alone module. The four types of J2EE modules are:

• Enterprise JavaBeans modules contain class files for enterprise beans and an EJB deployment descriptor. EJB modules are packaged as JAR files with a .jar extension.
• Web modules contain JSP files, class files for servlets, GIF and HTML files, and a Web deployment descriptor. Web modules are packaged as JAR files with a .war (Web ARchive) extension.
• Resource adapter modules contain all Java interfaces, classes, native libraries, and other documentation, along with the resource adapter deployment descriptor. Together, these implement the Connector architecture for a particular EIS. Resource adapter modules are packages as JAR files with a .rar (Resource adapter ARchive) extension.
• Application client modules contain class files and an application client deployment descriptor. Application client modules are packaged as JAR files with a .jar extension.

Development Roles

Reusable modules make it possible to divide the application development and deployment process into distinct roles so that different people or companies can perform different parts of the process.

The first two roles involve purchasing and installing the J2EE product and tools. Once software is purchased and installed, J2EE components can be developed by application component providers, assembled by application assemblers, and deployed by application deployers. In a large organization, different individuals or teams might execute each of these roles. This division of labor works because each of the earlier roles outputs a portable file that is the input for a subsequent role. For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a J2EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the J2EE application into a J2EE server.

The different roles are not always executed by different people. If you work for a small company, for example, or if you are prototyping a sample application, you might perform the tasks in every phase.

J2EE Product Provider

The J2EE product provider is the company that designs and makes available for purchase the J2EE platform, APIs, and other features defined in the J2EE specification. Product providers are typically operating system, database system, application server, or Web server vendors who implement the J2EE platform according to the Java 2 Platform, Enterprise Edition Specification.

Tool Provider

The tool provider is the company or person who creates development, assembly, and packaging tools used by component providers, assemblers, and deployers.

Application Component Provider

The application component provider is the company or person who creates Web components, enterprise beans, applets, or application clients for use in J2EE applications.

Enterprise Bean Developer

An enterprise bean developer performs the following tasks to deliver an EJB JAR file that contains the enterprise bean:

• Writes and compiles the source code
• Specifies the deployment descriptor
• Bundles the .class files and deployment descriptor into an EJB JAR file

Web Component Developer

A Web component developer performs the following tasks to deliver a WAR file containing the Web component:

• Writes and compiles servlet source code
• Writes JSP and HTML files
• Specifies the deployment descriptor for the Web component
• Bundles the .class, .jsp, .html, and deployment descriptor files in the WAR file

J2EE Application Client Developer

An application client developer performs the following tasks to deliver a JAR file containing the J2EE application client:

• Writes and compiles the source code
• Specifies the deployment descriptor for the client
• Bundles the .class files and deployment descriptor into the JAR file

Application Assembler

The application assembler is the company or person who receives application component JAR files from component providers and assembles them into a J2EE application EAR file. The assembler or deployer can edit the deployment descriptor directly or use tools that correctly add XML tags according to interactive selections. A software developer performs the following tasks to deliver an EAR file containing the J2EE application:

• Assembles EJB JAR and WAR files created in the previous phases into a J2EE application (EAR) file
• Specifies the deployment descriptor for the J2EE application
• Verifies that the contents of the EAR file are well formed and comply with the J2EE specification

Application Deployer and Administrator

The application deployer and administrator is the company or person who con-figures and deploys the J2EE application, administers the computing and networking infrastructure where J2EE applications run, and oversees the runtime environment. Duties include such things as setting transaction controls and security attributes and specifying connections to databases.

During configuration, the deployer follows instructions supplied by the application component provider to resolve external dependencies, specify security settings, and assign transaction attributes. During installation, the deployer moves the application components to the server and generates the container-specific classes and interfaces.

A deployer/system administrator performs the following tasks to install and con-figure a J2EE application:

• Adds the J2EE application (EAR) file created in the preceding phase to the J2EE server
• Configures the J2EE application for the operational environment by modifying the deployment descriptor of the J2EE application
• Verifies that the contents of the EAR file are well formed and comply with the J2EE specification
• Deploys (installs) the J2EE application EAR file into the J2EE server

Reference Implementation Software

The J2EE SDK is a noncommercial operational definition of the J2EE platform and specification made freely available by Sun Microsystems for demonstrations, prototyping, and educational use. It comes with the J2EE application server, Web server, relational database, J2EE APIs, and complete set of development and deployment tools. You can download the J2EE SDK from http://java.sun.com/j2ee/download.html#sdk

The purpose of the J2EE SDK is to allow product providers to determine what their implementations must do under a given set of application conditions, and to run the J2EE Compatibility Test Suite to test that their J2EE products fully comply with the specification. It also allows application component developers to run their J2EE applications on the J2EE SDK to verify that applications are fully portable across all J2EE products and tools.

Database Access

The relational database provides persistent storage for application data. A J2EE implementation is not required to support a particular type of database, which means that the database supported by different J2EE products can vary. See the Release Notes included with the J2EE SDK download for a list of the databases currently supported by the reference implementation.

J2EE APIs

The Java 2 Platform, Standard Edition (J2SE™) SDK is required to run the J2EE SDK and provides core APIs for writing J2EE components, core development tools, and the Java virtual machine. The J2EE SDK provides the following APIs to be used in J2EE applications.

Enterprise JavaBeans Technology

An enterprise bean is a body of code with fields and methods to implement modules of business logic. You can think of an enterprise bean as a building block that can be used alone or with other enterprise beans to execute business logic on the J2EE server.

There are three kinds of enterprise beans: session beans, entity beans, and message-driven beans. Enterprise beans often interact with databases. One of the benefits of entity beans is that you do not have to write any SQL code or use the JDBC™ API directly to perform database access operations; the EJB container handles this for you. However, if you override the default container-managed persistence for any reason, you will need to use the JDBC API. Also, if you choose to have a session bean access the database, you have to use the JDBC API.

JDBC API

The JDBC API lets you invoke SQL commands from Java programming language methods. You use the JDBC API in an enterprise bean when you override the default container-managed persistence or have a session bean access the database. With container-managed persistence, database access operations are handled by the container, and your enterprise bean implementation contains no JDBC code or SQL commands. You can also use the JDBC API from a servlet or JSP page to access the database directly without going through an enterprise bean.

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.

Java Servlet Technology

Java Servlet technology lets you define HTTP-specific servlet classes. A servlet class extends the capabilities of servers that host applications accessed by way of a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by Web servers.

Java Server Pages Technology

JavaServer Pages technology lets you put snippets of servlet code directly into a text-based document. A JSP page is a text-based document that contains two types of text: static template data, which can be expressed in any text-based format such as HTML, WML, and XML, and JSP elements, which determine how the page constructs dynamic content.

Java Message Service

The JMS is a messaging standard that allows J2EE application components to create, send, receive, and read messages. It enables distributed communication that is loosely coupled, reliable, and asynchronous. For more information on JMS, see the online Java Message Service Tutorial:

http://java.sun.com/products/jms/tutorial/index.html

Java Naming and Directory Interface

The JNDI provides naming and directory functionality. It provides applications with methods for performing standard directory operations, such as associating attributes with objects and searching for objects using their attributes. Using JNDI, a J2EE application can store and retrieve any type of named Java object.

Because JNDI is independent of any specific implementations, applications can use JNDI to access multiple naming and directory services, including existing naming and directory services such as LDAP, NDS, DNS, and NIS. This allows J2EE applications to coexist with legacy applications and systems. For more information on JNDI, see the online JNDI Tutorial:

http://java.sun.com/products/jndi/tutorial/index.html

Java Transaction API

The Java Transaction API (“JTA”) provides a standard interface for demarcating transactions. The J2EE architecture provides a default auto commit to handle transaction commits and rollbacks. An auto commit means that any other applications viewing data will see the updated data after each database read or write operation. However, if your application performs two separate database access operations that depend on each other, you will want to use the JTA API to demarcate where the entire transaction, including both operations, begins, rolls back, and commits.

Java Mail™ API

J2EE applications can use the Java Mail™ API to send e-mail notifications. The Java Mail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface. The J2EE platform includes Java Mail with a service provider that allows application components to send Internet mail.

JavaBeans Activation Framework

The JavaBeans Activation Framework (“JAF”) is included because Java Mail uses it. It provides standard services to determine the type of an arbitrary piece of data, encapsulate access to it, discover the operations available on it, and create the appropriate JavaBeans component to perform those operations.

Java API for XML Processing

XML is a language for representing text-based data so the data can be read and handled by any program or tool. Programs and tools can generate XML documents that other programs and tools can read and handle. The Java API for XML Processing (“JAXP”) supports processing of XML documents using DOM, SAX, and XSLT. JAXP enables applications to parse and transform XML documents independent of a particular XML processing implementation.

For example, a J2EE application can use XML to produce reports, and different companies that receive the reports can handle the data in a way that best suits their needs. One company might put the XML data through a program to translate the XML to HTML so it can post the reports to the Web, another company might put the XML data through a tool to create a marketing presentation, and yet another company might read the XML data into its J2EE application for processing.

Java API for XML Registries

The Java API for XML Registries (JAXR) lets you access business and general purpose registries over the Web. JAXR supports the Web XML Registry/Repository standards and the emerging UDDI specifications. By using JAXR, developers can learn a single API and get access to both of these important registry technologies. Additionally, businesses submit material to be shared and search for material that others have submitted. Standards groups have developed schemas for particular kinds of XML documents, and two businesses might, for example, agree to use the schema for their industry's standard purchase order form. Because the schema is stored in a standard business registry, both parties can use JAXR to access it.

Java API for XML-Based RPC

The Java API for XML-based RPC (JAX-RPC) uses the SOAP standard and HTTP so client programs can make XML-based remote procedure calls (RPCs) over the Internet. JAX-RPC also supports WSDL so you can import and export WSDL documents. With JAX-RPC and a WSDL, you can easily interoperate with clients and services running on Java-based or non-Java-based platforms such as .NET. For example, based on the WSDL document, a Visual Basic .NET client can be configured to use a Web service implemented in Java technology or a Web service can be configured to recognize a VB NET client. JAX-RPC relies on the HTTP transport protocol. Taking that a step further, JAXRPC lets you create service applications that combine HTTP with a Java technology version of the Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols to establish basic or mutual authentication. SSL and TLS ensure message integrity by providing data encryption with client and server authentication capabilities.

Authentication is a measured way to verify whether a party is eligible and able to access certain information as a way to protect against the fraudulent use of a system and/or the fraudulent transmission of information. Information transported across the Internet is especially vulnerable to being intercepted and misused, so configuring a JAX-RPC Web service to protect data in transit is very important.

SOAP with Attachments API for Java (SAAJ)

The SOAP with Attachments API for Java (SAAJ) is a low-level API upon which JAX-RPC depends. It enables the production and consumption of messages that conform to the SOAP 1.1 specification and SOAP with Attachments note. Most developers will not use the SAAJ API, but will use the higher-level JAX-RPC API instead.

Note: Java API for XML Messaging (JAXM) is not part of J2EE 1.4. Instead, you

can use JAX-RPC and SAAJ to send XML documents over the Web.

J2EE Connector Architecture

J2EE tools vendors and system integrators to create resource adapters that support access to enterprise information systems that can be plugged into any J2EE product use the J2EE Connector architecture. A resource adapter is a software component that allows J2EE application components to access and interact with the underlying resource manager. Because a resource adapter is specific to its resource manager, there is typically a different resource adapter for each type of database or enterprise information system.

Java Authentication and Authorization Service

The Java Authentication and Authorization Service (“JAAS”) provides a way for a J2EE application to authenticate and authorize a specific user or group of users to run it.

JAAS is a Java programming language version of the standard Pluggable Authentication Module (PAM) framework that extends the Java 2 Platform security architecture to support user-based authorization.

Simplified Systems Integration

The J2EE platform is a platform-independent, full systems integration solution that creates an open marketplace in which every vendor can sell to every customer. Such a marketplace encourages vendors to compete, not by trying to lock customers into their technologies but by trying to outdo each other by providing products and services that benefit customers, such as better performance, better tools, or better customer support.

The J2EE APIs enable systems and applications integration through the following:

Unified application model across tiers with enterprise beans

• Simplified response and request mechanism with JSP pages and servlets
• Reliable security model with JAAS
• XML-based data interchange integration with JAXP
• Simplified interoperability with the J2EE Connector Architecture
• Easy database connectivity with the JDBC API
• Enterprise application integration with message-driven beans and JMS, JTA, and JNDI

We can learn more about using the J2EE platform to build integrated business systems by reading J2EE Technology in Practice:

7.2 About BEA WebLogic Server™ 7.0

WebLogic Server implements J2EE 1.3 technologies, Web services, and other leading Internet standards to provide a reliable framework for highly available, scalable, and secure e-business applications.

Evaluation Product Details

BEA WebLogic Platform 7.0 with Service Pack 1 for Microsoft Windows NT/2000

File Size

BEA WebLogic Platform Net Installer - Dependent on installation choices

BEA WebLogic Platform Package Installer - 290 MB

Description

BEA WebLogic Platform includes BEA WebLogic Server, BEA WebLogic Workshop, BEA WebLogic Portal and BEA WebLogic Integration. When installing, choose Typical installation to install all of these product components, or choose Custom installation to select the product components you wish to install.

Minimum Requirements

OS: Microsoft Windows NT/2000

Hardware: Intel

Weblogic Server Tools

Weblogic Workshop

WebLogic Workshop is the industry's leading visual development environment for building enterprise-class web services. With WebLogic Workshop, you can focus on building business logic into your web service rather than on complex implementation details. Whether you are an application developer with a problem to solve and no J2EE experience or a J2EE code jockey, WebLogic Workshop makes it easy to design, test, and deploy web services.

WebLogic Workshop's intuitive user interface lets you design your web service visually. Controls make it simple to connect to enterprise resources, like databases and Enterprise JavaBeans, without writing a lot of code. Conversations handle the job of keeping track of application state. And WebLogic Workshop's support for asynchronous processes makes it easy to build highly reliable web services for the enterprise.

Weblogic Builder

WebLogic Builder provides a visual environment for editing an application's deployment descriptor XML files. You can view these XML files as you visually edit them in WebLogic Builder, but you won't need to make textual edits to the XML files.

Use WebLogic Builder for the following development tasks:

• Generate deployment descriptor files for a J2EE module.
• Edit a module's deployment descriptor files.
• View deployment descriptor files.
• Compile and validate deployment descriptor files.
• Deploy a module to a server

Web Services

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. A new Web service deployment descriptor file completely describes a Web service

Security Infrastructure

A completely redesigned security framework exposes a set of fully implemented Service Provider Interfaces for authentication, authorization, auditing, and PKI management. Modules from third-party security vendors can plug right into the WebLogic Server framework. A new role-based authorization module can be applied to all J2EE and non-rules for dynamically assigning roles and access privileges.

Access Com Objects

WebLogic jCOM is a bi-directional COM-Java bridging tool that developers can use to access Component Object Model (COM) components as though they were Java objects, and to access pure Java objects as if they were COM components.

Cache JSP's ,Pages,URLs and File Types

The CacheFilter enables you to configure caching for entire pages, URLS, JSPs, and certain file types. Because cache filters act on forwards() and includes(), they allow you to cache forwarded and included pages from a jsp/servlet. Use cache filters toimprove the performance of your applications.

Enhance Availability and Cluster Failover

Use the new Java Message Service (JMS) distributed destinations feature to map a single virtual destination to a set of physical destinations on multiple servers within a cluster.

Connect with Message Service Providers

The new foreign message service bridge connects WebLogic JMS with third-party message service providers.

7.3 About Dreamweaver 4

Macromedia Dreamweaver 4, the solution for professional Web s