Architecture Overview

 

Applies To: Service Bus for Windows Server 1.1

This section provides an overview of the architecture of Service Bus for Windows Server, including the platform stack, the execution process system, farm solutions, scale out, and high availability.

Service Bus for Windows Server Overview

Service Bus for Windows Server is a set of installable components for Windows that provides Service Bus messaging capabilities (similar to the capabilities found in Service Bus [AppFabric_ServiceBus]). 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. Service Bus queues offer reliable message storage and retrieval with a choice of protocols and APIs. Building on the same foundation as queues, Service Bus topics provide rich publish/subscribe capabilities that allow multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published message stream.

Service Bus for Windows Server Platform Stack

Service Bus for Windows Server is built on the Microsoft dnprdnshort 4.0 PU3, lserver R2, SQL Server 2008 R2 and Azure SQL Database, 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 on a dedicated remote server, on one of the compute nodes, or in Microsoft Azure SQL Database. The compute nodes can be hosted either on-premises or on Microsoft Azure IAAS.

The following figure shows the platform stack for Service Bus for Windows Server.

Process and Execution Model

Service Bus for Windows Server supports a farm topology in which multiple servers (three) provide both scale and high availability. Each of the servers in the farm is identical and contains all the processes (hosted as NT services) required for Service Bus:

• Windows Fabric: Core clustering technology that manages a “ring” of nodes in the farm.

• Service Bus Message Broker: Manages the send and receive operations from Service Bus queues, topics and subscriptions.

• Service Bus Gateway: Serves as protocol head for supported Service Bus protocols. The gateway also performs security validation on incoming requests.

• Service Bus Resource Provider: Handles management requests from the Azure Pack portal.

• Service Bus VSS Writer: Discovers and automates backup and restore operations using Microsoft Volume Shadow Copy Service (VSS) technology.

The following figure shows the logical operation model for Service Bus for Windows Server. Each server has three key processes: the Service Bus Gateway, Service Bus Message Broker and winfab. All the processes in the server are hosted as Windows NT services.

You can connect a set of servers together in a highly-available “farm.”

Intra-Farm Communication Patterns

Because the Service Bus for Windows Server server farm is “highly available,” there is inter-process communication that spans local and remote computers.

• The Service Bus gateway process is a stateless service and can communicate with the message broker on local or remote computers within the farm.

• The Service Bus message broker process on every computer registers with the Windows Fabric service (on the same computer). This registration indicates availability to host Windows Fabric services.

• The Windows Fabric services on every computer communicate with each other to establish a “Highly Available Ring.”

Windows Fabric

This process contains the core logic necessary for high availability, farm and cluster formation, and load balancing across computers in the farm. The message broker service on each computer registers with the Windows Fabric process on respective computers. Windows Fabric determines the number of registered instances of the message container service and places them on the various computers in the farm based on a simple load balancing algorithm.

Service Bus Gateway

All incoming requests from clients are first received and processed by the Service Bus gateway. The protocol heads process the requests and perform the necessary authentication, authorization, and address resolution. The request is then forwarded to the appropriate message broker. In some cases, the client then communicates with the message broker directly for subsequent requests. The following diagram shows the communication flow that involves the Service Bus gateway:

Clients can use Net.TCP, AMQP, or REST over HTTP as the protocol for communication with the Service Bus for Windows Server server.

Serving Messaging Requests with REST, Net.TCP, and AMQP

When a client request is received at the gateway, it starts by authenticating the sender and authorizing access to the destination entity (see Authentication and Authorization). Then, it identifies the host (message container) for the messaging entity, such as a queue, topic, or subscription. The service then forwards the requests to the appropriate Service Bus message broker (local or remote) in which the message container is running.

Note

Net.TCP and AMQP support a messaging redirect feature (not available when using REST).

In this mode, after authentication and authorization the client can ask the gateway to respond with the address of the Service Bus message broker. The client can then connect directly to the Service Bus message broker for subsequent requests. This feature reduces the overhead of routing all requests through the gateway for every message sent over the wire.

Service Bus Message Broker

The message broker is a Windows NT service that hosts the protocol head and one or more message containers. The service registers itself with Windows Fabric and acts as a host for the message container service.

The following diagram shows a logical representation of the Service Bus message broker NT service.

The lifecycle of the Windows NT service is the basis for failover detection and high availability.

Message Container

You can view the message container as a logical collection of runtime (compute) logic that is backed by a persistent store (SQL Database). In the case of failover or for load balancing, the message container is a modular service that moves. Each message container is backed by a store (SQL database) and hosts a set of queues, topics, and subscriptions as determined by a simple round-robin capacity management algorithm. Entities such as queues, topics, and subscriptions placed in a container cannot be moved, and remain with the container and its associated database. All state related to the message container is persisted in the database.

High Availability

The Service Bus for Windows Server supports high availability. There are two aspects to high availability:

• Compute

• Storage

Compute Layer

Service Bus for Windows Server is a highly available server. The server depends on Windows Fabric to achieve high availability. In order to achieve high availability, Service Bus for Windows Server requires three computers. Topologies that have fewer than three computers cannot support high availability.

The following diagram shows the steady state condition of a three-computer farm in which there are three message containers.

If a Windows NT message broker 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 computers in the farm. The message containers continue to service requests with a small interruption in the case of failover.

If the server has more than one container, load balancing is another aspect of high availability. As new computers are added to the farm, the compute capacity is optimized by rebalancing the list of containers assigned to a specific messaging broker Windows NT service. The load balancing algorithm is also triggered when server administrators create new message containers or remove existing ones.

Service Bus for Windows Server automates the addition of new computers to the farm. It also automates farm reconfiguration to support high availability. To achieve this automation, the server automatically enables remote printer and file sharing.

Storage Tier

Service Bus for Windows Server provides no native support for high availability at the storage layer. You can use your own solution, such as SQL mirroring or SQL AlwaysOn availability groups.