The previous two articles described the WebSphere DataPower XC10 Appliance and how it can be used to offload cache from a JVM. I described two scenarios for the XC10. This article describes the final of the three scenarios. This scenario is different because the cache of the WebSphere DataPower XC10 appliance is more deeply integrated into the application layer.
In the final use case, the term "side cache" denotes that the cache is not directly in the path of requests to the database. The application is written to use the cache for retrieval of data. This scenario means that the XC10 is used for recently accessed data that can be served for an application from a data grid. This data grid provides cache storage, lookup, and retrieval. The cache data is indexed with name/value pairs and is stored in a standard ObjectMap.
The XC10 as side cace (For the DataPower 150)
This article does not get into the details of writing an application to make use of a data grid. An application that makes use of cache at this level must be designed and written for caching data. Two quick concrete examples can illustrate this point.
First an application that provides weather forecast information. As requests for weather forecasts are received for specific locations (Pittsburgh, PA; Raleigh, NC) the data for that location is read and stored in cache. Data stored in the cache can still be valid for minutes, possibly hours. For the weather forecast application it may be sufficient to let cache expire after a period of time. The point is that our data isn't time-critical and any particular piece of data doesn't change based on client requests. Just because I want it to snow in Rhode Island, doesn't change the forecast for Providence. As you saw in the first article, this is an example of dynamic elastic cache. The dynamic elastic cache scenario does not require application level cache integration. The cache can be indexed based on requests.
The second application is for an online travel agency. The agency doesn't sell airline tickets but acts as broker to airlines. This application is similar to the weather forecast application because data will be cached as requests are made. (PIT to ORD round trip, RDU to LAS one way) The difference is that the data in our cache is highly volatile; this cached data may change based on queries, flights booked, and more. Only the architects and designers of this application will truly understand when and how data in the cache should be updated or invalidated.
This series of articles has described three scenarios for using the WebSphere DataPower XC10 appliance. In many situations the XC10 can be used without any changes required to the application code. In all of these scenarios, additional XC10 appliances can be added in a collective. This allows the cache capability to grow seamlessly. These scenarios show how a caching tier provides data much faster, reduces resources, and reduces the calls to the backend tier. The WebSphere DataPower XC10 appliance is a robust, drop in solution for a caching tier.
Growing the data grid
Bio and Contact Information
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 and Linkedin: www.linkedin.com/pub/matt-oberlin/1/4b9/802/