What Does Service Broker Do?
Service Broker helps developers build asynchronous, loosely coupled applications in which independent components work together to accomplish a task. These application components exchange messages that contain the information that is required to complete the task. This topic describes the following fundamental aspects of Service Broker:
- Conversations
- Message ordering and coordination
- Transactional asynchronous programming
- Support for loosely coupled applications
- Service Broker components
Conversations
Service Broker is designed around the basic functions of sending and receiving messages. Each message forms part of a conversation -- a reliable, persistent communication channel. Each message and conversation has a specific type that Service Broker enforces to help developers write reliable applications.
New Transact-SQL statements allow applications to reliably send and receive the messages. An application sends messages to a service, which is a name for a set of related tasks. An application receives messages from a queue, which is a view of an internal table.
Messages for the same task are part of the same conversation. Within each conversation, Service Broker guarantees that an application receives each message exactly once, in the order in which the message was sent. The program that implements a service can associate related conversations for the same service in a conversation group, as described in Advantages of Service Broker.
Certificate-based security helps you protect sensitive messages and control access to services.
One way to understand Service Broker is to think of it as a postal service. To hold a conversation with a distant colleague, you can communicate with letters sent through the postal service, which sorts and delivers the letters. You and your colleague retrieve the letters from your mailboxes, read them, write responses, and send new letters until the conversation has ended. Letter delivery occurs "asynchronously," while you and your colleague handle other tasks.
.gif "Two users exchange mail through a postal service.")
In the postal service analogy, the letters are messages. A Service Broker service is the address to which the post office delivers the letters. Queues are the mailboxes that hold the letters after they are delivered. Applications receive the messages, act on the messages, and send responses.
A program that uses Service Broker holds conversations with other programs in a manner similar to postal delivery.
You do not have to know specifically when your colleague reads mail or writes responses. Similarly, an application that uses Service Broker does not have to know how another service processes a message, how it is delivered, or when the other application processes the message.
Message Ordering and Coordination
Service Broker handles queuing, a common database programming technique, differently from traditional products in two key respects:
- Service Broker queues are integrated into the database.
- The queues coordinate and order related messages.
Integrated queuing means that ordinary database maintenance and administration also include Service Broker. Typically an administrator has no routine maintenance tasks related to Service Broker.
The Service Broker framework provides a simple Transact-SQL interface for sending and receiving messages combined with a set of strong guarantees for message delivery and processing. Service Broker guarantees that a program receives each message in a conversation exactly once in the order in which the message was sent, not the order in which the message entered the queue. Traditional queuing products provide messages in the order in which the messages entered the queue, requiring an application to determine the order and grouping of messages. Service Broker guarantees that two queue readers cannot simultaneously process messages from the same conversation or the same group of related conversations.
The initiating program starts a conversation for each task and then sends a message to the target service. The message contains the data required to perform a specific step in a task. The target service receives the message. The program for the target service processes the message, and then responds to the initiating service. The conversation proceeds and eventually ends according to rules that are determined by the developer.
Service Broker handles the most difficult tasks involved in writing messaging applications. These include message coordination, reliable message delivery, locking, and starting queue readers. This lets database developers free to concentrate on solving business problems.
Transactional Asynchronous Programming
In the Service Broker infrastructure, message delivery between applications is transactional and asynchronous. Because Service Broker messaging is transactional, if a transaction rolls back, all Service Broker operations in the transaction roll back. This includes send and receive operations. In asynchronous delivery, the Database Engine handles delivery while the application continues running. To improve scalability, Service Broker provides mechanisms for automatically starting programs that process a queue when there is useful work for the program to do. For more information, see Service Broker Activation.
Asynchronous programming helps developers write applications that use queuing. Many database applications include tables that function as queues of work to be accomplished as resources allow. Queuing lets the database remain responsive for interactive users while efficiently using available resources. Service Broker provides queuing as an important part the Database Engine.
Queuing lets an application perform work in a different transaction than the transaction that requests the work. Service Broker extends this idea to let applications perform the work in a different instance, or on a different computer. Service Broker helps database developers by providing built-in queuing in the database and reliable, transactional messaging between instances.
Support for Loosely Coupled Applications
Service Broker supports loosely coupled applications. Loosely coupled applications are composed from multiple programs that send and receive messages independently of each other. Such applications must contain the same definitions for the exchanged messages and must define the same overall structure for the interaction between the services. However, the applications do not have to run at the same time, run in the same instance of SQL Server, or share implementation details. An application does not have to know the physical location or the implementation of the other participant in the conversation.
Service Broker Components
Service Broker has three types of components:
- Conversation components. Conversation groups, conversations, and messages form the run-time structure of a Service Broker application. Applications exchange messages as part of a conversation. Each conversation is part of one conversation group; a conversation group can contain multiple conversations. Service Broker conversations are dialogs, that is, conversations between exactly two participants. For more information about conversation components, see Conversation Architecture.
- Service definition components. These are design-time components that specify the basic structure of the conversations that the application uses. They define the message types for the application, the conversation flow for the application, and the database storage for the application. For more information about service definition components, see Service Architecture.
- Networking and security components. These components define the infrastructure for exchanging messages outside an instance of SQL Server. To help database administrators manage changing environments, Service Broker lets administrators configure these components independently of the application code. For more information about networking and security components, see Networking and Remote Security.
Service definition components, networking components, and security components are part of the metadata for the database and the instance of SQL Server. Conversation groups, conversations, and messages are part of the data that the database contains.
See Also
Concepts
Other Resources
Service Broker Architecture
Service Broker Activation
Security Considerations for Service Broker
Service Broker Tutorials