|
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. | 
Disclaimer
