Implementing Services for Message-Based Communication Chapter 11 In n-tier architecture, the clients and servers can be placed at distant locations. The server that implements business logic can provide services to various clients. In such a scenario, it is essential to ensure asynchronous communication. This allows the client applications to send requests even if the server is not available to process the requests immediately. SQL Server 2005 allows you to implement this by using service broker. Service Broker is a feature provided by SQL Server that provides a platform on which the services interact by sending and receiving messages. Services are self-contained components that provide a required functionality. This chapter provides an overview of message-based communication. Further, it explains how to implement services for a message-based communication. In this chapter, you will learn to:  Appreciate message-based communication  Implement Service Broker Objectives ¤NIIT Implementing Services for Message-Based Communication 11.3 Consider a scenario of credit card services. When a person makes a purchase through a credit card, the credit card details are validated and a purchase transaction is completed. In addition, an entry is made in the database of the bank that issued the credit card for an amount that the person had to pay for the transaction. At the end of a period, a consolidated bill is sent to the person to receive the credited amount. In this scenario, there is also a possibility of the client application not being able to connect to the database. Therefore, it is required to build a reliable system to ensure that all the requests sent to the server will be processed. SQL Server 2005 provides the developers with Service Broker. Service Broker is a message-based communication platform that helps in maintaining reliable query processing and asynchronous communication. Service Broker allows the database developers to create services that converse with each other by sending and receiving messages. A service is a database object that provides an endpoint for a conversation. A service sends a request message to another service to utilize the functionality provided. In the previous example of the credit card system, the client application sends a message to a service on the database server to enter the transaction details. This service places the message in a queue and commits the transaction of the client application. When multiple users send requests, all the messages are placed in the queue. The server processes these messages in the order in which they are received, as shown in the following figure. Asynchronous Processing of Messages Message-Based Communication Introduction to Service Broker 11.4 Implementing Services for Message-Based Communication ¤NIIT If due to some problem in the database server, the message could not be processed, the message is returned to its original position in the queue. Whenever the server is available, the message is again sent for processing. After successful processing, a reply is sent to the client. This helps in performing asynchronous transactions and reliable query processing. Service Broker is also useful for large-scale distributed applications that need to process data in multiple database servers located at different locations. For example, a Web application accepts data from a user through a Web form. The data needs to be saved on two different database servers. In addition, the application needs to update the data in another database server. Such an application can implement the Service Broker because it provides message queuing and reliable message delivery. The application can continue to accept information from the clients even if one of the servers is not available. Service Broker Architecture Service Broker is based on the Service Broker architecture. This architecture consists of the following database objects:  Message: Is the data exchanged between services.  Service: Is an addressable endpoint for the conversations. The Service Broker messages are sent from one service to another. The two types of services that take part in a conversation are initiator and processing services. The initiator services initiate the conversation and send a message to the processing service.  MessageTypes: Defines the content of the messages exchanged between the participants in a conversation. A message type object defines the name of the message type and the type of content the message can contain.  Contract: Is an agreement between the participant applications defining the messages that will be exchanged between them. The same contract must be created on each participant database that is involved in the conversation.  Queue: Is a container that stores messages. Each service is associated with a queue. When a message is sent for a service, Service Broker places the message in the queue. A queue is represented in the form of a table where each message is a row. Each row contains the message and its information, such as the message type, the initiator, and the target service.  Service program: Is a program that provides logic to the service. When a message is received for a service, Service Broker automatically initiates the service program and forwards the message to the program. ¤NIIT Implementing Services for Message-Based Communication 11.5 In the Service Broker architecture, various services converse with each other by sending and receiving messages. The following diagram explains the conversation process between two services. The Service Broker Conversation Process The Service Broker applications send and receive messages across services. A message is sent from one service to another for processing. When a service receives a message, it verifies that the message is of the same type as specified in the contract. After verification, the message is added to the queue. Every service has a service program attached to it. The service program receives the top-most message in the queue and processes it. After the processing is complete, a response or acknowledgement can also be sent back to the initiator service. Introduction to Service Broker Con v ersation Process 11.6 Implementing Services for Message-Based Communication ¤NIIT Just a minute: Which of the following objects processes a message from a queue? 1. Service 2. Service program 3. Contract Answer: 2. Service program ¤NIIT Implementing Services for Message-Based Communication 11.7 N ote When implementing Service Broker, you need to first create the Service Broker objects such as messages, queues, contracts, services. Next, you can begin a conversation. After the conversation has started, the objects can communicate with each other by sending and receiving messages. To create any of the Service Broker objects, you need to be a member of the ddladmin role on the specific database. In addition, you also need to enable Service Broker in the database by using the following statement: ALTER DATABASE <database name> ENABLE_BROKER where, <database name> is the name of the database for which the Service Broker needs to be enabled Only users with the sysadmin privileges can enable the Service Broker. A message is an entity that is exchanged between the Service Broker services. A message requires a name to participate in a conversation. A message can contain a validation over the datatype that a message possesses. As a part of the conversation, a message has a unique identifier as well as a unique sequence number to enforce message queuing. You can use the CREATE MESSAGE command to create a new message. The syntax of the CREATE MESSAGE command is: CREATE MESSAGE TYPE message_type_name [ VALIDATION = { NONE | EMPTY | WELL_FORMED_XML | VALID_XML WITH SCHEMA COLLECTION schema_collection_name } ] [ ; ] where, message_type_name is the name of the message type that you want to create. VALIDATION specifies how the message should be validated before sending. The default value is NONE. The validation clause can take any of the following values:  NONE: Specifies that no validation is performed.  EMPTY: Specifies that the message body must be NULL. Implementing Service Broker Creating Messages 11.8 Implementing Services for Message-Based Communication ¤NIIT  WELL_FORMED_XML: Specifies that the message must be a well-formed XML snippet.  VALID_XML WITH SCHEMA COLLECTION: Validates the XML snippet present in the message with an existing schema. For example, the following statement creates a message type named sendMessage: CREATE MESSAGE TYPE sendMessage VALIDATION = WELL_FORMED_XML The preceding statement creates a message type named sendMessage, which ensures that the message is a valid XML snippet. A queue is an object that stores the messages. In other words, a queue is the primary storage for messages transferred between two services. A queue can be viewed as a pipeline for messages. When the queue receives a message, it calls an associated stored procedure to process the message. This stored procedure is the service program that provides the required functionality. You can create a queue by using the CREATE QUEUE command. The syntax of the CREATE QUEUE command is: CREATE QUEUE [ database_name. [schema_name. ] ] queue_name [ 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 } ) ] ] where, queue_name is the name of the queue. STATUS (Queue) specifies the state of the queue. The state of the queue can be ON or OFF. ON signifies that the queue is available to receive messages. Alternatively, OFF specifies that the queue is not available and no message can be added or removed from the queue. RETENTION specifies that the messages sent or received within a particular conversation will be retained in the queue or not. The default value if OFF. ACTIVATION specifies information about the stored procedure to process messages in this queue. Creating Queues ¤NIIT Implementing Services for Message-Based Communication 11.9 STATUS (Activation) specifies that when the queue receives a message, it should execute a stored procedure or not. The default value is ON. EXECUTE AS specifies the SQL Server database user account under which the activation stored procedure runs. SELF specifies that the stored procedure executes as the current user. 'user_name' is the name of the user with whose credentials the stored procedure will be executed. OWNER specifies that the stored procedure executes as the owner of the queue. For example, the following statement creates a queue named sendQueue: CREATE QUEUE sendQueue WITH STATUS = ON The preceding statement creates a queue named sendQueue that has sendProc as a service program attached to it. A contract is an agreement between two services that need to communicate with each other. It also specifies the type of message that will be used in a conversation between the two services. You can create a message by using the CREATE CONTRACT command. The syntax of the CREATE CONTRACT command is: CREATE CONTRACT contract_name [ AUTHORIZATION owner_name ] ( { { message_type_name | [ DEFAULT ] } SENT BY { INITIATOR | TARGET | ANY } } [ , n] ) [ ; ] where, contract_name is the name of the contract to be created. AUTHORIZATION owner_name sets the owner of the contract to the specified database user or role. message_type_name is the name of the message type to be included in the contract. SENT BY specifies that what type of message will be sent by which endpoint. It may take the following values:  INITIATOR indicates that only the endpoint that started the conversation will be able to send this type of message. Creating Contracts 11.10 Implementing Services for Message-Based Communication ¤NIIT  TARGET indicates that only the endpoint that is the target of the conversation will be able to send this type of message.  ANY indicates that messages of this type can be sent by both the initiator and the target. For example, the following statement creates a contract named sendContract: CREATE CONTRACT sendContract ( sendMessage SENT BY INITIATOR ); In the preceding statement, a new contract with the name sendContract is created. The contract uses the sendMessage message type for communication. A service is used by Service Broker to deliver messages to the correct queue within a database or to route messages to another database. In addition, it is also used to enforce the contract for a conversation. You can create a service by using the CREATE SERVICE command. The syntax of the CREATE SERVICE command is: CREATE SERVICE service_name [ AUTHORIZATION owner_name ] ON QUEUE [ schema_name. ]queue_name [ ( contract_name | [DEFAULT] [ , n ] ) ] [ ; ] where, service_name is the name of the service to be created. You can not use the name of a Server, Database, or a Schema as the name of a service. 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 in which all the messages sent to this service will be stored. contract_name specifies a contract for which this service may be a target. For example, the following statements create a service named sendService: CREATE SERVICE sendService Creating Services [...]... 11.18 Implementing Services for Message-Based Communication NIIT Practice Questions 1 What is a Service Broker? 2 In the Service Broker architecture, what is a message? 3 What is the use of a queue in a Service Broker? 4 How can you create a queue? 5 How can you send a message? 6 What is asynchronous communication? 7 What is reliable query processing? NIIT Implementing Services for Message-Based Communication. .. to the VList table of the Vendor database How will you solve this problem? Note For this exercise, the Vendor database will be provided to you The vendor list is present in the VList table of the Vendor database NIIT Implementing Services for Message-Based Communication 11.21 11.22 Implementing Services for Message-Based Communication NIIT ... the sent message message_body_expression is the message that is required to be sent For example, the following statements send a message named sendMessage: SEND ON CONVERSATION @dialog_handle MESSAGE TYPE [sendMessage] ('John') 11.12 Implementing Services for Message-Based Communication NIIT Activity: Implementing Service Broker Problem Statement The management of AdventureWorks, Inc wants... Management Studio window: USE SalesDB GO CREATE PROCEDURE [dbo].[OnReceiveMessage] NIIT Implementing Services for Message-Based Communication 11.13 AS DECLARE @message_type int DECLARE @dialog uniqueidentifier, @ErrorSave int, @ErrorDesc nvarchar(100), @message_body int; WHILE (1 = 1) BEGIN BEGIN TRANSACTION WAITFOR ( RECEIVE TOP(1) @message_type=message_type_id, @message_body=message_body, @dialog... key to execute the statements 11.14 Implementing Services for Message-Based Communication NIIT Task 2: Creating the Message Type, Contract, Queue, and Service Objects After the service program has been created, you need to create the message type, contract, queue, and service objects in the AdventureWorks and SalesDB databases To create these objects, you need to perform the following steps: 1 Type the... TYPE AcknowledgeMessage VALIDATION = NONE CREATE CONTRACT MyContract (SendMessage SENT BY INITIATOR, AcknowledgeMessage SENT BY INITIATOR) CREATE QUEUE SalesQueue WITH STATUS=ON, NIIT Implementing Services for Message-Based Communication 11.15 ACTIVATION ( PROCEDURE_NAME = OnReceiveMessage, MAX_QUEUE_READERS = 5, Execute AS SELF) ; CREATE SERVICE RecieveService ON QUEUE SalesQueue (MyContract) 4 Press... UPDATE Sales.SalesOrderHeader SET ShipDate = getdate() WHERE SalesOrderID = 43692 Verify that the respective amount is added to the SalesDetails table of the SalesDB database 11.16 Implementing Services for Message-Based Communication NIIT To verify the reliable query processing feature of the Service Broker, detach the SalesDB database from the SQL Server by executing the following statement: EXEC... After you have attached the SalesDB database, you need to enable Service Broker in the SalesDB database by using the following statement: ALTER DATABASE SalesDB SET ENABLE_BROKER NIIT Implementing Services for Message-Based Communication 11.17 Next, you need to verify that the SalesDetails table of the SalesDB database has been updated with the amount sent in the message The table is now updated If you... CONTRACT [sendContract]; Sending and Receiving Messages After you have created all the required broker objects and begin the conversation, you are ready to send and receive messages NIIT Implementing Services for Message-Based Communication 11.11 To send a message, you need to use the Send command The syntax of the Send command is: SEND ON CONVERSATION conversation_handle [ MESSAGE TYPE message_type_name... be created by using the CREATE SERVICE command A conversation can be started by using the BEGIN DIALOG command Messages can be sent by using the SEND ON CONVERSATION command 11.20 Implementing Services for Message-Based Communication NIIT Exercises Exercise 1 In the AdventureWorks database, the details of the vendors are stored in the Vendors table In addition, the names of the vendors are saved in . be NULL. Implementing Service Broker Creating Messages 11.8 Implementing Services for Message-Based Communication ¤NIIT  WELL_FORMED_XML: Specifies that the message must be a well-formed XML. figure. Asynchronous Processing of Messages Message-Based Communication Introduction to Service Broker 11.4 Implementing Services for Message-Based Communication ¤NIIT If due to some problem. message is received for a service, Service Broker automatically initiates the service program and forwards the message to the program. ¤NIIT Implementing Services for Message-Based Communication