A Microsoft Branded Service Bus without BizTalk

| by Jonathan Allen on Aug 23, 2012. Estimated reading time: 2 minutes |

For quite some time now BizTalk has been essentially on life support. Being both very complex and very expensive, it was never a particularly popular product. None the less, many companies used it because they trust the Microsoft name and actually do need some sort of enterprise service bus. Seeing this gap, Microsoft has created a new product called Microsoft Service Bus 1.0 for Windows Server.

Service Bus for Windows Server is based on Azure Service Bus and shares many of the same capabilities such as queue, topic, and subscription support, reliable message storage, and a variety of communication protocols. It is built with .NET 4.5 and requires a SQL Server or SQL Azure database for message persistence. This is a change from Microsoft Message Queues, which used a file-based persistence and couldn’t store more messages than what fit in RAM.

The primary communication protocols are Net.TCP and REST over HTTP. Net.TCP is a binary format that is designed for high performance communication between WCF clients and servers. For non-.NET applications, REST over HTTP is the preferred protocol.

A Service Bus installation would normally have a set of message brokers. Each message broker in turn contains one or more message containers. The message container hosts the actual queues, topics, and subscriptions. Each container is backed by its own database for persistence. When a new queue, topic, or subscription is created a load balancer determines which container to put it in. After that, the queue, topic, or subscription cannot be moved. However, the container itself can be moved to another server during a failover or for load balancing scenario.

> If a messaging broker NT service crashes or recycles, or in the event of a complete node recycle/shutdown, the associated message containers that were placed in this broker instance before the crash are automatically moved to other machines in the farm. The message containers continue to service requests with a small interruption in the case of failover.

Windows Fabric provides the “core logic necessary for high availability, farm and cluster formation, and load balancing across machines in the farm.” It is important to note that this alone isn’t enough for actual high availability. The SQL Server databases will also need to be mirrored, clustered, or replicated in some fashion to ensure they too will survive hardware failure.

Service Bus 1.0 for Windows Server is currently available as a beta.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Not a brand new product but copy of what's in Windows Azure by Richard Seroter

Good stuff Jonathan. Seems a bit editorial at the beginning, as even though the roadmap has been hazy (see my own take here, there is a new release of the product coming shortly. Also, "expensive", "complex" and "never particular popular" are relative. It's pretty affordable compared to enterprise competitors, complex is probably a fair assessment, but it is also the best selling enterprise ESB product by a mile.

The rest of the content looks great, but the BizTalk comparison isn't too valid at the moment. The inspiration for the Service Bus for Windows, the Windows Azure Service Bus, is likely the future of integration at Microsoft (with robust messaging, EAI, etc), but this local Windows Server version currently has 3% of the BizTalk functionality!

NServiceBus? by Kelvin Meeks

Udi Dahan's work on NServiceBus might also be of interest to folks looking for Microsoft-centric solutions for an Open Source service bus for .NET

Shuttle Service Bus by Eben Roux

A service bus should provide some basic functionality out-of-the-box and I'd imagine "Service Bus for Windows Server" may provide some more functionality in future. Perhaps some more detail could've been provided in the article. So all messages are stored only in a Sql Server database. Does this mean I cannot use MSMQ or any other queue technology with MS-SB, or can I implement my own queue using a new technology that may come up? Does it have the ability to retry message processing failures? Is it centralised or would I be able to run it on a client machine to perform some back-end processing?

For anyone interested in a simple solution I do have a free open-source project going:

- project site:
- wiki / documentation / overview:

I would urge interested parties to have a look at options other than only MS-SB as your may be pleasantly surprised. NServiceBus, MassTransit, and possibly others are also worth a look.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss