User who	Initiator permissions	Target permissions
Begins the conversation	RECEIVE permission on the queue
Owns the initiating service		SEND permission on the service
Sends a message		SEND permission on the service
Specified for remote authorization	CONNECT permission on the database SEND permission for the service	SEND permission on the service
Service account for the remote database (when using Windows authentication)	CONNECT permission in master Valid login

Sending and receiving messages

You send and receive messages within the context of a dialog. A dialog ensures that each message is delivered to the recipient exactly once in the order in which it was sent (EOIO).

Creating conversations

The first step in initiating communication with a service is to begin a conversation. The BEGIN DIALOG [CONVERSATION] statement has the syntax:

You use the @dialog_handle when you send a message. You must declare it as a uniqueidentifier before calling BEGIN DIALOG. You must specify the FROM SERVICE (initiator) and the TO SERVICE (target). If multiple instances of the target service exists, you should specify the service_broker_guid if connecting to a specific instance. If you don’t specify a contract, the DEFAULT contract is used.

The RELATED_CONVERSATION and RELATED_CONVERSATION_GROUP keywords are optional. You use them to identify an existing group for the dialog. Conversation groups can ensure that all messages related to a business task are handled by the same session.

You use the LIFETIME keyword to set an expiration time on the conversation. If you don’t specify LIFETIME, the conversation lasts until both participants end it. A conversation isn’t considered successful if it times out.

You use the ENCRYPTION keyword to specify whether or not communication with a service in a different instance is secured. The default is ON. If you set ENCRYPTION off and a remote service binding exists, the conversation is still secured.

Sending messages

You can send a message using the SEND statement. The statement’s syntax is:

The conversation_handle is the same conversation handle referenced in the BEGIN DIALOG statement. The MESSAGE TYPE must be a valid message type in the contract identified in BEGIN DIALOG. The message_body_expression is the content of the message. For example, if the message is XML, you provide a string containing the XML.

Receiving messages

You use the RECEIVE statement to read messages from the queue. Its syntax is:

You use WAIT FOR if the stored procedure should stay activated and wait for messages to be placed in the queue. You use TIMEOUT to specify the length of time to wait for a message in milliseconds. You can receive:

• All messages in the queue

• The first message in the queue

• Only messages from a specific conversation

• Only messages from a specific conversation group

You can limit the columns you read. A full list of columns is described in the RECEIVE statement documentation in SQL Server Books Online. The column you most likely want is the message_body column. The message_body column is of type varbinary(max). You must cast it as the appropriate data type before you can use it. You can determine whether to cast it as XML or a different type by checking the validation column. You might also retrieve the message_type_name if the queue can be the target for more than one message type.

You use the INTO statement to store the results in a temporary table variable. For example, the following stored procedure retrieves a message from the queue and stores the message_type_name, validation, and message_body in a table named QueueLog.

Ending the conversation

When the each service is finished sending and receiving messages for a conversation, the service must call END CONVERSATION. The syntax is:

When one side of the conversation calls END CONVERATION without passing an error code, Service Broker sends an EndDialog message to the other service as the last message for the conversation.

When a service calls END CONVERSATION with an error, Service Broker drops all pending messages for the conversation and sends an Error message to the other service.

You can use the WITH CLEANUP option to remove messages and conversation handles that cannot be deleted normally. No notification is sent to the remote service.

Managing Service Broker

You might encounter times when you must modify a Service Broker configuration. As with most SQL Server objects, you can modify a Service Broker object by executing an ALTER statement. For example, to disable the Service Broker endpoint, you execute:

To temporarily stop an endpoint, for example when you are performing maintenance and don’t want users to connect, you execute:

You can use the ALTER QUEUE statement to prevent a specific queue from receiving messages or to change a queue’s configuration. The ALTER QUEUE statement has the syntax:

The parameters are similar to those supported by CREATE QUEUE. The key difference is the DROP keyword, which you use to remove activation information.

You use the ALTER SERVICE to:

• Move messages from one queue to another queue.

• Add a contract.

• Drop a contract.

You use the ALTER MESSAGE TYPE statement to change the validation for a message type. For example, you might need to modify a WELL_FORMED_XML type to use a schema collection for validation.

Note that there is no ALTER CONTRACT statement. A contract is an agreement between services and you can’t alter it after it is defined.

You can drop Service Broker components using the following statements:

• DROP CONTRACT

• DROP MESSAGE TYPE

• DROP ENDPOINT

• DROP QUEUE

• DROP SERVICE

For complete syntax and description of the ALTER and DROP commands relating to Service Broker, refer to SQL Server Books Online documentation for each command.

Monitoring and troubleshooting queues

If you need to determine whether messages are reaching a service’s queue, you can issue a SELECT query on the queue. For example, to view the messages in the inventoryQ, you execute:

You can view the messages in the sys.transmission_queue to determine whether there are undeliverable messages there. The transmission_status column contains information about why the message hasn’t been delivered.

You can use the following dynamic management views to troubleshoot Service Broker application problems:

• sys.dm_broker_activated_tasks — View the stored procedures activated by Service Broker and the security context they are running under.

• sys.dm_broker_forwarded_messages — View the messages that are being forwarded.

• sys.dm_broker_connections — View information about the state of Service Broker network connections.

• sys.dm_broker_queue_monitors — View the queue monitors, which activate the stored procedure associated with a queue.