Section 2 covers the related work. While section 3, describes 
the developed system. Section 4 illustrates the simulation 
results carried out on weather web service. Section 5 describes 
the conclusion & future scope. 
2. QOS PARAMETERS 
The service discovery is based on the UDDI, in which the 
services can be searched by using functional attributes. For the 
non functional attributes i.e. Quality of Service (QoS) there are 
various approaches or methods suggested by researchers. Lots 
of models and frameworks have been proposed for discovery 
and selection of web services based on QoS parameters as 
explained below. 
The QoS parameters are adopted by extending the conceptual 
Publishing & Discovery models [3] [4]. Such models are 
mostly associated with UDDI directories. Ran et al. [3] 
proposed a four roles model for publishing QoS by extending 
the UDDI registry and a Web Services QoS certifier. The 
difference between the new UDDI registry and the standard 
one is that the new UDDI registry has information about the 
functional description and its associated QoS attributes. This 
proposal supports two directions; publishing and discovering as 
well as verification and certification. Serhani et al. [4] added a 
new component, a broker, to the original Web Service 
framework and used a QoS-enabled UDDI called UDDIe 
registry. The QoS-enabled UDDIe is a registry, which supports 
the publication and discovery of the QoS aware services. It 
supports the idea of blue pages which enables the discovery of 
Web Services based on user defined attributes. 
Another approach is through Web Services Description & 
Handling models. Such models were associated with policy 
e.g. WS-Policy, which is a specification that allows Web 
Services to advertise their capabilities, requirements, and 
general characteristics in a flexible and extensible grammar 
using XML format [5]. A policy assertion is a requirement or 
rule which describes Web Services behavior and gives it a 
better robustness and extendibility. WS-Policy framework is 
used to include some QoS properties such as security, reliable 
messaging and transaction. Mathes et al [6] has proposed an 
approach to use the WS-Policy to include other QoS attributes 
by extending it. 
Another approach is a combination of both the above 
mentioned approaches. Garcia et al. [7] proposed a 
combination of UDDI and WS-Policy approach. In their work, 
the authors extend the UDDI registry to include WS-Policy and 
add a broker to the standardized UDDI architecture. Ontology 
Web Language (OWL) as well as ABLE Rule Language (ARL) 
is used to enrich QoS policies with semantic information. Such 
enrichments allow more flexible interactions between policies. 
Another approach is SLA (Service Level Agreement) e.g. 
WSLA. IBM proposes Web Service Level Agreements (WSLA) 
which is an XML specification of SLAs for Web Services, 
focusing on QoS constraints. We can not only specify the 
Service Level Objectives (SLO) of a service and its service 
operations, but also the measurement directives and 
measurement endpoints for each quality dimension. WSLA 
represents a configuration for a SLA management and 
monitoring system. 
Another approach is Model like DAMLS: provided an upper 
ontology for semantic description of web services, including 
specification of functionalities and QoS constraints [8]. 
The main drawbacks of these models/frameworks are that they 
are not validating the QoS parameters provided by the service 
providers. Also, there is no end-to-end solution for solving the 
best-fit web service amongst the available similar services at 
broker side. We are proposing an automated end-to-end Multi- 
Agent QoS based architecture (AMAQ) to be implemented at 
broker side for selection of web services. 
3. AMAQ SYSTEM IMPLEMENTATION 
The Automated Multi-Agent QoS based (AMAQ) System 
Architecture and algorithms are described in this section. 
3.1 AMAQ Architecture 
The proposed architecture and functionalities are shown in 
Figure 2. 
Web Service Registry: The Service Provider (SP) shall register 
the web services into registry. All the information related to 
web service and service provider shall be stored in the web- 
service registry. Service provider shall submit and update 
(optional) the Web Service QoS parameters which are to be 
stored in database along with .wsd/ file. By reading that 
description Service Requester (SR) can use the service of SP. 
SP can also send QoS parameters through the Service Receptor 
Agent ie. serviceRecAgent. This serviceRecAgent aids in 
registration of service and invokes the Parsing Agent, 
parseAgent and QoS Measurement Agent, QoSAgent that will 
aid in WSDL & QoS parameters validation. 
WSDL Validation: The .wsdl file contains the description of the 
web service, provided by service provider that is stored into 
registry. Checking and validation of the .wsd/ file shall be done 
by the Parsing Agent, parseAgent. In the case of incomplete 
information in .wsdl, service provider can get the feedback 
from the registry. Based on feedback, SP can submit the proper 
wsdl. 
QoS Parameters Validation: The QoS parameters shall be 
calculated by QoS Measurement Agent, QoSAgent and the 
differentiated result (Measured QoS — QoS provided by SP) 
shall be stored in database. 
When SR places a discovery request, the Request Receptor 
Agent, reqRecAgent shall collect the functional and QoS 
requirements and store internally to its data structure and 
invoke the Discovery Agent, discoveryAgent. 
Web Service Discovery: The SR shall discover the web service 
from the registry. For the discovery, SR has to provide the 
required web service functionalities as well as non-functional 
parameters. The  discoveryAgent shall match the SR 
requirements with the available result sets from the QoS & 
Web service registry database and provide the discovered web 
services list to the Decision Agent, decisionAgent. 
Web Service Selection & Ranking: The decisionAgent shall 
select & rank the web service(s) using Fuzzy Methods. 
230 
CNT ed [29] 
o2 
ta)