lbsq doc - for merge

Location Based Spatial Query Processing in Wireless Broadcast Environments

CHAPTER - 1

INTRODUCTION

SPATIAL query processing is becoming an integral part of many new

mobile applications. Recently, there has been a growing interest in the use of location-

based spatial queries (LBSQs), which represent a set of spatial queries that retrieve

information based on mobile users’ current locations [2], [29].

User mobility and data exchange through wireless communication give

LBSQs some unique characteristics that the traditional spatial query processing in

centralized databases does not address. Novel query processing techniques must be

devised to handle the following new challenges:

1. Mobile query semantics. In a mobile environment, a typical LBSQ is of the form

“find the top-three nearest hospitals.” The result of the query depends on the

location of its requester. Caching and sharing of query results must take into

consideration the location of the query issuer.

2. High workload. The database resides in a centralized server, which typically

serves a large mobile user community through wireless communication.

Consequently, bandwidth constraints and scalability become the two most

important design concerns of LBSQ algorithms.

3. Query promptness and accuracy. Due to user mobility, answers to an LBSQ will

lose their relevancy if there is a long delay in query processing or in

communication. For example, answers to the query “find the top-three nearest

hospitals” received after 5 minutes of high-speed driving will become

meaningless. Instead, a prompt, albeit approximate, answer, telling the user right

away the approximate top-three nearest hospitals, may serve the user much better.

This is an important issue, as a long latency in a high workload wireless

environment is not unusual.

DEPT OF MCA, SSCET, KNL. PAGE NO: 1


The wireless environment and the communication constraints play an

important role in determining the strategy for processing LBSQs. In the simplest

approach, a user establishes a point-to-point communication with the server so that her

queries can be answered on demand. However, this approach suffers from several

drawbacks. First, it may not scale to very large user populations. Second, to communicate

with the server, a client must most likely use a fee-based cellular-type network to achieve

a reasonable operating range. Third, users must reveal their current location and send it to

the server, which may be undesirable for privacy reasons [19]. A more advanced solution

is the wireless broadcast model [1], [15], [30]. It can support an almost-unlimited number

of mobile hosts (MHs) over a large geographical area with a single transmitter. With the

broadcast model, MHs do not submit queries. Instead, they tune in to the broadcast

channel for information that they desire. Hence, the user’s location is not revealed. One of

the limitations of the broadcast model is that it restricts data access to be sequential.

Queries can only be fulfilled after all the required on-air data arrives. This is why in some

cases; a 5-minute delay to the query “find the top-three nearest hospitals” would not be

unusual.

Alleviating this limitation, we propose a scalable low-latency approach for

processing LBSQs in broadcast environments. Our approach leverages ad hoc networks to

share information among mobile clients in a peer-to-peer (P2P) manner [17], [18]. The

rationale behind our approach is based on the following observations:

As mentioned previously, when a mobile user launches a nearest neighbor (NN)

query, in many situations, she would prefer an approximate result that arrives with

a short response time rather than an accurate result with a long latency.

The results of spatial queries often exhibit spatial locality. For example, if two

MHs are close to each other, the result sets of their spatial queries may overlap

significantly. Query results of a mobile peer are valuable for two reasons:

o they can be used to answer queries of the current MH directly and

o they can be used to dramatically reduce the latency for the current MH

relative to on-air information.



. P2P approaches can be valuable for applications where the response time is an

important concern. Through mobile cooperative caching of the result sets, query

results can be efficiently shared among mobile clients.

In this paper, we concentrate on two common types of spatial searches, namely, kNN

queries and window queries (WQs). The contributions of our study are given as follows:

1. We identify certain characteristics of LBSQs that enable the development of

effective sharing methods in broadcast environments.

2. We introduce a set of algorithms that verify whether data received from

neighboring clients are complete, partial, or irrelevant answers to the posed query.

3. We utilize a P2P-based sharing method to improve the current approaches in

answering on-air kNN queries and WQs.

4. We evaluate our approach through a probabilistic analysis of the hit ratio in

sharing. In addition, through extensive simulation experiments, we evaluate the

benefits of our approach with different parameter sets.

1.1 Scope of the Project

The scope of the project is to reduce the latency considerably in answering

LBSQs. Our approach is based on peer-to-peer sharing, which enables us to process

queries without delay at a mobile host by using query results cached in its neighboring

mobile peers.

1.2 Existing System

• Existing techniques cannot be used effectively in a wireless broadcast

environment, where only sequential data access is supported.

• It may not scale to very large user populations.

• In an existing system to communicate with the server, a client must most

likely use a fee-based cellular-type network to achieve a reasonable

operating range.

• Third, users must reveal their current location and send it to the server,

which may be undesirable for privacy reasons



1.3 Proposed System

• This System is a novel approach for reducing the spatial query access latency

by leveraging results from nearby peers in wireless broadcast environments.

• Our scheme allows a mobile client to locally verify whether candidate objects

received from peers are indeed part of its own spatial query result set.

• The method exhibits great scalability: the higher the mobile peer density, the

more the queries answered by peers.

• The query access latency can be decreased with the increase in clients.



CHAPTER – 2

SYSTEM ANALYSIS

2.1 Wireless Data Broadcast

In general, there are two approaches for mobile data access. One is the on-

demand access model, and the other is the wireless broadcast model. For the on-demand

access model, point-to-point connections are established between the server and the

mobile clients, and the server processes queries that the clients submit on demand. For the

wireless broadcast model, the server repeatedly broadcasts all the information in wireless

channels, and the clients are responsible for filtering the information. An example of such

a system is the Microsoft Direct Band Network. The advantage of the broadcast model

over the on-demand model is that it is a scalable approach. However, the broadcast model

has large latency, as clients have to wait for the information that they need in a

broadcasting cycle. If a client misses the packets that it needs, it has to wait for the next

broadcast cycle.

To facilitate information retrieval on wireless broadcast channels, the

server usually transmits an index structure, along with data objects. A well-known

broadcast index structure is the (1, m) indexing allocation method [15]. As we can see in

Fig. 2, the whole index is broadcast preceding every 1=m fraction of the data file.

Because the index is available m times in one cycle, it allows a mobile client easy access

to the index so that it can predict the arrival time of its desired data in a timely manner,

and once it knows the

arrival time, it only needs to tune into the broadcast channel when the data bucket arrives.

This mechanism is important for battery-based devices.



Thus, the general access protocol for retrieving data on a wireless

broadcast channel involves three main steps [15]:

The initial probe

A client tunes in to the broadcast channel and determines when the next

index segment will be broadcast.

Index search

The client accesses a sequence of pointers in the index segment to figure

out when to tune in to the broadcast channel to retrieve the required data.

Data retrieval

The client tunes in to the channel when packets containing the required

data arrive and then downloads all the required information.

Two parameters, access latency and tuning time, characterize the broadcast

model. The access latency represents the time duration from the point that a client

requests its data to the point that the desired data is received. The tuning time is the

amount of time spent by a client listening to the broadcast channel, which proportionally

represents the power consumption of the client.

However, nearly all the existing spatial access methods are designed for

databases with random access disks. These existing techniques cannot be used effectively

in a wireless broadcast environment, where only sequential data access is supported.

Zheng et al. [31] proposed indexing the spatial data on the server by a space-filling curve.

The Hilbert curve [16] was chosen for this purpose because of its superior locality. The

index values of the data packets represent the order in which these data packets are

broadcast. For example, the Hilbert curve in Fig. 3 tries grouping data of close values so

that they can be accessed within a short interval when they are broadcast sequentially.

The MHs use on-air search algorithms [31] to answer LBSQs (kNN and WQs) over data

that arrives in the order prescribed by the Hilbert curve.



2.2 Spatial Queries

We focus on two common types of spatial queries, namely, k NN queries

and WQs. With R-tree-based [10] spatial indices, depth-first search (DFS) [25] and best

first search (BFS) [13] have been the prevalent branch-and-bound techniques for

processing NN queries. The DFS method recursively expands the index nodes for

searching NN candidates. At each newly visited non leaf node, DFS computes the

ordering metrics for all its child nodes and applies pruning strategies to remove

unnecessary branches. When a leaf node is reached, the data objects are retrieved, and the

NN candidates are updated. Comparatively, the BFS technique utilizes a priority queue to

store nodes to be explored through the search process. The nodes in the queue are sorted

according to their minimum distance (MINDIST) to the query point. During the search

process, BFS repeatedly de queues the top entry in the queue and enquires its child nodes

with their MINDIST into the queue. When a data entry is de queued, it is inserted into the

result set.

2.3 Cooperative Caching

Caching is a key technique to improve data retrieval performance in

widely distributed environments [14], [21], [22]. Hara and Madria proposed three data

replica allocation methods in ad hoc networks by considering the access frequency from

MHs to each data item and the status of the network connection [12]. With the increasing

deployment of new P2P wireless communication technologies (for example, IEEE

802.11b/g and Bluetooth), P2P cooperative caching becomes an effective sharing

alternative [6], [11], [28]. With this technique, MHs communicate with neighboring peers

in an ad hoc manner for information sharing instead of relying solely on the

communication between remote information sources. Yin and Cao [28] proposed three



schemes, that is, CachePath, CacheData, and HybridCache, for cooperative caching in ad

hoc networks. With CachePath, mobile nodes cache the data path and use it to redirect

prospective requests to a neighboring node, which has the data instead of fetching data

from the remote data center. With CacheData, intermediate nodes cache the data to serve

prospective queries. The HybridCache approach further improves performance by taking

advantage of both CacheData and CachePath while avoiding their weaknesses. P2P

cooperative caching can bring about several distinctive benefits to a mobile system:

improved access latency, reduced server workload, and alleviated point-to- point channel

congestion. In this research, we leverage the P2P caching technique to alleviate the

inherent access latency limitation in wireless broadcast environments.

2.4 FEASIBILITY STUDY

Feasibility study is an important phase in the software development

process. It enables the developer to have an assessment of the product being developed.

It refers to the feasibility study of the product in terms of outcomes of the product,

operational use and technical support required for implementing it.

Feasibility study should be performed on the basis of various criteria and

parameters. The various feasibility studies are:

Economic Feasibility

Operational Feasibility

Technical Feasibility

ECONOMIC FEASIBILITY

It refers to the benefits or outcomes we are deriving from the product as

compared to the total cost we are spending for developing the product. If the benefits are

more or less the same as the older system, then it is not feasible to develop the product.

OPERATIONAL FEASIBILITY

It refers to the feasibility of the product to be operational. Some products

may work very well at design and implementation but may fail in the real time



environment. It includes the study of additional human resource required and their

technical expertise.

TECHNICAL FEASIBILITY

It refers to whether the software that is available in the market fully

supports the present application. It studies the pros and cons of using particular software

for the development and its feasibility. It also studies the additional training needed to be

given to the people to make the application work.

2.5 SYSTEM REQUIREMENTS

HARDWARE REQUIREMENTS:

Processor : Pentium-IV

Speed : 1.1GHz

RAM : 512MB

Hard Disk : 40GB

General : Key Board, Monitor, Mouse

SOFTWARE REQUIREMENTS:

Operating System : Windows XP

Software : JAVA (JDK 1.6.0)

Back End : Oracle



CHAPTER - 3

SYSTEM DESIGN

3.1 Data Flow Diagram

A data flow diagram is graphical tool used to describe and analyze

movement of data through a system. These are the central tool and the basis from which

the other components are developed. The transformation of data from input to output,

through processed, may be described logically and independently of physical components

associated with the system. These are known as the logical data flow diagrams. The

physical data flow diagrams show the actual implements and movement of data between

people, departments and workstations. A full description of a system actually consists of

a set of data flow diagrams. Using two familiar notations Yourdon, Gane and Sarson

notation develops the data flow diagrams. Each component in a DFD is labeled with a

descriptive name. Process is further identified with a number that will be used for

identification purpose.

The development of DFD’s is done in several levels. Each process in

lower level diagrams can be broken down into a more detailed DFD in the next level.

The lop-level diagram is often called context diagram. It consists a single process bit,

which plays vital role in studying the current system. The process in the context level

diagram is exploded into other process at the first level DFD. . The transformation of

data from input to output, through processed, may be described logically and

independently of physical components associated with the system. These are known as

the logical data flow diagrams. The physical data flow diagrams show the actual

implements and movement of data between people, departments and workstations.The



idea behind the explosion of a process into more process is that understanding at one level

of detail is exploded into greater detail at the next level. This is done until further

explosion is necessary and an adequate amount of detail is described for analyst to

understand the process.

Larry Constantine first developed the DFD as a way of expressing system

requirements in a graphical from, this lead to the modular design.

A DFD is also known as a “bubble Chart” has the purpose of clarifying

system requirements and identifying major transformations that will become programs in

system design. So it is the starting point of the design to the lowest level of detail. A

DFD consists of a series of bubbles joined by data flows in the system.

Data Flow Symbols:

In the DFD, there are four symbols A square defines a source(originator) or destination of system data

An arrow identifies data flow. It is the pipeline through which the

information flows

A circle or a bubble represents a process that transforms incoming data

flow into outgoing data flows.

An open rectangle is a data store, data at rest or a temporary repository of

data.

Process that transforms data flow.

Source or Destination of data

Data flow



Data store

Constructing D F D:

Several rules of thumb are used in drawing DFD’s: Process should be named and numbered for an easy reference. Each name should

be representative of the process.

The direction of flow is from top to bottom and from left to right. Data

traditionally flow from source to the destination although they may flow back to

the source. One way to indicate this is to draw long flow line back to a source.

An alternative is to repeat the source symbol as a destination. Since it is used

more than once in the DFD it is marked with a short diagonal.

The names of data stores and destinations are written in capital letters. Process and

dataflow names have the first letter of each work capitalized. A DFD typically

shows the minimum contents of data store. Each data store should contain all the

data elements that flow in and out.

Questionnaires should contain all the data elements that flow in and out. Missing

interfaces redundancies and like is then accounted for often through interviews.

Salient Features D F D:

The DFD shows flow of data, not of control loops and decision are controlled

considerations do not appear on a DFD.

The DFD does not indicate the time factor involved in any process whether the

data flows take place daily, weekly, monthly or yearly.



The sequence of events is not brought out on the DFD.

Types of D F D:

1. Current Physical

2. Current Logical

3. New Logical

4. New Physical

Fig: 3.1 NH-MOBILES HOST

Technique used or algorithm used

Peer to Peer Communication technique

Nearest Neighbor Verification Method

Sharing Based Nearest Neighbor

Sharing Based Window Query

Advantages

Maintaining high scalability and accuracy.


Centralized Server

MH1 MH

2

MH3

MH4


Reducing the latency while processing query to neighboring peers.

Applications

Now a day this is used in mobile search application to get the approximate

result in short time instead of getting accurate results in long time. SDLC

METHDOLOGIES:

This document play a vital role in the development of life cycle (SDLC) as

it describes the complete requirement of the system. It means for use by developers and

will be the basic during testing phase. Any changes made to the requirements in the

future will have to go through formal change approval process.

SPIRAL MODEL was defined by Barry Boehm in his 1988 article, “A

spiral Model of Software Development and Enhancement. This model was not the first

model to discuss iterative development, but it was the first model to explain why the

iteration models.

As originally envisioned, the iterations were typically 6 months to 2 years

long. Each phase starts with a design goal and ends with a client reviewing the progress

thus far. Analysis and engineering efforts are applied at each phase of the project, with

an eye toward the end goal of the project.

The steps for Spiral Model can be generalized as follows:

The new system requirements are defined in as much details as possible. This

usually involves interviewing a number of users representing all the external

or internal users and other aspects of the existing system.

A preliminary design is created for the new system.

A first prototype of the new system is constructed from the preliminary

design. This is usually a scaled-down system, and represents an approximation



of the characteristics of the final product.

A second prototype is evolved by a fourfold procedure:

1. Evaluating the first prototype in terms of its strengths, weakness, and

risks.

2. Defining the requirements of the second prototype.

3. Planning an designing the second prototype.

4. Constructing and testing the second prototype.

At the customer option, the entire project can be aborted if the risk is deemed

too great. Risk factors might involve development cost overruns, operating-

cost miscalculation, or any other factor that could, in the customer’s judgment,

result in a less-than-satisfactory final product.

The existing prototype is evaluated in the same manner as was the previous

prototype, and if necessary, another prototype is developed from it according

to the fourfold procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined

prototype represents the final product desired.

The final system is constructed, based on the refined prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is

carried on a continuing basis to prevent large scale failures and to minimize

down time.



The following diagram shows how a spiral model acts like:

Fig 3.1.1 -Spiral Model

ADVANTAGES:

Estimates(i.e. budget, schedule etc .) become more realistic as work

progresses, because important issues discover earlier.

It is more able to cope with the changes that are software development

generally entails.

Software engineers can get their hands in and start working on the core of a

project earlier.



3.2 MODULES

Multiple peer simulation Module

Server Module

Sharing-based nearest neighbor query visualization Module

Module Description

Multiple peer simulation Module

The multiple peer simulation modules concurrently models a predefined

number of mobile hosts. It implements all the functionality of a single mobile host and

provides the communication facilities among peers and from peers to remote spatial

database servers.

Server Module

The server module is responsible for storing points of interest indexed by

an R-tree structure. It performs NN queries from peers with pruning bounds and records

the I/O load and access frequency of the spatial database server.

Sharing-based nearest neighbor query

Visualization Module

The sharing-based nearest neighbor query visualization Module provides a

rendering of the verification process of a sharing-based NN query in a step-by-step

manner. Users can arbitrarily select a mobile host and launch a location-based NN query

within the simulation region.

In module given input and expected output



The Query location and preferred criteria are the input for Mobile Host.

The Mobile Host gets the results for the corresponding location and criteria, with

considerably reducing latency while getting results from neighboring peers.



Module 1

Fig: 3.2 Finding Neighbor Host

Module 2

Fig: 3.2.1 Interacting with Server


Mobile Host1

Mobile Host 2

Finding nearest

Neighbor

Mobile Host Centralized Server


Module 3

Fig: 3.2.2 Host Connected in the Network

3.3 UML Diagrams:

The Unified Modeling Language (UML) is a standard language for writing

software blueprints. The UML is appropriate for modeling systems ranging from

enterprise information systems to distributed Web-based applications and even to hard

real time embedded systems. It is a very expressive language, addressing all the views

needed to develop and then deploy such systems.

The vocabulary of the UML encompasses three kinds of building blocks

Things

Relationships

Diagrams

Things are the abstractions that are first-class citizens in a model, Relationships tie

these things together, and diagrams group interesting collections of things.A diagram is

the graphical presentation of a set of elements, most often rendered as a connected graph

of vertices (things) and arcs (relationships). Diagrams project a system from different

angles and perspectives. The UML has nine diagrams, classified into two categories.


MH1

MH2

MH3

Server


Use case Diagram:

A use case diagram shows a set of use cases and actors and their

relationships. Use case diagrams address the static use case view of a system. These

diagrams are especially important in organizing and modeling the behaviors of a system.

Use case diagrams commonly contain

Use cases

Actors

Dependency, generalization and association relationships

Use case:

A use case describes a set of sequences, in which each sequence represents

the interaction of the things outside the system ( its actors) with the system itself. A use

case represents a functional requirement of a system as a whole. A use case involves the

interaction of actors and the system.

Actor:

An actor represents a coherent set of roles that users of use cases play when

interacting with these use cases. Actors can be human or they can be automated systems.


Use case


Dependency:

A dependency is a semantic relationship between two things in which a

change to one thing (the independent thing) may affect the semantics of the other thing

(the dependent thing).

A dependency is rendered as a dashed line, possibly directed.

Generalization:

A generalization is a specialization/generalization relationship in which

objects of the specialized element (the child) are substitutable for objects of the

generalized element (the parent). With this the child shares the structure and the behavior

of the parent

Association:

An association is a structural relationship that describes a set of links, a link

being a connection among objects. Aggregation is a special kind of association,

representing a structural relationship between a whole and its parts.

Graphically Association rendered as a solid line.



USECASE DIAGRAM:

Fig: 3.3 Use Case Diagram for Finding the Nearest Neighbor

CLASS DIAGRAM:



Fig: 3.3.1 Class Diagram for Finding the Nearest NeighborACTIVITY DIAGRAM:

Fig: 3.3.2 Activity Diagram for Finding the Nearest Neighbor

Component Processing Details:



Fig: 3.3.3 Component Diagram for Finding the Nearest Neighbor

CHAPTER - 4

CODING AND IMPLEMENTATION

APPLICATION DEVELOPMENT:

N-TIER APPLICATIONS

N-Tier Applications can easily implement the concepts of Distributed

Application Design and Architecture. The N-Tier Applications provide strategic benefits

to Enterprise Solutions. While 2-tier, client-server can help us create quick and easy

solutions and may be used for Rapid Prototyping, they can easily become a maintenance

and security night mare

The N-tier Applications provide specific advantages that are vital to the business

continuity of the enterprise. Typical features of a real life n-tier may include the

following:

Security

Availability and Scalability

Manageability

Easy Maintenance

Data Abstraction

The above mentioned points are some of the key design goals of a successful n-tier

application that intends to provide a good Business Solution.

DEFINITION:



Simply stated, an n-tier application helps us distribute the overall functionality

into various tiers or layers:

Presentation Layer

Business Rules Layer

Data Access Layer

Database/Data Store

Each layer can be developed independently of the other provided that it adheres to the

standards and communicates with the other layers as per the specifications.

This is the one of the biggest advantages of the n-tier application. Each layer can

potentially treat the other layer as a ‘Block-Box’.

In other words, each layer does not care how other layer processes the data as long as it

sends the right data in a correct format.

Fig 4.1-N-Tier Architecture

1. THE PRESENTATION LAYER

Also called as the client layer comprises of components that are dedicated

to presenting the data to the user. For example: Windows/Web Forms and buttons,

edit boxes, Text boxes, labels, grids, etc.

2. THE BUSINESS RULES LAYER



This layer encapsulates the Business rules or the business logic of the

encapsulations. To have a separate layer for business logic is of a great advantage.

This is because any changes in Business Rules can be easily handled in this layer.

As long as the interface between the layers remains the same, any changes to the

functionality/processing logic in this layer can be made without impacting the

others. A lot of client-server apps failed to implement successfully as changing the

business logic was a painful process.

1. THE DATA ACCESS LAYER

This layer comprises of components that help in accessing the Database. If

used in the right way, this layer provides a level of abstraction for the database

structures. Simply put changes made to the database, tables, etc do not affect the

rest of the application because of the Data Access layer. The different application

layers send the data requests to this layer and receive the response from this layer.

2. THE DATABASE LAYER

This layer comprises of the Database Components such as DB Files,

Tables, Views, etc. The Actual database could be created using SQL Server,

Oracle, Flatfiles, etc. In an n-tier application, the entire application can be

implemented in such a way that it is independent of the actual Database. For

instance, you could change the Database Location with minimal changes to Data

Access Layer. The rest of the Application should remain unaffected.



Software Environment:

Java Technology

Java technology is both a programming language and a platform.

The Java Programming Language

The Java programming language is a high-level language that can be

characterized by all of the following buzzwords:

Simple

Architecture neutral

Object oriented

Portable

Distributed

High performance

Multithreaded

Robust

Dynamic

Secure

With most programming languages, you either compile or interpret a

program so that you can run it on your computer. The Java programming language is

unusual in that a program is both compiled and interpreted. With the compiler, first you

translate a program into an intermediate language called Java byte codes —the platform-

independent codes interpreted by the interpreter on the Java platform. The interpreter

parses and runs each Java byte code instruction on the computer. Compilation happens

just once; interpretation occurs each time the program is executed. The following figure

illustrates how this works.



Fig: 4.1.1 Procedure of Program execution

You can think of Java byte codes as the machine code instructions for the

Java Virtual Machine (Java VM). Every Java interpreter, whether it’s a development tool

or a Web browser that can run applets, is an implementation of the Java VM. Java byte

codes help make “write once, run anywhere” possible. You can compile your program

into byte codes on any platform that has a Java compiler. The byte codes can then be run

on any implementation of the Java VM. That means that as long as a computer has a Java

VM, the same program written in the Java programming language can run on Windows

2000, a Solaris workstation, or on an iMac.

The Java Platform

A platform is the hardware or software environment in which a program

runs. We’ve already mentioned some of the most popular platforms like Windows 2000,

Linux, Solaris, and MacOS. Most platforms can be described as a combination of the

operating system and hardware. The Java platform differs from most other platforms in

that it’s a software-only platform that runs on top of other hardware-based platforms.

The Java platform has two components:

The Java Virtual Machine (Java VM)

The Java Application Programming Interface (Java API)



You’ve already been introduced to the Java VM. It’s the base for the Java

platform and is ported onto various hardware-based platforms. The Java API is a large

collection of ready-made software components that provide many useful capabilities,

such as graphical user interface (GUI) widgets. The Java API is grouped into libraries of

related classes and interfaces; these libraries are known as packages. The next section,

What Can Java Technology Do? Highlights what functionality some of the packages in

the Java API provide. The following figure depicts a program that’s running on the Java

platform. As the figure shows, the Java API and the virtual machine insulate the program

from the hardware.

Fig: 4.1.2 Java API and the virtual machine insulate the program from the

hardware.

Native code is code that after you compile it, the compiled code runs on a

specific hardware platform. As a platform-independent environment, the Java platform

can be a bit slower than native code. However, smart compilers, well-tuned interpreters,

and just-in-time byte code compilers can bring performance close to that of native code

without threatening portability.

What Can Java Technology Do?

The most common types of programs written in the Java programming

language are applets and applications. If you’ve surfed the Web, you’re probably already

familiar with applets. An applet is a program that adheres to certain conventions that

allow it to run within a Java-enabled browser.



However, the Java programming language is not just for writing cute,

entertaining applets for the Web. The general-purpose, high-level Java programming

language is also a powerful software platform. Using the generous API, you can write

many types of programs. An application is a standalone program that runs directly on the

Java platform. A special kind of application known as a server serves and supports clients

on a network. Examples of servers are Web servers, proxy servers, mail servers, and print

servers. Another specialized program is a servlet. A servlet can almost be thought of as an

applet that runs on the server side. Java Servlets are a popular choice for building

interactive web applications, replacing the use of CGI scripts. Servlets are similar to

applets in that they are runtime extensions of applications. Instead of working in

browsers, though, servlets run within Java Web servers, configuring or tailoring the

server.

How does the API support all these kinds of programs? It does so with

packages of software components that provides a wide range of functionality. Every full

implementation of the Java platform gives you the following features:

The essentials: Objects, strings, threads, numbers, input and output, data

structures, system properties, date and time, and so on.

Applets: The set of conventions used by applets.

Networking: URLs, TCP (Transmission Control Protocol), UDP (User

Data gram Protocol) sockets, and IP (Internet Protocol) addresses.

Internationalization: Help for writing programs that can be localized for

users worldwide. Programs can automatically adapt to specific locales and

be displayed in the appropriate language.

Security: Both low level and high level, including electronic signatures,

public and private key management, access control, and certificates.

Software components: Known as JavaBeans TM, can plug into existing

component architectures.



Object Serialization: Allows light persistence and communication via

Remote Method Invocation (RMI).

Java Database Connectivity (JDBCTM): Provides uniform access to a

wide range of relational databases.

The Java platform also has APIs for 2D and 3D graphics, accessibility,

servers, collaboration, telephony, speech, animation, and more. The following figure

depicts what is included in the Java 2 SDK.

Fig: 4.1.3 Structure of Java 2 SDK

How Will Java Technology Change My Life?

We can’t promise you fame, fortune, or even a job if you learn the Java

programming language. Still, it is likely to make your programs better and requires less

effort than other languages. We believe that Java technology will help you do the

following:

Get started quickly: Although the Java programming language is a

powerful object-oriented language, it’s easy to learn, especially for

programmers already familiar with C or C++.



Write less code: Comparisons of program metrics (class counts, method

counts, and so on) suggest that a program written in the Java programming

language can be four times smaller than the same program in C++.

Write better code: The Java programming language encourages good

coding practices, and its garbage collection helps you avoid memory leaks.

Its object orientation, its JavaBeans component architecture, and its wide-

ranging, easily extendible API let you reuse other people’s tested code and

introduce fewer bugs.

Develop programs more quickly: Your development time may be as

much as twice as fast versus writing the same program in C++. Why? You

write fewer lines of code and it is a simpler programming language than

C++.

Avoid platform dependencies with 100% Pure Java: You can keep your

program portable by avoiding the use of libraries written in other

languages. The 100% Pure JavaTM Product Certification Program has a

repository of historical process manuals, white papers, brochures, and

similar materials online.

Write once, run anywhere: Because 100% Pure Java programs are

compiled into machine-independent byte codes, they run consistently on

any Java platform.

Distribute software more easily: You can upgrade applets easily from a

central server. Applets take advantage of the feature of allowing new

classes to be loaded “on the fly,” without recompiling the entire program.

ODBC

Microsoft Open Database Connectivity (ODBC) is a standard

programming interface for application developers and database systems providers. Before

ODBC became a de facto standard for Windows programs to interface with database

systems, programmers had to use proprietary languages for each database they wanted to



connect to. Now, ODBC has made the choice of the database system almost irrelevant

from a coding perspective, which is as it should be. Application developers have much

more important things to worry about than the syntax that is needed to port their program

from one database to another when business needs suddenly change.

Through the ODBC Administrator in Control Panel, you can specify the

particular database that is associated with a data source that an ODBC application

program is written to use. Think of an ODBC data source as a door with a name on it.

Each door will lead you to a particular database. For example, the data source named

Sales Figures might be a SQL Server database, whereas the Accounts Payable data source

could refer to an Access database. The physical database referred to by a data source can

reside anywhere on the LAN.

The ODBC system files are not installed on your system by Windows 95.

Rather, they are installed when you setup a separate database application, such as SQL

Server Client or Visual Basic 4.0. When the ODBC icon is installed in Control Panel, it

uses a file called ODBCINST.DLL. It is also possible to administer your ODBC data

sources through a stand-alone program called ODBCADM.EXE. There is a 16-bit and a

32-bit version of this program and each maintains a separate list of ODBC data sources.

From a programming perspective, the beauty of ODBC is that the

application can be written to use the same set of function calls to interface with any data

source, regardless of the database vendor. The source code of the application doesn’t

change whether it talks to Oracle or SQL Server. We only mention these two as an

example. There are ODBC drivers available for several dozen popular database systems.

Even Excel spreadsheets and plain text files can be turned into data sources. The

operating system uses the Registry information written by ODBC Administrator to

determine which low-level ODBC drivers are needed to talk to the data source (such as

the interface to Oracle or SQL Server). The loading of the ODBC drivers is transparent to

the ODBC application program. In a client/server environment, the ODBC API even

handles many of the network issues for the application programmer.

The advantages of this scheme are so numerous that you are probably

thinking there must be some catch. The only disadvantage of ODBC is that it isn’t as



efficient as talking directly to the native database interface. ODBC has had many

detractors make the charge that it is too slow. Microsoft has always claimed that the

critical factor in performance is the quality of the driver software that is used. In our

humble opinion, this is true. The availability of good ODBC drivers has improved a great

deal recently. And anyway, the criticism about performance is somewhat analogous to

those who said that compilers would never match the speed of pure assembly language.

Maybe not, but the compiler (or ODBC) gives you the opportunity to write cleaner

programs, which means you finish sooner. Meanwhile, computers get faster every year.

JDBC

In an effort to set an independent database standard API for Java; Sun

Microsystems developed Java Database Connectivity, or JDBC. JDBC offers a generic

SQL database access mechanism that provides a consistent interface to a variety of

RDBMSs. This consistent interface is achieved through the use of “plug-in” database

connectivity modules, or drivers. If a database vendor wishes to have JDBC support, he

or she must provide the driver for each platform that the database and Java run on.

To gain a wider acceptance of JDBC, Sun based JDBC’s framework on

ODBC. As you discovered earlier in this chapter, ODBC has widespread support on a

variety of platforms. Basing JDBC on ODBC will allow vendors to bring JDBC drivers to

market much faster than developing a completely new connectivity solution.

JDBC was announced in March of 1996. It was released for a 90 day

public review that ended June 8, 1996. Because of user input, the final JDBC v1.0

specification was released soon after. The remainder of this section will cover enough

information about JDBC for you to know what it is about and how to use it effectively.

This is by no means a complete overview of JDBC. That would fill an entire book.

JDBC Goals

Few software packages are designed without goals in mind. JDBC is one

that, because of its many goals, drove the development of the API. These goals, in



conjunction with early reviewer feedback, have finalized the JDBC class library into a

solid framework for building database applications in Java.

The goals that were set for JDBC are important. They will give you some

insight as to why certain classes and functionalities behave the way they do. The eight

design goals for JDBC are as follows:

1. SQL Level API

The designers felt that their main goal was to define a SQL interface for

Java. Although not the lowest database interface level possible, it is at a low enough

level for higher-level tools and APIs to be created. Conversely, it is at a high enough

level for application programmers to use it confidently. Attaining this goal allows for

future tool vendors to “generate” JDBC code and to hide many of JDBC’s

complexities from the end user.

2. SQL Conformance

SQL syntax varies as you move from database vendor to database vendor.

In an effort to support a wide variety of vendors, JDBC will allow any query

statement to be passed through it to the underlying database driver. This allows the

connectivity module to handle non-standard functionality in a manner that is suitable

for its users.

3. JDBC must be implemental on top of common database interfaces

The JDBC SQL API must “sit” on top of other common SQL level APIs.

This goal allows JDBC to use existing ODBC level drivers by the use of a software

interface. This interface would translate JDBC calls to ODBC and vice versa.



4. Provide a Java interface that is consistent with the rest of the Java

system

Because of Java’s acceptance in the user community thus far, the designers

feel that they should not stray from the current design of the core Java system.

5. Keep it simple

This goal probably appears in all software design goal listings. JDBC is no

exception. Sun felt that the design of JDBC should be very simple, allowing for only

one method of completing a task per mechanism. Allowing duplicate functionality

only serves to confuse the users of the API.

6. Use strong, static typing wherever possible

Strong typing allows for more error checking to be done at compile time;

also, less error appear at runtime.

7. Keep the common cases simple

Because more often than not, the usual SQL calls used by the programmer

are simple SELECT’s, INSERT’s, DELETE’s and UPDATE’s, these queries should

be simple to perform with JDBC. However, more complex SQL statements should

also be possible. Finally we decided to proceed the implementation using Java

Networking. And for dynamically updating the cache table we go for MS Access

database.

Java has two things: a programming language and a platform.



Java is a high-level programming language that is all of the following

Simple Architecture-neutral

Object-oriented Portable

Distributed High-performance

Interpreted multithreaded

Robust Dynamic

Secure

Java is also unusual in that each Java program is both compiled

and interpreted. With a compile you translate a Java program into an

intermediate language called Java byte codes the platform-independent code

instruction is passed and run on the computer.

Compilation happens just once; interpretation occurs each time

the program is executed. The figure illustrates how this works.

You can think of Java byte codes as the machine code

instructions for the Java Virtual Machine (Java VM). Every Java interpreter,

whether it’s a Java development tool or a Web browser that can run Java

applets, is an implementation of the Java VM. The Java VM can also be

implemented in hardware.


Java Program

Compilers

Interpreter

My Program


Java byte codes help make “write once, run anywhere” possible.

You can compile your Java program into byte codes on my platform that has a

Java compiler. The byte codes can then be run any implementation of the Java

VM. For example, the same Java program can run Windows NT, Solaris, and

Macintosh.

Networking

TCP/IP stack

The TCP/IP stack is shorter than the OSI one:

TCP is a connection-oriented protocol; UDP (User Datagram Protocol) is a

connectionless protocol.

IP datagram’s



The IP layer provides a connectionless and unreliable delivery system. It

considers each datagram independently of the others. Any association between datagram

must be supplied by the higher layers. The IP layer supplies a checksum that includes its

own header. The header includes the source and destination addresses. The IP layer

handles routing through an Internet. It is also responsible for breaking up large datagram

into smaller ones for transmission and reassembling them at the other end.

UDP

UDP is also connectionless and unreliable. What it adds to IP is a

checksum for the contents of the datagram and port numbers. These are used to give a

client/server model - see later.

TCP

TCP supplies logic to give a reliable connection-oriented protocol above

IP. It provides a virtual circuit that two processes can use to communicate.

Internet addresses

In order to use a service, you must be able to find it. The Internet uses an

address scheme for machines so that they can be located. The address is a 32 bit integer

which gives the IP address. This encodes a network ID and more addressing. The network

ID falls into various classes according to the size of the network address.

Network address

Class A uses 8 bits for the network address with 24 bits left over for other

addressing. Class B uses 16 bit network addressing. Class C uses 24 bit network

addressing and class D uses all 32.

Subnet address

Internally, the UNIX network is divided into sub networks. Building 11 is

currently on one sub network and uses 10-bit addressing, allowing 1024 different hosts.

Host address



8 bits are finally used for host addresses within our subnet. This places a

limit of 256 machines that can be on the subnet.

Total address

The 32 bit address is usually written as 4 integers separated by dots.

Port addresses

A service exists on a host, and is identified by its port. This is a 16 bit

number. To send a message to a server, you send it to the port for that service of the host

that it is running on. This is not location transparency! Certain of these ports are "well

known".

Sockets

A socket is a data structure maintained by the system to handle network

connections. A socket is created using the call socket. It returns an integer that is like a

file descriptor. In fact, under Windows, this handle can be used with Read File and Write

File functions.

#include <sys/types.h>

#include <sys/socket.h>

int socket(int family, int type, int protocol);

Here "family" will be AF_INET for IP communications, protocol will be

zero, and type will depend on whether TCP or UDP is used. Two processes wishing to



communicate over a network create a socket each. These are similar to two ends of a pipe

- but the actual pipe does not yet exist.

JFree Chart

JFreeChart is a free 100% Java chart library that makes it easy for

developers to display professional quality charts in their applications. JFreeChart's

extensive feature set includes:

A consistent and well-documented API, supporting a wide range of chart

types;

A flexible design that is easy to extend, and targets both server-side and

client-side applications;

Support for many output types, including Swing components, image files

(including PNG and JPEG), and vector graphics file formats (including PDF, EPS and

SVG);

JFreeChart is "open source" or, more specifically, free software. It is

distributed under the terms of the GNU Lesser General Public Licence (LGPL), which

permits use in proprietary applications.

1. Map Visualizations

Charts showing values that relate to geographical areas. Some examples

include: (a) population density in each state of the United States, (b) income per capita for

each country in Europe, (c) life expectancy in each country of the world. The tasks in this

project include:

Sourcing freely redistributable vector outlines for the countries of the

world, states/provinces in particular countries (USA in particular, but also other areas);

Creating an appropriate dataset interface (plus default implementation), a rendered, and

integrating this with the existing XYPlot class in JFreeChart;

Testing, documenting, testing some more, documenting some more.


http://www.gnu.org/licenses/lgpl.html

http://www.gnu.org/philosophy/free-sw.html


2. Time Series Chart Interactivity

Implement a new (to JFreeChart) feature for interactive time series charts

--- to display a separate control that shows a small version of ALL the time series data,

with a sliding "view" rectangle that allows you to select the subset of the time series data

to display in the main chart.

3. Dashboards

There is currently a lot of interest in dashboard displays. Create a flexible

dashboard mechanism that supports a subset of JFreeChart chart types (dials, pies,

thermometers, bars, and lines/time series) that can be delivered easily via both Java Web

Start and an applet.

4. Property Editors

The property editor mechanism in JFreeChart only handles a small subset

of the properties that can be set for charts. Extend (or reimplement) this mechanism to

provide greater end-user control over the appearance of the charts.



CHAPTER - 5

PROJECT TESTING

5.1 TESTING:

Testing is the process of detecting errors. Testing performs a very critical

role for quality assurance and for ensuring the reliability of software. The results of

testing are used later on during maintenance also.

The aim of testing is often to demonstrate that a program works by

showing that it has no errors. The basic purpose of testing phase is to detect the errors that

may be present in the program. Hence one should not start testing with the intent of

showing that a program works, but the intent should be to show that a program doesn’t

work. Testing is the process of executing a program with the intent of finding errors.

Testing Objectives

The main objective of testing is to uncover a host of errors, systematically

and with minimum effort and time. Stating formally, we can say,



Testing is a process of executing a program with the intent of finding an error.

A successful test is one that uncovers an as yet undiscovered error.

A good test case is one that has a high probability of finding error, if it exists.

The tests are inadequate to detect possibly present errors.

Levels of Testing

In order to uncover the errors present in different phases we have the

concept of levels of testing. The basic levels of testing are as shown below…

Client Needs

Requirements

Design

Code

Fig: 5.1 Levels of Testing

5.2 Testing Strategies:


Acceptance Testing

System Testing

Integration Testing

Unit Testing


A strategy for software testing integrates software test case design methods

into a well-planned series of steps that result in the successful construction of software.

5.2.1 Unit Testing

Unit testing focuses verification effort on the smallest unit of software i.e.

the module. Using the detailed design and the process specifications testing is done to

uncover errors within the boundary of the module. All modules must be successful in the

unit test before the start of the integration testing begins.

Unit testing in this project:

In this project each service can be thought of a module. There are so many

modules like Login, New Registration, Change Password, Post Question, Modify Answer

etc. When developing the module as well as finishing the development so that each

module works without any error. The inputs are validated when accepting from the user.

Test Plan:

A number of activities must be performed for testing software. Testing

starts with test plan. Test plan identifies all testing related activities that needed to be

performed along with the schedule and guidelines for testing. The plan also specifies the

level of testing that need to be done, by identifying the different units. For each unit

specifying in the plan first the test cases and reports are produced. These reports are

analyzed.

Test plan is a general document for entire project, which defines the scope,

approach to be taken and the personal responsible for different activities of testing. The

inputs for forming test plans are:

1. Project plan

2. Requirements document

3. System design

5.2.2 White Box Testing



White Box Testing mainly focuses on the internal performance of the

product. Here a part will be taken at a time and tested thoroughly at a statement level to

find the maximum possible errors. Also construct a loop in such a way that the part will

be tested with in a range. That means the part is executed at its boundary values and

within bounds for the purpose of testing.

White Box Testing in this Project: I tested step wise every piece of code, taking care

that every statement in the code is executed at least once. I have generated a list of test

cases, sample data, which is used to check all possible combinations of execution paths

through the code at every module level.

5.2.3 Black Box Testing

This testing method considers a module as a single unit and checks the unit

at interface and communication with other modules rather getting into details at statement

level. Here the module will be treated as a block box that will take some input and

generate output. Output for a given set of input combinations are forwarded to other

modules.

Black Box Testing in this Project:

I tested each and every module by considering each module as a unit. I

have prepared some set of input combinations and checked the outputs for those inputs.

Also I tested whether the communication between one module to other module is

performing well or not.

5.2.4 Integration Testing

After the unit testing we have to perform integration testing. The goal here

is to see if modules can be integrated properly or not. This testing activity can be

considered as testing the design and hence the emphasis on testing module interactions. It

also helps to uncover a set of errors associated with interfacing. Here the input to these

modules will be the unit tested modules.



Integration testing is classifies in two types…

Top-Down Integration Testing.

Bottom-Up Integration Testing.

In Top-Down Integration Testing modules are integrated by moving

downward through the control hierarchy, beginning with the main control module.

In Bottom-Up Integration Testing each sub module is tested separately and then the full

system is tested.

Integration Testing in this project:

In this project integrating all the modules forms the main system. Means I used Bottom-

Up Integration Testing for this project. When integrating all the modules I have checked

whether the integration effects working of any of the services by giving different

combinations of inputs with which the two services run perfectly before Integration.

5.2.5 System Testing

Project testing is an important phase without which the system can’t be

released to the end users. It is aimed at ensuring that all the processes are according to

the specification accurately. System Testing in this project: Here entire ‘system’ has been

tested against requirements of project and it is checked whether all requirements of

project have been satisfied or not.

5.2.6 Alpha Testing

This refers to the system testing that is carried out by the test team with the

organization.

5.2.7 Beta Testing

This refers to the system testing that is performed by a select group of

friendly customers.



5.2.8 Acceptance Testing

Acceptance Test is performed with realistic data of the client to

demonstrate that the software is working satisfactorily. Testing here is focused on

external behavior of the system; the internal logic of program is not emphasized.

Acceptance testing in this project: In this project I have collected some data that was

belongs to the University and tested whether project is working correctly or not.

I conclude that this system is tested using all variety of tests… and found

no errors. Hence the testing process is completed.

CHAPTER - 6

OUTPUT SCREENS

MODULE 1:



MODULE 2 :



CONCLUSION & FUTURE ENHANCEMENTS

This paper presented a novel approach for reducing the spatial query

access latency by leveraging results from nearby peers in wireless broadcast

environments. Significantly, our scheme allows a mobile client to locally verify whether

candidate objects received from peers are indeed part of its own spatial query result set.

The experiment results indicate that our method can reduce the access to the wireless

broadcast channel by a significant amount, for example, up to 80 percent, in a dense

urban area. This is achieved with minimal caching at the peers. By virtue of its P2P

architecture, the method exhibits great scalability: the higher the mobile peer density, the

more the queries answered by peers. Therefore, the query access latency can be markedly

decreased with the increase in clients.



BIBLIOGRAPHY

[1] S. Acharya, R. Alonso, M.J. Franklin, and S.B. Zdonik, “Broadcast Disks: Data

Management for Asymmetric Communications Environments,” Proc. ACM SIGMOD

’95, pp. 199-210, 1995.

[2] D. Barbara´ , “Mobile Computing and Databases: A Survey,” IEEE Trans. Knowledge

and Data Eng., vol. 11, no. 1, pp. 108-117, Jan./Feb. 1999.

[3] N. Beckmann, H.-P. Kriegel, R. Schneider, and B. Seeger, “The R*-Tree: An Efficient

and Robust Access Method for Points and Rectangles,” Proc. ACM SIGMOD ’90, pp.

322-331, 1990.

[4] J. Broch, D.A. Maltz, D.B. Johnson, Y.-C. Hu, and J.G. Jetcheva, “A Performance

Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols,” Proc. ACM

MobiCom ’98, pp. 85-97, 1998.

[5] V. Bychkovsky, B. Hull, A.K. Miu, H. Balakrishnan, and S. Madden, “A

Measurement Study of Vehicular Internet Access Using In Situ Wi-Fi Networks,” Proc.

ACM MobiCom ’06, Sept. 2006.



[6] C.-Y. Chow, H. VA Leong, and A. Chan, “Peer-to-Peer Cooperative Caching in

Mobile Environment,” Proc. 24th IEEE Int’l Conf. Distributed Computing Systems

Workshops (ICDCSW ’04), pp. 528-533, 2004.

[7] C.-Y. Chow, H. Va Leong, and A.T.S. Chan, “Distributed Group- Based Cooperative

Caching in a Mobile Broadcast Environment,” Mobile Data Management, pp. 97-106,

2005.

[8] M. de Berg, M. van Kreveld, M. Overmars, and O. Schwarzkopf, Computational

Geometry Algorithms and Applications, second ed. Springer, 2000.

[9] G. Gaertner and V. Cahill, “Understanding Link Quality in 802.11 Mobile Ad Hoc

Networks,” IEEE Internet Computing, vol. 8, no. 1, pp. 55-60, 2004.

[10] A. Guttman, “R-Trees: A Dynamic Index Structure for Spatial Searching,” Proc.

ACM SIGMOD ’84, pp. 47-57, June 1984.

[11] T. Hara, “Cooperative Caching by Mobile Clients in Push-Based Information

Systems,” Proc. 11th ACM Int’l Conf. Information and Knowledge Management (CIKM

’02), pp. 186-193, 2002.

[12] T. Hara and S.K. Madria, “Data Replication for Improving Data Accessibility in Ad

Hoc Networks,” IEEE Trans. Mobile Computing, vol. 5, no. 11, pp. 1515-1532, Nov.

2006.

[13] G.R. Hjaltason and H. Samet, “Distance Browsing in Spatial Databases,” ACM

Trans. Database Systems, vol. 24, no. 2, pp. 265-318, 1999.


lbsq doc - for merge

Documents