When considering moving an application to the Windows Azure Cloud, many reasons can prevent an application from taking full advantage of all the technologies Windows Azure offers.   For instance, regulatory requirements, customer agreements, entrenched legacy technologies, limited time schedules, budget restrictions, poor existing architecture, etc. As a result some applications can only move specific parts to Azure and are required to preserve remaining parts on-premise.

One of the compelling features of an application hosted in Windows Azure is able to use the Azure Service Bus.   By using the Service Bus an application can easily connect using REST or WCF (Windows Communication Foundation) calls to service endpoints that normally would be hard to reach through firewall or NAT (Network Address Translation) boundaries.  This can be accomplished through a relay or brokered messaging service.  Relay messaging offer direct contact between endpoints.  Brokered messaging is done asynchronously, such as through service queues.

Wouldn’t it be nice if those naughty applications (which for one reason or another can’t move totally to the Cloud) could use that service bus functionality while doing time in on-premise purgatory?   Well with the 1.0 Beta release of Service Bus for Windows Server (SBFWS) that is now possible.

Service Bus for Windows Server offers the same functionality of the Windows Azure Service Bus moved onto the local network. It allows message-based and loosely-coupled applications to run in self-managed on-premise environments.  Clients can use TCP or HTTP/REST as the protocol for communication.  The API to utilize its functionality is the same as that for the Windows Azure Service Bus.  Thus it can communicate with either on- or off-premise applications transparently. By preserving this paradigm an application that today cannot move physically to the Cloud can at least do so logically using the same relay or brokered messaging pattern found in services hosted in Windows Azure.  Thus when the time comes that the on-premise app has served its time in purgatory (maybe that organization finally allocates funding) to move to Windows Azure the move will be greatly simplified.

The following installations are required for Service Bus for Windows Server:

  • Windows Server 2008 R2 SP1 x64 (Standard, Enterprise, and Core)
  • Windows Server 2012 x64(Standard, Enterprise, and Core)
  • Windows 7 SP1 x64 and Windows 8 x64 are not supported for production purposes. The Service Bus for Windows Server can be installed on them for development purposes.
  • SQL Server – 2008 R2 SP1, SQL Server 2008 R2 SP1 Express, SQL Server 2012, or SQL Server 2012 Express

Deployment is limited to a few simple configurations. SBFWS can run on a single server hosting both the Web server and SQL Server. Or it can run on a server farm with three Web servers with a separate SQL Server machine. If more than three Web servers are needed that should be done scaling up in incremental multiples of three servers.

Key features include enterprise-level Service Bus queues and communication with those queues using the Service Bus. The message queues actually reside within a SQL Server database. Each database is mapped to a runtime component called a message container. Message containers are hosted on a single server and link to the database backing store.  A Service Bus messaging entity (a queue, topic, subscription or rule) is created in a message container (and corresponding database). A Service Bus application server can host multiple message containers linked to many databases. All messages in a Service Bus messaging entity are stored in both the same container and database.

There are three primary components of the SBFWS – the Fabric, Message Broker, and Gateway. These Windows services run on the Web server and interact with each other to ensure messages are transmitted and stored correctly across the Web farm.

 Service Bus Gateway

All TCP or HTTP/REST requests from clients must enter through the service bus gateway.  The gateway manages the security using token-based authentication (since the Azure Access Control Service is not available on-premise). It subsequently resolves the call to the correct message container.

 Service Bus Message Broker

The message broker hosts and manages the message containers which receive the messages from the gateway.


Windows Fabric

The Fabric is the infrastructure that all the machines in a farm register with and use to communicate.  The Fabric manages load balanced requests to the farm.  It dynamically determines the number of registered instances of the message container service and distributes them to the servers on the farm using a rudimentary algorithm.

So start using the Service Bus for Windows Server on-premise today to get a jump on moving your message processing to Windows Azure.  It gives you the advantage of using an enterprise-class service bus on your own home turf.

For more information on Service Bus for Windows Server Beta 1.0, refer to the documentation found here:  http://msdn.microsoft.com/en-us/library/windowsazure/jj193022(v=azure.10)