SERVICE BROKER

SQL Server Service Broker SQL Server Service Broker provides the SQL Server Database Engine native support for messaging and queuing applications. This makes it easier for developers to create sophisticated applications that use the Database Engine components to communicate between disparate databases. Developers can use Service Broker to easily build distributed and reliable applications.

Initial Installation (Service Broker) Service Broker is included in each instance of the Database Engine. By default, Service Broker is enabled in each instance, and in each new database. To use Service Broker functionality, you deploy an application that is coded to use Service Broker messaging. If you do not have an existing application, you can design, code, and test a new application.

Advantages of Service Broker Service Broker's features provide a number of significant benefits to database applications. These features and benefits include: Database integration enhances application performance and simplifies administration. Message ordering and coordination for simplified application development

Advantages (contd.) Loose application coupling provides workload flexibility. Related message locking allows more than one instance of an application to process messages from the same queue without explicit synchronization. Automatic activation allows applications to scale with the message volume.

ACTIVATION : Startup Strategies The strategies for starting an application fall into four broad categories: Internal activation Event-based activation Scheduled task Startup task Each activation strategy has different advantages. An application can combine these strategies. For example, an application can use internal activation with a small number of queue readers most of the time. But, at certain times of the day, it can start more queue readers.

Internal Activation With Service Broker internal activation, a Service Broker queue monitor directly activates a stored procedure when it is necessary. This is often the most straightforward approach. By using direct activation of a stored procedure, you do not have to write additional code in the application to manage activation. However, internal activation requires that the application be written as a SQL Server stored procedure. When using internal activation, you write the application to exit when there are no more messages to process.

Event-Based Activation Some applications run in response to a specific event. For example, you can run an application when the CPU usage on the computer falls below a certain level. Or, you can run a logging application when a new table is created. Service Broker external activation is a special case of event-based activation. For external activation, the application starts in response to the QUEUE_ACTIVATION event. When using event-based activation, an application typically exits when there are no more messages to process.

Scheduled Task With a scheduled task, an application is activated on a set schedule. This strategy is convenient for batch-processing applications. An application that runs as a scheduled task can exit when there are no more messages to process, or the program can exit at a certain time. For example, an application that processes orders to a supplier can store messages during the day and then process the messages overnight to produce a single order to the supplier. In this case, the application can use a SQL Server Agent job to start the application at a specific time each night.

Startup Task Some applications start one time, typically when the computer starts or when SQL Server starts. Examples of these tasks are a startup stored procedure in SQL Server, an application in the Windows startup group, or a Windows service. In this case, the application remains running and processes messages as they arrive. An application that runs continuously does not require startup time when a message arrives on the queue. However, because the application does not exit when there are no messages, the program consumes resources even when there is no work for the program to do. This strategy can be useful for an application that processes a constant stream of messages and that is relatively resource- intensive during startup.

THANK YOU