Service Bus for Windows Server 1.1 Overview
Service Bus for Windows Server is a set of installable components that provides the messaging capabilities of Windows Azure Service Bus on Windows Server. Service Bus for Windows Server enables you to build, test, and run loosely-coupled, message-driven applications in self-managed environments and on developer computers.
The purpose of Service Bus for Windows Server is to provide similar capabilities across Windows Azure and Windows Server, and to enable flexibility in developing and deploying applications. It is built on the same architecture as the Service Bus cloud service and provides scale and resiliency capabilities. The programming model, Visual Studio support, and APIs exposed for developing applications are symmetric to that for the cloud service making it easier to develop applications for either, and switch between the two. Going forward, the experience for managing entities on the Windows Azure Management Portal will be consistent across the on-premises and cloud versions.
Scenarios for Service Bus for Windows Server
Develop on-premises, deploy in the cloud. This common scenario helps cloud application developers to develop and test applications on-premises in a development environment that can be installed on a desktop or laptop. To support cloud developers, the Service Bus for Windows Server can be installed on a client operating system (Windows 7 or 8, 64-bit) and use SQL Express editions (SQL Express 2008 R2 SP1 or higher). In addition, the Service Bus for Windows Server can be configured to use local accounts (rather than domain accounts) for development on a computer that is not domain joined, or is offline.
Flexible Deployment. Software vendors who offer their solutions to a wide range of customers want to be able to deploy their solution either as a cloud application, or distributed to their customers for deployment on-premises. Similarly, enterprises want the choice of where to deploy the application. To support this scenario, the Service Bus for Windows Server offers symmetry with the Windows Azure Service Bus (the Microsoft PaaS offering), as well as support for IaaS. Symmetry starts with the supported feature set (brokered messaging only for this release), the same SDK, and support for a configurable connection string that enables customers to change their deployment option without rebuilding the solution.
On-premises publish-subscribe. For enterprises developing services and applications, the Service Bus for Windows Server offers a Messaging Oriented Middleware (MOM) layer, with a rich publish-subscribe feature set. To support this scenario, the Service Bus for Windows Server offers features such as high availability, scalability, Windows token-based authentication (support for Active Directory), and more.
Messaging Features in Service Bus for Windows Server
Service Bus for Windows Server supports the same brokered messaging feature set as Windows Azure Service Bus. Service Bus queues offer reliable message storage and retrieval with a choice of protocols and APIs.
Service Bus Queues
Service Bus queues provide load leveling by allowing the message receiver to process messages at its own pace. In addition, Service Bus queues provide load balancing by having multiple competing receivers that accept messages from the same queue. For more information about Service Bus queues, see How to Use Service Bus Queues.
Service Bus Topics
In addition to queue features, Service Bus topics and subscriptions provide rich publish-subscribe capabilities that enable multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published message stream. For more information about Service Bus topics, see How to Use Service Bus Topics/Subscriptions.
Deployment and Manageability Options in Service Bus for Windows Server
Service Bus for Windows Server supports two methods of deployment, supporting different scenarios.
Service Bus runtime only (standalone): In this deployment scenario, there is a single administrator who deploys and manages the Service Bus farm, and creates namespaces. All management operations are supported with PowerShell commands, and there is no user interface (with the exception of the Service Bus configuration wizard for initial configuration).
Service Bus integration with Windows Azure Pack: In this deployment scenario, the administrator manages Service Bus using the Windows Azure Pack portal, deploying and managing the actual farm (cloud). Service Bus tenants also use the portal to create namespaces and messaging entities. The portal experience is similar to the one in Windows Azure.
Use the Service Bus standalone deployment (no portal) when there is a single tenant who manages Service Bus resources using PowerShell cmdlets and the Service Bus APIs.
Use the Service Bus integration with Windows Azure Pack in situations in which you want a management experience similar to the cloud, or when you want to expose some of the management experience to your tenants. Service Bus integration with the Windows Azure Pack also supports the management of multiple Service Bus farms (clouds) from a single portal. This is sometimes the case with large enterprises or hosters who want to offer resources (messaging) to multiple customers (different teams in an enterprise or for hosters, different companies).
Deciding whether to deploy Service Bus in a managed or unmanaged environment impacts the deployment steps. For more information, see the Getting Started with Service Bus for Windows Server 1.1 guide.
Note
Service Bus for Windows Server 1.0 offered only unmanaged Service Bus. Windows Azure Pack integration is a new addition to the Service Bus for Windows Server 1.1 release.
For more information about Windows Azure Pack, go here.The following table captures the main differences between the two alternatives.
| Area | Service Bus runtime only | Service Bus integration with Windows Azure Pack |
|---|---|---|
Service Bus deployment |
Setup using WebPI. Configuration using the configuration wizard or PowerShell. |
|
Create a Service Bus offering (a plan) |
Not supported. |
|
Namespace creation |
Farm administrator creates namespaces and assign owners. |
|
Service Bus entities management |
Using the Service Bus SDK (.NET or REST based). |
|
Supporting multiple farms |
Each farm is managed separately. |
|
Platform Features in Service Bus for Windows Server
The Service Bus for Windows Server provides a messaging platform for enterprise applications with a multi-host farm topology that provides both scale and high availability. The platform is based on Windows Server and Microsoft SQL Server. Developers that want a lightweight development environment can install the Service Bus for Windows Server on Windows client operating systems (64-bits) and Microsoft SQL Express.
You can deploy the Service Bus for Windows Server in a hosted environment such as Windows Azure Virtual Machines using a hosted Microsoft SQL Server database, or Windows Azure SQL Database (IaaS). For more information about supported platforms, see Supported Topologies.
Comparing Service Bus for Windows Server with Windows Azure Service Bus
Although symmetry exists between Service Bus for Windows Server and Windows Azure Service Bus in APIs and messaging features, there are differences between the two Service Bus products.
With respect to manageability, in a hosted Platform As A Service (Windows Azure) environment, the PaaS vendor (Microsoft) provides the management. With Service Bus for Windows Server, the local administrator deploys, secures, scales, and monitors the Service Bus for Windows Server farm.
In both Windows Azure and Windows Server, Service Bus requires access tokens for authorizing access to its messaging entities. Both share the Shared Access Secrets (SAS) authentication scheme for Service Bus namespaces as well as entities (queues and topics). However, in Windows Azure, Service Bus also supports the Windows Azure Active Directory Access Control (also known as Access Control Service or ACS), which is not available on Windows Server. However, on Windows Server, Service Bus supports Windows integrated authentication (domain joined users and Active Directory user groups), which are not available in Windows Azure.
While quotas and other runtime settings are fixed in the Windows Azure Service Bus, with the Service Bus for Windows Server an administrator can change those settings and customize the Service Bus for Windows Server farm.
The addressing schema is fixed in the Windows Azure Service Bus. In other words, all the endpoints have the Service Bus postfix added to the URL. With the Service Bus for Windows Server, you can use the fully qualified domain name (FQDN) of the hosts, or a mapped DNS entry representing your service.
Build Date:
2013-10-18