Microsoft SQL Server 2005 Developer’s Guide- P15 ppsx

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

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

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

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

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

Developing 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

T-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

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

the 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

and 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

Reservation System

Confirmation

Reservation Request Queue

Reservation Response Queue

Batch Update Process

Batch Reply Process

Reservation Database

Figure 4-3 Queued Application Design

Creating 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

which 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 ;

Declare 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