Highly scalable implementations of service-oriented architectures (SOAs) always include heavy doses of caching. A guided tour through the SOA tiers, describing the caching and XML acceleration techniques employed along the way, provides the SOA enterprise architect with an awareness of optimization possibilities applicable to a Web service infrastructure. Consolidating the acceleration functions in an integrated appliance and controlling them via policies specified by WSDL annotations simplifies the implementation.

Caching is a fundamental optimization technique found in all computer systems and networks. Modern CPU chips maintain instruction and data caches along with clever methods of ensuring coherency with the RAM that may be simultaneously accessed by other CPUs and I/O processors. In many respects, RAM can be thought of as a cache of your virtual memory swap file. Our networked world is full of caching subsystems, each designed to minimize the latency required to access correct content. As the computing paradigm has evolved to multitiered SOAs, caching continues to play a crucial role.

A typical SOA solution is implemented in a multitiered fashion for many reasons, not the least of which is performance. Figure 1 illustrates the "nearest tier" through the "farthest" tier - the nearest tier is closest to the Web service consumer that issued the request; the farthest tier is the central database engine.

The computing devices and software that drive the farther tiers are generally more expensive compared with the subsystems in the nearer tiers. The processing that takes place in the farther tier subsystems tends to be "business-logic," is often executed in higher-level interpretive languages, and generally takes more time and resources to execute. The logic of subsystems at the nearer tiers is usually very system software-oriented, is executed in the native machine language if not in ASICs, and tends to be highly efficient. The subsystems in all tiers are usually designed for high scalability, where simply adding more like subsystems can expand capacity. In front of each subsystem, tier load balancers are employed to intelligently deliver object requests and route responses between the tiers. The message communication between each tier requires TCP/IP routing, load balancing, parsing, and other processing, all of which adds further latency to the transaction response time. Therefore, the more work that can be completed in the nearer tiers, the more efficient and responsive the overall SOA implementation will be.

A Caching Tour of the Tiers
Caching begins at the farthest Enterprise Information System (EIS) tier and proceeds through the nearest tier. XML caching takes place at the nearer tiers.

Caching at the Core
In the farthest EIS tier, most database engines such as DB2, MS SQL Server, and Oracle have a myriad of caching options designed to minimize disk I/O operations as much as possible while ensuring that transactions are always physically recorded. The guidelines for these products usually suggest that the database files should be stored on a file system where the caching services supplied by the native OS's file system are disabled. The rationale for this is that the caching services of the native OS can't possibly be as intelligent as what is performed by the database, so therefore any memory resources devoted to the native OS caching engine would be wasted. Furthermore, the database engines want to guarantee that updates are physically written to storage. Database engines also make extensive use of "SQL Statement Caching," which reduces the costly parse processing on the database server. While these database-caching techniques may be very exciting for system and database administrators, they are likely only of passing interest to the SOA enterprise architect.

Moving Nearer Outward
As we move outward to the application servers or business tier, the application designer often carries the burden of integrating caching optimization. In this tier we find two basic flavors of server platforms, J2EE and Microsoft ASP.NET. Each of the two environments offers the application developer a means for injecting caching to optimize performance and increase scalability. Some of the caching techniques employed in the business tier directly relate to Web services, while others optimize the business logic implementation of the Web service. The SOA enterprise architect should have a full understanding of all caching techniques utilized in this tier.

In the business tier, there are two important caching objectives: storing business data in memory to be readily accessed by application servers, and controlling caching strategies by setting related HTTP headers through platform APIs.

J2EE Caching Techniques
In the J2EE environment, the caching of business data is achieved by various Object-Relational mapping technologies. The dominant choice offered by J2EE vendors is the Enterprise Java Bean (EJB). The Entity Bean developer often implements transactional caching of dynamic data by adhering to the Container Managed Persistence (CMP) model that provides caching as an inherent attribute. Some J2EE platforms such as IBM WebSphere offer extensions to CMP that allow data caching of static items across transactions. This extended functionality can be easily integrated into an application by setting attributes in property sheets. EJB can be a bit heavy-handed targeting large, complex systems. Some "lighter" technologies include both standards-based model abstraction such as Java Data Objects (JDO) and open-source offerings such as Hibernate.

The "JCache" specification defines a powerful set of Java-caching APIs that support implementations of caching frameworks. Both open-source and commercial offerings of caching frameworks allow cached objects to be shared among multiple applications. These caching frameworks are often an important component in enterprises where "single sign-on" to multiple applications is required. JCache provides methods to control temporary storage and expiration of Java objects in common memory in a manner that ensures that the cached objects are coherent with the data stored in the farther tiers.

For controlling caching-employed HTTP servers and proxies, the J2EE specification defines the HttpServletResponse class, a component of the servlet container, as a fundamental J2EE building block. This class provides control of HTTP-specific functionality by furnishing methods to access and generate HTTP headers and cookies. Specifically, the addHeader method allows the HTTP 1.1 "cache-control" and "expiration" directives to be emitted to facilitate caching in the nearer tiers.

The Microsoft Way
Instead of mapping business data into a constellation of objects, Microsoft employs a different strategy of caching transactional data. Data elements are presented as relational tables in memory, which is very similar to how they are persisted on disk. Those in-memory tables can be accessed via the rowset API, and maintained via either DataReader or DataSet APIs by ADO.NET.