This document describes quality-of-service (QoS) requirements for web services. With the proliferation of web services as a business solution to enterprise application integration, the QoS for web services is becoming increasingly important to service providers. However, due to the dynamic and unpredictable characteristics of the web services, it is not an easy task to provide the desired QoS for web service users. Furthermore, different web service applications with different QoS requirements will compete for network and system resources such as bandwidth and processing time. Nevertheless, an enhanced QoS for a web service will bring competitive advantage for service provider. To provide such a better QoS, it is first necessary to identify all the possible QoS requirements for web services, which is the objective of this document. This document also discusses possible approaches for supporting the web service QoS.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the first W3C Note of the Web Services QoS Requirements and Possible Approaches document.
It is a chartered deliverable of the Web Services Architecture Working Group, which is part of the Web Services Activity. This Note represents the Working Group's consensus agreement as to the current set of requirements for the Web Services Architecture. The Working Group considers this document to be a living document and may add or change the requirements as the analysis of the architecture proceeds through the Working Group's deliberations. The Working Group requests feedback and comments on this Working Draft from the Web services community and other W3C Working Groups.
Publication as a Working Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. Patent disclosures relevant to this Note may be found on the Math Working Group's patent disclosure page.
The QoS requirements for web services here mainly refer to the quality aspect of a web service. These may include performance, reliability, scalability, capacity, robustness, exception handling, accuracy, integrity, accessibility, availability, interoperability, security, and network-related QoS requirements. In the subsequent sections, we define each of these quality aspects and describe desired requirements, based on the various research efforts [1-11] in this area.
The performance of a web service represents how fast a service request can be completed. It can be measured in terms of throughput, response time, latency, execution time, and transaction time, and so on [2, 4].
Throughput is the number of web service requests served in a given time interval. Response time is the time required to complete a web service request. Latency is the round-trip delay (RTD) between sending a request and receiving the response. Execution time is the time taken by a web service to process its sequence of activities. Finally, transaction time represents the time that passes while the web service is completing one complete transaction. This transaction time may depend on the definition of web service transaction.
In general, high quality web services should provide higher throughput, faster response time, lower latency, lower execution time, and faster transaction time.
Web services should be provided with high reliability. Reliability here represents the ability of a web service to perform its required functions under stated conditions for a specified time interval . The reliability is the overall measure of a web service to maintain its service quality. The overall measure of a web service is related to the number of failures per day, week, month, or year. Reliability is also related to the assured and ordered delivery for messages being transmitted and received by service requestors and service providers .
Web services should be provided with high scalability. Scalability represents the capability of increasing the computing capacity of service provider's computer system and system's ability to process more users' requests, operations or transactions in a given time interval . It is also related to performance. Web services should be scalable in terms of the number operations or transactions supported.
Web services should be provided with the required capacity. Capacity is the limit of the number of simultaneous requests which should be provided with guaranteed performance . Web services should support the required number of simultaneous connections.
Web services should be provided with high robustness. Robustness here represents the degree to which a web service can function correctly even in the presence of invalid, incomplete or conflicting inputs . Web services should still work even if incomplete parameters are provided to the service request invocation.
Web services should be provided with the functionality of exception handling. Since it is not possible for the service designer to specify all the possible outcomes and alternatives (especially with various special cases and unanticipated possibilities), exceptions should be handled properly . Exception handling is related to how the service handles these exceptions.
Web services should be provided with high accuracy. Accuracy here is defined as the error rate generated by the web service . The number of errors that the service generates over a time interval should be minimized.
Integrity for web services should be provided so that a system or component can prevent unauthorized access to, or modification of, computer programs or data. There can be two types of integrity: data integrity and transactional integrity. Data integrity defines whether the transferred data is modified in transit. Transactional integrity refers to a procedure or set of procedures, which is guaranteed to preserve database integrity in a transaction .
Web services should be provided with high accessibility. Accessibility here represents whether the web service is capable of serving the client's requests . High accessibility can be achieved, e.g., by building highly scalable systems.
The web service should be ready (i.e., available) for immediate consumption. This availability is the probability that the system is up and related to reliability . Time-to-Repair (TTR) is associated with availability. TTR represents the time it takes to repair the web service . The service should be available immediately when it is invoked.
Web services should be interoperable between the different development environments used to implement services so that developers using those services do not have to think about which programming language or operating system the services are hosted on .
Web services should be provided with the required security. With the increase in the use of web services which are delivered over the public Internet, there is a growing concern about security. The web service provider may apply different approaches and levels of providing security policy depending on the service requestor.
Security for web services means providing authentication, authorization, confidentiality, traceability/auditability, data encryption, and non-repudiation. Each of these aspects is described below [2, 4].
To achieve desired QoS for web services, the QoS mechanisms operating at the web service application level must operate together with the QoS mechanisms operating in the transport network (e.g., RSVP, DiffServ, MPLS, etc.) which are rather independent of the application. In particular, application level QoS parameters should be mapped appropriately to corresponding network level QoS parameters. Basic network level QoS parameters include network delay, delay variation, and packet loss, and they are described as follows.
The network delay is the average length of time a packet traverses in a network. The network delay can be handled by a good network design that minimizes the number of hops encountered and by the advent of faster switching devices like Layer 3 switches and tag switching system such as MPLS systems and ATM switches.
The delay variation is the variation in the inter-packet arrival time (leading to gaps, known as jitter, between packets) as introduced by the variable transmission delay over the network. Removing jitter requires collecting packets in buffers and holding them long enough to allow the slowest packets to arrive in time to be played in correct sequence. Jitter buffers may cause additional delay, which is used to remove the packet delay variation as each packet transits the network.
The Internet does not guarantee delivery of packets. Packets will be dropped under peak loads and during periods of congestion. Approaches used to compensate for packet loss include replay of the last packet, and transmission of redundant information. Out of order packets may need to be re-ordered at the receiver.
In addition, network management mechanisms may also be involved in controlling and managing QoS for web services.
The existing UDDI can be extended to support web service QoS. For example, it may be extended to publish QoS-enabled web services by registering them at the UDDI registry. To achieve this, the existing UDDI data structure should be extended to describe specific QoS information of a web service. The following example shows the
The existing SOAP can be extended to find web services which satisfy specific QoS requirements. This can be achieved by extending the format of SOAP messages. A possible way is the use of a query to find desired web services. In response to the query, a result message which contains a proper web service can be generated.
The following example shows how to find appropriate web services using a query message . In the example, a query message is used to find a car reservation web service of which availability is 0.9.
The following example shows the contents of a result message generated in response to the query message .
It is also possible that a SOAP sender may want the SOAP message to be handled with specific QoS as it traverses the SOAP message path to include multiple SOAP intermediaries. Information in the SOAP message can be used to select appropriate QoS mechanisms (e.g., RSVP, Diffserv, MPLS, etc.). Selection of a QoS mechanism may be constrained by certain QoS policies and Service Level Agreements (SLAs).
A SOAP header block may be used for implementing the above scenario . For example, an initial SOAP sender can send a SOAP message containing a QoS header block through one or more SOAP intermediaries to the final SOAP receiver. This can be considered as a QoS-aware SOAP message routing. The following shows an example of such a routing where mycompany.com is a message sender, japan.rental.com and asia.rental.com are message forwarders, and usa.rental.com is the ultimate message receiver .
The SOAP intermediary should extract and interpret QoS information from the SOAP QoS block, and determine how to invoke the QoS capabilities. If the SOAP intermediary is not QoS-aware, then a SOAP error message which indicates that this SOAP QoS block cannot be handled should be generated. If the SOAP intermediary is QoS-aware, then the information in the QoS block can be used when forwarding the SOAP message further along on its message path toward the final SOAP receiver.
It may be necessary to certify the result messages from the UDDI registry in response to a query about QoS-enabled web services. To achieve this, an efficient certification protocol  may need to be defined, which describes how to register and certify the QoS-related information.
If a SOAP node sends SOAP messages using HTTP, extensions to the HTTP binding may be required to invoke the lower layer QoS mechanisms such as RSVP, Diffserv, MPLS, etc. In this case, interactions with the lower layer QoS mechanisms should be well defined. For example, traffic classification of the HTTP flow may be done using Diffserv, and therefore particular per-hop behaviors can be used within the network route to the next SOAP node. Traffic classification for Diffserv can be done by the SOAP node sending the SOAP message, or by network devices. If traffic classification is preformed by a network device, communications between the SOAP node and the network device may be needed, e.g., to provide the network device with the TCP port numbers and IP addresses of the HTTP connection. This may need an efficient way to obtain the port and address information . The QoS-related information may also be included in the differentiated services code point (DSCP) of the IP header which can be used for traffic classification. In this case, it should be possible to extract and interpret the DSCP information for appropriate forwarding to the next SOAP node. Based on the QoS-related information, incoming SOAP messages will be treated differently.
QoS support for web services can provide a new business value to service providers by guaranteeing a certain service quality for users. An enhanced QoS for a web service will bring a highly competitive advantage for web service providers. As a first step toward providing such an enhanced QoS, this document identified various QoS requirements for web services, including performance, reliability, scalability, capacity, robustness, exception handling, accuracy, integrity, accessibility, availability, interoperability, security, and network-related QoS requirements. This document also discussed some possible approaches for supporting web service QoS. More detailed QoS requirements and solutions are for further study.