Modeling the Aspects of Quality of Service in Web Services and ...

Modeling the Aspects of Quality of Service in Web Services and Service
Oriented Architectures
Art Sedighi
Rensselaer Polytechnic Institute
sediga@av8.net
Abstract
We propose a model by which Quality of Service
(QoS) can be used as the means of requesting a
service. This model integrates the notion of QoS into
Service Oriented Architectures (SOA), and
recommends additions to the current working
standards that would take advantage of QoS. The
recommended extensions to the current working
documents of the Web Services will be minor and will
allow a method to implement an end-to-end QoS
method, which will start from the service discovery
phase. The extensions will allow the Service
Consumer to search the service directory and use the
Quality Attributes that are most important to it. The
directory can fulfill the quality demand of every
Service Consumer and allow for a more proactive
service discovery phase.
1. Background
In [15] [16], it is argued that QoS must be
configurable, predictable and maintainable on an
end-to-end basis. [10] adds that meeting service
guarantees is fundamentally an end-to-end issue, and
that means from application-to-application.
With new trends in System Integration,
architectural patterns, growth and maturity of Web
Services (WS) and its supporting protocols
(Universal Description Discovery & Integration
(UDDI) [7], Web Services Description Language
(WSDL) [8] and Simple Object Access Protocol
(SOAP) [5]), it is crucial to take into consideration
the aspect of service quality as it pertains to WS.
IBM has introduced the concept of QoS in a new
protocol called Web Services Endpoint Language
(WSEL) [2] [3]. A problem with WSEL is that it
applies the concept of QoS atop WSDL and after the
service discovery phase.
In the Service Oriented Architecture (SOA)
scenario [17], it is possible for a single Service
Consumer (SC) or Service Requestor as depicted in
[2] to request a service that can potentially be offered
by more than one Service Provider (SP). In order for
the SC to be able to distinguish between SPs, we
have introduced the idea of quality as the
distinguishing factor between services that provide
the same service at the service discovery phase.
More generally, in this research we have applied
some of the basic principles of QoS to SOA. In
doing so, we have found that QoS should be an
integral part of the end-to-end SOA, due to the
flexibility and dynamic ability of WS to be boundedto
at run-time -- from discovery until the service
release phase.
The current UDDI draft standard does not have
the notion of quality. As mentioned before the only
related work in the area of applying QoS into WS’s is
done in [1] and using WSEL. But WSEL fails to
apply QoS to discovery phase. When a SC searches
for a service, UDDI returns the results and it is up to
the SC to choose between the SPs that match its
criteria. UDDI searches for keywords entered by the
SC. If a match is found, the SPs that match the
search results are returned to the requestor. The SC
then chooses from one of the returned options and
thru WDSL, it goes thru an interface discovery
session. After the public interface of the SP has been
realized, the SC starts using the service. By the
recommended WSEL working documents, this is the
point where the SC can determine the quality of the
SP. WSEL does not carry the notion of multiple SPs
providing the same service, and enabling a SC to
choose a service at the early stages using the quality
of the SP.
The recommended protocol to send messages
between the SP and the SC is SOAP. The SC, after
getting the results back from the SP, may choose to
keep using the service or simply drop the service.
There is no way of telling whether a SC is satisfied
with the service that was provided by the SP.
Furthermore, there is no way for the SC to realize the
attributes of the SP before binding. There are also no
standard ways of keeping history, nor is there a way

to determine if the quality of a service has been
changed since the previous encounter of the two
parties.
2. Significance
QoS can be used as the means of measuring
applicability when searching for a service, and after
the usage of the service for measuring the efficacy of
the SP. The notion of QoS applies to an end-to-end
basis, so QoS in the context of WS becomes an
abstract term by which the quality as perceived by an
SC can be measured. The quality perceived by a
number of SCs may vary greatly for the same service
provided by a single SP. In this research, the term
QoS is the perceived quality by an SC that is
exclusive of all the other SCs that are using the same
service. Thus, it becomes important, as the number
of SPs increase, the ability to determine with some
level of certainty the quality of a service in order to
distinguish between the various SPs.
There are two ways of measuring quality:
• Determine attributes before
• Calculate quality after the usage
Since we are, for the purpose of this research, not
interested in self-improving services (intelligent
agents, self modifying code, etc), the latter of the two
options is not of value. We would like to be able to
predetermine as much as we can about a service
before we start using it. Based on the current
working standards, there is no way for an SC to
determine if a service is better than another service
offered. For the situation where services are
deployed over the Internet and an SC must pay-perusage,
it is crucial to find as much as possible about a
service before an SC starts using a service.
3. Approach and Methodology
This paper will show the benefits of adding the
notion of QoS to WS and SOA at the service
discovery phase. We will propose an extension to the
current protocols through an elaborated example in
which a number of SPs provide search engine
services with each one having a different search
algorithm. It will start by integrating the basic
principles of QoS outlined in [10] into WS. These
principles are as follows:
• Principle of Integration
• Principle of Separation
• Principle of Transparency
• Principle of Asynchronous Resource
Management
• Principle of Performance
Each of these principles will be depicted as they
apply to the concept of WS and SOA.
A brief description of the components that make
up WS, mainly UDDI, WSDL, WSEL and SOAP,
will be given along with the role that each component
plays in a SOA. An example application that utilizes
the SOA will be shown to clarify the changes that
need to be made to current protocols. This research
mainly focuses on the role that QoS plays in the
service discovery phase – a role that is played by the
proposed UDDI standard. Therefore, a more detailed
description of the UDDI will be given along with a
list of proposed changes to the current proposed
standard to allow it to take advantage of QoS. These
changes even thought very minor, play an important
role in the discovery and usage of a service.
Our example consists of a series of SPs that
provide a document search service to the SCs in an
enterprise. The SPs receive queries from the various
SCs and search a database for matches – Boolean or
otherwise. Each SP employs a different search
algorithm and depending on the SCs needs, a
different SP is used. The SCs, through the service
discovery process, will determine which SP will be
able to handle their request. In addition to the basic
search criteria, which we will call Functional
Attributes (FA), there can be other search criteria
used to determine the applicability of the SP.
Quality Attributes (QA) will be used in
conjunction with the FAs to determine the QoS of an
SP. During the service discovery process, the QAs
are used to map the applicability of each SP’s
capabilities to the SC’s request and are assigns a
value. The combination of all the values assigned
via these QAs will be called the QoS Value (QV)
throughout this paper. We aim to model the
discovery dialog that takes place before a service is
acquired in order to predetermine the QV based on
the QAs that are of significant value to an SC.
In the current working standard, it is mainly the
FAs that are taken into consideration. Examples of
FAs are the service name and contact phone number.
In [1] examples of what it called non-functional
properties, or what is called QA in this research, are
given:
• Availability: the availability of service for
use
• Accessibility: the probability degree of
success of accessing the service
• Integrity: available mechanisms for ensuring
data integrity considered – rolling back in
case of failure, for example
• Performance: the performance of the service
using some available metric(s)
• Reliability: the reliability of the service
using some available metric(s)

• Regulatory: Regulatory and legal
compliance
• Security: the security of the service in terms
of communication with the SC
It is important to note that some of the QAs are
very difficult to quantify: some heuristic needs to be
considered to determine some of these values. Past
history can be used as an estimate for some the QAs
that are difficult to quantify. For purposes of this
research, it is assumed that these estimations have
some basis and are kept up to date by the SP. In
addition to the dynamic flexibility of SOA, we also
aim to show that the notion of QoS also benefits
reliability, scalability and predictability of a
distributed architecture.
4. QoS Principles
As mentioned in the previous section, the
principles of QoS [10] need first be applied to the
concept of SOA and WS to ensure the integrity of our
model.
Some of these principles are as follows:
• Principle of Integration
• Principle of Separation
• Principle of Transparency
• Principle of Asynchronous Resource
Management
• Principle of Performance
The Principle of Integration states that QoS must
be configurable, predictable and maintainable over all
architectural layers to meet the end-to-end QoS [9].
The focus of this paper is on the predictability factor
of QoS as it applies to WS during the service
discovery phase initiated by the SC. The ability to
configure and maintain QoS will be secondary, since
they are for the most part left for the implementer of
the SC and the SP.
The Principle of Separation states that content
transfer, control and management are functionally
distinct architectural activities [11]. In SOA, each of
these activities, are accomplished separately by virtue
of how the UDDI protocol finds and manages
services.
The Principle of Transparency states the
application should be shielded from the underlying
QoS management and maintenance. The Principle of
Asynchronous Resource Management models the
control and management mechanisms of QoS [11].
The Performance Principle includes a wide variety of
guidelines from [12] [13] and [14]. Some aspects of
these principles do not apply to WS and SOA as it
stands today. It is important to mention them to
ensure that the changes proposed will not negatively
affect these principles.
5. Web Services Technologies
The four main protocols proposed for WS and
their purpose and functionalities are explained in this
section. However, it is beyond the scope of this
document to explain each protocol in detail. The
reader is referred to [7] for UDDI, [8] for WSDL, [2]
and [3] for WSEL and to [5] for SOAP.
5.1 UDDI
The Universal Description, Discovery, and
Integration is used for the discovery of services. It is
a specification for publishing and finding businesses
and services provided by those businesses.
5.2 WSDL
The Web Services Description Language is used
to describe the interface of the service, its available
functions and their signatures.
5.3 WSEL
The Web Services Endpoint Language is used to
model non-functional characteristics of services.
This protocol is currently being developed by IBM.
5.4 SOAP
The Simple Object Access Protocol is an XMLbased
protocol for exchanging information between
applications or services.
6. Search Engine Service
Without the use of QoS, only the FAs of a search can
be verified. Figure 1 shows how that task is
accomplished today. The services publish their
service description and other information needed to
access the service to the directory service.
The User Application or the SC search the
directory, implemented in UDDI, for a specific
service. For the purposes of this paper, we will use a
generic Search Engine Service (SES) to demonstrate
our proposed extension to UDDI. The SES takes
queries from the SC and searches a backend database
or other available databases for results request it by
the SC. For the simple case as depicted in Figure 1,
the current working standard for UDDI will suffice.
There are three SES’s, each one offering different
FAs; each one is using a different algorithm to do the
search.
In this scenario, where FAs can be used to
distinguish between the services, a simple search by
service type will unveil the desired service. It is
unpredictable, however, if there are many SPs
offering services with the same FA. The

distinguishing factor between the SES’s in Figure 2
are the QAs discussed in this paper.
UDDI
Directory
Find
User
Application
Publish
Publish
Publish
Bind
Search Engine
(Algoritm A)
Search Engine
(Algoritm B)
Search Engine
(Algoritm C)
number of SPs increase. With wider acceptance of
WS’s, it will be prudent to allow the SPs a way to
distinguish themselves from other SPs whom offer
the same service. The distinguishing factor must be
QAs, due to the fact that the FAs of the competing
SPs are the same.
Another complication with the current working
model arises when the marginal benefit of choosing a
service is solely determined by QAs. Figure 3
illustrates this scenario.
The marginal benefit of choosing the SES with
algorithm A should be greater than the benefit gained
from choosing the SES with algorithm B or algorithm
C. If the search performed by SES with algorithm A
is faster by 5 seconds, and it would take 10 seconds
to transfer the data from San Jose (SJ) to New York
(NY) as opposed to the SES with algorithm B which
would have the same results in 7 seconds but with
only a 1 second travel time of the results, the SC is
better off choosing the SES with algorithm B. This
trade off is not modeled in the current working
standards. QAs of a service need to taken into
account to address this scenario.
Figure 1: The Basic Pattern of the Service
Oriented Architecture
Search Engine
(Algoritm A)
SJ
Search Engine
(Algoritm C)
NY
Publish
Search Engine
(Algoritm A)
Publish
UDDI
Directory
(SJ)
UDDI
Directory
(NY)
Publish
Publish
Search Engine
(Algoritm B)
NY
Find
UDDI
Directory
Publish
Search Engine
(Algoritm A)
User
Application
Find
User
Application
Bind to ?
Publish
Search Engine
(Algoritm A)
Figure 2: Service Providers All with the Same
Functional Attributes
In Figure 2, all the SPs have the same FAs; they
are all using the same algorithm to do the search. A
simple service type search will not be able to unveil
any potent information about the services available.
This scenario will be the more likely scenario as the
Figure 3: Effects of Marginal Benefit in Choosing
a Service
The above scenario would become more
unpredictable if all the services have the same FAs
and only vary in their QAs. This situation would be
described by economists as perfect competition [18].
Currently, the UDDI protocol works as follows:
The User Application sends a request to the directory,
and the UDDI returns with the results. The request
for the SES depicted in figure 1 is as follows:
%AlgorithmB%

We assume in this case that the business key is
known and Acme Web Services is offering the three
search engines mentioned before. For large scale,
over the Internet deployment, the SC must be able to
leave out the business key field and search the
directory solely using keywords.
The UDDI, which has the three SES’s registered
with it, returns the following results to the User
Application:
Acme Search Service B
There are API implementations that encapsulate
UDDI protocol such as UDDI4J [6] by IBM, but the
underlying wire-format messages sent back and forth
between the UDDI directory and the user Application
are very similar as shown above.
7. Proposed Extensions to UDDI
The concept of distinguishing between
Functional Attributes and Quality Attributes is the
first step towards adopting the notion of QoS onto
Web Services. As with defining any language, there
are a number of obstacles that need to be overcome in
order to create a Ubiquitous Language that would
describe Quality Attributes:
• Semantic ambiguity of the attributes
o Example: turn_around_time = 60 sec
vs. turn_around_time = 1 min
• Syntactic ambiguity of attributes
o Example: turn_around_time vs.
turnAroundTime
• Ambiguity of application specific attributes
o Example: Two SPs have the same QAs,
but each one is expressed differently.
For instance, one service might express
reliability as a percentage (99.999%),
versus another which expresses it in
days, of a continuously running service
In order to mitigate some of these difficulties, we
have broken Quality Attributes into two
subcategories: Application Specific QAs, and
General QAs. There should be an agreed upon set of
QAs that would be common to all services, and there
could also be QAs that are more specific to an
application type. We have also added the concept of
Quality Weights (QW) as the means of measuring the
importance factor of a QA.
As mentioned before, there is no direct way to
distinguish between SPs offering the same service.
Thus, the SCs need the ability to state their quality
requirements such as reliability, precision,
availability of service, turn around time of results and
other non-functional attributes, in order to be able to
decide on an SP in real-time.
These QAs need to be generic to all the attributes
to enable an SC to discover the appropriate SP. It is
important to mention that QAs are only needed if the
SC desires a better-than-best-effort service, and are
not mandatory to the service discovery process.
Table 1 lists some of the Application Specific
and General QAs. For Reliability and Security, there
could be many attributes associated with them. Only
an abstract attribute of each is depicted in table 1.
8. Measuring Quality
The SC will choose some or the entire QA list
shown in table 1. These attributes are chosen based
on the needs of the SC and the task that needs to be
accomplished. There could be other attributes, but
the list mentioned in table 1 represent the most
common attributes that are required to represent
quality of a service. The weight of each attribute is
sent by the SC initially to the UDDI during the
service discovery phase. The SC along with the list
of the attributes sets a flag called calculate_qos to
true or false depending on whether it wishes the
UDDI to calculate the QoS of a service on its behalf,
or the SC wants the UDDI to send back the attributes
along with their values to be calculated by the SC.
This flag is very useful for mobile devices or devices
with limited computing capability to off load the QoS
calculation that could sometimes be processor
intensive to the directory. From the QoS values
returned by the UDDI directory, the SC determines
which service it will connect to. An example of the
UDDI service find query is shown below:
%AlgorithmB%
80

1
< comm_protocol match =“exact”>
HTTPS
< security_type match = “exact”>
SSL
< time_scale match = ‘exact”>
sec
< ta_time match = “max”>
3600
< relative_scale match = “exact”>
%
< reliability match = “min”>
85
The UDDI upon receiving this message will
modify the search by taking the QAs with the highest
weights into account. Weights of zero represents
informational fields and are used to establish the
clear protocol between the SC and the UDDI. Any
scale attributes, such as time_scale, would be
considered informational and are used to establish the
basis for the dialog between the SC and UDDI.
Using the “match” field of every attribute, UDDI
can narrow the search and better estimate the Quality
Value (QV). The “match” field dictates the accuracy
of the desired QA. The “match” field can have four
different values:
• exact – the QA value must match exactly
• min – the value given for the QA is the
minimum desired value
• max – the value given for the QA is the
maximum allowed
• value unknown – the value for the QA is not
known
The UDDI will then use the search result to
calculate the QV as follows:
• For each QA that meets the accuracy
requirement, the value of the weight is
added to the overall QV.
• For each QA that does not meet the accuracy
requirement, the value of the weight is
subtracted from the overall QV.
• The attributes with a weight of zero are used
to establish dialog and ensure the scale of
comparison of data
• The attributes with an unknown value are
not considered, and only indicate to the
directory that the SC is interested in
knowing the value. The values for these
attributes indicated unknown are returned
with the search results
The weights assigned are arbitrarily and relative. The
UDDI returns the QV for the services that closely
match the required attributes and the SC determines
to which SP to connect to.
Let us assume initially that the SC has requested
the directory to calculate the QV, and return it with
the search result. In this case, the following would be
returned from the directory as it conforms to figure 2.
Acme Search Service B1
175
Acme Search Service B2
205
1 Due to space limitations, we have abbreviated the
word quality_attribute with ‘qa’ and the
with

Type Attribute Attribute Name Example
Application Specific Accuracy of results result_accuracy
result_accuracy = 78
weight = 100
Interface requirements interface_grammar
interface_grammar = “int int string
real”
weight = 10
comm_protocol = https
weight = 40
Protocol used
comm_protocol
Security variables: type of
security – certificate and the
location of the certificate, etc… security_type
Session state variables: session
timeout, maximum number of
session variables allowed, keep
alive timeout
Time scale
Acme Search Service B3
25
In the scenario described above, Acme Services
Corp. offers three SES’s, all using the same
session_timeout,
max_session_var,
keep_alive_to
time_scale
General Value scale value_scale
Cost scale
Size scale
Relative scale
Price
Turn around time of results
Bandwidth requirements
Total data to be transmitted
Reliability
Login Required
cost_scale
size_scale
relative_scale
cost_per_usage
ta_time
bandwidth_req
est_data_size
reliability
req_login
Table 1: Quality Attributes and Example Values
security_type = SSL
weight = 40
session_timeout = 600
max_session_var = 10
keep_alive_to = 30
weight = 10
time_scale = seconds
weight = 0
value_scale = real
weight = 0
cost_scale = USD
weight = 0
size_scale = KB
weight = 0
relative_scale = %
weight = 0
cost_per_usage = 0.50
weight = 101
ta_time = 360
weight = 90
Bandwidth_req = 256
Weight = 10
est_data_size = 1024
weight = 10
reliability = 99.999
weight = 100
req_login = false
weight = 10
algorithm, algorithm B. Based on the QAs desired by
the SC, the directory service calculates the (QV) and
returns it with the search results. The SC can then
determine to which SES it wants to connect to: Acme
Search Service B2 in this case.
9. Benefits of QoS
In addition to the filtering ability gained during
discovery time by the SC in choosing an SP, the SC
can cache the returned QVs for later use. In recovery
time, the QVs can initially be used to further
investigate the possibilities of choosing a backup.
The backup and recovery benefits of adding QoS is

even greater when the environment in which these
services are deployed is closely administered. Other
scenarios in which the QoS can be of use is during
the contract negotiation phase between the two
parties, either in person or electronically.
10. Conclusion
In this paper, we have shown some proposed
extensions and their benefits to WS during the
service discovery phase. The concept of Quality
Attributes and Quality Weights were introduced to
enable the Service Consumers to make a more
deterministic and predictable decision when choosing
to bind to a service. These attributes can also ease
the unpredictability of fail-over situations and aid the
choosing of a backup service during recovery. We
recommend these changes to be implemented in
UDDI to enable a true end-to-end Quality of Service
capability for Web Services.
11. Future Work
More research needs to be done on the modeling
of the various stages of Web Services. Furthermore,
the application of Web Services in Software Agents
needs to be further studied.
12. Acknowledgement
The author would like to thank Ken Brooks for his
tireless feedback and for assistance with this research
project.
13. References
[1] Anbazhagan Mani, Nagarajan Arun, Understanding
quality of service for Web services, IBM developerWorks,
http://www-
106.ibm.com/developerworks/webservices/library/wsquality.html,
April 2004
[2] Judith M. Myerson, IBM Software Group, Advancing
the Web services stack,
IBM developerWorks, http://www-
106.ibm.com/developerworks/webservices/library/ws-wsa,
April 2004
[3] IBM Web Services Architecture Team, Web Services
architecture overview, IBM developerWorks, http://www-
106.ibm.com/developerworks/web/library/w-ovr/, April
2004
[4] Kreger Heather, IBM Software Group,
Web Services Conceptual Architecture (WSCA 1.0),
IBM Web Services, http://www-
3.ibm.com/software/solutions/webservices/pdf/WSCA.pdf,
April 2004
[5] Simple Object Access Protocol (SOAP) 1.2, World
Wide Web Consortium, http://www.w3c.org, April 2004
[6] UDDI4J Java API, IBM UDDI4J V2.0.2, Online-
Documentation,
http://www-
124.ibm.com/developerworks/oss/uddi4j, April 2004
[7] UDDI Version 3 Specification, UDDI.org,
http://www.oasis-open.org, April 2004
[8] Web Services Description Language (WSDL) 1.1,
World Wide Web Consortium, http://www.w3c.org, April
2004
[9] Campbell, A., Coulson, G., García, F., Hutchison, D.,
and H. Leopold, “Integrated Quality of Service for
Multimedia Communications”, Proc. IEEE Infocom’93,
Hotel Nikko, San Francisco, CA, March 1993
[10] Campbell, A., “A Quality of Service Architecture”,
Ph.D. Dissertation, Computing Department, Lancaster
University, January 1996
[11] Lazar, A.A., “A Real-time Control, Management, and
Information Transport Architecture for Broadband
Networks”, Proc. International Zurich Seminar on Digital
Communications, pp. 281-295, 1992
[12] Saltzer, J., Reed, D., and D. Clark, "End-to-end
Arguments in Systems Design", ACM Trans. on Computer
Systems, Vol. 2, No. 4, 1984
[13] Tennenhouse, D.L., “Layered Multiplexing
Considered Harmful”, H. Rudin and R. Williamson, eds.,
Protocols for High-Speed Networks, pages 143-148,
Amsterdam, North-Holland, 1989
[14] Clark, D., and D.L. Tennenhouse, "Architectural
Consideration for a New Generation of Protocols", Proc.
ACM SIGCOMM ‘90, Philadelphia, USA, 1990
[15] Private communication with Chris Sluman, 1995
[16] Anderson, M., Tzou, S.Y., Wahbe, R., Govidan, R.
and Andrews, M., "Support for Continuous Media in the
DASH System", Proc of the 10th International
Conference on Distributed Computing Systems, Paris, May
1990
[17] Graham, S., Simeonov, S., Boubez, T., Davis, D.,
Daniels, G., Nakamura, Y., Neyama, R., Building Web
Services with Java, Sams Publishing, USA, 2002
[18] Perfect Competition, Land and Freedom Lessons in
Economics,
http://www.landandfreedom.org/econ/econ8f.htm, April
2004