AppFabric requires .NET Framework 4 as a foundation. It also requires the Windows Process Activation service (WAS) and IIS Manager. To support management and deployment of WCF and WF services, AppFabric provides management APIs and tools that you can use either from the IIS Management console or from Windows PowerShell. AppFabric also provides several run-time services and stores for the monitoring and persistence of hosted services and workflows.
AppFabric Caching Service is a distributed cache platform for in-memory caches spread across multiple systems, developed by Microsoft. It is one of Microsoft's AppFabric's Services. In its early stages of development, it was referred by a code name Velocity.
AppFabric Caching Service is available as a Windows Azure Service.
A long time ago, applications running on Windows Server were simply EXEs, where developers wrote a lot of custom code on top of the Operating System (OS) to interact with clients and other applications over the network. COM+ and Microsoft Transaction Server (MTS) were added to make it easier to write and host server-side applications and Internet Information Server (IIS) was added to make it easier to write and host Web applications. Application logic was typically written in native code and/or in scripts (CGI, ASP) back then.
In 2002 Microsoft shipped .NET 1.0 and IIS was extended to support ASP.NET enabling managed code Web applications to be hosted on Windows Server. In 2006, with .NET Framework 3.0, Microsoft released two new programming models designed to simplify development of application logic, namely: Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF). WCF enables service-orientation and interoperability and WF enables authoring and execution of long-running workflows. IIS was refactored in Windows Server 2008/Vista and WAS (Windows process Activation Service) was born to enable HTTP and non-HTTP activation of application hosting worker processes (w3wp.exe, also known as AppPool worker) even when the full IIS is not installed. While Windows Server 2008 and .NET 3.0 provided basic administration tools for applications written using WCF and WF programming models, there wasn’t out-of-the-box support for hosting long-running workflows (one had to self-host workflows or build a solution around WAS to ensure reliability and timer activation).
In the upcoming Windows Server AppFabric release we are evolving the application server capabilities in Windows Server to introduce enhanced application hosting and administration tooling (previously codename “Dublin”) for services written using WCF and WF programming models, and providing distributed cache capabilities (previously codename “Velocity”) for .NET applications. The high-level architecture overview of AppFabric is available at http://msdn.microsoft.com/en-us/library/ee677374.aspx.
Design
Any number of systems can be a part of the cache; the caching runtime pulls together the individual caches on each machine to present a unified view to the applications. Applications need not know on which machine the cache is stored; rather the applications query the caching runtime which in turn forwards the request to the system that houses the cache item. The API is surfaced in managed code; so any CLI-compliant language can be used to access the cache. Any serialized managed object can be added to the cache.
Caching is an essential component to speed up any web application by minimizing the number of trips to the actual database. AppFabric Caching or Velocity caching is a distributed caching system that leverages the caching infrastructure available across a cluster of cache servers efficiently to enhance application performance as well as scalability. The secret behind the effectiveness of appfabric caching lies in the fact that duplicate data is not cached by the cache cluster because whenever data is requested by any client, it is first looked up in the unified logical cache and if available the data that reaches the client can be from the physical cache memory of any of the servers in the cluster.

Velocity caching is implemented in a synchronized tier and the service can be accessed across the network with the cache servers in the cluster running the process (DistributedCache.exe). Even though several cache servers contribute to the shared cache memory, there is a common gateway for data to enter and exit in the form of a centralized and shared cache. The distributed cache is handled in code with the help of simple get and put methods that will retrieve, insert, update or delete data items in the unified logical cache as a whole. The programmer is not worried about the internal implementation or the physical location of cached data in the cluster.
Notable Aspects:
- Each server in the cluster stores the session object data in its RAM and does not write it to disk for obvious reasons
- No code change or new code has to be incorporated by the programmer and all that is needed is to change a configuration setting in order to activate velocity caching
- Distributed caching means multiple web servers can each run an instance of the same application which helps in load balancing
- Both web server (IIS) and cache server (Appfabric) can be deployed on a single application server running on Windows Server OS
- Turning on the high-availability feature helps mitigate situations when a server in the cluster goes down by storing a synchronous secondary copy of the data item on a different server
One of the key challenges for the implementation of velocity caching involves managing parallel access to data that changes rapidly and velocity caching offers different concurrency models suitable for the concerned application. Controlling access to sensitive data among the clients is another challenge which is controlled by limiting access to such data with encryption or restricted accounts. Appfabric caching attempts to maximize the benefits from the underlying computer infrastructure with the help of a distributed yet shared architecture to provide value for both application developers and end users. Things can only get better from here.
In parallel, we were also working to elastically scale .NET applications and make them highly available, using commodity hardware. Out of this effort came the distributed in-memory cache (formerly known as Project “Velocity”) which helps cache frequently used data in-memory across multiple machines thereby increasing the performance and scale of these applications. In addition it can elastically scale up and down and replicates data to increase the availability of these applications. These capabilities make the distributed cache an ideal option to cache reference data such as catalogs, profile etc. and session data such as shopping cart.
In this blog post we go deeper into the AppFabric system and its inner workings.
Architecture Overview
The diagram below provides a high-level overview of the AppFabric system.
· Apps are deployed into a farm of AppFabric servers that share Workflow Instance Stores and Monitoring Stores (Databases).
· Distributed Cache provides unified data cache view to Apps while distributing and replicating data across multiple machines
Functional View
The diagram below illustrates key components of the AppFabric system and their functions from a single-machine view (one AppFabric Server view) in a typical setup.
Deployment and Configuration
Deploying and configuring an AppFabric application is as easy as deploying and configuring a Web application.
1. An Administrator deploys and configures a Web application containing WCF and WF services.
a. The Web application is developed using Visual Studio, and developers can easily add WCF services and WF workflow services to the application.
b. The Web application can be packaged and deployed using MSDeploy just like any other Web application targeting IIS/WAS environment. MSDeploy is integrated with Visual Studio and IIS Manager and provides command-line scripting.
c. AppFabric provides configuration tools for WCF and WF services via IIS Manager modules and PowerShell command-lets which enable tasks like setting application monitoring levels and configuring workflow persistence.
d. Application artifacts are copied to a directory together with web.config and an entry in %SystemRoot%\system32\inetsrv\config\applicationHost.config. e. WAS watches applicationHost.config and upon registering an entry, notifies transport listeners and starts waiting for message traffic addressed to the application. Activation
For WCF and WF services, AppFabric supports both on-demand activation and auto-start activation (Windows 7 and Windows Server 2008 R2). On-demand activation improves resource utilization at the price of the first-request response time. Auto-start activation improves the first-request response time at the price of resource utilization. 2. A message arrives and is dispatched to a code service or a workflow service for processing.
a. When a first message arrives to the application via HTTP or via non-HTTP transport listeners, WAS activates a w3wp.exe worker process corresponding to the AppPool that the application is associated with.
b. CLR AppDomains are created inside the w3wp.exe for each application.
c. A ServiceHost object is created for each code service in the AppDomain.
d. A WorkflowServiceHost object is created for each workflow service in the AppDomain.
e. Both the ServiceHost and WorkflowServiceHost create endpoints and dispatch the received message for processing.
i. Based on the instancing model declared on the service, the ServiceHost either creates an instance of the service or finds an existing in-memory instance and invokes the method corresponding to the received message.
ii. Based on the message, WorkflowServiceHost either creates a new workflow instance or loads an existing workflow instance from the Instance Store and transfers execution to the workflow instance.
f. After activation, subsequent messages are dispatched by WAS and transport listeners directly to endpoints established by ServiceHosts and WorkflowServiceHosts during activation.
g. If the Web application is configured for auto-start activation, corresponding w3wp.exe process, AppDomain, ServiceHost and WorkflowServiceHost objects are created whenever WAS starts.
Conclusion
The upcoming Windows Server AppFabric release evolves application hosting and administration tooling capabilities in Windows to support services written using WCF and WF programming models. The AppFabric release provides powerful distributed cache capabilities to .NET applications. In this blog post we discussed inner workings of the AppFabric system components and a typical scale-out deployment topology.
References:
http://techtitude.blogspot.com/2010/08/appfabric-caching-aka-velocity-caching.html
Happy Coding.........