2012 International Conference on Computer Communication and Informatics (ICCCI -2012), Jan.

10 12, 2012, Coimbatore, INDIA

Dynamic Web Services Discovery and Selection Using

QoS-Broker Architecture
1

Pon Harshavardhanan, 2J. Akilandeswari & 2R. Sarathkumar

Dept of CSE, KPR institute of engineering and technology, Coimbatore, India,
2
Dept of IT, Sona College of Technology, Salem, India
1
E-mail : pponharsh@yahoo.co.in, 2akila_rangabashyam@yahoo.com, 2r.sarathkumar@gmail.com
1

Abstract Web Services are the most emerging

distributed applications which can be published and
invoked using standardized protocols over the public
or private registries. Due to rapid development of the
Web, there are numerous functionally similar Web
Services available, which made the selection of the
Web Service based on functional properties is not
reliable. To select the functionally similar Web
Service, the non functional criteria such as Quality of
Service (QoS) will be considered. However, most of the
clients are not experienced enough to acquire the best
selection of Web Service based on its described QoS
properties. In this paper we are proposing QoS-Broker
architecture to find the best Web Service, which will
get Web Service client's query along with QoS
requirements, and then it will use an efficient
mechanism to find the best Web Service.
Keywords- Web Service selection; QoS; QoS-Broker
architecture;distributed application;

I. INTRODUCTION
Web Services (WSs) are modular, self-describing, and
loosely coupled software applications that can be
advertised, located, and used across the Internet using a
set of standards such as SOAP, WSDL, and UDDI [1]. It
can be accessed over the network through the
standardized XML messages. Since we are in the rapid
Web development era, there are number of companies
developed Web Services and made them available to the
Web Service clients by publishing them over the public
Web Service registries. Web Services are can be
accessible either by functional criteria or non-functional
criteria. Since there are many functionally similar Web
Services available, the functional criteria is not an optimal
one for the client to find the best Web Service. The
ultimate solution for this problem is to use the non
functional criteria such as Quality of Service (QoS). By
QoS, we refer to non-functional parameters [9] of Web
Services, some of them are,
Availability: Availability is the quality aspect of whether
the Web Service is present or ready for immediate use.
Accessibility: Accessibility is the quality aspect of a
Service that represents the degree it is capable of serving a

978-1-4577-1583-9/ 12/ $26.00 2012 IEEE

Web Service request.

Integrity: Integrity is the quality aspect of how the Web
Service maintains the correctness of the interaction in
respect to the source.
Performance: Performance is the quality aspect of Web
Service, which is measured in terms of throughput and
latency. Higher throughput and lower latency values
represent the best quality aspect of a web services.
Regulatory: Regulatory is the quality aspect of the WS in
conformance with the rules, the law, compliance with
standard and the established Service level agreement.
Security: Security is the quality aspect of the Web
Service of providing confidentiality and non-repudiation
by authenticating the parties involved, encrypting
messages, and providing access control.
However, most of clients are not experienced enough to
acquire the best selection of Web Service based on its
described QoS characteristics. They simply trust the QoS
information published by the provider; however most of
Web Service providers do not guarantee and assure the
level of QoS offered by their Web Services. Based on the
above we propose a Web Service discovery architecture
that contains an extended UDDI to accommodate the QoS
information, and WS-QoS Broker to facilitate the Web
Service discovery [2].
The broker based selection architecture uses the concept
of middleware (broker) for QoS aware Web Service
publishing and selection mechanisms. The broker is a
critical architectural component of interaction for the
requester and provider towards dynamic Web Service
selection and publishing. The functionality of the broker is
to select the most suitable Web Service for the Requester
that satisfies his QoS constraints and preferences. The
other functionalities of the broker may include QoS
publishing, QoS verification & certification and QoS
management & monitoring.
The rest of the paper is organized as follows, Section 2 we
present the related research on Web Service QoS broker.
Section 3 describes how the Web Service client can send
their requirement to the broker. In section 4 describes the
QoS broker architecture and selection mechanism of the
best Web Service. Section 5 presents the conclusions.

2012 International Conference on Computer Communication and Informatics (ICCCI -2012), Jan. 10 12, 2012, Coimbatore, INDIA

II. RELATED WORK

Kyriakos Kritikos and Dimitris Plexousakis [6], defining
QoS and the role it plays in the management of WSs, after
that an analysis of the requirements for semantic QoSbased WSDD were provided. Additionally, a proposal of
how to produce a semantically enhanced and stand-alone
QoS broker that could be used in a complementary way to
current functional WS registries was given. Last but not
least, the responsibilities of the participating entities in
sight of the envisioned QoS broker were analyzed.
D'Mello D.A, AnanthanarayanaV.S and Santhi.T presents
a A QoS broker based architecture[1] approach to select
the best Web Service where the functionally similar Web
Service will be found by service selector. They are using
the Quality Constrain Tree mechanism (QCT) to compute
the QoS score for functionally similar Web Service using
Min-Max normalization method and find out the best WS.
QoS matching algorithm [2] is presented by T.Rajendran ,
Dr.P.Balasubramanie and Resmi Cherian, used to get the
Web Services which are matching with the requesters
quality constrains. The getServiceQoS method finds the
QoS advertisements of a service in a UDDI registry.
QoSMatchAdvert method finds if the QoS advertisements
of a service satisfies the QoS requirements. QoS Ranking
Algorithm [2] consists of the following methods:
calculateQoSScore calculates QoS scores for the services
that meet the QoS requirements. sortByQoSScore returns
a list of services sorted by the QoS score in descending
order. Quality driven Web Service selection and ranking
[3] handles the situation where we got tie in the Quality
Constrains Tree. D'Mello, D.A, Ananthanarayana
consider service providers quality aspects as the
secondary criterion for selecting the best Web service.
Such as, Reputation of Provider (Rwsp), Conformity of
Provider (Cwsp), Existence Period (Ewsp), Web Service
Provider Size (Swsp). The algorithm [3] uses RWSP of WS1
and WS2 to assign the distinct rank. Since both WS1 and
WS2 have same RWSP, the algorithm uses EWSP for ranking.
In [4] we have Second level class which has a set of Web
Services which are compared to each other based on the
value of two or more WSP of services/providers. The
author use Learning Automata [4] to select the position of
services in the Second Level Classes. All Web Services
sorted based on their QoS scores and if the service remain
in the same rank then it will be rewarded, otherwise it will
get a penalty.
Hai Liu, Weimin Zhang, Kaijun Ren and Zhuxi Zhang
presented a new approach for QoS-aware services
selection in transactional CWS [6]. Two algorithms
proposed were used to formulate a graph model called
actual SCP, which was used to address the problem of
transactional atomicity consistency for CWS. Therefore,
the problem of QoS optimal utilities selection with
transactional constraints was transferred into the problem

of single-source shortest path.

Although there are many mechanisms to find the best web
service, there so such clear method which is used to
identify the target web service when we have tie with best
Web Services is the motivation for this paper.

III. PROPOSED WORK

QoS broker architecture

1. Functional requirements of the client

2. Obtain the discovered Web Services
3. Store the certificates
4. Selected Web Service
Figure.1. QoS broker architecture.
The proposed QoS-Broker architecture which is showed
in Fig.1 comprises three layers. The first layer is the
Interaction layer contains service client as well as the Web
Service provider. The client is probably some business
provider but not a naive user.
Broker layer is containing the Web Service selection
methods and also the Web Service validation [7]
mechanisms which are likely done by some third party
consultants. There two repositories also will be available
that are, local Web Service registry and also the Web
Service usage registry.
The last layer is the Web Service repository, where the
published Web Services and also the validated QoS
parameters given by the service provider.
Web Service request message structure
Web Service requesters suppose to give the functional and
non functional criteria for the target Web Service in a

2012 International Conference on Computer Communication and Informatics (ICCCI -2012), Jan. 10 12, 2012, Coimbatore, INDIA

standardized XML SOAP messages. In that XML

message there must be functional requirement detail and
the non-functional criteria such as the quality measures
for the Web Service also included within that message.
The functional requirement contains the business method
of the target Web Service. For Quality criteria, the client
has to give the name, weight and value; the client may
specify many number of quality criterion along with their
weights. So the broker can understand the exact
requirement for the client and select the best Web Service
for the Web Service client.
Figure.2 is a sample XML SOAP message for a clients
request to obtain the credit card validation Web Service.
In
that XML, the functional requirement tag having the
method required for the client as credit card validation and
the QoS requirement having two constrains such as
maximum price, the client can afford is 0.01 which has
the weight of 2 and the response time as 0.05 which has
the weight as 3. With this message itself client can define
the number of Web Services has to be returned after the
selection of the best matching Web Services. In Figure.2
max number of the requested Web Service is defined is 1.
<?xml version="1.0" encoding="UTF-8" ?>
<envelope xmlns="http://schemas.xmlsoap.org/soap/envelope">
<body>
<find_service generic="1.0" xmlns="urn:uddi-org:api">
<functionalRequirement>
credit card validation
</functionalRequirement>
<qualityRequirement>
<property>price</property>
<value>0.01</value>
<weight>2</weight>
</qualityRequirement>
<qualityRequirement>
<property>responseTime</property>
<value>0.05</value>
<weight>3</weight>
</qualityRequirement>
<max>1<max>
</find_service>
</body>
</envelope>
Figure.2.

Service Request

Data structure for the QoS information

The QoS properties of a Web Service can be represented
using the data structure called tmodel [8]. The role of a
tModel is to register categorizations, which provides an
extensible mechanism for adding property information to
a UDDI registry. It can be used to provide QoS
information on bindingTemplates. In the tModel for
quality of service information for the binding template
that represents a Web Service deployment is generated to
represent quality of service information. Each QoS metric,
such as average response time or average throughput is
represented by a keyedReference that is a general-purpose
structure for a name-value pair, on the generated tModel.
The example showed in Figure.3 is one of a Stock Quote

service.
A
tModel
with
tModelKey
"uddi:mycompany.com:
Creditcardvalidationservice:PrimaryBinding:QoSInformat
ion" containing the QoS attribute categories is referenced
in the bindingTemplate. In order to retrieve more detailed
management information, the location of a WSDL
description is stored in a keyed reference with tModelKey
"uddi: mycompany.com: Creditcardvalidationservice .
<tModel tModelKey="mycompany.com:creditcardvalidationService:
PrimaryBinding:QoSInformation"" >
<name>QoS Information for credit card validation Service</name>
<overviewDoc>
<overviewURL>
http://<URL describing schema of QoS attributes
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReferencetModelKey="uddi:uddi.org:QoS:Availability"
keyName="Availability"
keyValue="99.9%" />
<keyedReference tModelKey="uddi:uddi.org:QoS:Throughput"
keyName="Average Throughput"
keyValue=">10Mbps" />
<keyedReference tModelKey="uddi:uddi.org:QoS:Reliability"
keyName="Average Reliability"
keyValue="99.9%" />
</categoryBag>
</tModel>
Figure.3.

tmodel for the QoS information.

Discovering the Web Service

All WSDL service interfaces are published in a UDDI
registry as a tModel. Each of these tmodel is categorized
to identify them as a WSDL service description. The
UDDI find_tModel [10] message can be used to find
tmodel that have been categorized. The find_tModel
message can be used to locate all WSDL service interface
descriptions. The find_tModel message will return a list of
tModel keys. A specific service interface description is
retrieved using the get_tModelDetail message
<?xml version="1.0"?>
<find_tModel generic="1.0" xmlns="urn:uddi-org:api">
<categoryBag>
<keyedReference
tModelKey="UUID:DB77450D-9FA8-45D4-A7BC-D14E384"
keyName="credit card validation"
keyValue="84121801"/>
</categoryBag>
</find_tModel>
Figure.4.

find_tmodel for discovering Web Service.

After a tModel has been retrieved, the overviewURL can

be used to retrieve the contents of the WSDL service
interface document. Additional keyedReferences can be
added to the categoryBag to limit the set of tModels that
are returned in the response to this find request.
In figure.4 an example showed a find_tModel message,
which can be used to locate all of the credit card

2012 International Conference on Computer Communication and Informatics (ICCCI -2012), Jan. 10 12, 2012, Coimbatore, INDIA

validation services that are defined using WSDL.

Web Service Selection
The Web Service broker obtain both functional and non
functional criterion for the target Web Service from the
requesters message .Then the broker will discover the
Web Services from the UDDI registry by using the
tmodel_find message and placed them in the local Web
Service repository.
The Next step in the selection process is to sort the web
services based on the clients request. For that we used the
min-max normalization technique and weighted AND-OR
tree to obtain the Quality Constrain Tree (QCT) which is
explained in [1]. In the Weighted AND-OR tree every
edge between parent and child node is labeled with a nonnegative real number in an interval (0, 1) such that for any
parent node the sum of edge labels (weights) of all child
nodes is equal to one i.e. for any parent node P with C
(2CN) child nodes, the sum of edge weights WPCi
(1iC) is equal to 1.
Each leaf node having the quality criteria of the client and
all the obtained Web Services in the local registry
matched with the leaf node. The web services which all
are passing through the leaf node criteria will be given a
score. If the root node for the leaf nodes is a AND node
then web services which all present in all the leaf nodes
will be selected and new score will be calculated using
weight of the particular leaf node.

After constructing the tree the root node will be having

the descending ordered list of the Web Services based on
their QoS Score. In the top ranked one is the best Web
Service based on the particular clients quality
requirement.
Once finding the best target Web Service we need to
increment the usage count value of the particular web
service in the Web Service repository. Then negotiation
and binding process initiated by the interaction layer.
In the QCT, if the root node having two Web Services
having same QoS Score then broker need to check for
another aspect to choose the best one. For this [2] defining
four Web Service Provider qualities to compare and find
the best Web Service in case of the Tie.
In this paper we use another method to find the best web
service in the tie situation which is explained in the
Figure.4. We increment the count for the Web Service in
the usage repository whenever a Web Service is happened
to bind with a business client.
So we can use this count value as the criteria for selection.
Because the service which having the maximum count
value selected as a best Web Service for many clients. In
case of the tie in the QCT, the broker will obtain the count
value of the both Web Service and select the maximum
count valued Web Service as the best one.
Selection algorithm
selectService (ranklist, NumofServices)
{
selection = service [];
while (sortlist[0].QoSScore = = sortlist[1].QoSScore)
{
If(count(sortlist[0])<count(sortlist[1]))
Selection.add(sortlist[1])
Count.add(sortlist[1])
else
Selection.add(sortlist[0])
Count.add(sortlist[1])
}
if maxNumServices > 1
i = 0;
while i < maxNumServices && i < sortlist.size()
selection.add(sortlist[i]);
Count.add(sortlist[i])
return selection;
}

Figure.5.

Web Service Selection model

For the selection algorithm, input will be the sorted list of

Web Services matching with clients quality criteria then
the maximum number of Web Services required by the
client message. It will check with the sorted list that
whether there is any tie [3] with the top two services QoS
Score. If tie occurred then the broker will check with the

2012 International Conference on Computer Communication and Informatics (ICCCI -2012), Jan. 10 12, 2012, Coimbatore, INDIA

usage repository. The Web Service which is having most

number of counts will be returned as the best Web Service
to the client.

[3].
[4].

IV. CONCLUSION
In this paper we presented the standard method to
represent the Web Service clients requirement message
and then we proposed QoS broker architecture to get the
clients message and then it will discovered the Web
Service from the local Web Services repository based on
the functional requirement of the client, then it will select
the best Web Service which match with the clients QoS
requirements by using the min-max normalization
technique. Then it will increase the usage count of the
dispatching Web Service in the usage repository. The
count value also used to choose the best Web Service
when we get a tie. Finally the broker will return the best
Web Service to the client. The methodology proposed
provides a relevant match Web Service to the client.

REFERENCES
[1].

[2].

D'Mello, D.A., Ananthanarayana, V.S., Santhi, T,A QoS

Broker Based Architecture for Dynamic Web Service
Selection, Modeling & Simulation, 2008. AICMS 08. Second
Asia International Conference.
T.Rajendran , Dr.P.Balasubramanie , Resmi Cherian,An
Efficient WS-QoS Broker Based Architecture for Web Services
Selection , 2010 International Journal of Computer
Applications , Volume 1 No. 9.

[5].

[6].

[7].

[8].

[9].
[10].

D'Mello, D.A., Ananthanarayana,Quality Driven Web Service

Selection and Ranking, Information Technology: New
Generations, 2008. ITNG 2008. Fifth International Conference .
Reza
Tabein,
Mahdi
Naser
Moghadasi,
Alireza
Khoshkbarforoushha,Broker-based Web Service Selection
using Learning Automata , Service Systems and Service
Management, 2008 International Conference .
Kyriakos Kritikos, Dimitris Plexousakis, Requirements for
QoS-Based Web Service Description and Discovery, IEEE
Transactions On Services Computing, Vol. 2, No. 4, Octoberdecember 2009
Hai Liu, Weimin Zhang, Kaijun Ren , Zhuxi Zhang ,A Novel
Selection Approach for Transactional Web Services
Composition , 2010 Ninth International Conference on Grid
and Cloud Computing 2010 IEEE.
M.A.Serhani, R.Dssouli,A.Hafid, H.Sahraoui ,A QoS broker
based architecture for efficient Web Services selection,
Proceedings of the IEEE International Conference on Web
Services (ICWS05) .
T. Rajendran, Dr.P. Balasubramanie, An Optimal BrokerBased Architecture for Web Service Discovery with QoS
Characteristics , International Journal of Web Services
Practices, Vol. 5, No.1 (2010).
Al-Masri, E and Mahmoud, Q.H.,Toward Quality-Driven Web
Service Discovery, Published by the IEEE Computer Society,
IT Pro May/June 2008, Vol. 10, Issue-3.
http://www.ibm.com/developerworks/webservices/library/wswsdl/