Web services are a broad architectural technology that is built on other point technologies such as SOAP. In turn, SOAP is based on XML and HTTP, and uses networks (including the Internet) for communications. In order to understand quality of service for Web services, we must first understand the inherent limitations and bottlenecks of the underlying technologies and transport systems. Once we have a full grasp of these holes, we will be in a position to craft a Web services architecture that supports QoS.
SOAP messages are encoded in XML. Various aspects of Web services QoS are affected by XML because:
Given that XML is a human-readable and self-describing language for representing information, it incurs much overhead. In the next section, we see that HTTP also adds to the overall overhead and is another source of "holes" for QoS.
HTTP is the most prevalent transport for SOAP. HTTP is a lightweight, stateless protocol for distributed communications. HTTP was chosen because of its near ubiquitous status achieved as the protocol for the World Wide Web. Moreover, SOAP based on HTTP allows Web service messages to traverse enterprise firewalls easily, as many firewalls are already configured to allow HTTP traffic. As such, HTTP is a good choice since it supports near ubiquitous communications, and works with existing enterprise IT configurations.
As we have already seen, SOAP messages are relatively large, with the actual payload representing just a fraction of the entire message. These weighty messages must traverse communication networks between the client application to the actual Web service and then back again to the client application for each Web service invocations.
Some of these networks will be internal private networks, while others will be public shared networks, such as the Internet. In many cases, the messages will travel over a combination of private and public networks traveling some parts of its path on a private network and other parts on a public network. No matter what the type of network used, as Web services are used more often and the number of SOAP requests and responses mount, the communications network will be a significant source of latency.
The latency will not simply increase linearly with the increase in network traffic. When the demands placed on the network surpass its bandwidth, packets can simply be dropped. The sender of the packet will resend the packet only after a specified time-out period. For a successful Web service invocation, messages must be transmitted both for the request as well as for the response. So the percentage increase in network traffic that causes a packet to be dropped can result in a many times larger increase in application latency.
Web services do not exist within a vacuum. Instead, they must live in harmony with existing server-side and back-office infrastructure such as Web servers, application servers, databases, as well as legacy systems. Since many initial Web services are simply existing applications, including legacy and mainframe applications, which have been "wrapped" as Web services, server-side infrastructure also has a profound impact on the performance of Web services.
A typical Java 2 Enterprise Edition (J2EE) server-side infrastructure (together with the corresponding client side) is depicted in Figure 9-2.
Figure 9-2. Web services exist within and alongside server-side infrastructure.
How this server-side infrastructure may potentially impact a service's QoS measure must be taken into account.
As we have seen, a variety of systems and technologies contribute to the overall quality of a Web service. In the next section, we look at how to address some of these issues and best practices for doing so.