I’ve gotten a few questions about AppFabric for Windows Server, so I’d like to share some thoughts on the topic, specifically on the Workflow management aspects of AppFabric Server.
First, it’s important to clarify what AppFabric Server is/isn’t, since I’ve seen some confusion on this. Simply put, AppFabric provides a set of extensions for IIS-hosted workflows. With .NET 4, we added support for “WCF Workflows Services”, workflows that you can call as WCF SOAP services and that can consume other SOAP services. These workflows run in WorkflowServiceHost (WFSH) instances. As with other WCF ServiceHosts, WFSH can be self-hosted in a process of your choosing, e.g. a Windows Service, an Azure Worker role, etc. We also provided integration which makes it easy to host WFSH instances in IIS, including use of the WAS (Windows Process Activation Service) for message-based activation of workflows. All of these capabilities were part of the framework in .NET 4.
AppFabric Server builds on WF and provides extensions to IIS to deliver additional capabilities for the management of WCF Workflow Services. The most important pieces are:
In this release, we have continued to invest significantly in the WCF Workflow Service scenarios that WFSH and AppFabric Server target. These investments have largely been in the core framework in .NET 4.5, where they are most leveraged. They include support for contract-first authoring of WCF Workflow Services and support in WFSH for versioning (via WorkflowIdentity integration), Dynamic Update and C# expressions. And of course, our other core investments such as the authoring improvements, state machine and performance enhancements accrue to all of our hosting options, including WorkflowApplication and WFSH.
Given the big investments we’ve been making across the workflow stack, we have not been able to invest in surfacing all of the new 4.5 functionality in the AppFabric tooling. However, we are doing the work to ensure that AppFabric works well on .NET 4.5 and Windows Server 2012.