Chapter 4: SQL Server Service Broker 119 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 120 Microsoft SQL Server 2005 Developer’s Guide 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. 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 Chapter 4: SQL Server Service Broker 121 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 QueueDialog Figure 4-2 SQL Service Broker dialog 122 Microsoft SQL Server 2005 Developer’s Guide 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 Chapter 4: SQL Server Service Broker 123 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 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. 124 Microsoft SQL Server 2005 Developer’s Guide 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 Chapter 4: SQL Server Service Broker 125 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 Web Front End Database 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 126 Microsoft SQL Server 2005 Developer’s Guide 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 Chapter 4: SQL Server Service Broker 127 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 ; GO 128 Microsoft SQL Server 2005 Developer’s Guide 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 . 2GB. SQL Server Database Message Service Queue Application SQL Server Database Message Queue Application Dialog Service Figure 4-1 SQL Service Broker Architecture 120 Microsoft SQL Server 2005 Developer’s. 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. messages. Service Queue Service QueueDialog Figure 4-2 SQL Service Broker dialog 122 Microsoft SQL Server 2005 Developer’s Guide Developing SQL Service Broker Applications As you saw in the first part of this chapter, the SQL Server Service