Quality of Service for Web Services-Demystification, Limitations, and Best Practices for Performance
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.
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.
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.
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:
- 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.
- Ensure the client data remains up to date by using a call to a service, which blocks until data is changed.
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.
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 email@example.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 firstname.lastname@example.org.
Page 2 of 2