ASP.NET developers have at least three types of caching capabilities available to them. "Output caching" informs ASP.NET that responses built for a page can be returned on subsequent requests for the same page without re-executing the ASPX script. Either an entire page can be added to the output cache or to a specified ASP.NET user control. Although the ASP.NET designer can embed an HttpCachePolicy class into their objects so that standard HTTP caching proxies can interpret HTTP headers, this feature is of limited value because most standard HTTP proxy servers are not designed to deal with responses associated with HTTP "POST" commands. Another powerful caching method of ASP.NET is "application caching," which allows the application to use the cache to store any data by leveraging the System.Web.Caching.Cache class.

Web Servers and HTTP Caching Proxies
Much of the Web services infrastructure is dependent on a highly scalable Web server tier. Microsoft's .NET framework for Web services depends largely upon the Web services functionality that is built into "Internet Information Server" (IIS) and its accompanying Microsoft Internet Security and Acceleration Server (ISA). J2EE-oriented infrastructures are more likely to leverage the J2EE-based Web/application servers, such as Apache Tomcat, embedded with the Axis SOAP handlers, as a common critical component. In an SOA implementation, caching proxy servers perform front-end processing offload and can sometimes provide layer-7 load balancing to the Web servers.

Traditional Web-caching proxy servers were designed to optimize the viewing of HTML Web pages by a browser. With HTML, even individualized page views share a similar layout, thus a large number of common components and many page views will be absolutely identical. This led to the establishment of a well-defined set of caching rules spelled out in the HTTP 1.1 specification for caching frequently requested pages and page components.

In an SOA, though the need for caching might be even greater, the means for caching in the Web tier is less defined. Unlike HTML, XML supports many different types of messages determined by the set of applications supported by the enterprise network. XML messages are most often transactional in nature - reflecting the dynamic nature of a conversation, negotiation, or exchange between parties. With XML traffic, there is less use of the common components that can be effectively cached. One of the caching rules set forth in the aforementioned HTTP 1.1 specification is that responses to HTTP POST messages are not cacheable, unless the response includes appropriate "Cache-Control" or "Expires" header fields. Unfortunately, most SOAP toolkits are designed to embed SOAP requests inside an HTTP POST message. Therefore, since traditional HTTP proxy servers make the assumption that responses to an HTTP POST are not cacheable, they provide no benefit for an SOA implementation.

An intelligent, "SOAP-aware" Web-caching tier can provide many important optimizations to an SOA implementation. Advanced caching engines can observe the "Cache-Control" and "Expiration" directives that can be set in the farther tiers. They also provide the ability to observe caching policy directives defined by the SOA enterprise architect.

Near Tier XML Caching and Optimization
Traditionally, XML processing was entirely handled at the business tier. The now mature XML-related standards and the desire for higher performance have resulted in the capability to perform many of these functions in the nearer tiers.

The nearest tier is what I refer to as the XML "front gate" - the subsystem that first receives and parses the SOAP message. Usually, the first task to be performed in a highly scalable SOA implementation is content-based routing of incoming SOAP messages. This technique uses knowledge of traffic and caching for message classification in which a series of rules or tests are cached by a server component that provides useful information about each message as it is processed. These tests are used to determine whether the message type is accepted by the receiving system and has an associated cached XML schema. Dropping unsupported message types saves processing time. This XML content-aware classification is the basis for routing and load balancing SOAP messages to different servers based on various characteristics of the messages. Classification is an important ingredient in efficient protection against malicious content, including denial-of-service attacks. XML rules or tests are most frequently expressed as a series of XPath statements, a W3C-standardized language for finding any XML content in a message and making assertions against that content. Similar in many ways to the SQL statement caching performed at the EIS tier, a sophisticated SOA near-tier component will precompile and cache these XPath statements for the most rapid possible evaluation against incoming XML messages.

A properly classified SOAP message should then have its schema validated. While Web browsers can deal with malformed HTML content by simply ignoring the unrecognizable content, the same is seldom true of XML applications. It is critical for network security and performance to ensure that each message is correctly composed and can be safely handled by the receiving applications in the farther tiers. XML message types are described in a formal grammar known as an XML schema. This grammar, processed against the individual message, is used by an XML validator to ensure that the message can be correctly and safely handled. XML schema validation is a CPU-intensive operation, consuming as much as 30 percent of the overall time spent processing each XML message. When XML Schema validation is performed on a server in the nearer tier, the computing resources of the farther tiers are significantly off-loaded. XML schema validation should also be performed on outbound responses. This ensures that dynamically composed XML messages do not compromise unprotected Web service intermediaries and that sent messages conform to content-level agreements between partners.

Caching is important to smooth schema validation processing. While XML may describe an infinite number of message types, within any given application environment there is a limited number of types of messages that can be handled. Therefore, an intelligent SOA-processing component will cache the XML schemas for those messages that an SOA implementation will handle. The cached schemas are precompiled into a binary data structure to increase the execution speed of validation. In most validation systems, the XML message must be fully parsed before it is validated, but a more sophisticated validator may be able to scan the message to determine whether the message type is supported before invoking full validation. Messages that are not supported by the SOA implementation can be discarded at the least possible cost.

In order to meet the heavy computational requirements of schema validation and content-based routing, using a device that can perform these computations in ASIC hardware is a recommended practice. One such device is the Tarari RAX Content Processor (RAX-CP). Table 1 summarizes the tremendous throughput improvement that can be achieved by effectively applying the RAX-CP to these important SOA functions.

WSDL Annotations - The New Sheriff in Town
In an SOA, caching optimizations can be provided by many SOAP nodes, including service providers, clients, and intermediaries. Caching is not even limited to HTTP traffic since SOAP is not bound to any specific transport. A generic, transport-independent caching control mechanism is needed.