20 August, 2012

AppFabric Distributed Caching and SharePoint 2013

Windows Server AppFabric is installed as a prerequisite for SharePoint 2013. AppFabric is installed as an extension to the Windows Server Application Server Role and consist of two main components:
  1. Distributed caching – Previously codename Velocity
  2. Service and workflow management – Previously codename Dublin 
This blog will focus on the distributed caching component and how this is leveraged in the context of SharePoint 2013. The following elements will be described:
  1. What is AppFabric distributed caching and how does it work?
  2. How does SharePoint 2013 utilize AppFabric distributed caching? 

What is AppFabric distributed caching and how does it work? 

The concept of distributed caching is to provide caching across multiple servers. This enables highly scalable and available caching environments which results in more scalable, available and high-performance applications.

AppFabric implements this caching methodology by using a cache cluster containing a number of caching servers. This cache cluster automatically handles the complexity of load balancing, scaling and failover. Each one of the servers in the cache cluster has AppFabric installed and is running an instance of the AppFabric Caching Service. As an addition to storing data in the cache cluster AppFabric Caching Service also has the ability to store data in a local cache on the server. This can be used to provide faster access to certain data which can be configured to automatically synchronize with cached items in the cache cluster.

When a cached item is being requested the local cache is checked first (if it is being used). If the item is found it is returned to the client. If the item does not exist the query is sent to the cache cluster and returned if it exists. This interaction with the caching service is transparent to the client which only sees the cluster and local cache as a single entity. This way the client does not have to worry about which server the caching is stored on. AppFabric distributed caching implements the cache-aside architecture (Explicit Caching) which means that all items must be explicitly added to the cache. The client can therefore not expect that the data is available in the cache and should implement functionality to query and add the data when needed. AppFabric now also supports the ability to ‘Read-Through and Write-Behind’ by implementing a Read-Through and Write-Behind provider. This provider is able to integrate with a backend system and perform read and writes when data is queried from the cache cluster. ‘Read-Through’ implements support for automatically reading and caching the data from the backend system if the data is not available in the cache cluster. This way the client never have to worry about where the data comes from but always expect to receive the data when requesting it from the cache. ‘Write-Behind’ supports periodically and asynchronously writing added or updated data from the cache cluster to the backend system.

All data in the cache cluster is stored in memory on the cache servers. By default the data is stored in the memory on only one server in the cache cluster. By enabling the high-availability option in the AppFabric Caching Services a second copy of each cached item is created on another server in the cache cluster. The first cached item is called the primary item and the second copy is the secondary item. In case a server in the cache cluster becomes unavailable the data is available on one of the other servers. The secondary item is then promoted to the primary item and a new secondary item is created on another server in the cluster.


In the above example the cache cluster consist of three servers each containing a primary and a secondary item. If cache server one was shut down S1 in cache server two would be promoted to the primary item and a new secondary item would be created on cache server three. Since S2 on cache server one is also lost, a new secondary item would be created on cache server two. The result would be the following:


AppFabric distributed caching is designed to be used with .Net and supports caching of any serialized .Net object. Cached items can be updated and deleted explicitly or removed by the caching service through expiration time-out periods or to make room for more frequent accessed data. The AppFabric caching service also provides built-in support for the ASP .Net session objects which can be configured to be stored in the cache cluster by simple configuration. This means that existing applications can get the benefit of AppFabric distributed caching without changing any code.

The communication between clients and the data cluster can be configured to be digitally signed and encrypted, and administrators can configure which users should have access to each cache in the cache cluster.

Caching components 

The logical architecture of a cache cluster is made up of the following components:

  • Named Caches
  • Regions
  • Items

When items are stored in the cache cluster they are always added to a specific cache. When installing the cache cluster a default cache is always created which is used if no specific cache is selected. Other caches can be created and configured independently through PowerShell in order to divide the data into separate cache containers. These cache containers are referred to as ‘named caches’. Named caches are persisted even if the cache cluster is restarted however the content of the named caches will be deleted.

Regions are containers within named caches and are optional. Regions are created at runtime through code and make it possible to search through items stored inside the region. This search is performed by using tags which can be added to the cached items. The downfall of using regions is that regions are not able to span over multiple servers and hence not able to take advantage of the benefits of using distributed caching.


An item is the data that is stored in the cache cluster. An item can be stored in a named cache or a region and is always stored using a key-value approach. An item is always returned as an Object and must be cast to the correct type at runtime.

AppFabric Concurrency Model 

The AppFabric distributed caching supports two different concurrency models:

  • Optimistic
  • Pessimistic

The optimistic concurrency model does not use locks to update items in the cache but instead adds a version number to the cached item every time it is updated. When an item is requested from the cache, the item and its version number is returned. When updating the item the version number must be supplied and the cached item is only updated if the version number matches the current version number in the cache. If the version number does not match, the item has been updated since it was received and a DataCacheException is thrown. The pessimistic concurrency model uses locks to ensure no other users update or delete the cached data while it is locked. When an item is requested a lock handle is returned which is later used to unlock the item. If the lock is requested while the item is locked a DataCacheException is thrown. Locked items can be configured to automatically release their locks in case the client application ends before releasing a locked item. This concurrency model assumes that all clients follow the rules for locking. Any item in the cache can be updated and deleted by an operation not using locks whatever the item is locked or not.

Comparison 

The following table compares distributed caching to some of the commonly used caching techniques in .Net.


How does SharePoint 2013 utilize AppFabric distributed caching? 

The distributed caching is used by SharePoint 2013 for caching social elements and FedAuth tokens. Every time a user accesses a front end server the user needs to be authenticated which can become an issue when using multiple front end servers. In SharePoint 2010 this was handled by enabling load balancing affinity (Sticky Sessions) to ensure that the user stayed on the same front end server. By caching the FedAuth token in the distributed cache it is no longer necessary to enable sticky session since the authentication token is now available from all front end servers through the cache cluster.

13 August, 2012

Implementing the Service Locator Pattern

The idea of a service locator is to have a single point of reference to obtain a service needed by an application. The service locator acts as a registry for services and provides functionality for registering and retrieving references to services.

A service locator implementation consists of three components:

  1. Service interface(s)
  2. Service implementation(s)
  3. Service locator

The picture below illustrates how the service locator, the interfaces (I1, I2 and I3) and the service implementations (Service 1, Service 2 and Service 3) are connected.


The following illustrates an example of how the service locator pattern can be implemented.

All interfaces implement a global interface called IService:
public interface IService { }
This example uses two services Products and Users. For each service an interface is defined:
// Interface for product service
public interface IProductService : IService
{
    // Get all products
    List<Product> GetProducts();
}

// Interface for user service
public interface IUserService : IService
{
    // Get all products
    List<User> GetUsers();
}
The service implementations implement the interfaces:
public class ProductService : IProductService
{
    // Get all products
    List<Product> GetProducts()
    {
        // Return List of products
    }
}

public class UserService : IUserService
{
    // Get all products
    List<User> GetUsers()
    {
        // Return list of users
    }
}
The service locator is implemented using the singleton pattern and provides a registry for registering and retrieving service references. Services a registered using the service interfaces:
public class ServiceLocator
{
    // Service Locator
    private static ServiceLocator _serviceLocator;
        
    // Lock to make singleton pattern thread safe
    private static object _lock = new object();

    // Dictionary of all available services
    private Dictionary<Type, IService> _services;

    // Constructor to initialize all services
    private ServiceLocator() 
    {
        _services = new Dictionary<Type, IService>();
        _services.Add(typeof(IProductService), new ProductService());
        _services.Add(typeof(IUserService), new UserService());
    }

    // Get service locator
    public static ServiceLocator GetServiceLocator()
    {
        lock (_lock)
        {
            if (_serviceLocator == null)
                _serviceLocator = new ServiceLocator();
        }
        return _serviceLocator;
    }

    // Get service of type T
    public T GetService()
    {
        return (T)_services[typeof(T)];
    }
}
To receive a reference to a service through the service locator, the application calls the generic GetService method on the service locator:
var serviceLocator = ServiceLocator.GetServiceLocator();
var productService = serviceLocator.GetService<IProductService>();
var products = productService.GetProducts();
The service locator pattern reduces the dependency on the implementation and makes it easy to substitute service implementation without changing the entire application. In this case if products were read from a database, the implementation could be changed to read from an XML file by simply changing the service implementation.