Microsoft’s new Service Broker feature in SQL 2005 introduces a number of new concepts, processes and terminology which for some may make the idea of using Service Broker a little daunting. On this site we hope to ease some of that pain by giving our thoughts, examples and explanations on the platform.
To start with lets have a look at some of the terminology which may be new to many.
A:
Asynchronous
Asynchronous in process terms means a task which can continue independently “in the background”. Other processes may be started before the asynchronous process has finished.
In Service Broker this means that we can effectively decouple messages from the processes that initiated them. A sending process can send a message and then continue to completion or start a number of other processes without ever having to know the status of the sent message. This could be particularly useful if you use multiple systems that may not function at the same speed. The faster initiating system could start a process in a ‘fire and forget’ manner allowing the slower system to process at its own speed.
C:
Contracts
A contract is an agreement between two endpoints within a Service Broker conversation. It determines what type of messages can be sent and who can send them. To preserve its integrity, once a contract is defined its list of message typ0e cannot be changed.
Conversation
A conversation in the context of Service Broker is defined as a reliable, ordered and asynchronous transfer of messages between conversation endpoints. Conversations can be either dialog or monolog, however in 2005, monolog conversations were taken out, but will likely be included in a future release. Service Broker will continue trying to deliver a message irrespective of database or network failure hence reliability. In terms of ordering, Service Broker will ensure that messages sent on the same conversation will be delivered and processed in the order in which they were sent. This could be particularly important in multi-threaded environments or where payload size or complexity exists.
D:
Dialogs
A dialog conversation, or dialog, is a conversation between two services
The lifetime of a dialog lasts from the time that the local SQL Server instance creates the dialog until an application either explicitly ends the dialog or receives an error message associated with the dialog. Each participant is responsible for explicitly ending the conversation when the application receives a message that indicates an error or the end of the conversation. In most services, one participant is responsible for indicating that the conversation is complete and successful by ending the conversation without an error. Whether this is done by the target or the initiator depends on the purpose of the conversation.
E:
Endpoints
Endpoints are used to allow Service Broker to send and receive messages across a network. Out of the box an installed instance of SQL Server will not contain any Service Broker Endpoints for security reasons. In order to use Service Broker you must first create an endpoint.
G:
Groups (as in conversation groups)
Every conversation is associated with a conversation group. When a message is sent or received the conversation group is locked to stop any other messages can be sent on it until the transaction holding the lock completes. This ensures that even with many queue readers active a conversation can only be accessed by one queue reader at any one time.
M:
Messages
Messages are as you might expect, the payload or information that is being exchanged during a conversation. This information is divided into two parts, one being the message header and the other being the message itself.
The header contains information about he message such as the message type. This is a kind of descriptor for the message that is being relayed.
The message body is a VARBINARY(MAX) datatype which can contain up to 2GB or data. This data can be of any SQL datatype that can be cast to VARBINARY(MAX)
Q:
Queues
Queues are one of the ways that Service Broker manages the work being transmitted, by storing it in the database. In the same way as other queues manage data or objects it allows items to be stacked up in order by an initiating process which can then move on to another task. Many people have probably used some kind of process table in sql server to manage data, one process puts it on and another pulls it off. This is the same idea.
These queue tables are hidden system tables but there are system views that will allow you to read the data.
