I talked a lot on this blog about the fallacies of distributed computing and how messaging addresses some of the fallacies. But messaging does more, it helps to decouple (temporal, spatial and platform coupling vice) your components which build up a system. Service Bus for Windows Server provides messaging capabilities of Windows Azure Service Bus on Windows for On-Premise purposes (self-managed environments and on developer computers). It contains a rich feature set such as reliable queues, a variety of protocols and APIs to interact with it, and a rich publish/subscribe model that allows multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published messages.
Despite its name it is not a bus architectural style but a broker (mediator / hub and spoke). Therefore the Service Bus for Windows Server is not a lightweight store-and-forward queuing system like MSMQ. On the other hand it offers rich message exchange semantics such as topic based routing via publish-subscribe. MSMQ only supports point-to-point one way messaging. NServiceBus builds publish-subscribe on top of MSMQ by leveraging persistent storage on the publisher side to store routing information (where are the subscribers, what are their interests). I usually prefer store-and-forward transports over broker based transports because in my opinion they incorporate better the true nature of distributed systems than centralized brokers. But of course brokers have the advantage of a centralized administration and connection point. In the end both have their advantages and disadvantages, you need to choose according to your non-functional requirements or in the most extreme case have both styles in place.
Let us look at the underlying architecture of Service Bus for Windows Server and how easily it can be installed on-premise.
Service Bus for Windows Server is based upon the .NET 4.0 framework (namely PU3) and uses SQL Server 2008 R2 or Azure SQL Database as the backing store and can be administrated with Windows PowerShell 3.0. The platform stack consists out of 5 different services which need to run on each computing node.
- Service Bus Resource Provider
- Service Bus VSS Writer
- Service Bus Gateway
- Service Bus Message Broker
- Windows Fabric 1.0 CU1
The installation package ships a few administrative commandlets for each computing node which allows you to command & conquer the service bus services with PowerShell. The storage tier should be run separately from the computing nodes and should be at least SQL Server 2008 R2 SP1 or higher (or SQL Azure). So let’s visualize a computing node for better clarity (leaving out the resource provider and the VSS writer).
The Service Bus gateway is a stateless service which receives all incoming requests from clients first and performs the necessary authentication, authorization and address resolution. The request is then forwarded to the Service Bus Message Broker service. Once that process is done subsequent requests from clients are directly routed to the Service Bus Message Broker service (redirect). The Windows Fabric services establish a highly available ring for Service Bus farm operation mode which we will cover later. The Service Bus Gateway offers a variety of protocol heads such as REST, TCP and AMQP. Depending on the chosen protocol head the above described message redirect doesn’t work (for example with the REST protocol). The Service Bus message brokers “hosts” queues, topics and subscriptions. Inside the Service Bus Message broker the queues, topics and subscriptions are logically grouped together into collection of so called message containers. All state related to those message containers is persisted to the storage layer.
The next installment will cover high availability and why it is important for a broker based transport