Microsoft SQL Server 2005 Developer’s Guide- P7

Microsoft SQL Server 2005 Developer’s Guide- P7:This book is the successor to the SQL Server 2000 Developer’s Guide, whichwas extremely successful thanks to all of the supportive SQL Server developerswho bought that edition of the book. Our first thanks go to all of the peoplewho encouraged us to write another book about Microsoft’s incredible new relationaldatabase server: SQL Server 2005.
Nội dung trích xuất từ tài liệu:
Microsoft SQL Server 2005 Developer’s Guide- P7 Chapter 4: SQL Server Service Broker 119the SQL Server Service Broker subsystem to enable functionality in several otherareas of SQL Server 2005, including Notification Services, Reporting Services, andasynchronous query notifications. The SQL Server Service Broker is completely integrated with the SQL Server2005 engine and is fully transactional. Transactions can incorporate queued eventsand can be both committed and rolled back. In addition, the new SQL Server ServiceBroker also supports reliable delivery of messages to remote queues. This meansthat information sent via SQL Server Service Broker can span multiple SQL Serversystems and still provide guaranteed in-order, one-time-only message delivery—even to remote queues that must be reached across multiple routing steps. The SQLServer Service Broker will take care of the mechanics required to break the largemessages into smaller chunks that are sent across the network and then reassemblethem at the other end. You can see an overview of the SQL Server Service Brokerarchitecture in Figure 4-1.MessagesMessages are the core bits of information that are sent by a SQL Server ServiceBroker application. These messages can be text messages or consist of binary dataor XML. For XML messages, SQL Server can validate that the messages are wellformed and that they comply with a predefined schema. You create a SQL ServerService Broker message by running the CREATE MESSAGE TYPE command,which is where you specify the type of content that the message will have. Themessages that are sent across the queues can be very large—up to 2GB. SQL Server Database SQL Server Database Service Service Dialog Queue Queue Message Message Application ApplicationFigure 4-1 SQL Service Broker Architecture120 M i c r o s o f t S Q L S e r v e r 2 0 0 5 D e v e l o p e r ’s G u i d e 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 Service Service Queue Dialog QueueFigure 4-2 SQL Service Broker dialogdialogs 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 processedin order from the point of the last processed queued entry. Dialogs can be set up toprocess messages in either full-duplex mode or half-duplex mode.Message TransportThe SQL Server Service Broker message transport protocol enables messages to besent across the network. It is based on TCP/IP, and the overall architecture of theSQL Server Service Broker message transport is a bit like the architecture used byTCP/IP and FTP. By default the SQL Service Broker uses TCP/IP port 4022. TheSQL Server Service Broker message transport is composed of two protocols: theAdjacent Broker Protocol, which is a lower-level protocol like TCP, and the DialogProtocol, 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 eff ...