Quality of Service for Web Services-Demystification, Limitations, and Best Practices
Web Services are based on a collection of standards and protocols that allow us to make processing requests to remote systems by speaking a common, non-proprietary language and using common transport protocols such as HTTP and SMTP.
With the proliferation of Web Services as a business solution to enterprise application integration, the quality of service (QoS) offered by Web Services is becoming the utmost priority for service provider and their partners. Due to the dynamic and unpredictable nature of the Web, providing the acceptable QoS is really a challenging task. In addition to this, the different applications that are collaborating for Web Services interaction with different requirements will compete for network resources. The above factors will force service providers to understand and achieve Web Services QoS. Also, a better QoS for a Web Service will bring competitive advantage over others by being a unique selling point for service provider.
The Web Services QoS requirement mainly refers to the quality, both functional as well as non-functional, aspect of a Web Service. This includes performance, reliability, integrity, accessibility, availability, interoperability, and security. In this article, we are trying to cover each of these aspects, with first demystifying that quality aspect, then stating the problems to achieve the same in Web Service, and lastly we propose some of the solutions/best practices to be followed while orchestrating Web Services.
Web Services QoS "Stack"
We are proposing a QoS stack that addresses various issues that are present in different layers of the Web Services stack, which is depicted in Figure 1.
Figure 1: The layers of a Web Services stack
Web Services Performance
The performance of a Web Service is measured in terms of throughput, latency, execution time, and transaction time. Throughput represents the number of Web Services requests served in a given time period. Latency is the round-trip time between sending a request and receiving the response. Execution time is the time taken by a Web Service to process its sequence of activities. And transaction time represents the period of time that passes while the Web Service is completing one complete transaction. Higher throughput, lower latency, lower execution and faster transaction times represent good performing Web Services.
The overall performance of Web Services depends on application logic, network, and most importantly on underlying messaging and transport protocols, such as SOAP and HTTP, that it uses. The SOAP protocol is still maturing and harbors a lot of performance and scalability problems. The SOAP protocol uses a multi-step process to complete a communication cycle.
The SOAP request begins with the business logic of your application learning the method and parameter to call from a Web Services Description Language (WSDL) document. This whole process is a time-consuming one, which requires various levels of XML parsing and XML validation and hence hits the performance of the Web Service.
Analyzing the above situation and looking in to SOAP and other related standards, as of now we cannot get away with the steps of XML processing. Instead, we can optimize the XML processing steps.
Some of the best practices to be followed to achieve the same are listed below:
- Use of efficient and lightweight parsers.
- Efficient use of XML validation in production mode.
- Use of compressed XML for sending the messages over network.
- Web Service Caching
- Use of simple data types in SOAP messages as far as possible.
Web Services Reliability
Reliability is the overall measure of a Web Service to maintain its service quality. The number of failures per day, week, month, or year represents an overall measure of reliability for a Web Service. Reliability also refers to the assured and ordered delivery for messages being sent and received by service requestors and service providers.
The Web Services currently rely on transport protocols such as HTTP, which are inherently stateless and follow a best-effort delivery mechanism. It does not guarantee whether the message will be delivered to the destination.
The above problem rising due to the use of unreliable protocols can be solved using the following techniques:
- Use of asynchronous message queues.
- Adoption of new reliable transport protocols (such as HTTPR, REST, and BEEP).
Web Services Integrity
Integrity is the degree to which a system or component prevents unauthorized access to, or modification of, computer programs or data. 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; in other words, whether the database is consistent before and after a transaction: atomicity (no intermediate state).
Data Integrity is important for any object's proper functioning and must be assured or it could corrupt a larger program and generate a very difficult to trace error. Web Services transactions tend to be asynchronous and long running in nature. Transaction integrity is just one of several QoS elements, including security and process orchestration, which are missing from the first incarnations of Web Services standards of SOAP, UDDI, and WSDL.
Emerging standards in the business process management and transactions will help to achieve the desired QoS.
- Adopting standards such as BPEL4WS, WS-Coordination, WS-Transaction, and BTP would benefit service providers.