The SQL Server Service Broker is a new subsystem that provides a framework for building asynchronous applications using SQL Server 2005. The ability to support asynchronous queuing expands the scalability of SQL Server 2005 applications. Asynchronous queuing is an important factor for scalability because it allows an application to respond to more requests than the platform may be able to physically handle. Asynchronous queuing is found in many other highly scalable applications, such as the operating system’s I/O subsystems, Web servers, and even the internal operations of the SQL Server database engine itself. For instance, in the case of a Web server, if ten thousand users simultaneously requested resources from the server, without asynchronous queuing the Web server would be overwhelmed as it attempted to synchronously handle all of the incoming requests one at a time. Asynchronous queuing enables all of the requests to be captured in a queue. Then instead of being overwhelmed, the Web server can process entries from the queue at its maximum levels of efficiency. The addition of the SQL Server Service Broker to SQL Server 2005 enables you to build this same type of scalability into your database applications.

SQL Server Service Broker Architecture

It’s important to keep in mind that the SQL Server Service Broker is an application framework. Its goal is to take on the hard work of building asynchronous applications, and it does that by handling all of the heavy lifting for the asynchronous application. SQL Server Service Broker takes care of all of the hard-to-code details like guaranteed-in-order message routing and delivery. In other words, SQL Server Service Broker provides the plumbing for an asynchronous application but doesn’t provide the application itself. It is still up to you to build the application that uses the framework supplied by the SQL Server Service broker subsystem. Microsoft has made use of the SQL Server Service Broker subsystem to enable functionality in several other areas of SQL Server 2005, including Notification Services, Reporting Services, and asynchronous query notifications.

The SQL Server Service Broker is completely integrated with the SQL Server 2005 engine and is fully transactional. Transactions can incorporate queued events and can be both committed and rolled back. In addition, the new SQL Server Service Broker also supports reliable delivery of messages to remote queues. This means that information sent via SQL Server Service Broker can span multiple SQL Server systems and still provide guaranteed in-order, one-time-only message delivery— even to remote queues that must be reached across multiple routing steps. The SQL Server Service Broker will take care of the mechanics required to break the large messages into smaller chunks that are sent across the network and then reassemble them at the other end.

Messages

Messages are the core bits of information that are sent by a SQL Server Service Broker application. These messages can be text messages or consist of binary data or XML. For XML messages, SQL Server can validate that the messages are well formed and that they comply with a predefined schema. You create a SQL Server Service Broker message by running the CREATE MESSAGE TYPE command, which is where you specify the type of content that the message will have. The messages that are sent across the queues can be very large—up to 2GB.

Queues

SQL Server Service Broker queues contain a collection of related messages. Each queue is associated with a service. When a SQL Server Service Broker application sends a message, that message must first be placed in a queue. Likewise, when that message is received by the target system, it is received into a queue. Messages are validated when they are received by the target queue. If a message is not valid, then the service returns an error to the sender. Then the application can read the queue and process the message. You create a SQL Server Service Broker queue by running the CREATE QUEUE command.

Contracts

Contracts essentially define which messages can be used by a given queue. In order to be processed, a contract must first be created between a SQL Server Service Broker message and a queue or, more specifically, the queue’s service. The contract provides information to the service about the type of messages it will process. The contract also prevents errant messages from being sent to and used by an unintended target application. You create a SQL Server Service Broker message by running the CREATE CONTRACT command.

Services

A SQL Server Service Broker service is a specific Service Broker task or set of tasks. Each queue has an associated service. Conversations occur between services. The contracts associated with the service define the specific messages that will be processed by the service.

Dialogs

Dialogs are an essential component of Microsoft’s new SQL Server Service Broker. Essentially, dialogs provide two-way messaging between two SQL Server Service Broker services. Dialogs can be used for interserver communications for services running on different servers or instances, or they can be used for intraserver communications linking two applications running on the same server.

The main purpose of a SQL Server Service Broker dialog is to provide an ordered message delivery. In other words, dialogs enable queued messages to always be read in the same order that they are put into the queue. SQL Server Service Broker dialogs maintain reliable event ordering across servers even if network, application, or other failures temporarily disrupt the communications between dialog endpoints. When the communications are restored, the events will continue to be processed in order from the point of the last processed queued entry. Dialogs can be set up to process messages in either full-duplex mode or half-duplex mode.

Message Transport

The SQL Server Service Broker message transport protocol enables messages to be sent across the network. It is based on TCP/IP, and the overall architecture of the SQL Server Service Broker message transport is a bit like the architecture used by TCP/IP and FTP. By default the SQL Service Broker uses TCP/IP port 4022. The SQL Server Service Broker message transport is composed of two protocols: the Adjacent Broker Protocol, which is a lower-level protocol like TCP, and the Dialog Protocol, which is a higher-level protocol like FTP that rides on top of the lowerlevel Adjacent Broker Protocol.

Adjacent Broker Protocol The Adjacent Broker Protocol is a highly efficient lowlevel TCP/IP protocol that provides the basic message transport. It is a bidirectional and multiplexed protocol and so can handle the message transport for multiple SQL Server Service Broker dialogs. It doesn’t worry about message order or confirming message delivery. That’s all handled by the Dialog Protocol. Instead, the Adjacent Broker Protocol simply sends messages across the network as quickly as it can.

Dialog Protocol The Dialog Protocol is a higher-level protocol that utilizes the services of the Adjacent Broker Protocol to handle end-to-end communications for a SQL Server Service Broker dialog. It is designed to provide one-time-only, inorder delivery of messages, handling the sending and acknowledgment of messages. It also provides symmetric failure handling where both end nodes are notified of any message delivery failures. In addition, the Dialog Protocol is responsible for authentication and encryption of messages.