Table of Contents

1. Abstract______________________________________________2
2. Service Broker: What is it?____________________________3
3. Service Broker: What are the components of it?_______4
4. Service Broker: How it works?________________________8
5. Service Broker: What are the Advantages?____________9
6. Service Broker: Where it can be used?_______________10
7. Service Broker: A Case Study?_______________________11
6 Conclusion______________________________________________12
7 References______________________________________________12
8 Annexure_______________________________________________12
1. Abstract

Objectives are covered with answers to the following questions –

Objective
Service Broker -
 What is it?
 What are the components of it?
 How it works?
 What are the Advantages?
 Where it can be used?
 A case study

SQL Service Broker (SSB) is a powerful feature by Microsoft introduced in

SQL Server 2005. It provides a means of “conversation” between
Abstract
databases of same or different instances through the basic functions of
sending and receiving messages. The conversation allows you to write
asynchronous, distributed, decoupled, scalable and secure – messaging
and queuing applications within the database itself.
With Service Broker framework, a database developer can develop range
of asynchronous applications within an instance – like simple workload
queuing or between different instances - like complex cross-server logging
or auditing.
2. Service Broker: What is it?

Service Broker is nothing but a mechanism to deliver messages end to end. It is an integrated part
of the database engine and provides reliable direct Asynchronous messaging across instance or
instances. Being a part of the database engine, it inherits database qualities like Reliability,
Security and Transactional consistency.

Asynchronous Messaging –
Since I have mentioned “Asynchronous” – powerful quality, it is important to understand what it
means.
In the service broker conversation, two parties are involved – Initiator and Target. Initiator sends
messages while Target picks those messages to process. These two interacting parties are working
independently to perform their task. So, in Asynchronous messaging, Initiator and Target can
overlap their computation because they do not wait for each other. Thus, the Asynchronous
messaging system encourages developers to develop loosely coupled components that work
independently.
While in Synchronous messaging, the interacting parties will each other until the message is
received and processed.
3. Service Broker: What are the components of it?

This section will be explained with the help of an example database – ServiceBrokerDemo.

In order to allow Service Broker to send and receive messages, we need to configure following
things –
a. Switch-on the Service Broker on the database –
Each database is having a feature of Service Broker. Before creating other Service Broker
components, it should be enabled. Following code shows – Creating a database and
enabling Service Broker. You can verify if it is enabled or not by querying sys.databases
catalog view.

-- Create Database
CREATE DATABASE ServiceBrokerDemo
GO

-- Alter database to enable Service Broker

USE ServiceBrokerDemo
GO

ALTER DATABASE ServiceBrokerDemo

SET ENABLE_BROKER
GO

-- Verify if Service Broker is enables or not. Column value 1 means it is enabled.

SELECT is_broker_enabled, *
FROM sys.databases
WHERE name = 'ServiceBrokerDemo'

b. Message Type –
This object defines the type of messages that will be sending between interacting parties –
Initiator and Target. Message Type performs the validation on the type of content of the
message before sending. The Initiator and Target parties have to use same Message Type
for successful communication. For our example, we will create two Message Types –
Request and Response in the database – ServiceBrokerDemo.

-- Request Message from Initiator

USE ServiceBrokerDemo
CREATE MESSAGE TYPE [//SBDemo/RequestMessage]
VALIDATION = WELL_FORMED_XML;

-- Response Message from Target

USE ServiceBrokerDemo
CREATE MESSAGE TYPE [//SBDemo/ResponseMessage]
VALIDATION = WELL_FORMED_XML;

-- Verify if Message Type is created or not

USE ServiceBrokerDemo
SELECT *
FROM sys.service_message_types
WHERE name IN ('//SBDemo/RequestMessage', '//SBDemo/ResponseMessage')

Syntax:
CREATE MESSAGE TYPE message_type_name
[ AUTHORIZATION owner_name ]
[ VALIDATION = { NONE
| EMPTY
| WELL_FORMED_XML
| VALID_XML WITH SCHEMA COLLECTION schema_collection_name
} ]
[ ; ]
VALIDATION
Specifies how Service Broker validates the message body for messages of this type. When this clause is not
specified, validation defaults to NONE.

NONE
Specifies that no validation is performed. The message body can contain data, or it can be NULL.

EMPTY
Specifies that the message body must be NULL.

WELL_FORMED_XML
Specifies that the message body must contain well-formed XML.

VALID_XML WITH SCHEMA COLLECTION schema_collection_name

Specifies that the message body must contain XML that complies with a schema in the specified schema
collection The schema_collection_name must be the name of an existing XML schema collection.

c. Contract –
Service Broker will need a contract which will define Message Type that Service Broker is
going to use the conversation, which party can send message of that Message Type. Each
conversation follows a contract. Following code will create a contract for our example.
-- Create Contract for the conversation
USE ServiceBrokerDemo
CREATE CONTRACT [//SBDemo/SBContract]
(
[//SBDemo/RequestMessage] SENT BY INITIATOR,
[//SBDemo/ResponseMessage] SENT BY TARGET
);

-- Verify if Contract is created or not

SELECT *
FROM sys.service_contracts
WHERE name = '//SBDemo/SBContract'

Syntax:
CREATE CONTRACT contract_name
[ AUTHORIZATION owner_name ]
( { { message_type_name | [ DEFAULT ] }
SENT BY { INITIATOR | TARGET | ANY }
} [ ,...n] )
[ ; ]

AUTHORIZATION owner_name
Sets the owner of the contract to the specified database user or role. When this clause is omitted, the contract
belongs to the current user.

message_type_name
Is the name of a message type to be included as part of the contract.

SENT BY
Specifies which endpoint can send a message of the indicated message type.

INITIATOR
Indicates that only the initiator of the conversation can send messages of the specified message type. A
service that starts a conversation is referred to as the initiator of the conversation.

TARGET
Indicates that only the target of the conversation can send messages of the specified message type. A service
that accepts a conversation that was started by another service is referred to as the targetof the conversation.

ANY
Indicates that messages of this type can be sent by both the initiator and the target.
 d. Queue –
Service Broker Queue is nothing but a Message Storage container. When an Initiator sends
a message, it is put into the Initiator Queue. The message then moved to the Target
Queue from where Target can pull the message whenever it feels like. The message from
the Initiator Queue will be deleted only when it is successfully received in the Target
Queue. Thus, Transactional Consistency is implemented in Service Broker which ensures
not message is lost in transit. SQL Server provides a way to view the messages in Queue
through a Read-Only view. Following code will create queue for our example.

-- Create Queue
USE ServiceBrokerDemo
CREATE QUEUE SBDemoInitiatorQueue;
CREATE QUEUE SBDemoTargetQueue;

-- Verify of Queue is created or not

SELECT *
FROM sys.service_queues
WHERE name IN ('SBDemoInitiatorQueue','SBDemoTargetQueue')

Syntax:

CREATE QUEUE <object>

[ WITH
[ STATUS = { ON | OFF } [ , ] ]
[ RETENTION = { ON | OFF } [ , ] ]
[ ACTIVATION (
[ STATUS = { ON | OFF } , ]
PROCEDURE_NAME = <procedure> ,
MAX_QUEUE_READERS = max_readers ,
EXECUTE AS { SELF | 'user_name' | OWNER }
) [ , ] ]
[ POISON_MESSAGE_HANDLING (
[ STATUS = { ON | OFF } ] ) ]
]
[ ON { filegroup | [ DEFAULT ] } ]
[ ; ]

queue_name
Is the name of the queue to create.

RETENTION
Specifies the retention setting for the queue. If RETENTION = ON, all messages sent or received on
conversations that use this queue are retained in the queue until the conversations have ended. Default is OFF.

ACTIVATION
Specifies information about which stored procedure you have to start to process messages in this queue.

STATUS (Activation)
Specifies whether Service Broker starts the stored procedure. When STATUS = ON, the queue starts the stored
procedure specified with PROCEDURE_NAME when the number of procedures currently running is less than
MAX_QUEUE_READERS and when messages arrive on the queue faster than the stored procedures receive
messages. When STATUS = OFF, the queue does not start the stored procedure. Default is ON.

PROCEDURE_NAME = <procedure>
Specifies the name of the stored procedure to start to process messages in this queue.

MAX_QUEUE_READERS =max_readers
Specifies the maximum number of instances of the activation stored procedure that the queue starts at the
same time.

POISON_MESSAGE_HANDLING
Specifies whether poison message handling is enabled for the queue. The default is ON.
A queue that has poison message handling set to OFF will not be disabled after five consecutive transaction
rollbacks. This allows for a custom poison message handing system to be defined by the application.

e. Service –
Service Broker Service is a named object that delivers messages to the correct queue
within a database and enforces a contract for a conversation. Following code creates a
Service for our example –
-- Create Request Service on Initiator Queue
USE ServiceBrokerDemo
CREATE SERVICE [//SBDemo/SBRequestService]
ON QUEUE SBDemoInitiatorQueue ([//SBDemo/SBContract]);

-- Create Response Service on Target Queue

USE ServiceBrokerDemo
CREATE SERVICE [//SBDemo/SBResponseService]
ON QUEUE SBDemoTargetQueue ([//SBDemo/SBContract]);

-- Verify if Service is created or not

SELECT *
FROM sys.services
WHERE name IN ('//SBDemo/SBRequestService','//SBDemo/SBResponseService')

Syntax:

CREATE SERVICE service_name

[ AUTHORIZATION owner_name ]
ON QUEUE [ schema_name. ]queue_name
[ ( contract_name | [DEFAULT][ ,...n ] ) ]
[ ; ]

AUTHORIZATION owner_name
Sets the owner of the service to the specified database user or role.

ON QUEUE [ schema_name. ] queue_name
Specifies the queue that receives messages for the service. The queue must exist in the same database as the
service.

contract_name
Specifies a contract for which this service may be a target. Service programs initiate conversations to this
service using the contracts specified. If no contracts are specified, the service may only initiate conversations.

These components make the framework for Service Broker to start a conversation – Sending and
Receiving messages.
4. Service Broker: How it works?

By now, we have our basic framework ready to start conversation between the parties – Initiator
and Target. When a conversation is started, messages in a particular format are sent as Message
Type to Initiator queue, and then sent to Target queue. These messages are received at Receiver
queue and processed. Once the processing finished, conversation is ended.

Conversation is started by means of a Dialog. A Dialog defines the Sending and Receiving of
messages between two services, specifies a contract used to enforce what messages can be sent
between services.

Typical conversation can be completed in following steps -

a. Establish the communication channel – BEGIN DIALOG statement establishes the
communication channel between services.
DECLARE @SBDemoDialog uniqueidentifier

BEGIN DIALOG CONVERSATION @SBDemoDialog

FROM SERVICE [//SBDemo/SBRequestService]
TO SERVICE '//SBDemo/SBResponseService'
ON CONTRACT [//SBDemo/SBContract]
WITH ENCRYPTION = OFF

b. Send Messages – Once conversation dialog is established, Messages are sent on the
conversation between participating services using SEND statement.

SEND ON CONVERSATION @SBDemoReqDialog (@Message) ;

Here, the message will be sent to ‘//SBDemo/SBResponseService’ and placed in

dbo.SBDemoTargetQueue. One can verify this queue with SELECT query like

SELECT * FROM dbo.SBDemoTargetQueue

c. Processing Messages – As soon as the messages are sent to queue, it will be processed by
associated activation procedure, if available. If procedure is not coded, messages will
remain in the Queue until it is read by RECEIVE command. Once messages is RECEIVEd, it
will be removed from the queue so that it won’t be picked up more than once. Here,
messages is received in variable @ResMessage which if of xml type.

DECLARE @SBDemoResDialog uniqueidentifier

DECLARE @ResMessageName sysname
DECLARE @ResMessage xml;

RECEIVE TOP (1)

@SBDemoResDialog = conversation_handle,
@ResMessageName = message_type_name,
@ResMessage = CAST(message_body AS XML)
FROM dbo.SBDemoTargetQueue;

d. Close communication channel – Once you processes all messages in the Queue, you should
close the conversation by END CONVERSATION statement.

END CONVERSATION @SBDemoResDialog

5. Service Broker: What are the Advantages?

Service broker provides many advantages like –

1. Because of the Asynchronous communication nature of Service Broker, it allows to
decouple dependencies on other applications by communicating through messages.

2. Because of the control over How and When messages to be processed, one can plan to
schedule messages processing overnight when server is at a lower load.

3. Because of the support to SEND and RECEIVE messages not only in the same database but
also different databases on different servers, it provides better Scalability of architecture.

4. Because Service Broker is part of the Database Engine itself, its Maintenance is one of
the routine DBA procedures.

5. Because Service Broker queue can be read by multiple readers simultaneously based on
the type of messages, Parallel Processing is achieved.
6. Service Broker: Where it can be used?

a. Service Broker’s Asynchronous triggering would be valuable for Online Transaction

Processing (OLTP) systems like Order processing with Inventory update. In such systems,
trigger setup a message which contains actual work to do and pushes it to the queue.
Service broker service performs the actual work. Once the actual work is committed,
service brokers sends message to the destination service to complete the transaction.

b. An application where Reliable query processing is important, service broker is good option.
As an example, Funds Transfer application should reliably complete or rollback transaction
in case of computer failure, power outage or similar problems. In such applications, Fund
Transfer transaction related work sent as messages to the service broker service where it
is read, runs query and returns results. If failure occurs before transaction commit, roll
back will happen and message is returned to queue. When the computer recovers, the
application restarts and processes the messages again which makes reliable query
processing.

c. Service broker’s support for distributed applications will be helpful in large applications
where multiple databases on different server exchanges messages with central application
server where service broker resides. Though one of the remote servers has downtime, the
service broker continues to accept and process messages from other remote databases.

d. Service broker’s ability of queueing and parallel processing offers quick and efficient
handling of large volume of work in batch processing. Applications collecting the data in
daytime and storing in the service broker queue. A nightly batch program reads the queue
and processes to perform tasks like Letter processing, report generations etc.

e. Service broker’s parallel processing on multiple databases can be advantageous to the

applications where displaying information at one place is a primary function. Applications
such as showing all information on a dashboard page can be achieved efficiently with
service broker. In such cases, multiple requests are sent in parallel through different
services, as the services responds to requests, responses are collected and displayed at
one place.
7. Service Broker: A Case Study?
6 Conclusion
The paper concluded with followings:

7 References

8 Annexure