USING PARETO PRINCIPLE TO IMPROVE THE EFFICIENCY FOR SELECTION

OF QoS WEB SERVICES

PROJECT REPORT

Submitted by

AKILA@ACHAYAA.T Register No.: 283475184

SUBIKSHA.R Register No.: 283475144

VASANTHI.K Register No.: 283475161

Under the guidance of

Mr. PREM KUMAR

in partial fulfillment of the requirements for the degree

of

BACHELOR OF TECHNOLOGY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SRI MANAKULA VINAYAYAGAR ENGINEERING COLLEGE

MADAGADIPET, PUDUCHERRY-605107
 NOV-2010

SRI MANAKULA VINAYAGAR ENGINEERING COLLEGE

PONDICHERRY UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

BONAFIDE CERTIFICATE

This is to certify that the project work entitled “USING PARETO PRINCIPLE TO

IMPROVE THE EFFICIENCY FOR SELECTION OF QoS WEB SERVICES” is a

bonafide work done by AKILA@ACHAYAA.T [Register No.: 283475184], SUBIKSHA.R

[Register No.: 283475144], AND VASANTHI.K [Register No.: 283475161] in partial

fulfillment of the requirement, for the award of B.Tech Degree in Computer Science and

Engineering by Pondicherry University during the academic year 2010-2011.

PROJECT GUIDE HEAD OF THE DEPARTMENT

Submitted for the University Examination held on ……………………………..

2
INTERNAL EXAMINER EXTERNAL EXAMINER

ACKNOWLEDGEMENT

We are grateful to our Chairman Mr. N. KESAVAN. He has been a constant source of
inspiration right from the beginning.

We would like to express our faithful and grateful thanks to our Managing Director, Mr.
M. DHANASEKARAN for his support.

We would also like to thank our Vice Chairman Mr. S. V. SUGUMARAN, for providing
us with pleasant learning environment.

We would also like to extend our sincere gratitude and grateful thanks to our Principle,
Dr. V. S. K. VENGATACHALAPATHY for having extended the Research and Development
facilities of the department.

We also sincerely thank our Head of the Department, Mr. K. PREMKUMAR whose
continuous encouragement and sufficient comments enabled us to complete our project.

We are very thankful and grateful to our beloved guide, Mr. M. GANESAN whose great
support in valuable advices, suggestions and tremendous help enabled us in completing the first
phase of our project. He has been a great source of inspiration to us.

We thank all our staff members who have been by our side always and helped us with
our project.

We wish to thank our family members and friends for their constant encouragement,
constructive criticisms and suggestions with regards to this project review.

3
 Last but not the least; we would like to thank the ALMIGHTY for His grace and
blessings over us throughout the project.

ABSTRACT
With the rapid increase of Web Services, we can have a chance to select the best Qos
Web Service. To obtain the best QoS Web Service, a huge amount of computations on all the
candidate Web Services are required to computed. This will lead to less efficiency. To improve
selection performance, we use Pareto Principle to calculate only small part of Web Services

Here the client request for a particular Web Service. The Web Service Provider contains
already registered Web Services. The Web Service Discovery finds all the related Web Service
from the Web Service Provider and returns it to the client as response. By this way there is a
proper interaction.

Input obtained from user/client (Service Requestor). The given input is matched with the
UDDI (Service Discovery). The matched Web Services are retrieved (Service Provider). Here
they are called Semantic Web Services. Reordering based on historical usage is done. First
twenty percent of the Semantic Web Services are obtained. They are termed as Candidate Web
Service. Candidate Web Service obtained are given back to user as response. Here in addition we
make use of the Pareto Principle. By using the Pareto Principle we can obtain the most
frequently used Web Services. Pareto Principle works on the concept of 80/20 rule (i.e) 80 –
number of people, 20 – number of web services in use. The resulting Web Service is obtained
easily by using the Pareto Principle.

4
 TABLE OF CONTENTS
CHAPTER NO TITLE PAGE NO.
1 ABSTRACT 4
2 LIST OF FIGURES 6
3 LIST OF TABLES 7
4 LIST OF ABBREVATION 8
5 USING PARETO PRINCIPLE TO IMPROVE 9

THE EFFICIENCY FOR SELECTION OF QoS

WEB SERVICES

5
 LIST OF FIGURES

FIGURE NO NAME OF THE FIGURE PAGE NO

1 Model of Pareto principle based Qos Web Service selection 10

2 Web Service Working 12
3 Working of the Web Service using Pareto Principle 17
4 The Markup Language Pyramid 19
5 Pareto Principle Example 1 25
6 Pareto Principle Example 2 26

6
 LIST OF TABLES

TABLE NO. NAME OF THE TABLE PAGE NO.

1 Software Requirements for Visual Studio .net 2009 27

7
 LIST OF ABBREVATIONS
XML - eXtensible Markup Language
SOAP - Simple Object Access Protocol
WSDL - Web Services Description Language
UDDI - Universal Description, Discovery and Integration
Qos – Quality of Service
WSP – Web Service Provider
WSC – Web Service Consumer
PQA - Pareto based Qos Authority
IOPE - Inputs Outputs Preconditions and Effects
HTTP – Hypertext Transfer Protocol
TCP/IP – Transmission Control Protocol
RPC – Remote Procedure Call
COM – Component Object Model
CORBA – Common Object Request Broker Architecture
MIME – Multipurpose Internet Mail Extensions

8
 CHAPTER 1
INTRODUCTION
The Web is a distributed, dynamic, and large information repository. It has now evolved
to encompass various information resources accessible worldwide. Organizations across all
spectra have already moved their main operations to the Web, which has brought about a fast
growth of various Web applications. This has dramatically increased the need to build a
fundamental infrastructure for efficient deployment and access of the exponentially growing
plethora of Web applications. The development of enabling technologies for such an
infrastructure is expected to change the business paradigm on the Web. Web services have
become de facto the most significant technological by-product. Simply put, a Web service is a
piece of software application whose interface and binding can be defined, described, and
discovered as XML artifacts. It supports direct interactions with other software agents using
XML-based messages exchanged via Internet-based protocols. Examples of Web services
include online reservation, ticket purchase, stock trading, and auction. Standards are key enablers
of Web services. Major industry players took a lead to set up crucial standards. This has greatly
facilitated the adoption and deployment of Web services. Three key XML-based standards have
been defined to support Web service deployment: SOAP, WSDL, and UDDI. SOAP defines a
communication protocol for Web services. WSDL enables service providers to describe their
applications. UDDI offers a registry service that allows advertisement and discovery of Web
services.

LITERATURE SURVEY
Compared with other models, the model of Pareto principle based Qos Web Service
selection uses Qos database and compute small part of quantity of Qos Web service to improve
performance. In figure 1, Web Service Provider(WSP) publishes Web Services and executes Web
Services; Web Service Consumer (WSC) requests service from registry centers, and consumes the
Qos Web Services; Pareto based Qos Authority(PQA) provides the quantification of Web Service
providers and consumers, and matches up the suitable Qos Web Services; UDDI is registry center
to register Web Services.
Compared with other models, this proposal uses Pareto principle to reduce the amount of
computations for selection of Qos Web Service. In this proposal, the selection of Web Services is
divided into four stages, which is described in detail in the following.
(1) The set of the possible Web Services in UDDI are Matched up according to the keywords of
required Web Service requested by Web Service consumers.
(2) The set of semantic Web Services is decided by matching up the Service Profiles which
describe the properties of a services, such as their functionalities and their set of inputs, outputs,
preconditions and effects (IOPE).
(3) The set of semantic Web Services is reordered according to the numbers of historical usage.
The first 20 percentage of semantic Web Services are chosen as candidate Web Services.
(4) The candidate Web Services are reordered according to Qos quantification formula. As

9
various different kinds of Qos parameters, the parameters should be first changed into the norm
form, and calculated by the formula such as the paper.

Fig1: Model of Pareto principle based Qos Web Service selection

If all the candidate Web Services do not satisfy the Qos requirement of Web Service consumer,
the rest of semantic Web Services are computed according to Qos quantification formula to find
the satisfied Web Services. Finally the Web Service with the first Qos quantification is selected as
the invoked Web Service.

EXISTING SYSTEM
In the existing system there is a major component namely XML web service.

XML Web Service

XML Web services are the fundamental building blocks in the move to distributed computing on
the Internet. Open standards and the focus on communication and collaboration among people
and applications have created an environment where XML Web services are becoming the
platform for application integration. Applications are constructed using multiple XML Web
services from various sources that work together regardless of where they reside or how they
were implemented.

10
There are probably as many definitions of XML Web Service as there are companies building
them, but almost all definitions have these things in common:

• XML Web Services expose useful functionality to Web users through a standard Web
protocol. In most cases, the protocol used is SOAP.
• XML Web services provide a way to describe their interfaces in enough detail to allow a
user to build a client application to talk to them. This description is usually provided in an
XML document called a Web Services Description Language (WSDL) document.
• XML Web services are registered so that potential users can find them easily. This is
done with Universal Discovery Description and Integration (UDDI).

Why XML Web services

One of the primary advantages of the XML Web services architecture is that it allows programs
written in different languages on different platforms to communicate with each other in a
standards-based way. The first difference is that SOAP is significantly less complex than earlier
approaches, so the barrier to entry for a standards-compliant SOAP implementation is
significantly lower. You'll find SOAP implementations from most of the big software
companies, as you would expect, but you will also find many implementations that are built and
maintained by a single developer. The other significant advantage that XML Web services have
over previous efforts is that they work with standard Web protocols—XML, HTTP and TCP/IP.
A significant number of companies already have a Web infrastructure, and people with
knowledge and experience in maintaining it, so again, the cost of entry for XML Web services is
significantly less than previous technologies.

We've defined an XML Web service as a software service exposed on the Web through SOAP,
described with a WSDL file and registered in UDDI.

What with XML Web services

The first XML Web services tended to be information sources that you could easily incorporate
into applications—stock quotes, weather forecasts, sports scores etc. It's easy to imagine a whole
class of applications that could be built to analyze and aggregate the information you care about
and present it to you in a variety of ways; for example, you might have a Microsoft Excel
spreadsheet that summarizes your whole financial picture—stocks, 401K, bank accounts, loans,
etc. If this information is available through XML Web services, Excel can update it
continuously. Some of this information will be free and some might require a subscription to the
service. Most of this information is available now on the Web, but XML Web services will make
programmatic access to it easier and more reliable.

Exposing existing applications as XML Web services will allow users to build new, more
powerful applications that use XML Web services as building blocks. For example, a user might
develop a purchasing application to automatically obtain price information from a variety of
vendors, allow the user to select a vendor, submit the order and then track the shipment until it is
received. The vendor application, in addition to exposing its services on the Web, might in turn

11
use XML Web services to check the customer's credit, charge the customer's account and set up
the shipment with a shipping company.

In the future, some of the most interesting XML Web services will support applications that use
the Web to do things that can't be done today. For example, one of the services that XML Web
Services would make possible is a calendar service. If your dentist and mechanic exposed their
calendars through this XML Web service, you could schedule appointments with them on line or
they could schedule appointments for cleaning and routine maintenance directly in your calendar
if you like. With a little imagination, you can envision hundreds of applications that can be built
once you have the ability to program the Web.

Fig 2: Web Service Working

The existing system of Web services is having three major components namely SOAP, WSDL,
and UDDI.

SOAP

Soap is the communications protocol for XML Web services. While a SOAP implementation
will probably include these things, the SOAP standard doesn't specify them. SOAP is a
specification that defines the XML format for messages—and that's about it for the required

12
parts of the specification. If you have a well-formed XML fragment enclosed in a couple of
SOAP elements, you have a SOAP message.

All Web services use SOAP v1.1, a lightweight XML-based protocol optimized for use in
distributed environments. SOAP v1.1 is designed to provide the necessary infrastructure and
definition to support XML-based Remote Procedure Calls. These optional parts of the
specification are used to implement RPC-style applications where a SOAP message containing a
callable function, and the parameters to pass to the function, is sent from the client, and the
server returns a message with the results of the executed function. Most current implementations
of SOAP support RPC applications because programmers who are used to doing COM or
CORBA applications understand the RPC style. SOAP also supports document style applications
where the SOAP message is just a wrapper around an XML document. Document-style SOAP
applications are very flexible and many new XML Web services take advantage of this flexibility
to build services that would be difficult to implement using RPC.

SOAP v1.1 provides the following:

• An envelope for encapsulating a SOAP message—This envelope might be an HTTP

MIME-encoded message provided to WebLogic Server or another application server via
HTTP, HTTPS, JMS, SMTP, FTP, or in some other way. A SOAP envelope typically
wraps not only the method request, but also its parameters. An example might be a
request to invoke a credit grant along with the user who should get the credit and the
credit limit.
• A set of well-defined data and parameter encoding rules—Because SOAP messages
might be consumed by Web services written in any number of languages, a common set
of data-encoding rules—for example, specifying strings, integers, and the like—is
required. Using the same credit request example, the name might need to be provided as a
string and the credit limit as an integer.
• A set of rules for describing methods—As with data encoding, a predefined method
interface is required to make sure that both the requester and the supplier of information
understand and agree on what a call means. Examples of which could be the actual
method name and argument list are described by the encoding rules.

What About Security?

One of the first questions newcomers to SOAP ask is how does SOAP deal with security. Early
in its development, SOAP was seen as an HTTP-based protocol so the assumption was made that
HTTP security would be adequate for SOAP. After all, there are thousands of Web applications
running today using HTTP security so surely this is adequate for SOAP. For this reason, the
current SOAP standard assumes security is a transport issue and is silent on security issues.

When SOAP expanded to become a more general-purpose protocol running on top of a number
of transports, security became a bigger issue. For example, HTTP provides several ways to
authenticate which user is making a SOAP call, but how does that identity get propagated when
the message is routed from HTTP to an SMTP transport? SOAP was designed as a building-
block protocol, so fortunately, there are already specifications in the works to build on SOAP to

13
provide additional security features for Web services. The WS-Security specification defines a
complete encryption system.

WSDL

WSDL (often pronounced whiz-dull) stands for Web Services Description Language. For our
purposes, we can say that a WSDL file is an XML document that describes a set of SOAP
messages and how the messages are exchanged. In other words, WSDL is to SOAP what IDL is
to CORBA or COM. Since WSDL is XML, it is readable and editable but in most cases, it is
generated and consumed by software.

WSDL is the underpinning of how Web services are described to the outside world. Created by
Microsoft and IBM in 2000, WSDL defines an XML grammar for describing network services
and serves as a recipe for automating the details in application communication. Typically,
WSDL describes a Web service's methods, inputs, and contact mechanism.

To see the value of WSDL, imagine you want to start calling a SOAP method provided by one of
your business partners. You could ask him for some sample SOAP messages and write your
application to produce and consume messages that look like the samples, but this can be error-
prone. For example, you might see a customer ID of 2837 and assume it's an integer when in fact
it's a string. WSDL specifies what a request message must contain and what the response
message will look like in unambiguous notation.

The notation that a WSDL file uses to describe message formats is based on the XML Schema
standard which means it is both programming-language neutral and standards-based which
makes it suitable for describing XML Web services interfaces that are accessible from a wide
variety of platforms and programming languages. In addition to describing message contents,
WSDL defines where the service is available and what communications protocol is used to talk
to the service. This means that the WSDL file defines everything required to write a program to
work with an XML Web service. There are several tools available to read a WSDL file and
generate the code required to communicate with an XML Web service. Some of the most capable
of these tools are in Microsoft Visual Studio® .NET.

Many current SOAP toolkits include tools to generate WSDL files from existing program
interfaces, but there are few tools for writing WSDL directly, and tool support for WSDL isn't as
complete as it should be. It shouldn't be long before tools to author WSDL files, and then
generate proxies and stubs much like COM IDL tools, will be part of most SOAP
implementations. At that point, WSDL will become the preferred way to author SOAP interfaces
for XML Web services.

These are the most important aspects of WSDL:

• The methods provided by a Web service.

• The inputs, outputs, and faults (errors) the defined methods return.
• The mechanism used to contact the service.

14
Web services are defined in terms of the endpoint, or service, that actually acts on or processes
the Web service's request. These endpoints represent the actual methods being implemented and
how they can be called. In reality, there are only two mechanisms for communicating with a Web
service: one-way and bidirectional, depending on who originated the message.

The WSDL specification defines four specific types of requests a Web service can support:

• One-way—In a one-way message, a service receives a message and may or may not act
on it. The client might get nothing back or might receive a result later in some unknown
fashion.
• Request/response—In a request/response message, the service receives a request,
processes it, and returns a response.
• Solicit/response—In a solicit/response message, the end point sends a message and
receives a response.
• Notification—In a notification message, the Web service sends a message.

In fact, the only difference between one-way versus notification messages and request/response
versus solicit/response messages is who generates and sends the message. For example, in a one-
way message, the client makes a request, and the Web service acts on it without returning a
status. In a notification message, the Web service makes a call back to the client without waiting
for a response.

As you shall see shortly, WebLogic Workshop provides mechanisms for quickly and easily
developing Web services that support each request type.

UDDI

UDDI provides a mechanism for Web services developers to publish new and updated Web
services and a mechanism for clients to find and access published Web services. UDDI enables
businesses to publish and advertise the services they offer and describe how these services
should be used.

Web service functionality, as with most service-based functionality, is provided through a

programming interface specified in WSDL. In a publish-and-find scenario, a developer publishes
the existence of a service along with its definition, often referred to as a binding template. In a
picture-printing service, for example, any number of companies could offer a service to print
digital pictures. Binding templates contain one or more instances of a tModel, which represents
interfaces supported by the service. The tModel might have been uniquely published by the
service provider, with information on the interfaces and URL references to the WSDL document.

Universal Discovery Description and Integration is the yellow pages of Web services. As with
traditional yellow pages, you can search for a company that offers the services you need, read
about the service offered and contact someone for more information. You can, of course, offer a
Web service without registering it in UDDI, just as you can open a business in your basement
and rely on word-of-mouth advertising but if you want to reach a significant market, you need
UDDI so your customers can find you.

15
A UDDI directory entry is an XML file that describes a business and the services it offers. There
are three parts to an entry in the UDDI directory. The "white pages" describe the company
offering the service: name, address, contacts, etc. The "yellow pages" include industrial
categories based on standard taxonomies such as the North American Industry Classification
System and the Standard Industrial Classification. The "green pages" describe the interface to the
service in enough detail for someone to write an application to use the Web service. The way
services are defined is through a UDDI document called a Type Model or tModel. In many cases,
the tModel contains a WSDL file that describes a SOAP interface to an XML Web service, but
the tModel is flexible enough to describe almost any kind of service.

The UDDI directory also includes several ways to search for the services you need to build your
applications. For example, you can search for providers of a service in a specified geographic
location or for business of a specified type. The UDDI directory will then supply information,
contacts, links, and technical data to allow you to evaluate which services meet your
requirements.

UDDI allows you to find businesses you might want to obtain Web services from. What if you
already know whom you want to do business with but you don't know what services are offered?
The WS-Inspection specification allows you to browse through a collection of XML Web
services offered on a specific server to find which ones might meet your needs.

At a minimum, a Web service must publish its business name and service information via
business registry entries. A business registry can contain the following:

• Business identification—Name, description of the business, contact information, and

other descriptive information.
• Categories—Standard categorization information, such as Dun & Bradstreet's Data
Universal Numbering System (DUNS) numbers.
• Service description—Names and descriptions of the service given in the binding template
and custom category definitions given in the tModels, which contain binding information
for accessing the service at runtime to determine who actually implements a service.

UDDI also supports a wide variety of other information about the service, such as compliance
with a set of existing standards, usage details, transaction capabilities, and so forth.

What's Left

So far we've talked about how to talk to XML Web services (SOAP), how XML Web services
are described (WSDL) and how to find XML Web services (UDDI). These constitute a set of
baseline specifications that provide the foundation for application integration and aggregation.
From these baseline specifications, companies are building real solutions and getting real value
from them.

While much work has been done to make XML Web services a reality, more is needed. Today,
people are having success with XML Web services, but there are still things that are left as an
exercise for the developer e.g. security, operational management, transactions, reliable

16
messaging. The Global XML Web Services Architecture will help take XML Web services to
the next level by providing a coherent, general purpose model for adding new advanced
capabilities to XML Web services which is modular and extensible.

WS-Security is one of the specifications in the Global Web Services Architecture. Operational
management needs such as routing messages among many servers and configuring those servers
dynamically for processing are also part of the Global Web Services Architecture, and are met by
the WS-Routing specification and the WS-Referral specification. As the Global Web Services
Architecture grows, specifications for these and other needs will be introduced.

PROPOSED SYSTEM

Fig 3: Working of the Web Service using Pareto Principle

The following are the steps in the determination of best Web Service selection done on basis of
Qos.
• Input obtained from user/client (Service Requestor)
• The given input is matched with the UDDI (Service Discovery)
• The matched Web Services are retrieved (Service Provider)
• Here they are called Semantic Web Services
• Reordering based on historical usage is done
• First twenty percent of the Semantic Web Services are obtained
• They are termed as Candidate Web Service

17
 • Candidate Web Service obtained are given back to user as response
• Here in addition we make use of the Pareto Principle
• By using the Pareto Principle we can obtain the most frequently used Web Services
• Pareto Principle works on the concept of 80/20 rule
(i.e) 80 – number of people
20 – number of web services in use

• The resulting Web Service is obtained easily by using the Pareto Principle

MODULES DESCRIPTION
UDDI
The Universal Description, Discovery, and Integration (UDDI) specification defines a SOAP-
based Web service for locating Web services and programmable resources on a network. UDDI
provides a foundation for developers and administrators to readily share information about
internal services across the enterprise and public services on the Internet.

SEMANTIC WEB SERVICES

The objective of the Semantic Web Architecture is to provide a knowledge representation of

linked data in order to allow machine processing on a global scale. Currently, Web Services that
use the .NET and J2EE frameworks are struggling to expand against the limitations of existing
Web architecture and conflicting proprietary standards. With software vendors battling for any
advantage, Semantic Web Services offer a giant leap forward; the first-time developer can
successfully exploit its latent potential to deliver such applications as semantic search, collective
email and collaborative Web word processing.

Why such a system?

Today, the data available within HyperText Markup Language (HTML) is difficult to manipulate
on a large scale. Just think of information about plane schedules, baseball statistics, and product
purchasing information. While presently available at numerous sites, using this data in its HTML
form is problematic, even is eXtensible Markup Language (XML) is employed. The Semantic
Web offers an easier way to publish data that can be accessed and re-purposed as needed.

Semantic Web Services

For Semantic Web services to become a reality, a markup language must be descriptive enough
that a computer can automatically determine its meaning. The following is a list of tasks such a
language would be required to perform:

18
 • Discovery: A program must first be able to automatically find, or discover, an
appropriate Web service. Neither the Web Service Description Language (WSDL) nor
the Universal Discovery and Description language (UDDI) allows for software to
determine what a Web service offers to the client. A Semantic Web service describes its
properties and capabilities so that software can automatically determine its purpose.
• Invocation: Software must be able automatically to determine how to invoke or execute
the service. For example, if executing the service is a multi-step procedure, the software
needs to know how to interact with the service to complete the necessary sequence. A
Semantic Web service provides a descriptive list of what an agent needs to do to be able
to execute and fulfill the service. This includes defining the inputs and outputs of the
service.
• Composition: Software must be able to select and combine a number of Web services to
complete a certain objective. The services have to interoperate with each other seamlessly
so that the combined results are a valid solution.
• Monitoring: Agent software needs to be able to verify and monitor the service properties
while in operation.

When Web markup languages evolve to the point that they can perform the above tasks,
Semantic Web service can begin to prosper. You may be surprised to learn just how near the
W3C is to meeting these conditions.

Advanced Markup Languages

There are many ways in which the two areas of Web Services and the Semantic Web could
interact to lead to the further development of Semantic Web Services. Berners-Lee has suggested
that both of these technologies would benefit from integration that would combine the Semantic
Web's meaningful content with Web Services' business logic.

Fig 4: The Markup Language Pyramid

Areas such as UDDI and WSDL are ideally suited to be implemented using Semantic Web
technology. In addition, SOAP could use Resource Description Framework (RDF) payloads,

19
remote RDF queries and updates, and interact with Semantic Web business rules engines,
thereby laying the foundation for Semantic Web Services.

The W3C is engaged in building the Pyramid of Web Markup Languages, which starts with
HTML and XML and continues upward to include RDF and the most recent Web Ontology
Language (OWL). The off-spring of OWL is OWL for Services (OWL-S).

However, the technology issues of the Next Generation Web create many problematic questions
that must be solved before the full power and capability of the Semantic Web Services are
available.

Concerns about logic loops, syntax errors and trust-worthy published information remain
formidable problems.

CANDIDATE WEB SERVICE

These are nothing but the Web Services that are used by the users of web in a frequent manner.
The users of the web are termed as candidates here. Hence these Web Services are also known as
Candidate Web Services. Here the Candidate Web Service are dependent on the Semantic Web
Service in practice. The dependency is due to the fact that the Semantic Web Services are
reordered by using the factor of historical usage. This means that the most frequently used Web
Services take up the first position so the order is in the descending order of usage. Once the
ordering is complete the first twenty percentage of the Semantic Web Services are chosen as the
Candidate Web Services.

PARETO PRINCIPLE OR 80/20 RULE:

What It Means
The 80/20 Rule means that in anything a few (20 percent) are vital and many(80 percent) are
trivial. In Pareto's case it meant 20 percent of the people owned 80 percent of the wealth. In
Juran's initial work he identified 20 percent of the defects causing 80 percent of the problems.
Project Managers know that 20 percent of the work (the first 10 percent and the last 10 percent)
consume 80 percent of your time and resources. You can apply the 80/20 Rule to almost
anything, from the science of management to the physical world.
You know 20 percent of your stock takes up 80 percent of your warehouse space and that 80
percent of your stock comes from 20 percent of your suppliers. Also 80 percent of your sales will
come from 20 percent of your sales staff. 20 percent of your staff will cause 80 percent of your
problems, but another 20 percent of your staff will provide 80 percent of your production. It
works both ways.
How It Can Help You
The value of the Pareto Principle for a manager is that it reminds you to focus on the 20 percent
that matters. Of the things you do during your day, only 20 percent really matter. Those 20
percent produce 80 percent of your results. Identify and focus on those things. When the fire
drills of the day begin to sap your time, remind yourself of the 20 percent you need to focus on.

20
If something in the schedule has to slip, if something isn't going to get done, make sure it's not
part of that 20 percent.
There is a management theory floating around at the moment that proposes to interpret Pareto's
Principle in such a way as to produce what is called Superstar Management. The theory's
supporters claim that since 20 percent of your people produce 80 percent of your results you
should focus your limited time on managing only that 20 percent, the superstars. The theory is
flawed, as we are discussing here because it overlooks the fact that 80 percent of your time
should be spent doing what is really important. Helping the good become better is a better use of
your time than helping the great become terrific. Apply the Pareto Principle to all you do, but use
it wisely.
Manage This Issue
Pareto's Principle, the 80/20 Rule, should serve as a daily reminder to focus 80 percent of your
time and energy on the 20 percent of you work that is really important. Don't just "work smart",
work smart on the right things.
Pareto charts are used to graphically display the relative importance of groups or segments of
data. This makes it easier to identify which problems are most important. Typically, the data
groups in a Pareto chart are displayed as a histogram or vertical bar chart, in descending order of
significance.
Pareto Analysis
Setting priorities for action
When faced with a range of issues, it is often difficult to know which to work on first. To resolve
this dilemna, the most useful thing to do is to apply Pareto's rule. This rule says - "eighty percent
of your troubles will come from 20 per cent of your problems". In other words, problems will
rarely have equal impact, so it is best to first concentrate on the most important.
The value of this rule is not that it provides a scientifically accurate estimation of the weightings
which attach to a range of alternatives (which it does not), but simply that it is a reminder to
always look for 'the vital few' issues, and to separate them from 'the trivial many', before
attempting to solve problems. The next step is to identify which particular problems are the most
important. This is done by collecting appropriate data and displaying it in the form of a
histogram with each measured characteristic shown in descending order of magnitude. Such a
histogram is known as a Pareto chart. An example is shown below.
The high value items to the left hand side of the chart are the ones you need to concentrate on
first. Pareto's rule is also known as the 80/20 rule. It was named after Vilfredo Pareto who, in the
late 18th century, studied the distribution of wealth in Europe and found that 80% was held by
20% of the population. A number of well publicised business studies during this century showed
similar 80%/20% relationships, and claimed for example that, "managers spend only 20% of
their time to complete 80% of their work", and "80% of a company's business comes from 20%
of its customers". These studies served to confirm the rule as an accepted part of management
folklore.

21
Use the Rule whenever you need to make a choice
Apply Pareto's rule, and complete a Pareto chart, whenever a choice has to be made between a
number of alternative directions for action. This may be after an analytical exercise has been
completed to uncover the possible sources of a particular problem, or after a brainstorming
session to generate creative ideas to address an issue.
How to use the rule
After an analysis or ideas generating session, you will have a laundry list of items to evaluate. If
the list is a long one (say more than five or six items), try to get it down to a manageable size by
putting to one side any factors you reasonably suspect are of lesser significance. Don't discard
them entirely because without proper measurement you will never know for certain how
significant the factors are. Better just to put them to one side and return to them later if the
selected alternatives don't prove successful. For the remaining factors, decide on the best way to
measure their relative significance and collect the data required. Plot the data on a histogram in
descending order of importance.
Completing the histogram is particularly important if you are working with a team, or need to
communicate the results of the data collection in a report or presentation. If you are working with
a team, the histogram becomes the focal point for discussing the validity of the findings and how
to pursue the issues involved.Listed step-by-step below is an example of the development of a
Pareto chart.
In this case, an analysis session was completed on the reasons why customers experienced undue
delays in delivery of their goods from the time a picking slip is generated in the warehouse. This
session yielded a laundry list of possible causes.

• picking errors

• missing stock

• sent to wrong address

• part-supply refused

• refused at delivery address/no receiving authority

• goods returned/exceeded use-by date

• goods returned/damaged

• goods returned/servicing or preparation not done

• goods mislaid by carrier

• delivery delayed by carrier

• goods returned/damaged in transit

22
To reduce the list to a manageable number of items, some less likely causes were put aside and
others were aggregated to produce the following final list.

• goods returned/incorrect items

• goods returned/defective

• goods returned/wrong address

• goods not found in warehouse

A data collection program was then undertaken to find out how much time was being taken to
correct these problems for the customer, and the results plotted in the histogram shown below.

The Pareto chart shows that the priority problem, the one causing greatest delays to customers, is
incorrect goods being sent.Reducing the incidence of this problem will yield the greatest benefit
to customers. After improvements have been made, another analysis can be made to determine if
the problem has been reduced and confirm that "goods not found in the warehouse" is the next
most important problem to address.

Pareto Chart
Also called: Pareto diagram
Variations: weighted Pareto chart, comparative Pareto charts

23
A Pareto chart is a bar graph. The lengths of the bars represent frequency or cost (time or
money), and are arranged with longest bars on the left and the shortest to the right. In this way
the chart visually depicts which situations are more significant.

• When to Use a Pareto Chart

• When analyzing data about the frequency of problems or causes in a process.

• When there are many problems or causes and you want to focus on the most significant.

• When analyzing broad causes by looking at their specific components.

• When communicating with others about your data.

• Pareto Chart Procedure

• Decide what categories you will use to group items.

• Decide what measurement is appropriate. Common measurements are frequency,

quantity, cost and time.

• Decide what period of time the Pareto chart will cover: One work cycle? One full day? A
week?

• Collect the data, recording the category each time. (Or assemble data that already exist.)

• Subtotal the measurements for each category.

• Determine the appropriate scale for the measurements you have collected. The maximum
value will be the largest subtotal from step 5. (If you will do optional steps 8 and 9 below,
the maximum value will be the sum of all subtotals from step 5.) Mark the scale on the
left side of the chart.

• Construct and label bars for each category. Place the tallest at the far left, then the next
tallest to its right and so on. If there are many categories with small measurements, they
can be grouped as “other.”

• Steps 8 and 9 are optional but are useful for analysis and communication.

• Calculate the percentage for each category: the subtotal for that category divided by the
total for all categories. Draw a right vertical axis and label it with percentages. Be sure
the two scales match: For example, the left measurement that corresponds to one-half
should be exactly opposite 50% on the right scale.

• Calculate and draw cumulative sums: Add the subtotals for the first and second
categories, and place a dot above the second bar indicating that sum. To that sum add the
subtotal for the third category, and place a dot above the third bar for that new sum.
Continue the process for all the bars. Connect the dots, starting at the top of the first bar.
The last dot should reach 100 percent on the right scale.

24
Pareto Chart Examples
Example 1 shows how many customer complaints were received in each of five categories.

Fig 7: Pareto Principle Example 1

Example 2 takes the largest category, “documents,” from Example #1, breaks it down into six
categories of document-related complaints, and shows cumulative values.
If all complaints cause equal distress to the customer, working on eliminating document-related
complaints would have the most impact, and of those, working on quality certificates should be
most fruitful.

25
 Fig 8: Pareto Principle Example 2

SYSTEM REQUIREMENTS
1.HARDWARE SPECIFICATION
Distributed system and open environment a distributed system is a collection of independent
computers that appear to the users of the system as a single computer. And open environment is
defined as an environment where communication and data transfer can occur on remote system.

2.SOFTWARE SPECIFICATION
Visual studio .Net 2009 is the main software requirement which in turn needs some software
requirements as follows

Do you want to Windows XP

Windows Server 2003

Develop ASP Web applications and XML IIS (Internet Information Services)
Web services

26
Compile code related to Microsoft Windows Message Queuing Services
Message Queuing (MSMQ)

Debug code on remote computers Visual Studio Remote Debugger

Use source code control to version stored Visual Studio 6.0 Stored Procedure Versioning
procedures Visual SourceSafe
Microsoft SQL Server

Table 1: Software Requirements for Visual Studio .net 2009

CONCLUSION
Qos plays an important role in Web Service selection in order to evaluate and rank candidate
Web services that are able to provide expected functionality. Similarly to the problem of Web
Service description, there may be various Qos models which are adopted by different service
providers and service requestors for describing Qos information. It is necessary to match
different Qos concepts such as Qos properties, metrices and units which are specified in a Qos
advertisement and a Qos requirement. Semantic technology has been applied in recent works
aiming to provide efficient and compatible method for describing and reasoning about Qos of
different systems. By using the Pareto Principle calculation of only small part of Web Service is
done and its performance is improved thereby.

FUTURE ENHANCEMENTS
The main future enhancement is that the entire process can be done in a real time application and
thereby showing as to how the performance and the efficiency of the Web Service is been
improved.

REFERENCES
[1] YUE Kun, WANG Xiao-Ling, ZHOU Ao-Ying. Underlying Techniques for Web Services: A
Survey. Journal of Software,2004,15(3):428442.
[2] Cardoso.Jorge,Sheth.etal. Quality of service for work ows and web service processes. Web
Semantics Science,Services and Agents on the World Wide Web,2004,1(3):281308.
[3] Anton J,Jacobs L,Liu X.Web caching for database applications with Oracle Web cache.
In:Frank- lin MJ,Moon B,eds.Proceedings of the 2002 ACM SIGMOD International Conference
on Mana- g ement of Data. New York: ACM Press, 2002. 594599.
[4] Kim SM, Rosu MC. A survey of public Web services. In: Feldman SI, uretsky M, Najork M,
Wills CE, eds. Proc. of the 13th Int’l Conf. on World Wide Web (WWW 2004). New York: ACM
Press, 2004. 312-313.
[5] Yang shengli, Shi Meilin. A Model for Web Service Discovery with QoS Constraints. Journal
of Computer, 2005,28(4):589-594.

27
[6] F. John Reh. Pareto’s Principle-The 80-20 Rule.
http://management.about.com/cs/generalmanage-ment/a/Pareto081202.htm. 2007.
[7] GUO De-keREN, YanCHEN Hong-huiXUE, Qun-weiLUO, Xue-shan. A Web Services
Selection and Ranking Model with QoS Constraints. JOURNAL OF SHANGHAI JIAOTONG
UNIVERSITY,2007 41(6):870- 875
[8] UDDI http://www.uddi.org/pubs/uddi v3.htm
[9] Eyhab Al-Masri ,Qusay H. Mahmoud. Discovering the Best Web Service. www2007.
http://www2007.org/posters/poster970.pdf
[10] Eyhab Al-Masri ,Qusay H. Mahmoud. A Framework for Efficient Discovery of Web
Services across Heterogeneous Registries, IEEE Consumer Communication and Networking
Conference (CCNC) 2007.

28