Service Bus for Windows Server Overview

  • Article

The Service Bus for Windows Server is a set of installable components that provides the messaging capabilities of the Windows Azure Service Bus on Windows Server. The 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 the 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 the Service Bus for Windows Server

The Service Bus for Windows Server supports the same brokered messaging feature set as the 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.

Platform Features in the 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 the 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, the Service Bus requires access tokens for authorizing access to its messaging entities. Because the Windows Azure Active Directory Access Control (also known as Access Control Service or ACS) is not available on Windows Server, the Service Bus for Windows Server includes a simple Service Bus Security Token Service (SBSTS) integrated with the Windows security model. The SBSTS can issue Simple Web Tokens (SWTs) based on Windows identities (stored in the local Windows identity store or in Active Directory).

  • 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