Quality of Service for Web Services-Demystification, Limitations, and Best Practices for Performance

Introduction

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 service interaction with different requirements will compete for network resources. The preceding factors will force service providers to understand and achieve Web services QoS. Also, a better QoS for a Web service will bring a competitive advantage over others by being a unique selling point for a 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 the first part of this article, we covered each of the above QoS aspects from a broad perspective. Now, in each coming article we will look into each of the QoS in detail and will try to come up with solutions and explore best practices to be followed. In this article, we are trying to demystify the “performance” aspect of Web Services.

Web Services Performance

The Web services-QoS stack we proposed is shown in the following figure.

As you can see, the performance block (highlighted in purple) in the figure spans across almost all of the Web service layers on the left. It requires tuning at all layers to get a desired level of performance from Web service. Let us first briefly analyze this quality aspect, for demystifying and to see its limitations, and then work in depth on some of the optimal solutions.

Web Services Performance—Demystifying

The performance of a Web Service is measured in terms of throughput, latency, execution time, and transaction time. Throughput represents the number of Web service requests served at 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. 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 transaction times represent good performing Web Services.

Web Services Performance—Limitations

The overall performance of a Web service depends on application logic, network, and most importantly on underlying messaging and transport protocols such as the SOAP and HTTP 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 time consuming; it requires various levels of XML parsing and XML validation and hence hits the performance of the Web service.

Apart from these factors, the performance of a Web service becomes crucial if it uses the synchronous one where a consuming application is blocked for the time it gets a response from the Web service.

Web Services Performance—Best Practices and Solutions

Analyzing the above situations, following are some of the useful practices and solutions which we should have in mind while developing and exposing it to outside world. I am dealing with them layer by layer of the Web service stack.

1. At the Data Layer:
   At data layer of a Web service stack, the Web service is only sending/receiving XML messages through the network. Some of the best practices to be followed to achieve the same are listed below:
   1. Use of compressed XML for sending the messages over network:
      SOAP/XML messages are generally bigger in size than normal GET/POST calls, so we should try to compress the message if the network latency is bigger than CPU overhead for compression. Lots of XML compression tools are available from different vendors such as Oracle XDK and there are many open source tools also there to fit the budget.

   2. Use of simple data types in SOAP messages as far as possible reduces complexity to great extent. This reduces the processing time and increases maintainability; enhancements are easy to do.

2. At the Logical Layer:
   At the logical layer, Web service mainly deals in processing SOAP/XML messages. Being XML intensive at this layer, we should try to optimize XML processing steps. Some of the best practices to be followed to achieve the same are listed below:
   1. Use of efficient & lightweight parsers:
      There are many parsers available on the market, each vying for its performance. But, to get performance we should first analyze our application and its requirement. If the application requires big XML files to be exchanged, a SAX parser would be the best over a DOM parser. A DOM parser actually loads the whole document in memory and thus utilizes a considerable amount of the memory and processor. Instead, a SAX parser is event based, is faster, and does not consume much memory.

      Even better, if we know about XML messages that are coming (which is generally the case) from a client/application, we should try to use pull parsers instead of push ones. Using a pull parser will load only that part of XML, which is required by the application that time.

   2. Efficient use of XML validation in production mode.
      XML validation should be kept to minimum during the production mode because it generally slows down the parser. XML validation can be turned OFF for trusted parties after authorization has been done. And, instead of performing XML validation at the parser level, some critical validations, depending on application requirements, can be done at the application level.

   3. Web Service Caching:
      One must cache request results wherever possible in their Web service. Even the WSDL can be cached at the client side to minimize the multiple requests.

3. At the Presentation Layer:
   At the presentation layer, a Web service deals mainly with how to present the responses in an effective manner. Depending on the client, one can apply the following strategies:
   1. Repeated SOAP-client calls to access server state can choke a network and degrade the server performance. Cache data on the client whenever possible to avoid requests to the server.

   2. Ensure the client data remains up to date by using a call to a service, which blocks until data is changed.

Performance Monitoring

Tracing the performance of a Web service in real time gives lot of hints. We can actually identify the bottlenecks in the execution of a Web service. Once we know the problems, we can actually find solutions to it by applying best practices as mentioned above or by using better hardware. There are lot of tools and methodologies available for monitoring the performance.

You can find one at http://www.developer.com/services/article.php/2229161. The article tells about the Web service test harness framework.

Conclusion

The preceding article tries to demystify the performance QoS of Web services, analyze its limitations, and then propose some optimal solutions. The solution we proposed can be used to boost up the performance of the Web services. The actual power of making or breaking the system still depends on our understanding of the requirements and architecture of a Web service. A good understanding will lead to best solutions by narrowing down to problems in the system. In the next article, we will in a similar way analyze the other main aspects of Web Service QoS.

About the Authors

Rajesh Sumra has been working as a Senior Software Engineer for Hewlett-Packard. He has about three years of industry experience. He has extensively worked on Web service technologies such as WSDL, SOAP, and UDDI. Currently, he is involved in designing and developing a Web services-based framework for a mobile infrastructure for HP Labs, Japan. He holds a Masters degree in Information Technology from the Indian Institute of Information Technology, Bangalore. He can be reached at rajeshsumra@yahoo.com.

Arulazi D has been designing and building Java-based applications and SDK for more than three years. He was also involved in the API development of the UDDI4j project (http://uddi4j.org). He works with Hewlett-Packard (ISO), where he is involved in the development of an open service framework for mobile infrastructures. He holds a Master of Computer Applications degree from the PSG College of Technology, Coimbatore. He can be reached at aruld@acm.org.

References

• http://www.developer.com/services/article.php/2027911
• http://www.developer.com/services/article.php/2229161