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
- Leverage common deployment practices through MSDeploy
- 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)
- 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.
