End of Support on AppFabric: What now?

What is Windows Server AppFabric?

Windows Server AppFabric is an application infrastructure for hosting and managing WCF and WF applications. Users are able to configure and monitor their services through an extension on Internet Information Services (IIS) for Windows Server.

Another main feature is the distributed cache. It is highly scalable and allows you to combine multiple servers into a cache cluster. It gives developers a quick and simple caching solution.

AppFabric and BizTalk

Since AppFabric was released in 2010, both me and my colleagues have used it in several projects to host solutions with minimal overhead. This was especially useful in some of our BizTalk projects where BizTalk, because of its persistent messaging engine, introduced undesirable overhead in specific scenarios. Combining AppFabric with WF and WCF for typical scenarios like (aggregated) lookups (in which transactional processing and therefor persistence doesn’t always add value) was a great alternative. After the release of AppFabric, Microsoft also introduced a feature called AppFabric Connect in BizTalk Server 2010. This allowed developers to take advantage of the BizTalk mapper and BizTalk adapters in WF-based applications, allowing for a higher degree of reusability of components like maps. I’ve developed several solutions based on the model shown below.

Impact and alternatives

Hosting

First of all it is important note that even though the hosting part, that was frequently used over the last couple of years, will no longer be supported, it does not mean that there has to be any impact on the WF and WCF solutions we’ve developed. WF and WCF applications can be hosted in any managed application, such as IIS or Windows Process Activation Services (WAS). While the IIS extension for Windows Server AppFabric will not be available to monitor and configure your applications, IIS will still be able to host your WCF and WF applications.

For more information on hosting workflow services see: https://msdn.microsoft.com/en-us/library/ee358730%28v=vs.110%29.aspx.

Monitoring and Logging

To replace this functionality, Microsoft recommends creating a custom solution. This isn’t absolutely necessary however, since the WCF tracing functionality that was often used, was an IIS extension for Windows Server AppFabric, that is still available and can be enabled by following this guide: https://msdn.microsoft.com/en-us/library/ms733025.aspx.

Another option is to use Event Tracing for Windows. This allows you to capture diagnostic information during the execution of a WCF or WF application.

For more information see: https://msdn.microsoft.com/en-us/library/ee530019%28v=vs.110%29.aspx.

A sample can be found here: https://msdn.microsoft.com/en-us/library/dd764466%28v=vs.110%29.aspx.

As Microsoft notes a custom solution is also possible. While it would take some time to design, develop and implement, a custom solution can be setup to completely be in line with the customer’s architecture and requirements. This would, for example, allow for seamless logging and monitoring across both BizTalk and AppFabric, which in my opinion is a best practice and is something I’ve been doing from the start anyway.

Management

It will no longer be possible to use Windows Server AppFabric to control the workflow in a WF application, for example to Resume, Suspend, Cancel, Terminate or Delete a persisted workflow. A custom solution will need to be developed if this functionality is needed.

At Axon Olympus, one of our principles has always been to host transactional or long-running processes (for example, a CreateCustomer service) in Microsoft BizTalk and to host the non-transactional processes (for example, a GetCustomer service) in AppFabric, since combining WF and AppFabric allows for full control over persistence, in turn allowing for low-latency solutions. This provides an architecture where WCF and WF services handle the non-transactional processes, which can have strict performance requirements, and Microsoft BizTalk handles the transaction processes where persistence and management of the workflow is of greater importance.

For our solutions this means that the use of persistence and workflow management in WF was never really used and that this shouldn’t have any impact.

Caching

Unlike the hosting functionality of Windows Server AppFabric, where the functionality can be replaced by IIS (which is already available on your servers), the caching functionality does not have a direct replacement.

Microsoft has recommended replacing the AppFabric caching functionality with the Microsoft Azure Redis Cache (http://azure.microsoft.com/en-us/services/cache/), which is based on the open source Redis Cache. A migration guide on how to migrate from to Azure Redis Cache is available at https://msdn.microsoft.com/en-us/library/azure/dn690524.aspx.

The Microsoft Azure Redis Cache is fully supported by Microsoft, however (as the name suggests) it is only available in the cloud. If a cloud solution is not an option, Microsoft recommends using Redis on Windows which is available from MSOpen Tech. It is important to keep in mind that Redis on Windows is not supported by Microsoft.