Where Are the Holes?

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.

XML

SOAP messages are encoded in XML. Various aspects of Web services QoS are affected by XML because:

• XML representations of data result in significantly larger documents than their binary counterparts.

• Instantiating an XML parser takes time and increases the memory footprint, especially as these parsers grow increasingly bloated trying to support newer XML features.

• Parsing XML information from within a SOAP envelope is expensive, with respect to processor time and power consumption.

• SOAP data typing information results in larger XML documents.

• Generating XML from the application or service's native data representation adds further overhead in processor time and power consumption.

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

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.

Communication Networks

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.

Server-Side Infrastructure

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.

• Web servers: Are usually the front end of a n-tier architecture for distributed computing. Web servers accept incoming requests and route the requests to the appropriate application server based on load balancing and other techniques. As the front door access to a Web service, the performance, availability, reliability, and other QoS measures of the Web server itself will place a limit on the QoS measures of the Web service. For example, a Web server with high latency (response time) or low reliability will place a lower bound on the overall QoS measure of the actual Web service.

• Application servers: Implement "containers" that host various components of the business logic of an application. For a Java 2 Enterprise Edition (J2EE) application server, these include containers for Enterprise Java Beans (EJBs) and Servlets. The implementation of the application server determines its own QoS measures and, in turn, limits the QoS of the actual Web service.

• Databases: Many classes of applications access information stored in enterprise databases. The mechanisms by which these accesses are made as well as the performance of the database itself will also affect the QoS measures of the actual Web service.

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.