Introduction
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
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 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.
Limitations
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.
Best Practices
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
Demystifying
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.
Limitations
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.
Best Practices
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
Demystifying
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).
Limitations
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.
Best Practices
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.
Web Services Accessibility
Demystifying
Accessibility defines whether the Web Service is capable of serving the client’s request. High accessibility of Web Services can be achieved by building highly scalable systems.
Limitations
Building scalable systems are expensive, and this may cause smaller companies to defer this requirement. Also, this becomes an infrastructure issue for companies that deploy Web Services within their enterprise.
Best Practices
- Service pooling
- Load balancing (Scalability)
Web Services Availability
Demystifying
Availability defines whether the Web Service is ready for immediate consumption. Associated with availability is Time-to-Repair (TTR). TTR represents the time it takes to repair the Web Service.
Limitations
Building fault-tolerant systems for highly available Web Services is expensive. As companies roll out Web Services, the ability to manage this diverse, dynamic, distributed environment will become critical. Questions such as the following arise:
- Has one of my key servers become unavailable?
- Is a system being overly burdened?
- Why are requests taking so long?
Best Practices
- Web Service Management
- Web Service Clustering
Web Services Interoperability
Demystifying
The fundamental goal of interoperability in Web Services is to cross the lines between the development environments used to implement services so that developers using those services don’t have to think about which programming language or operating system the services are hosted on.
Limitations
Most of the Web Services specifications are defined under standards bodies. As these activities are under way, there seems to be a delay in the implementations. Vendors partly implement the specification in their products due to the competitive nature of this market. This results in poor interoperability.
Best Practices
- Key to enabling seamless Web Services interoperability is the ability of one Web Services framework to consume the WSDL documents generated by other frameworks.
- Web Services-Interoperability (WS-I) Profiles.
The Basic Profile defines how a selected set of specified Web Services technologies, such as messaging and discovery, should be used together in an interoperable manner.
Web Services Security
Demystifying
With the increase in the use of Web Services, which are delivered over the public Internet, there is growing concern towards security. Security for Web Services means providing non-repudiation and confidentiality by authorizing the parties involved, encrypting messages, and providing access control. The Web Service provider may apply different approaches and levels of providing security policy depending on the service requestor.
Limitations
SOAP is a de-facto messaging standard for Web Services; inherently, it does not support many security features. Some of the Web Services-enabled applications also require role-based security features, which expose different functionalities, depending on user credentials. Underlying technologies used by Web Services currently do not support these features.
Best Practices
The security-related issues in Web Service must be dealt with greater vigor, as it will build confidence among users. The following measures can be used while architecting the secure Web Services:
- Use of XML Encryption.
- Use of XML Key Management Specification.
- Use of Private WANs, Web Service Network, and VPNs.
- P3P (Platform for Privacy Preferences) is an emerging standard for specifying privacy preferences for a user while using Web Services.
- Use of security assertions.
Conclusion
QoS for Web Services is about bringing business value to service providers by guaranteeing a competitive edge through their ease of adoption and implementation. With these collections of best practices for the design and implementation of Web Services, one can think of Web Services as a perfect replacement for traditional integration problems that are being faced by the enterprises today. We will be analyzing each of these proposed best practices in forthcoming articles.
About the Authors
Rajesh Sumra is a senior software engineer in HP’s Wireless Solutions Lab. He has worked with the espeak project for more than a year and was involved in developing UDDI Server functionalities for the HP’s UDDI Server. Currently, he is involved with designing and developing a Web Services-based framework for the mobile infrastructure. Rajesh holds a Masters degree in Information Technology from IIIT, 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 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.
