Application developers understand that storing data in memory performs better than storing data on disk. Of course there are trade-offs and the data must be written to disk for it to persist. If data could be persisted and still be available in memory, these trade-offs become much less important. A caching appliance can bridge this gap and mitigate the trade-offs. 

 

The XC10 WebSphere DataPower Appliance 

 

The WebSphere DataPower XC10 Appliance is a dedicated caching appliance that fits into existing architecture with the stated goal of providing caching performance with little or no application changes. This series of blog posts will discuss the three primary use cases of the XC10: 

All three of these scenarios share the common purpose of taking existing cache out of the JVM of a WebSphere Application Server and moving it to the WebSphere DataPower XC10 Appliance. The XC10 stores recently used data and provides it to the application layer. This caching tier provides the data much faster, reduces resources that are used at the application tier (memory, threads, etc.), and reduces the calls to the database tier. The XC10 provides a caching tier that resides between the application tier and the database tier. The WebSphere DataPower XC10 Appliance stores this cache in a grid. This grid caching matches the caching style of WebSphere eXtreme Scale. WebSphere eXtreme Scale implements cache in software and the WebSphere XC10 implements cache in an appliance. Multiple XC10 appliances can be grouped to provide a "caching collective." This caching collective provides a virtually limitless pool of cache for data.

 

The caching tier in place

 

The most obvious difference between the XC10 and WebSphere eXtreme Scale is that the XC10 is hardware and WebSphere eXtreme Scale is implemented in software. There are several other differences that are not so easily seen. The WebSphere DataPower XC10 Appliance is more data centric while WebSphere eXtreme Scale is more application or API centric. WebSphere eXtreme Scale provides more capabilities to an application programmer for manipulating and working with data caching from APIs. The XC10, in contrast, provides a greater and more robust set of data monitoring capabilities.

 

One of the significant advantages of the XC10 appliance is that it can be dropped in to a topology with no code changes to existing applications. This capability means that for these scenarios: elastic dynamic caching and HTTP session management, the XC10 appliance can be deployed quickly and it immediately reduces response time and increases throughput for typical Java enterprise applications. In addition, the XC10 was engineered from the beginning to be secure, scalable, and fault tolerant. The straightforward administrative interface allows the XC10 be used as a rapid response caching solution.

 

Elastic dynamic caching was previously called "DynaCache." In this scenario, the application does not use an API for caching. Requests are handled based on the URL of the requests from clients. An administrator configures the dynamic caching by defining URLs or parts of URLs that identify a unique request. That request is checked to see if the data is available in the cache pool. If the data is not in cache, the application retrieves the data from the back-end systems. The cache is transparent to the way the application runs. When the application returns the data to the client, that data is stored in cache. The next time that unique request is called, it is served from cache and the application is not called.

Typically for the web application these pages are Java Server Pages (JSPs) or servlets. Without a cache appliance the WebSphere Application Server stores this cache in the JVM memory. Adding the XC10 appliance means that this cache can be offloaded from the JVM to the appliance. Caching dynamic web pages is efficient when served from the JVM, but it is even more efficient when offloaded to a caching appliance. Elastic dynamic caching provides faster response time and greater throughput with only administrative changes for the application. No changes need to be made to the application at the code level.

Elastic Dynamic Cache

As an example, imagine a website that provides current weather conditions for a given city. In this scenario, the weather data for frequently requested cities is cached and available for rapid response. At any given time, it isn't practical to try to predict which cities are requested most. The elastic dynamic cache responds to requests as they are made filling the cache as needed. The least recently requested data drops out of cache when the cache is full and new requests are made. As long as our weather application uniquely identifies weather requests based on their URL, cache can be configured to provide a highly dynamic and highly responsive application.

 

This article describes the first of three scenarios for using the WebSphere DataPower XC10 Appliance. In coming articles, I will describe how the XC10 can be used for managing HTTP session and as a side cache. In many situations, the XC10 can be used without any changes to the application code.

 

Matt Oberlin works for IBM in the WebSphere Education group. Matt enjoys providing complex technical information in a straightforward manner. You can find Matt at

Twitter: @MattO_Tweets

Linkedin: Matt Oberlin