This week, Microsoft released a beta of the Service Bus for Windows which has a subset of the functionality contained within the cloud-based Windows Azure Service Bus messaging engine. This is Microsoft’s first step towards delivering its rapidly-maturing cloud integration stack as a self-managed product.
The Windows Azure Service Bus consists of a suite of products used to integrate systems that span clouds. The Relay service, which was the first major component of the Windows Azure Service Bus, is used by developers to establish a bi-directional tunnel between an on-premises Windows Communication Foundation (WCF) service and the Windows Azure cloud. Service consumers can then send request messages to a public service address and the Windows Azure Service Bus will securely relay that message to the onsite service. Users are authenticated through an Access Control Service which supports identity federation with providers such as Google, Facebook, Yahoo and Microsoft. In the past year, Microsoft has added multiple capabilities to the Windows Azure Service Bus. These capabilities include integration with on-premise line of business systems through the Service Bus EAI components (previous InfoQ coverage), and durable messaging supported by Topics and Queues.
The Service Bus for Windows software makes it possible to provision and operate Service Bus Topics and Service Bus Queues on any server running Windows Server 2008 R2 or later. The entire solution is capable of running on a single Windows machine but also supports a highly available, multi-node deployment model. In addition to requiring a Windows operating system, this software also requires the use of SQL Server 2008 R2 (or later) for its persistence layer, and Windows PowerShell for administering the servers. Sam Vanhoutte, the chief architect of IT services company Codit, wrote a blog post that explained a handful of scenarios where it makes sense to use this software in a self-managed environment instead of within Microsoft’s Windows Azure cloud.
Durable messaging only scenarios
If you require to exchange messages in a local, messaging only scenario, you can perfectly use Service Bus for Windows server to deliver messages between applications and services in a durable and reliable fashion.
Store & forward scenariosThe Service Bus for Windows server release contains the possibility to define ForwardTo subscriptions on topics, so that messages that match the subscription of these rules, automatically get forwarded to the defined messaging entity. At this point it’s not possible to configure a ForwardTo that points to a remote entity, but one can work around that by having a subscriber that listens to a local ForwardTo entity and sends these messages to a public entity.
Distributed scenarios
A lot of organizations have different business units or plants that need to be interconnected. In a lot of companies (often after mergers and acquisitions), the technology that is used in these different plants is different. Therefore, it could be good to have Service Bus being used as the gateway to exchange messages between the different units, while every unit can use it’s standard of choice (REST, SOAP, .NET, AMQP…) to connect to that gateway.
Microsoft previously attempted to establish symmetry between on-premises and cloud products through the use of the “AppFabric” brand name. However, the only product in common between the environments was an in-memory cache engine and the Windows Azure team has recently dropped the AppFabric name from its cloud product. Microsoft has seemed to settle on the “Service Bus” name and it would seem likely that missing Windows Azure Service Bus capabilities will find their way into this on-premises software. The software currently lacks its own Access Control Service components and does not have any authentication model besides Microsoft Active Directory. Likewise, the Windows Azure Service Bus EAI components, which remain in beta form, currently have no stated timeline for an on-premises edition. Vanhoutte points out the challenges in trying to keep cloud and on-premises software capabilities in sync.
One of the biggest unknowns at this time, is how Microsoft will keep symmetry on server. The release cadence of server products versus cloud based services is just too different. New features are being added to the various services all the time, and they also have to ship to the server installations over time. I’m curious to find out what the release cycle will be for these updates.