Service Bus for Windows Server (Service Bus 1.0 Beta)
On July 16, Microsoft released the beta of Microsoft Service Bus 1.0 for Windows Server. This release has been tightly kept under wraps for several months and my team was fortunate enough to have the opportunity to evaluate the early bits and help shape this release.
With the Beta now live, I’d like to share a bit of our perspective on this release, why it is significant and provide some details based on our experience with the bits.
Before I do so, let me provide an overview of Azure Service Bus to put into context this important capability as it exists today and where it is going.
A Brief Introduction to Azure Service Bus
Windows Azure Service Bus enables customers to integrate applications leveraging messaging capabilities that until now were only available in enterprise grade on-premise middleware platforms like BizTalk, Tibco, Neuron, and IBM WebSphere.
Azure Service Bus provides foundational messaging capabilities like pub-sub over a highly elastic messaging fabric that in addition to providing scalability, significantly simplifies exposing, composing and consuming services regardless of where they reside.
The core features that are part of Azure Service Bus today include:
- Connectivity - Rich options for interconnecting apps such as relayed messaging which enables federation of service endpoints across network and trust boundaries
- Messaging – Reliable and transaction-aware Cloud messaging via Queues and Topics
- Service Management - Consistent management surface and service observation capabilities via the Azure Portal and rich APIs for building your own management tools
- Security – Integration with Azure Access Control Service for authentication against Service Bus endpoints
Until now, most of the capabilities in Windows Azure including Azure Service Bus have been delivered under Microsoft’s “cloud-first” approach. Since the release of Windows Server AppFabric in Spring of 2010 (rebranded Microsoft AppFabric 1.1 for Windows Server), Microsoft has been very focused on investing new capabilities in the cloud with a promise that these capabilities will eventually land on-premise . With the latest release of Microsoft Service Bus 1.0 Beta for Windows Server, Microsoft delivers on this promise of fidelity between Cloud and on-premise capabilities.
In addition, Microsoft seems to have taken a slight detour from their “cloud-first” trend by delivering a new cloud-scale Workflow host for Windows Azure simply called (for now) Workflow for Windows Server. See the following post http://blogs.neudesic.com/post/2012/07/17/Introducing-Workflow-10-On-Premise-and-Beyond.aspx for more information on Windows Azure Workflow, and if you would like to learn more about the Azure hosted version of Azure Service Bus, check out “Introducing Queues and Topics in Azure Service Bus” in CODE Magazine written by my Neudesic colleague Rick Garibay: http://www.code-magazine.com/Article.aspx?quickid=1112041
Introducing Service Bus for Windows Server
With the latest release of the Service Bus for Windows Server, Microsoft is extending the brokered messaging capabilities of Windows Azure Service Bus previously only available through Windows Azure hosting to a private, on-premise hosting environment. While this release is delivered under the name Microsoft Service Bus 1.0 Beta for Windows Server, you will find that there is strong parity with the existing Azure Service Bus capabilities in terms of the API and overall development experience.
In fact, you will find that the samples in the Service Bus for Windows Server SDK are very similar to the samples in the existing Azure Service Bus SDK. The capabilities in this release include:
- Secure messaging
- Multiple messaging protocols
- Reusable patterns
- Delivery assurance through reliable messaging
- Scalability
- Cross-domain/network connectivity with minimal network changes
Service Bus for Windows Server is built on the Microsoft .NET Framework 4.5 PU3 and requires Windows Server 2008 R2, SQL Server 2008 R2 and Windows PowerShell 3.0. All these platforms must be running on a 64-bit operating system. The storage layer for the system (SQL) can be deployed on dedicated remote server or on one of the compute nodes or in Windows Azure SQL Database. The compute nodes used in this stack can be hosted either on-premises or on Windows Azure IAAS.
The following figure shows the platform stack for Service Bus for Windows Server:
Before you start exploring these capabilities, it is worth spending some time understanding some of the core components of Service Bus for Windows Server. These key components include:
- Service Bus Message Container
Service Bus for Windows Server uses SQL Server to store messages. Each database is mapped to a runtime component called a message container. Message containers point to the underlying database as well as additional cached information in order to accelerate the Service Bus. A Service Bus application server can host multiple message containers (thus communicating to multiple databases), but a message container is always hosted on a single Service Bus application server.
A Service Bus messaging entity (a queue, topic, subscription or rule) is created in a message container (and corresponding database). All messages in a Service Bus messaging entity are stored in the same container (and database). You should create multiple containers (even on the same database engine) in order to enable the Service Bus to balance the load on its servers as well as to support future scaling (adding more servers).
Service Bus message containers are created by running the following PowerShell command:
- Service Bus Service Namespaces
With Windows Azure Service Bus, a service namespace is a projection used for addressing and management all top-level entities such as queues and topics which are either addressed as an HTTP or sb:// path which starts with the name of the service namespace.
The Service Bus for Windows Server uses a similar approach to using service namespaces, but extends the cloud schema to support specifying the server hosts in your own private hosting environment. The Service Bus 1.0 Beta for Windows Server enables creating service namespaces using one of three addressing scheme:
- A path-based address (the default), that uses the fully-qualified domain name (FQDN) of the Service Bus nodes. The service URI for this schema appears as follows:
sb://yourServePath:Port/yourServiceNamespace/yourResourcePath
- A DNS-registered namespace schema supports DNS capabilities. By using DNS, you can decouple the actual server nodes (FQDN) from clients using the Service Bus. In other words, when you create a service namespace with a DNS-registered schema, you provide the URI which registered in your DNS. The service URI will be similar to the following:
sb://yourServiceNamespace/yourResourcePath
In this release, the Windows Azure Service Bus supports the use of configuration files for passing parameters for initialization code. Using this method (whether you are using Service Bus on Windows Server, inside Windows Azure worker or web roles), you can control deployment parameters outside your code. This enables you to point to different Service Bus deployments without the need to recompile the application.
It is worth noting that any endpoints exposed for Service Bus entities are secured and require authentication via the use of a claims token. In support of this, Service Bus for Windows Server provides a Secure Token Service (STS) known as $STS, which can be used for translating traditional credentials like an Active Directory username and password into a claims token. As a result, you will find that you will need to obtain a token from $STS before you are able to consume any Service Bus endpoints.
Conclusion
Service Bus for Windows Server addresses a number of challenges which historically have inhibited adoption of this extremely innovative capability. With support for mature ALM scenarios while providing the benefit of evaluating this Azure features On-Premises instead of going only to “cloud”, we believe this release is a good step in the right direction, giving customers the best of both worlds when it comes to evaluating and choosing the right capability for the job at hand. While additional core messaging capabilities like transformation, validation, routing, etc. are not currently included in either version of Service Bus, the work happening on Azure Service Bus Integration Services/BizTalk PaaS currently in CTP provides a very interesting glimpse of what’s likely to come and this is a great time to jump in and learn more.
Documentation and sample code is available in the included SDK, which you can download here: http://www.microsoft.com/en-us/download/details.aspx?id=30376.