See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/228791890

A Survey of current Approaches towards Specification and Management of

Quality of Service for Web Services

Article  in  PIK - Praxis der Informationsverarbeitung und Kommunikation · September 2004

DOI: 10.1515/PIKO.2004.132 · Source: DBLP

CITATIONS READS

27 96

5 authors, including:

Andreas Gramm Jochen Hermann Schiller

14 PUBLICATIONS   435 CITATIONS   
Freie Universität Berlin
215 PUBLICATIONS   4,035 CITATIONS   
SEE PROFILE
SEE PROFILE

Rolf Winter
University of Applied Sciences Augsburg
30 PUBLICATIONS   412 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

context-oriented computer science education / Informatik im Kontext (IniK) View project

ScatterWeb View project

All content following this page was uploaded by Andreas Gramm on 03 June 2014.

The user has requested enhancement of the downloaded file.

 A Survey of current Approaches towards Specification and Management of
Quality of Service for Web Services

M. Tian, A. Gramm, H. Ritter, J. Schiller, R. Winter

Freie Universität Berlin, Institut für Informatik
Takustr. 9, D-14195 Berlin, Germany
{tian, gramm, hritter, schiller, winter}@inf.fu-berlin.de

Abstract
The current Web service standard does not provide mechanisms for service
offering and dynamic service selection based on QoS properties. A lot of research
work related to this topic has been carried out recently both in the industrial and
academic world. This article gives an overview of some recent efforts towards the
specification and management of QoS-aware Web services.

Keywords
Web services, Quality of Service, QoS Management, Service Level
Agreement, cross-layer communication.

1 Introduction
With the tremendous success of the Web service technology in both business and research area,
quality of service (QoS) issues will play an important role for Web service providers. While service
offers with no guarantees on throughput, response time, security, availability, reliability, etc. are
accepted in some simple cases, most likely this will be not acceptable when a Web service becomes
an important part of an application composed of various Web services [1].
The need for QoS specifications in Web services is driven by two demands. Clients aim to
experience a good service performance, e.g. low waiting time, high reliability, and availability to
successfully use services whenever the need arises. On the other hand, when it comes to e-business,
service providers need to formulate QoS-aware offers in order to gain the highest possible profit
from their business. Examples are high throughput guarantees and low response time through
dynamic capacity allocation, resource allocation, and load balancing in order to serve a high number
of clients with assured QoS. Moreover, crucial transactions such as payment should experience
prioritized execution realized by transaction differentiation. Service providers will strive to find an
optimal relation between user satisfaction and system utilization.
The main contribution of this article is an overview of selected major industrial and academic efforts
towards the specification and management of QoS for Web services. After discussing the state of the
art in the Web service technology, we introduce six current approaches towards QoS support in Web
services.

2 State of the art

In the standard Web service interaction model [2], a.k.a. the basic Service Oriented Architecture
(SOA) [3], the functionality and information on where and how to access Web services (i.e. under
which URI using which protocol) is described in a Web Services Description Language (WSDL)
file. This file is commonly referenced from a Universal Description, Discovery and Integration
(UDDI) registry for standardized service discovery.
A UDDI registry is basically a data base with UDDI logic and interfaces for publishing of and
searching for Web services [4]. Yellow, white, and green page information of Web services such as
contact information of a company or industry categories can be stored and viewed there by either
using a Web interface or an API. However, entries are often inaccurate or expired and UDDI does

1
not provide a mechanism for automatically updating the registry as services (and service providers)
change [5].
Since communication between clients and UDDI is a client/server interaction, UDDI could become a
performance bottleneck in case of overloading or even unavailability. To the best of our knowledge,
there are no publications on the performance of current UDDI implementations. However, our
experience shows that performance considerations of current UDDI implementations must be taken
seriously.
A Web service can be described by its static functional attributes and its dynamic non-functional
parameters including QoS aspects. The different QoS aspects are for example
• server performance including throughput, availability and reliability,
• network performance including bandwidth, jitter and delay,
• security and transactional support,
• scalability as well as
• cost.
With the emergence of functionally equivalent services implementing a common service type (e.g.
tModel), the non-functional QoS properties associated with services will become distinctive criteria
for the success of a company offering e-business through Web services. It is also imaginable that a
business will offer its services in various classes of quality to meet different customers’
requirements, according to what they might be willing to pay in return. Therefore, the need to
unambiguously specify both QoS properties and different QoS levels in some kind of contract such
as Service Level Agreements (SLA) and to prove the Web services’ compliance arises. In terms of
SOA, Web services are building blocks from which more sophisticated applications can be created.
An introduction of current specifications for Web service composition is given in [6].
Three different phases of QoS management can be identified. Firstly, QoS constraints on certain
parts of a provided service are formulated in a specification. Since the purpose of such a
specification is to reinforce a certain level of QoS, parameters are monitored by constant
measurement at runtime. Finally, the values measured have to be tested against the negotiated
specification and appropriate activities should be carried out in order to control the QoS
conformance ensuring a low violation rate. In case of violations, compensation may be refunded to
the service consumer.
In this article, we give an overview of six approaches towards QoS specification and management
for Web services, coming from both industry and academia. These approaches are
• the Web Service Level Agreement (WSLA) developed by IBM, [7]
• the Web Service Offering Language (WSOL) developed at Carleton University,
Canada, [8]
• SLAng developed at University College London, UK, [9]
• a UDDI eXtension (UX) developed at Nanyang Technological University, Singapore,
[10] and
• UDDIe developed at Cardiff University, UK [5].
In addition, we introduce our own approach called Web service-QoS (WS-QoS) [11], which
we developed at Freie Universität Berlin, Germany.

3 Approaches towards specification and management of QoS

for Web services
All approaches presented deal with the specification and management of QoS for Web services.
Although they all target the same issues, the proposed concepts are very different, which makes a
comparison and evaluation difficult. Generally, two basic ideas of a QoS-aware service selection can
be identified: The first type of concept proposes a new infrastructure for specifying QoS issues
associated with Web services. The second type deals with extending the functionality of UDDI

2
either within or outside UDDI by introducing an additional server or a broker. While WSLA, WSOL
and SLAng are of the first type, UX, UDDIe, and WS-QoS belong to the second.

3.1 Web Service Level Agreement

IBM’s Web Service Level Agreement (WSLA) framework fosters the idea of individually negotiated
customized service level agreements. A WSLA is an agreement between a service provider and a
customer and as such defines the obligations of the parties involved. Primarily, it is the obligation of
a service provider to perform a service according to agreed-upon guarantees for the service
parameters on the technical level (such as availability, response time, and throughput) [7].
The design goals of WSLA are a formal and flexible XML-based language for SLA definitions
between different organizations, a wide acceptance and applicability to existing e-business systems
and standards, nested relationships of service clients and providers, delegation of monitoring tasks to
third parties, and an SLA-driven configuration of the managed resources, i.e. deriving configuration
settings directly from SLAs.

3.1.1 Service level specification

While a great variety of SLAs with different semantics of QoS parameters exist, an SLA generally
includes information on the parties involved, a reference to the operational description of the service
covered by the SLA, SLA parameters to be monitored, the metrics and algorithms used to compute
the SLA parameters as well as the intended service level objectives (SLO) and appropriate actions to
be executed in case they are violated [7].
Figure 1. shows all the entities represented in a WSLA.

Web Service Level Agreement:

• parties
- signatory parties
- supporting parties
• service description
- covered service (WSDL)
- monitored SLA parameters
- measurement directives
- functions
• obligations
- validity period
- SLOs
- action guarantees

Figure 1. Entities in a WSLA

According to the WSLA XML schema a WSLA is divided into three sections:
In the “parties” section, signatory and supporting parties are introduced along with information on
which signing party sponsors the supporting ones.
The “service description” section yields information on the service’s characteristics and the
parameters to be observed. Resource Metrics are derived directly from the managed resources as
specified in a Measurement Directive. They can then be aggregated to Composite Metrics where a
Function explains how a composite metric is computed from input parameters which are either
resource metrics or composite metrics themselves. In an SLA Parameter the retrieved metrics are
put into the context of a specific customer, adding information on who supplies the value and to
whom it will be reported.
Finally, the third section “obligations” describes guarantees and constraints imposed on the SLA
parameters in the form of SLOs, i.e. high/low watermarks for associated SLA parameters which are

3
promised to be met for a certain period of time. In the case of SLA violations, appropriate
compensating activities are defined in Action Guarantees.

3.1.2 Deployment and monitoring – the SLA lifecycle

A WSLA’s management lifecycle consists of five stages, as shown in
Figure 2. These stages are:
1. The establishment of an SLA is negotiated with the help of an SLA Establishment Service.
2. After the signatory parties have reviewed the SLA, relevant information in form of Service
Deployment Information (SDI) is deployed to the supporting parties.
3. Based on the received SDI a Measurement Service collects the metrics specified and reports
them to a Condition Evaluation Service, which in return computes the grade of compliance of
the measured values with the SLA parameters.
4. On receiving this information the Management Service will take corrective management
actions to deal with the occurrence of SLA violations. Before carrying out any corrective
action, the Management Service has to consult the Business Entity for approval. The Business
Entity holds critical business information which normally is confidential.
5. The last stage is the termination of the customer/provider relationship.

Figure 2. The five stages of an SLA management lifecycle [12]

4
IBM’s SLA Compliance Monitor implements the Measurement, Condition Evaluation and
Deployment Service as described above. It is part of IBM’s Emerging Technologies Toolkit [13].

3.2 Web Service Offering Language

A research group from Carleton University in Canada has developed the notion of providing various
classes of service for one and the same functional service specification, which differ in QoS level
and management efforts. WSOL allows the formal and unambiguous specification of prices,
monetary penalties, management responsibilities and third parties, especially accounting parties.
The main targets of the WSOL project are the creation of service offerings, the definition of QoS
constraints, management statements, reusability, and a mechanism called service offering dynamic
relationship (SODR) allowing for a switching between services [8].
Another important design goal is a low run-time overhead achieved through defining classes of
services instead of individually managed SLAs. WSOL also supports the reusability of specifications
through the concept of constraint groups and constraint group templates to include formerly defined
elements and import of elements defined in other WSOL files.

3.2.1 Service offering

Classes of service are a mechanism for the description and the differentiation of a Web service and
QoS associated with that Web service. While classes of service of one Web service refer to the same
functionalities which are defined in the same WSDL file, they differ in QoS constraints and
management statements. Different classes of a service may imply a different utilization of the
underlying hardware and software resources. A service offering can also be seen as a contract or
SLA and consists of several components as listed in Figure 3.

WSOL Service Offering:

● import / include of external specification
● subscription
● price
● penalty
● management responsibility
● constraints
● domain (service-/port-/operation- name)
● condition (as Boolean expression)
● metrics (defined in external ontology)
● rules for metrics aggregation
● management entity for measurement
● statement
● domain (service-/port-/operation- name)
● <any definition>
● constraint group / instantiated CGT
● <any item listed above>

Figure 3. Components of a WSOL service offering

3.2.2 Constraints
WSOL allows the specification of three categories of constraints: functional constraints, non-
functional (QoS) constraints, and access rights. A constraint is a Boolean expression specifying a
condition that is to be verified before and/or after the execution of a Web service’s operation for
which it is specified. Constraints are defined by extending the generic constraint element. Functional
constraints such as pre- and post-conditions check some characteristics of message parts of an
invoked operation. Non-functional constraints describe guaranteed QoS parameters such as

5
performance, reliability and availability of a service. QoS metrics and measurement units are defined
in external ontologies. Finally, access control constraints define conditions under which a consumer
is admitted for service invocation.

3.2.3 Management
Management information is described in WSOL statement elements including pay-per-use price,
monetary penalty, and management responsibility. A pay-per-use price states the fee a consumer has
to pay for the service usage and the monetary penalty regulates the condition when the service
provider violates the assured QoS constraints. Management responsibility defines what party (the
consumer, the supplier, or a trusted third party) is responsible for monitoring a particular constraint.

3.2.4 Reusability
There are a number of features enabling the reusability of existing specifications. Existing WSOL
documents can be imported for the reuse with the import element. Constraints and statements that
have already been defined can be applied to a different scope by referencing and renaming them in
an include statement. Moreover, statements and constraints can be grouped into constraint groups
(CG) that can easily be referenced for alternative domains. This CG Element allows for nesting
definitions to an arbitrary level. An abstract Constraint Group Template is defined in a CGT
Statement and is instantiated with concrete parameters..

3.2.5 Service Offering Dynamic Relationship

Service Offering Dynamic Relationship (SODR), which is defined outside a WSOL file, ensures the
initiation of predefined management activities in case of underperformance. The management
activities are responsible for
• switching between service offerings,
• deactivating or reactivating existing service offerings, and
• the creation of new appropriate service offerings as well as
• the negotiation and selection of an appropriate replacement of service offerings.
A Service Offering Relationship element specifies a current service offering, a service offering
appropriate for replacement and a sequence of constraints. A violation of the constraints will trigger
the specified change in the service offering.

3.3 SLAng
The XML-based language for defining service level agreements SLAng was developed at University
College London, UK. The main targets of SLAng are the support for inter-organizational service
provisioning including storage, network, middleware, and applications as well as the specification of
non-functional parameters at service level in order to enable QoS description and negotiation [9].
SLAng is an SLA language that does not only support Web services. It can be used only for static
SLAs at the moment, since it does not support dynamic lookup of new services and update of non-
functional service properties at runtime.

3.3.1 Service provision reference model

Figure 4 depicts the service provisioning model of SLAng. The 3-tier architecture consists of the
application tier, the middle tier, and underlying resources. Applications of the first tier consume the
underlying components or Web services abstracted by the middle tier. The containers located in the
middle tier support QoS negotiation, establishment, and monitoring, while the components abstract
the resources in the underlying resource tier. The network and storage facilities are grouped to the
underlying resources.

6
Figure 4. SLAng's service provisioning reference model [9]

3.3.2 Structures
SLAng supports both horizontal and vertical SLAs. A horizontal SLA is a contract between peers in
the same tier. A vertical SLA describes the usage of the underlying layer.

Figure 5. Vertical and horizontal SLAs [9]

7
There are seven different types of SLA definitions in SLAng, as shown in Figure 5. The vertical
SLAs are related to application, hosting, persistence, and communication, while the horizontal ones
are related to services (between a component and a Web service provider), container, and
networking. Each kind of SLA includes definitions of responsibilities of the service client and the
service providers, and mutual responsibilities.

3.3.3 QoS semantics

The QoS semantics in SLAng are defined according to the different SLAs of the performance
properties. For example, the throughput of a database server and the throughput of a component
server are different concepts, although both contribute to the overall QoS. Therefore, they are treated
differently before being composed [9].

3.4 UX
UX is an architecture providing QoS-aware and cross organizational support for UDDI, developed at
School of Computer Engineering, Nanyang Technological University, Singapore. The first goal of
UX is to rate services with reputation in order to allow service requestors to discover services with
good quality. The second one is to share the ratings among UX servers – the proposed extension of
UDDI – in different domains [10].

3.4.1 Approach
Reputation is measured through QoS feedback made by service customers. The proposed UX server
uses the clients’ reports containing response time, terminating state, and cost to generate summaries
in order to predict the services’ future performance. The generated summary containing response
time, reliability, cost, timestamp, and report number is used to sort the query results.
The UX server is extended with an inquiry interface which is conforming to the standard UDDI one.
A lookup interface in UX allows the discovery and distribution of the QoS summaries among
different UX servers.
Figure 6 depicts the basic architecture of UX. When the UX server receives a request (1), it will first
search the local UDDI server for services (2). If the number of appropriate services in the local
registry is high enough, it will return a list of results back to the service requestor; otherwise it will
initiate a so-called federated discovery in order to find more results.
Federated service discovery describes the ability to search QoS-aware services among different UX
servers across different domains. UX applies a protocol that dynamically updates the links between
cooperating servers over a WAN according to different events happening, either to some servers, or
to the underlying WAN. The applied protocol is called Cooperating Server Graph (CSG) model [14].
In the UX architecture, the UX server returns a list of appropriate services to the service requestor,
so that the service requestor has to process the suggested service offers on receiving them. This
approach may result in additional processing time and increase configuration overhead at the client
side.

8
Figure 6. UX architecture [10]

3.4.2 Verity
UX extends UDDI with the ability to predict services’ future performance based on reputation,
which is measured through QoS feedback made by service customers. The users’ experience is
shared in a local and inter-domain way. Since reputation is mainly influenced by the user perception
and can be furthermore manipulated easily, a research group from Monash University, Australia,
extended the approach to reputation with a QoS attribute termed “verity” [15]. Verity is used as an
indicator of trustworthiness for the quality driven selection and composition of services.

3.5 UDDIe
UDDIe [5] was developed at Cardiff University, UK. It extends UDDI’s functionalities within
UDDI. Service providers can associate their services with QoS properties such as bandwidth, CPU,
and memory requirements, which are encoded in the service interface. They can make their services
available for a period of time by means of leasing. UDDIe introduced a concept allowing the
definition of three leasing types including finite, infinite, and future lease. Furthermore, UDDIe
supports qualifier-based search by introducing qualifiers such as EQUALto, LESSthan, and
GREATERthan.

3.5.1 Approach
UDDIe is implemented in the context of the G-QoSM framework for grid service discovery [16].
The client applications send their request to the QoS broker of the G-QoSM system. The broker is
not part of UDDIe. It processes the requests and forwards them to the UDDIe registry. After
receiving a list of services that implement the particular service type, the broker does the final

9
selection of the most appropriate service for the client by applying a weighted average concept.
Figure 7 shows a code fragment of a client request with QoS requirements.
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
....
targetNamespace="http://MyService-Interface">
<wsdl:messagename="printNameResponse">
</wsdl:message>
....
<QoS>
<service_cost> 5 </service_cost>
<network_bandwidth> 256K </network_bandwith>
<memory> 48MB </memory>
....
</QoS>
</wsdl:definitions>

Figure 7. Client request with QoS requirements [5]

QoS properties associated with a service are provided together with further information about that
service by the extended UDDI server. The QoS properties are encoded in the service interface.
Since non-functional properties of a service such as price and performance are subjects to frequent
changes, repeated requests to a huge UDDI registry might prove to be a bottleneck in the
performance of service lookups. Because of these facts the UDDI server is not the right place to
store non-functional properties. Encoding non-functional properties into service interfaces should be
avoided, since otherwise the service interface would have to be recompiled each time non-functional
properties are changed. WDSL is designed to hold information on functional aspects of a service
which is not expected to be changed often once designed. A more flexible way would be to delegate
the non-functional description of a service from the WSDL to an extra place so changes on non-
functional properties can take place without changing the WSDL.

3.6 WS-QoS
Most applications cannot actively consume the QoS that may be supported in the communication
networks and on the other hand common network technologies do not support application-dependent
requirements. In order to close the gap between the Web service and transport layers, the framework
Web service QoS (WS-QoS) [11] has been developed by the authors at Freie Universität Berlin. WS-
QoS supports the dynamic mapping of QoS properties concerning the network performance defined
in the Web service layer onto the underlying transport technology at runtime. We call this approach
cross layer communication. Further targets of the framework are
• an architecture that allows both service client and service provider to specify requests and
offers with QoS properties and QoS classes,
• mechanisms that accelerate the overall Web service lookup and matching process for the
client, and [17]
• tools that assist application developers with the QoS definition associated with Web services
[17].

3.6.1 WS-QoS XML schema for QoS definition

The WS-QoS XML schema enhances the current infrastructure of standardized service description,
publication, and lookup to allow for the selection of QoS-aware Web services at run-time.
Both client side QoS requirements and service providers’ QoS offers are specified by elements of the
type tQoSDefinition, which is depicted in Figure 8. While only one QoS requirement element is
allowed as a root element, multiple QoS offers may be held in a collection. The collection may also
contain references to existing WS-QoS files in order to include further offers, allowing dynamic
adjustments of offers without changing any WSDL file. Furthermore, an offer could be referenced
from multiple WSDL files and thus be reused for different services.

10
Figure 8. Structure of a QoS definition element [11]

Different QoS levels can be defined, either in a defaultQoSInfo which is applied to the scope of a
whole service or in an operationQoSInfo for a single operation. Both are of the type tQoSInfo, shown
in Figure 9. WS-QoS predefines some QoS categories with standard parameters, which are e.g.
serverPerformance (as category) with processingTime, requestsPerSecond, reliability (as standard
parameters) and transportQoSProperties (as category) with delay, jitter, throughput, packetLoss (as
standard parameters). The standard QoS parameters are necessary for an automated matching during
the QoS-aware service selection process. This process is performed by the Web service broker which
is introduced in the next subsection. Next to the predefined categories and standard parameters,
custom categories with individual parameters can be declared by referring to a public WS-QoS
ontology. Therefore, an element WSQoSOntology has been designed to hold definitions of QoS
parameters and protocol references [11].

Figure 9. Structure of a QoS info element [11]

11
3.6.2 Acceleration of the QoS-aware service selection process
A Web service broker (WSB) has been designed in order to accelerate the overall Web service
lookup and matching process for clients. The WSB can prefetch information about Web service
offers a client might be interested in. That means a client will contact the WSB for looking up QoS-
aware services instead of doing this with a UDDI server. The WSB holds up-to-date information on
offers currently available for a group of services. Offers are grouped by the interface (tModel) that
the services implement. The first time a service for a certain interface is requested, the WSB inquires
one or more UDDI registries for services that implement the required interface. The WSDL files for
the services that implement the requested service are then checked for WS-QoS extensions and
available offers are built at the WSB. From then on that newly created offer list is consulted to find
the best match for clients, accelerating the QoS-aware service selection process. The offer list is
updated at adjustable intervals.

3.6.3 QoS mapping in dynamic cross layer communication

Today, research activities in database, Web Services, middleware, and communication networks in
different layers in terms of the Internet model are running widely independent from each other. In
most cases, researchers of database and middleware technologies assume that existing
communication infrastructures provide reliable communication infrastructures. Furthermore,
researchers of higher layers are not very considerate of the resources like CPU processing power,
network bandwidth and memory. Thus, approaches that are common in database and middleware
technologies will break down in highly dynamic communication environments. Quite often, research
activities in certain communication architectures and protocols are concluded without paying
attention to requirements of actual applications. Therefore, most applications can not actively
consume the Quality of Service (QoS) that may be supported in communication networks.
The WS-QoS architecture allows QoS definitions concerning server performance, transaction,
security, pricing as well as network performance. In order to achieve an overall performance gain
through all layers, the underlying QoS-aware transport technology such as DiffServ, ATM, or
UMTS should take the application requirements into account. We have introduced a QoS proxy
between the Web service and the transport layer in order to map the requirements regarding network
performance defined in the higher layer onto the underlying transport network at runtime. Since
different QoS enabling technologies have different QoS mechanisms, the QoS parameters for
transport such as delay, jitter, and bandwidth are declared as priority rather than absolute values. The
QoS proxy will translate the different parameters with different priorities by applying a mapping
table. The current implementation supports the mapping of WS-QoS transport QoS requirements
into a DiffServ Code Point (DSCP) packet marking for a differentiation of various DiffServ traffic
classes. [18]

4 Conclusions
In this paper, we have presented six different approaches towards the QoS-aware specification and
management of Web services. Due to the different aspects they deal with, it is difficult to compare
them with respect to coherent criteria. Common denominators are the use of XML and the
conformance with the existing Web service technologies such as WSDL and UDDI. While WSLA
fosters individually customized SLAs, WSOL introduces a formal specification of classes of service.
SLAng can be used for SLA specifications in general not only for Web services. UX is able to select
services based on reputation among federated UX servers. UDDIe extends the standard UDDI API
in order to associate QoS properties with Web services. Beyond the QoS-aware specification and
selection of Web services, WS-QoS emphasizes the mapping of QoS between different layers in
order to achieve an overall performance gain.
The increasing industrial and academic involvement in the still emerging Web service technology
clearly shows that considering QoS is essential for the success of Web services. Current Web service
concepts are designed for application to application (A2A) communication running on desktop

12
 computers or servers. However, today the usage of small and mobile devices is increasing rapidly. It
is well known that mobile devices are resource constrained. They do not have as much CPU power,
memory, bandwidth, etc. as desktop computers. Therefore, it will be useful to analyze the behavior
of mobile Web services in order to improve performance and Quality of Service support for this ever
increasing group of users [19]. In this context QoS differentiation will prove to be a decisive factor.

5 References
[1] D. A. Menascé, “QoS Issues in Web Services”, IEEE Internet Computing, pp. 72-75, Dec. 2002,
http://csdl.computer.org/comp/mags/ic/2002/06/w6072abs.htm
[2] H. Kreger, IBM Software Group, “Web Service Conceptual Architecture (WSCA 1.0)”, May 2001,
http://dwdemos.dfw.ibm.com/wstk/common/wstkdoc/ettk/wstk/doc/WebServicesArchitecture.pdf
[3] Papazoglou, M.P. and Georgakopoulos, D. “Service-Oriented Computing”, In Communications of the ACM, 46(10):25-28,
October 2003, http://www.uvt.nl/infolab/pub/db/
[4] A. Eberhart and S. Fischer, “Web Services”, ISBN 3-446-22530-7, Carl-Hanser-Verlag, 2003.
[5] Ali ShaikhAli, Omer F. Rana, Rashid Al-Ali, David W. Walker, “UDDIe: An Extended Registry for Web Services”, 2003
Symposium on Applications and the Internet Workshops (SAINT'03 Workshops), Orlando, Florida, January 2003,
http://csdl.computer.org/comp/proceedings/saint-w/2003/1873/00/18730085abs.htm
[6] Francisco Curbera, Rania Khalaf, Nirmal Mukhi, Stefan Tai, and Sanjiva Weerawarana, “The next step in Web services”, In
Communications of the ACM, 46(10):29-34, October 2003,
http://portal.acm.org/citation.cfm?id=944234&jmp=cit&dl=GUIDE&dl=ACM
[7] A. Keller, H. Ludwig (IBM), “The WSLA Framework: Specifying and Monitoring of Service Level Agreements for Web
Services”, IBM research report RC22456, 2002, http://www.research.ibm.com/resources/paper_search.shtml
[8] V. Tosic, B. Pagurek, K. Patel, B. Esfandiari, W. Ma, "Management Applications of the Web Service Offerings Language
(WSOL)", The 15th International Conference on Advanced Information Systems Engineering(CAiSE'03), Velden, Austria,
June 2003, http://www.sce.carleton.ca/~vladimir/publications.html
[9] D. D. Lamanna, J. Skene, W. Emmerich, “SLAng: A language for defining Service Level Agreements”, The Ninth IEEE
Workshop on Future Trends of Distributed Computing Systems (FTDCS'03), San Juan, Puerto Rico, May
2003http://csdl.computer.org/comp/proceedings/ftdcs/2003/1910/00/19100100abs.htm
[10] Zhou Chen, Chia Liang-Tien, Bilhanan Silverajan, Lee Bu-Sung, “UX – An Architecture Providing QoS-Aware and Federated
Support for UDDI”, The 2003 International Conference on Web Services (ICWS'03), Las Vegas, Nevada, USA, June 2003,
http://www.ntu.edu.sg/home5/PG04878518/ Articles/ICWS03_Paper.pdf
[11] M. Tian, A. Gramm, T. Naumowicz, H. Ritter, J. Schiller. "A Concept for QoS Integration in Web Services", 1st Web Services
Quality Workshop (WQW 2003), in conjunction with IEEE Computer Society 4th International Conference on Web
Information Systems Engineering (WISE 2003), Rome, Italy, December 2003,
http://csdl.computer.org/comp/proceedings/wisew/2003/2103/00/21030149abs.htm
[12] A. Keller, H. Ludwig, “Defining and Monitoring Service Level Agreements for dynamic e-Business”, The 16th USENIX
System Administration Conference (LISA'02), Philadelphia, USA, November 2002,
http://www.research.ibm.com/people/a/akeller/#Publications
[13] IBM Emerging Technologies Toolkit, http://www.alphaworks.ibm.com/tech/ettk
[14] D. Belaid, N. Provenzano, and C. Taconet, “Dynamic Management of CORBA Trader Federation”, 4th USENIX Conference
on Object-Orented Technologies and Systems (COOTS), 1998,
http://www.usenix.org/publications/library/proceedings/coots98/full_papers/belaid/belaid.pdf
[15] S. Kalepu, S. Krishnaswamy, and S. Loke, “Verity: A QoS Metric for Selecting Web Services and Providers1st Web Services
Quality Workshop (WQW 2003), in conjunction with IEEE Computer Society 4th International Conference on Web
Information Systems Engineering (WISE 2003), Rome, Italy, December 2003, http://alarcos.inf-
cr.uclm.es/wqw2003/kalepu%20ABSTRACT.pdf
[16] R. Al-Ali, O. Rana, D. Walker, S. Jha, and S. Sohail, G-QoSM: “Grid service discovery using QoS properties”, Computing
and Informatics Journal, Special Issue on Grid Computing, 21(5), 2003, http://www.cse.unsw.edu.au/~nrl/pub/papers/cijnl.pdf
[17] M. Tian, A. Gramm, H. Ritter, and J. Schiller. Efficient Selection and Monitoring of QoS-aware Web services with the WS-
QoS Framework. 2004 IEEE/WIC/ACM International Conference on Web Intelligence (WI'04), Sep. 2004, Beijing, China,
http://page.mi.fu-berlin.de/~tian/
[18] M. Tian, A. Gramm, H. Ritter, J. Schiller, and T. Voigt. QoS-aware cross-layer communication for Mobile Web services with
the WS-QoS Framework. Mobile Computing und Medienkommunikation im Internet (Mobile Computing and Media
Communication in the Internet), Informatik 2004, 34. Jahrestagung der Gesellschaft für Informatik (GI) (34th Annual
Conference of the German Informatics Society), Sep. 2004, Universität Ulm, http://page.mi.fu-berlin.de/~tian/
[19] Min Tian, Thiemo Voigt, Tomasz Naumowicz, Hartmut Ritter and Jochen Schiller. Performance Considerations for Mobile
Web Services. Elsevier Computer Communications Journal, Volume 27, Issue 11, 1 July 2004, Pages 1097-1105,
http://page.mi.fu-berlin.de/~tian/

13

View publication stats