Service Broker

Service Broker

Rating:

Service Broker is a new technology in SQL Server 2005 and provides a solution to message delivery issues that occur while transferring transactional data from one server to another. This technology provides a message-based communication platform and is part of the Database Engine. Database developers develop secure, reliable, and scalable applications with the help of Service Broker. Service Broker is used for the applications that use a single instance of SQL Server 2005 as well as for those that use multiple instances of SQL Server 2005 across the network. It provides reliable messaging between multiple instances of SQL Server 2005. It uses TCP/IP protocol to exchange messages between instances of SQL Server 2005, prevents unauthorized users from accessing the network, and encrypts messages that are sent over the network. It provides a robust asynchronous programming model. Asynchronous programming is the most popular technique in database application programming. In asynchronous programming, the Database Engine handles commands while the application continues to run. Asynchronous programming minimizes response time and enhances application throughput of database applications.

Service Broker consists of various components that make up the entire architecture. It can be divided into three broad components. They are as follows:

• Conversation components


• Service definition objects


• Remoting and security components

Conversation Components

All the applications using Service Broker communicate through conversations that involve messages, dialog conversations, and conversation groups.

Message: A message is textual information exchanged between applications that use Service Broker. A message is part of a conversation. A message has a unique conversation identity and a sequence number within the conversation. When Service Broker receives messages, it enforces the order of messages by using the conversation identity and the sequence number of each message.

Dialog Conversation: All messages are part of a conversation. A dialog conversation, or dialog, is an agreement between two services. Dialogs use the conversation identity and the sequence number of the messages to identify them and deliver them in the correct order. A dialog conversation has two participants: The Initiator and the Target. The initiator begins the conversation, and the target accepts a conversation started by the initiator.

Conversation Group: A conversation group is a group of related conversations. Each conversation belongs to one conversation group. Each conversation group is associated with a specific service.

Service definition objects

Service definition objects are database objects that specify the basic design of an application that uses Service Broker. These database objects are message types, contracts, queues, and services. A Service Broker application uses these objects to hold conversation.

Message Types: Applications using Service Broker communicate with each other through conversations. The participants in a conversation agree with the name and contents of the message. A message type object is a name and the type of data for a message type. Service Broker offers a DEFAULT built-in message type. If an administrator does not specify a message type in a Service Broker SEND command, Service Broker will use the DEFAULT message type.

Contracts: An application uses message types to accomplish a particular task through a contract. A contract is an agreement between two services. The contract specifies which message types will be used to process a message. Service Broker offers a DEFAULT built-in contract. If an administrator does not specify a contract in the BEGIN DIALOG statement, Service Broker will use the DEFAULT contract.

Queues: Queues, such as containers, store messages. When Service Broker receives a message for a service, it inserts the message into the queue for that service. Service Broker manages queues and presents a view of a queue like a table. Each service is associated with one queue. When a message comes for a service, Service Broker places the message in the queue associated with that service. Each message in the queue is arranged in a row. A row contains the contents of a message and information about the message type, the service that the message is aimed at, the contract that the message follows, the conversation that the message is a part of, and other internal information related to the queue.

Services: Services reference the contract. Service Broker uses the name of a service to route and deliver messages to the correct queue and enforce the contract for a conversation. Each service specifies a queue to hold messages.

Remoting and Security components

Service Broker enables secure and reliable communication between multiple instances of SQL Server 2005, allows you to manage routing, and establishes security for the conversation.

After taking a brief look at the Service Broker architecture, you will learn how to design this architecture. To design this architecture, you will take the following steps:

1. Create message types that will be sent by the initiator and returned by the target.
2. Create queues where messages will be submitted.
3. Create a contract that will establish an agreement between services.
4. Create services that will reference the contract.

Now you can start creating a message type. The message type is created using the CREATE MESSAGE TYPE statement.

The syntax for creating a message type is as follows:

CREATE MESSAGE TYPE message_type_name
[ AUTHORIZATION owner_name ]
[ VALIDATION = { NONE
| EMPTY
| WELL_FORMED_XML
| VALID_XML WITH SCHEMA COLLECTION schema_collection_name
} ]
[ ; ]

Here is an example. In this example, you create the message types in the typed XML format for the initiator and the target.

CREATE MESSAGE TYPE CricketRequest
AUTHORIZATION dbo
VALIDATION = WELL_FORMED_XML

CREATE MESSAGE TYPE CricketStatus
AUTHORIZATION dbo
VALIDATION = WELL_FORMED_XML

After creating the message types, you will create the queue where the message types will be submitted. The queue is created using the CREATE QUEUE statement.

The syntax for creating a queue is as follows:

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 }
) ]
]
[ ON { filegroup | [ DEFAULT ] } ]
[ ; ]

<object> ::=
{
[ database_name. [ schema_name ] . | schema_name. ]
queue_name
}

<procedure> ::=
{
[ database_name. [ schema_name ] . | schema_name. ]
stored_procedure_name
}

In the example given below, you create the sender queue and the receiver queue to send and receive messages with no parameters.

CREATE QUEUE CricketSender
CREATE QUEUE CricketReceiver

After creating the queues, you will create the contract that will establish an agreement between services.
The contract is created using the CREATE CONTRACT statement.

The syntax for creating a contract is as follows:

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

[ ; ]

In the following example, you submit a cricket request from the initiator using the CricketRequest message and receive a cricket status from the target through the CricketStatus message.

CREATE CONTRACT CricketContract
(CricketRequest SENT BY INITIATOR, CricketStatus SENT BY TARGET)

After creating the contract, you will create the service that will reference the contract. The service is created using the CREATE SERVICE statement.

The syntax for creating a service is as follows:

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

[ ; ]

In the example given below, you create the services for the sender and the receiver.

CREATE SERVICE CricketSenderService ON QUEUE CricketSender (CricketContract)
CREATE SERVICE CricketReceiverService ON QUEUE CricketReceiver (CricketContract)

Rating: