A Microsoft Branded Service Bus without BizTalk
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.
Not a brand new product but copy of what's in Windows Azure
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!
Shuttle Service Bus
For anyone interested in a simple solution I do have a free open-source project going:
- project site: shuttle.codeplex.com/
- wiki / documentation / overview: servicebus.co.za/
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.