Darren Lewis bio photo

Darren Lewis

Professional Nerd

Twitter GitHub StackOverflow

We recently received a proposal from a supplier for their integration into our backend stock control system. A requirement of the solution is asynchronous communication in both directions so MSMQ was recommended as expected. However, I was surprised to see the implementation their side for processing messages was a Windows Service. The platform is entirely Windows Server 2008 and .NET 4.0 so the choice of a Windows Service which carries with it all of the responsibilities of appropriate application management is in my opinion the wrong choice.

The “better” solution in the absence of a full Service Bus (Biztalk etc) would be implemented using Windows Activation Service (WAS) hosted WCF/WF Services enriched by AppFabric. This feature set provides so many functional and operational benefits; I struggle to see where a valid use case exists for implementing any messaging solution via a Windows Service. That’s a broad statement that can’t hold true for all requirements but I believe architecturally when the discussion turns to a Windows Service we should be asking the question “Why shouldn’t we do this in IIS/WAS and AppFabric?” rather than “Why should we?”

Below are some of the benefits (not just limited to message queuing) of WAS and AppFabric you can leverage without writing a line of additional code </p>

  1. Leverage common deployment practices through MSDeploy
  2. WAS alone (via the IIS Process Model) will provide significantly enhanced Process Management through built in and easily configurable:
  • Recycling
  • Throttling
  • Security
  • Scalability (shared worker process where appropriate)

 

  1. AppFabric will provide (again through easy configuration):
  • IIS Management Console integration giving visibility into configurable searchable metrics via the AppFabric dashboard.
  • Workflow Persistence including idle time management
  • Caching Services (additional install)
  • Configurable Service Auto Start (requires Server 2008 R2)
  • WCF Endpoint Management
  • Easy configuration of WCF/WF Event Tracing
  • Easier integration of custom monitoring services (i.e. a custom system reporting website)
  • Pluggable tracking/tracing profiles
  • Easier integration for reporting into SCOM (additional install pack)

Significantly, AppFabric Server will also provide you with a head start (albeit a small one) into the runtime framework of Azure AppFabric as the two offerings begin to converge over the next few years.

I hope this post has proven useful to someone looking at delivering application services that might otherwise have considered a Windows Service to be their only option. AppFabric is available through the Web Platform Installer and further information on Windows Server AppFabric can be found here.