Programming Microsoft ASP.NET 4 - Dino Esposito [389]
Integration with the Data Access Layer
Finally, read-through and write-through (or write-behind) capabilities qualify a caching solution as a top-quality solution. Read-through capabilities refer to the cache’s ability to automatically read data from a configured data store in case of a cache miss.
Write-through capabilities, instead, enable the cache to automatically write data to the configured data store whenever you update the cache. In other words, the cache, not your application, holds the key to the data access layer. The difference between write-through and write-behind capabilities is that in the former case the application waits until both the cache and data store are updated. In write-behind (or write-back) mode, the application updates the cache synchronously but then the cache ripples changes to the database in an asynchronous manner.
This is a list of the features one would reasonably expect from a distributed cache. Not all products available today, however, offer these features to the same extent. Let’s see what the Microsoft distributed caching service currently offers.
AppFabric Caching Services
Windows Server AppFabric consists of a few extensions to Microsoft Windows Server to improve the application infrastructure and make it possible to use it to run applications that are easier to scale and manage.
Currently, Windows Server AppFabric has two extensions: AppFabric Caching Services and AppFabric Hosting Services. The former is Microsoft’s long-awaited distributed cache solution; the latter is the centralized host environment for services, and specifically services created using Windows Workflow Foundation. Let’s focus on caching services.
Fast Facts
AppFabric Caching Services (ACS) is an out-of-process cache that combines a simple programming interface with a clustered architecture. ACS should not be viewed as a mere (distributed) replacement for the native ASP.NET Cache object. When you have a very slow data access layer that assembles data from various sources (for example, relational databases, SAP, mainframes, and documents) and when you have an application deployed on a Web farm, you definitely need a caching layer to mediate access to data and distribute the load of data retrieval on an array of servers.
The plain old Cache object of ASP.NET is simply inadequate and, in similar scenarios, you are encouraged to use ACS in lieu of Cache. Keep in mind, however, that although endowed with a similar programming interface, ACS currently lacks some of the more advanced capabilities of the ASP.NET Cache, such as dependencies, sliding and absolute expiration, and removal callbacks. At the same time, it remains as simple to use as a hashtable, offers a scalable and reliable infrastructure, is configurable via Windows PowerShell, and presents some developer-oriented features that are not in ASP.NET, such as programmatic access to cache-related properties of cached items (such as priority or expiration) and event propagation (such as notifying client apps of changed items).
Architecture of Caching Services
ACS is articulated in two levels: the client cache and distributed cache. The client cache is a component to install on the Web server machine and represents the gateway used by ASP.NET applications to read and write through ACS. The distributed cache includes some cache server machines that are each running an instance of the AppFabric Caching Services and storing data according to the configured topology. In addition, the client cache can optionally implement a local, server-specific cache that makes access to selected data even faster. The data found in this local cache is not kept in sync with the data in the cluster. Figure 18-4 provides an overall vision of AppFabric Caching