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 not
Trang 1the 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 You can see an overview of the SQL Server Service Broker
architecture in Figure 4-1
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
SQL Server Database
Message
Service Queue
Application
SQL Server Database
Message Queue
Application
Dialog
Service
Figure 4-1 SQL Service Broker Architecture
Trang 2SQL 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 Figure 4-2 illustrates the SQL Server Services Broker’s dialog
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
Trang 3dialogs 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
lower-level Adjacent Broker Protocol
Adjacent Broker Protocol The Adjacent Broker Protocol is a highly efficient
low-level 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,
in-order 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
Service Queue
Service Queue Dialog
Figure 4-2 SQL Service Broker dialog
Trang 4Developing SQL Service Broker Applications
As you saw in the first part of this chapter, the SQL Server Service Broker is a subsystem that enables the development of asynchronous database-oriented messaging applications The first part of this chapter provided you with an overview of the primary components of the SQL Service Broker subsystem and gave you an idea of the functions and interactions of those components This section will present the new T-SQL commands that you can employ to create and use SQL Server Service Broker objects; it will then present a sample SQL Server Service Broker application
SQL Server Service Broker DDL and DML
SQL Server 2005 utilizes a new set of T-SQL commands to describe the database objects used in a Service Broker application as well as new commands that enable you to access those objects in your applications
T-SQL DDL
T-SQL has been enhanced with several new statements that enable the native
integration of SQL Server Service Broker messaging with traditional database procedures Table 4-1 summarizes the new T-SQL DDL statements that are used to create SQL Server Service Broker objects
T-SQL DML
In addition to the new T-SQL DDL statements that are used to create the new SQL Server Service Broker objects, there are also a group of new T-SQL statements that enable your applications to set up conversations and work with the messages in a SQL Server Service Broker application Table 4-2 lists the new SQL Server Service Broker–related T-SQL DML statements
Enabling SQL Server Broker
Before you can begin to build SQL Server Service Broker applications, you must first enable the SQL Server Service Broker subsystem Like the new SQL Server
2005 CLR support, to enhance out-of-the-box security, SQL Server 2005 ships with
Trang 5T-SQL DDL Description
CREATE MESSAGE TYPE Creates a new message type Message types can be text, binary, or XML
CREATE CONTRACT Creates a new contract associating a message type and service
CREATE QUEUE Creates a new queue in a database
CREATE ROUTE Creates a new route in a database
CREATE SERVICE Creates a new service in a database
ALTER MESSAGE TYPE Changes a message type
ALTER CONTRACT Changes a contract
ALTER QUEUE Changes a queue
ALTER ROUTE Changes a route
ALTER SERVICE Changes a service
DROP MESSAGE TYPE Deletes a message type from a database
DROP CONTRACT Deletes a contract from a database
DROP QUEUE Deletes a queue from a database
DROP ROUTE Deletes a route from a database
DROP SERVICE Deletes a service from a database
Table 4-1 The New T-SQL DDL Statements Used to Create SQL Server Service Broker
Objects
Table 4-2 The New SQL Server Service Broker–Related T-SQL DML Statements
T-SQL DML Description
BEGIN DIALOG CONVERSATION Opens a new dialog between two endpoints
END CONVERSATION Ends a conversation used by a dialog
MOVE CONVERSATION Moves a conversation to a new dialog
GET CONVERSATION GROUP Retrieves a conversation group identifier for the next message to be received
RECEIVE Receives a message from a queue
SEND Sends a message to a queue
BEGIN DIALOG TIMER Opens a timed dialog A message is placed on the dialog when the timer expires
Trang 6the SQL Server Service Broker disabled The following code illustrates how to enable the SQL Server Service Broker for the AdventureWorks database:
IF NOT EXISTS
(SELECT * FROM sys.databases
WHERE name = 'AdventureWorks'
AND is_broker_enabled = 1)
BEGIN
ALTER DATABASE AdventureWorks SET ENABLE_BROKER ;
END ;
This checks the is_broker_enabled property of the AdventureWorks database
If the is_broker_enabled value is not 1—if, in other words, Service Broker is not enabled—then the ALTER DATABASE SET ENABLE BROKER command is used
to enable the Service Broker This command sets the is_broker_enabled value to 1
As you might have noticed, the SQL Server Service Broker is enabled on a per-database basis
Using Queues
While the idea of queuing in applications may be a bit foreign to most relational database designers, queues are common in highly scalable applications Among the most well known of these types of applications are the airline reservation systems used by all major airlines like United, Delta, and American, as well as online travel brokers like Expedia and CheapTickets.com To get an idea of how queuing is used
in one of these applications, you can refer to Figure 4-3, where you can see the design of a sample queued application
Figure 4-3 presents a high-level overview of an example airline reservation system Here you can see that the application’s presentation layer is delivered to the end user’s browser by an application running on a web farm That application could
be written using ASP.NET or some other web development language The front-end application will then interact with the actual reservation system, which is normally running on another computer system Because applications like these must support thousands of simultaneous users, they can’t afford to lock rows while a given user waits to decide on the final details of a flight or even starts a reservation and then goes to lunch, planning to finish later Row locking in this type of scenario would seriously inhibit the application’s scalability and even the application’s usability Queuing solves this problem by enabling the application to make an asynchronous request for a reservation, sending the request to the back-end reservation system
Trang 7and immediately freeing the front-end application for other work At no point in
the process of placing the reservation have any locks been placed on the database
tables The back-end reservation system, which is essentially operating in batch
mode, will take the reservation request off the queue and then perform the update to
the database Since the update is being done in a batch-style mode, it happens very
quickly with no user interaction, and minimal time is needed to lock rows while
the update is performed If the request is successful, the end user’s reservation is
confirmed Otherwise, if the request is denied because all seats were booked or for
some other reason, then the reservation will not be accepted and the user will be
contacted with the status
Sample SQL Server Service Broker Application
This section will now dive into the code and show you how to create a sample SQL
Server Service Broker application First you’ll see how to create the required SQL
Server Service Broker objects, and then you’ll see how to use those objects The
sample application is a simple messaging system that places a simple XML message
on an input queue and then reads that message off the queue
Reservation Web Application
Back-End Reservation System
Confirmation
Reservation Request Queue
Reservation Response Queue
Batch Update Process
Batch Reply Process
Reservation Database
Figure 4-3 Queued Application Design
Trang 8Creating the SQL Server Service Broker Objects
The code that’s used to create the required SQL Server Service Broker objects is shown in the following listing:
Create the XML SBSampleMessage message type
CREATE MESSAGE TYPE SBSampleMessage
VALIDATION = WELL_FORMED_XML ;
GO
Create the SBSampleContract contract
CREATE CONTRACT SBSampleContract
( SBSampleMessage SENT BY INITIATOR);
GO
Create the queue
CREATE QUEUE [dbo].[ReceiverQueue];
GO
Create the queue for the Sender service
CREATE QUEUE [dbo].[SenderQueue];
GO
Create the service
CREATE SERVICE SenderService
ON QUEUE [dbo].[SenderQueue];
GO
Create the target service
CREATE SERVICE ReceiverService
ON QUEUE [dbo].[ReceiverQueue]
(SBSampleContract);
GO
The first step to creating a SQL Server Service Broker application is the creation
of the required message types, which describe the messages that will be sent The first statement shows the creation of the message type named SBSampleMessage The VALIDATION keyword indicates that this message will be an XML message, and SQL Server will check to make sure the XML is well formed
Next, a contract is created The contract describes all of the messages that can be received using a particular service The first argument is used to name the contract Here the contract is named SBSampleContract The SENT BY clause specifies
Trang 9which endpoint can send a message of the indicated message type INITIATOR
indicates that only the initiator of the conversation can send messages of the
SBSampleMessage type
Then the queues must be created This example shows the creation of two queues:
the ReceiverQueue and the SenderQueue As their names suggest, the SenderQueue
will be used to send messages and ReceiverQueue will be used to receive messages
of the SBSampleMessage type
After the queues are created, you can display the contents of the queues by using
the SELECT statement exactly as if the queue were a standard database table The
following line of code shows how you can display the contents of the Request queue:
SELECT * FROM ReceiverQueue
At this point, however, since there are no messages in the queues, the result set
will be empty However, running SELECT statements on the queue is a great way
to check out functionality of the SQL Server Service Broker applications you are
developing
After the queues have been created, the next step is to create the services for the
queues using the CREATE SERVICE statement The first parameter names the service
The ON QUEUE clause identifies the queue associated with the service, and then
the contracts that are associated with the service are listed In the preceding listing,
you can see two services being created: the SenderService and the ReceiverService
The SenderService handles messages in the SenderQueue, while the ReceiverService
handles messages in the ReceiverQueue
If one of the services were located on a remote system, you would also need to
create a route The CREATE ROUTE statement supplies the SQL Server Service
Broker with the system address where the remote service is found In this case, since
both services reside on the same system, no route is needed
Sending Messages to a Queue
After the necessary SQL Service Broker objects have been created, you’re ready to
use them in your queuing applications The following code listing shows how you
can add a message to the ResRequestQueue queue:
USE AdventureWorks ;
GO
Begin a transaction
BEGIN TRANSACTION ;
Trang 10Declare a variable for the message
DECLARE @SBmessage XML ;
SET @SBmessage = N'<message>Service Broker is Cool</message>' ;
Declare a variable for the conversation ID
DECLARE @conversationID UNIQUEIDENTIFIER ;
Begin a dialog between the services
BEGIN DIALOG CONVERSATION @conversationID
FROM SERVICE SenderService
TO SERVICE 'ReceiverService'
ON CONTRACT SBSampleContract ;
Put the message on the queue
SEND ON CONVERSATION @conversationID
MESSAGE TYPE SBSampleMessage
(@SBmessage) ;
End the conversation
END CONVERSATION @conversationID ;
GO
Commit the transaction to send the message
COMMIT TRANSACTION ;
GO
At the start of this listing you can see where a transaction is started Using
transactions enables all of the actions that are performed by the SQL Server Service Broker to commit and, optionally, to roll back any changes that are made within the context of the transaction Next, a variable named SBMessage is declared that contains the message that will be sent by SQL Service Broker Then the conversationID variable
is created that contains a unique identifier that will be used by a SQL Server Service Broker dialog Then the BEGIN DIALOG COVERSATION statement is used to open up a new conversation When you declare a dialog, you always need to specify two endpoints The FROM SERVICE identifies the sender of the messages, while the TO SERVICE keyword identifies the target endpoint Here, the sender is named SenderService and the target is named ReceiverService While this example uses simple names, Microsoft BOL recommends that you use a URL name to uniquely identify the SQL Server Service Broker objects For example, to ensure uniqueness in