Chapter 4: SQL Server Service Broker 129 the network, they recommend using names like [//AdventureWorks.com/MySample/ SenderService]. The ON CONTRACT keyword specifies the contract that’s used for the dialog. The Contract specifies the contract that will be used. Then a SEND operation is executed to send a message on the conservation that was started. Finally, the transaction is committed. The target service will receive the message and add it to the queue that is associated with that service. At this point you can see the message on the ReceiverQueue by running the following SELECT command: USE AdventureWorks ; GO SELECT * FROM ReceiverQueue This shows two entries in the ReceiverQueue. The first entry on the queue is for the message that was placed on the queue by the sample application, and the second entry was created by the END CONVERSATION command. A partial view of the result set showing the contents of the ReceiverQueue is shown here: status priority queuing_order conversation_group_id 1 0 0 82C5F460-3305-DA11-8D17-005056C00008 1 0 1 82C5F460-3305-DA11-8D17-005056C00008 (2 row(s) affected) In order to see the contents of the message, you need to cast the contents of the message_body column in the results set to a varchar, as is shown in the following listing: USE AdventureWorks ; GO SELECT CAST(message_body as nvarchar(MAX)) from ReceiverQueue The result set showing the contents of the message is listed here: <message>Service Broker is Cool</message> NULL (2 row(s) affected) 130 Microsoft SQL Server 2005 Developer’s Guide Retrieving Messages from a Queue Now that you’ve seen how to add a message to a queue, the next example will illustrate how to retrieve the messages off the queue. You can see the T-SQL code in the following listing: use Adventureworks GO DECLARE @conversationID UNIQUEIDENTIFIER DECLARE @message_type_id int DECLARE @message_body NVARCHAR(1000) DECLARE @message NVARCHAR(1000) while(1=1) BEGIN BEGIN TRANSACTION WAITFOR (RECEIVE top(1) @message_type_id = message_type_id, @message_body = message_body, @conversationID = conversation_handle FROM ReceiverQueue), TIMEOUT 200; IF @@ROWCOUNT = 0 OR @@ERROR <> 0 BREAK; IF @message_type_id =2 BEGIN Print 'Conversation Ended' END CONVERSATION @conversationID ; END ; SELECT @message = 'Received: ' + @message_body; PRINT CONVERT(nvarchar(100), @message) COMMIT TRANSACTION END COMMIT TRANSACTION A variable that will contain the receiver dialog identification is declared at the top of this listing, followed by three variables that will be used to pull back information from the queue that’s being read. Then a loop is initiated to read all of the entries Chapter 4: SQL Server Service Broker 131 from the queue. Within the loop a transaction is started and the RECEIVE statement is used to receive a message. In this example, the TOP(1) clause is used to limit the procedure to receiving only a single message at a time. If the TOP clause were omitted, you could receive all of the messages that were present on the queue. The RECEIVE statement populates the three variables. The message_type_id identifies the type of message, which is typically either a user-defined message or an EndDialog message. The @message_body variable contains the contents of the actual message, while the @ReceiverQueue variable contains a handle that identifies the sending dialog. Then the result set is checked to ensure that a message was actually received. If no rows were received or an error is encountered, then the procedure is ended. Otherwise, the contents will be processed. If the message_type_id is a 2 (meaning the message was an EndDialog message), then the dialog conversation is stopped. Otherwise, the Select statement is used to access the message contents. The received message is concatenated with the string “Received:”, the message is printed, and the transaction is committed. You can see the sample text results in the following listing: (1 row(s) affected) Received: <message>Service Broker is Cool</message> (1 row(s) affected) Conversation Ended (0 row(s) affected) SQL Server Service Broker Activation SQL Server Service Broker activation is another unique feature of the SQL Server Service Broker subsystem. Activation enables you to create a stored procedure that is associated with a given input queue. The purpose of the stored procedure is to automatically process messages from that queue. As each new message comes in, the associated stored procedure is automatically executed to handle the incoming messages. If the stored procedure encounters an error, it can throw an exception and be automatically recycled. Periodically, the SQL Server Service Broker checks the status of the input queue to find out if the stored procedure is keeping up with the incoming messages on the input queue. If the SQL Server Service Broker determines that there are waiting messages 132 Microsoft SQL Server 2005 Developer’s Guide on the queue, then it will automatically start up another instance of the queue reader to process the additional messages. This process of automatically starting additional queue readers can continue until the preset MAX_QUEUE_READERS value is reached. Likewise, when the SQL Server Service Broker determines that there are no remaining messages on the queue, it will begin to automatically reduce the number of active queue readers. SQL Server Service Broker queues don’t necessarily need to be associated with just stored procedures. Messages that require more complex processing can also be associated with external middle-tier procedures. Since these middle-tier processes are external to the database, they need to be activated differently. To enable the automatic activation of external processes, the SQL Server Service Broker also supports firing a SQL Server event. These events can be subscribed to using WMI (Windows Management Instrumentation). Dialog Security When dialogs are created, they can optionally be secured using the WITH ENCRYPTION clause. When a dialog is created using the WITH ENCRYPTION clause, a session key is created that’s used to encrypt the messages sent using the dialog. One important point about dialog security is the fact that it is an end-to- end security. In other words, the message is encrypted when it is first sent from a dialog, and it is not decrypted until the message reaches its endpoint. The message contents remain encrypted as the message is forwarded across any intermediate hops. To implement dialog security, the SQL Service Broker uses certificate-based authentication, where the certificate of the sending user is sent along with the message. Because of the asynchronous nature of SQL Service Broker, the security information is stored in the message headers and retrieved by the receiving service when the message is retrieved. This enables SQL Service Broker applications to avoid the need to establish a connection to authenticate messages. System Views SQL Server 2005 supplies several new system views that enable you to retrieve information about SQL Service Broker objects and its current status. Table 4-3 lists the new system views. Chapter 4: SQL Server Service Broker 133 Summary SQL Server Service Broker is an all new subsystem that enables you to create highly scalable asynchronous applications. In this chapter you learned about the new SQL Server Service Broker architecture and you saw how to create and use the objects that make up a SQL Server Service Broker application. System View Description sys.service_message_types Lists all the message types that have been created. System message types are listed at the top, while user-defined message types are listed at the end of the display. sys.service_contracts Lists all of the contracts that have been created. sys.service_contract_message_usages Lists the relationships between contracts and message types. Relationships can be one-to-one or one-to-many. sys.services Lists the created services. sys.service_contract_usages Lists the relationships between contracts and services. Relationships can be one-to-one or one-to-many. sys.service_instances Lists the services that are active at the current time. sys.conversation_endpoints Lists the conversation endpoints that are currently active. sys.routes Lists the created routes. sys.remote_service_bindings Lists the relationship of the services and the users that will execute them. sys.transmission_queue Lists all of the messages that are queued to be sent. sys.service_queues Lists the queues that have been created. Table 4-3 SQL Server 2005 New System Views This page intentionally left blank 135 CHAPTER 5 Developing with Notification Services IN THIS CHAPTER Notification Services Overview Developing Notification Services Applications Notification Services Application Sample Updating Notification Services Applications Building a .NET Subscription/Event Application Copyright © 2006 by The McGraw-Hill Companies. Click here for terms of use. 136 Microsoft SQL Server 2005 Developer’s Guide N otification Services is a new subsystem that Microsoft has added to SQL Server 2005. First introduced as a Web download for SQL Server 2000, Notification Services provides a framework that enables you to develop custom notification applications that monitor for specific data events and then push customized notification information concerning those events to multiple subscribers and devices. Notification Services is used in a number of well-known scenarios. Microsoft’s MSN Messenger uses Notification Services to alert your cell phone of traffic. NASDAQ’s Nasdaq.com site and The New York Times’ NYTimes.com are two other high-profile Notification Services users. The Nasdaq.com site allows subscribers to receive personalized notifications about changes in financial data. Here subscribers can ask to be alerted about specific changes in market prices. The NYTimes.com site uses Notification Services to push new real estate listings in the East Coast market to subscribers. In this scenario, renters or buyers specify the property characteristics that they are interested in, and they receive notifications whenever a property matching their criteria is listed in The New York Times real estate classified section. In this chapter you’ll learn how to create a Notification Services application. In the first part of this chapter you’ll get an overview showing you how the new subsystem works. In the second part of the chapter you’ll see how to build a Notification Services application. Later in the chapter you’ll learn how to update a Notification Services application, as well as how to build a .NET subscription/event application. Notification Services Overview A Notification Services application is a software layer that sits between an information source and the intended recipient of that information. The Notification Services application monitors certain predefined events and can intelligently filter and route the information about those events to a variety of different target devices using a personalized delivery schedule. Notification Services applications consist of three basic components: events, subscriptions, and notifications. Figure 5-1 provides a very high-level overview of a Notification Services application. Events In a Notification Services application, events are just what they sound like—things happening that you want to be informed about. In the case of the NASDAQ, an event might be a given stock price rising to a certain level. In a typical database application Chapter 5: Developing with Notification Services 137 an event could be associated with the value of a given column. Here the event would be fired if the column’s value passed a certain predefined threshold. Event Providers A Notification Services application monitors for events using an event provider. There are three types of Notification Services event providers: hosted, non-hosted, and standard event providers. Hosted Providers Hosted event providers are directly executed by Notification Services. When Notification Services starts, it automatically initializes and runs enabled hosted event providers. Non-Hosted Providers Non-hosted event providers are external applications that do not run within the Notification Services process. Non-hosted event providers post event data to a Notification Services application using the EventCollector class; the EventLoader class; or the NseventBeginBatch, NSEventWrite, or NSEventFlushBatch stored procedures. Notification Services Application Event provider Generator Event Provider Host SQL Match Rule File System Watcher SQL Server Provider Custom EP Distributor Custom CF SMTP HTTP Custom DP File X S L T XSLT CF Events Notifications Subscribers Subscriber Devices Subscriptions External Delivery Data Changes Figure 5-1 Notification Services overview 138 Microsoft SQL Server 2005 Developer’s Guide Standard Providers SQL Server 2005 ships with a base set of standard event providers that you can readily use to build Notification Services applications. Notification Services provides the following event providers: ᭤ File System Watcher The File System Watcher event provider monitors the fi le system and is triggered when a fi le is added to the monitored directory. It reads the directory contents into memory and then writes event information to the event table. ᭤ SQL Server The SQL Server event provider uses a T-SQL query to specify database data that will be monitored. It then uses Notifi cation Services– provided stored procedures to create events based on this new or updated data and then write these events to the event table. ᭤ Analysis Services The Analysis Services event provider uses a static or dynamic MDX query to gather data from an Analysis Services cube and submit the data as events to an application. Subscriptions Subscriptions correlate users and the types of events that they are interested in. For example, with the NASDAQ example, a user might create a subscription to get a notification when a given stock price drops below $50 per share. SQL Server 2005’s Notification Services stores subscriptions, like events, as rows in a table. Notifi cations The notification is essentially a message that will be sent to the end user that contains the information regarding the event that the user subscribed to. Notifications can be delivered in various formats to a variety of different target devices, including XML, HTML, e-mail, WAP, and other formats. Notification Engine The Notification Services engine receives external events from the event provider and looks for matches between events and registered subscriptions. When an event matches a subscription, the Notification Services engine sends a notification to the end user. The scalability of a Notification Services application depends in a large part on how well the Notification Services engine matches events to subscriptions. Microsoft has designed the underlying Notification Services framework to be scalable at an Internet level, meaning that with the appropriate platform, SQL Server 2005’s Notification Services can scale upward to handle millions of events, subscriptions, and notifications. To do that, Notification Services takes advantage of SQL Server . use. 136 Microsoft SQL Server 2005 Developer’s Guide N otification Services is a new subsystem that Microsoft has added to SQL Server 2005. First introduced as a Web download for SQL Server 2000,. Notifications Subscribers Subscriber Devices Subscriptions External Delivery Data Changes Figure 5-1 Notification Services overview 138 Microsoft SQL Server 2005 Developer’s Guide Standard Providers SQL Server 2005 ships with a base set of standard event providers that. affected) Conversation Ended (0 row(s) affected) SQL Server Service Broker Activation SQL Server Service Broker activation is another unique feature of the SQL Server Service Broker subsystem. Activation