Routing Service Broker conversations (Part 1)

To allow conversations across SQL Server instances, Service Broker provides a binary adjacent transport protocol. Brokers can communicate directly from initiating service to target service or use multiple intermediate forwarding brokers. In order to identify brokers uniquely, they carry a GUID property called broker_instance. (In SQL Server 2005, each database takes on the role of a broker). When a service begins a dialog with a remote service, the user only specifies the target service name and optionally a broker_instance GUID. We denote the target of a dialog using a tuple (service_name, broker_instance) . The service name does not directly identify a network location. The routing infrastructure provides the mechanism for finding a network path to the remote service.

You can create/drop/alter routes that map service_name and broker_instance to a network address. We denote a route using a tuple (service_name, broker_instance, address, mirror_address) . We classify the types of route definitions as follows: [Note: ‘*’ means not specified and hence match-all]

The address is typically a URL of the form:

   tcp://hostname|ip_address[:port]

But there are two special cases for last_resort routes. You can specify the address to be ‘LOCAL’ which indicates that the router should try to find a locally deployed broker. You can also specify ‘TRANSPORT’ which means the router should parse the service_name to extract a fully-qualified network location, eg> tcp://rushi.desai.name:4256/MyService.

When the initiating service sends the first message on the dialog, the broker attempts to resolve the route based on a routing policy. The following precedence rules are used for matching routes:

Broker Configuration Notification service or BCN is a mechanism for doing external route lookup and is explained in a future post.

By default, Service Broker creates a route (*, *, LOCAL) when a database is created. The helps map service_name to local services when no other matching routes are present (and BCN is not configured).

Typical scenarios

Migration – Disassociating names from locations enables the DBA to physically move a service without changing the application.

Forwarding – If there are thousands of front-end brokers initiating dialogs with a few backend target brokers, the overhead of managing thousands of connections could put too much load on the backend servers. The routing mechanism allows you to deploy mid-tier forwarding brokers which simply forward messages to next-hop broker without persisting them. The intermediate brokers are ‘forward-only’ and not ‘store-and-forward’ and do not participate in acknowledgement and retry.

Load-balancing – If a single broker cannot take the load of incoming requests, the services may be replicated on multiple brokers. A load-balancing router would have definitions for all the backend brokers. The router picks a route uniformly by hashing the conversation handle. A route chosen is sticky so that all messages belonging to a particular conversation will always be forwarded to the same remote broker.

Mirrored routes – For high-availability, databases may be mirrored using database mirroring. Service Broker can talk to mirrored brokers using a mirrored route. In such a case, you must define a ‘full’ route with the network addresses of both principal as well as mirror. The initiating broker monitors the state of the mirrored brokers and sends messages to the principal when available. On failover, it automatically switches to sending messages to the new broker seamlessly.

Disclaimer: The information presented here may be incorrect or out-of-date. The purpose of the post is only to give a general idea about typical usage scenarios. Refer to Books Online in your SQL Server 2005 for an exhaustive list of routing rules and policies