De-mystifying Windows Azure AppFabric


There seems to lot of confusion about the Windows Azure AppFabric. Lot of it is primarily because of many people trying to over-sell the capabilities of Azure AppFabric based on the marketing collaterals published by Microsoft. Another big reason behind the confusion is the similarity in name of an entirely different product from Microsoft called as “Windows Server AppFabric”.

“Windows Azure AppFabric” Vs. “Windows Server AppFabric” :

  • They are two very different product designed for two very different purposes.
  • Windows Server App Fabric” has come out of Microsoft projects like Dublin and Velocity; whereas “Windows Azure App Fabric” is the next version of what was called as “Windows Azure .NET Services”.
  • As I will explain in below post, they can complement each other to enable some really cool capabilities.

Windows Server AppFabric:

  • It’s part of Windows Server (on-premise)
  • It aims to help developers who are trying to build on-premise web applications
  • Following are the key areas where it tries to provide help (also called as core capabilities):
    • Caching: This is used to speed up access to frequently accessed data such as session info in an ASP.NET application. This is done using a feature called as “AppFabric Caching Service”.
    • Hosting of composite applications: These are typically the applications built using “Windows Workflow Foundation” or “Windows Communication Foundation”. The AppFabric management is integrated into the IIS, and can be used to deploy, manage, and control your services.

Step 1 of the wizard that you will go through to configure AppFabric for a windows server gives a good high level overview of some of the core capabilities:


Additionally, tight integration with PowerShell and System Center can also help streamline various capabilities provided by Windows Server App Fabric.

Windows Azure AppFabric:

Initial focus was to enable applications hosted in cloud be able to talk to applications hosted behind firewalls (on-premise) in a streamlined secure way. The product has evolved to enable many different new scenarios such as “mobility – consumption of cloud hosted services by mobile and smart devices”, “messaging relay for communication between multiple desktop/on-premise/cloud applications” and other features typically associated with an ESB (Enterprise Service Bus) implementations.

Currently it comprises of two key components (aka services), but I definitely see this feature going multiple enhancements as cloud and on-premise technologies start to merge. Here is the official definition of the two features:

  • Service Bus – Helps to provide secure connectivity between loosely-coupled services and applications, enabling them to navigate firewalls or network boundaries and to use a variety of communication patterns. Services that register on Service Bus can easily be discovered and accessed, across any network topology.
  • Access Control – Helps you build federated authorization into your applications and services, without the complicated programming that is normally required to secure applications that extend beyond organizational boundaries. With its support for a simple declarative model of rules and claims, Access Control rules can easily and flexibly be configured to cover a variety of security needs and different identity-management infrastructures.

Conclusion: While Windows Server AppFabric is a product that is targeted to make life easier for developers who are writing WCF and WWF based application to be hosted in IIS, Azure AppFabric is focused on enabling consumption of those (on-premise) services/workflows from cloud. The combination of these two products can enable unprecedented level of integration between organizations (vendors/suppliers/customers/public services/etc.).