In: Categories » Computers and technology » Databases » SQL Server Service Broker Architecture
| The SQL Server Service Broker is a new subsystem that provides a framework for building asynchronous applications using SQL Server 2005. The ability to support asynchronous queuing expands the scalability of SQL Server 2005 applications. Asynchronous queuing is an important factor for scalability because it allows an application to respond to more requests than the platform may be able to physically handle. Asynchronous queuing is found in many other highly scalable applications, such as the operating system’s I/O subsystems, Web servers, and even the internal operations of the SQL Server database engine itself. For instance, in the case of a Web server, if ten thousand users simultaneously requested resources from the server, without asynchronous queuing the Web server would be overwhelmed as it attempted to synchronously handle all of the incoming requests one at a time. Asynchronous queuing enables all of the requests to be captured in a queue. Then instead of being overwhelmed, the Web server can process entries from the queue at its maximum levels of efficiency. The addition of the SQL Server Service Broker to SQL Server 2005 enables you to build this same type of scalability into your database applications. SQL Server Service Broker ArchitectureIt’s important to keep in mind that the SQL Server Service Broker is an application framework. Its goal is to take on the hard work of building asynchronous applications, and it does that by handling all of the heavy lifting for the asynchronous application. SQL Server Service Broker takes care of all of the hard-to-code details like guaranteed-in-order message routing and delivery. In other words, SQL Server Service Broker provides the plumbing for an asynchronous application but doesn’t provide the application itself. It is still up to you to build the application that uses the framework supplied by the SQL Server Service broker subsystem. Microsoft has made use of the SQL Server Service Broker subsystem to enable functionality in several other areas of SQL Server 2005, including Notification Services, Reporting Services, and asynchronous query notifications. The SQL Server Service Broker is completely integrated with the SQL Server 2005 engine and is fully transactional. Transactions can incorporate queued events and can be both committed and rolled back. In addition, the new SQL Server Service Broker also supports reliable delivery of messages to remote queues. This means that information sent via SQL Server Service Broker can span multiple SQL Server systems and still provide guaranteed in-order, one-time-only message delivery— even to remote queues that must be reached across multiple routing steps. The SQL Server Service Broker will take care of the mechanics required to break the large messages into smaller chunks that are sent across the network and then reassemble them at the other end. Messages Messages are the core bits of information that are sent by a SQL Server Service Broker application. These messages can be text messages or consist of binary data or XML. For XML messages, SQL Server can validate that the messages are well formed and that they comply with a predefined schema. You create a SQL Server Service Broker message by running the CREATE MESSAGE TYPE command, which is where you specify the type of content that the message will have. The messages that are sent across the queues can be very large—up to 2GB. Queues SQL Server Service Broker queues contain a collection of related messages. Each queue is associated with a service. When a SQL Server Service Broker application sends a message, that message must first be placed in a queue. Likewise, when that message is received by the target system, it is received into a queue. Messages are validated when they are received by the target queue. If a message is not valid, then the service returns an error to the sender. Then the application can read the queue and process the message. You create a SQL Server Service Broker queue by running the CREATE QUEUE command. Contracts Contracts essentially define which messages can be used by a given queue. In order to be processed, a contract must first be created between a SQL Server Service Broker message and a queue or, more specifically, the queue’s service. The contract provides information to the service about the type of messages it will process. The contract also prevents errant messages from being sent to and used by an unintended target application. You create a SQL Server Service Broker message by running the CREATE CONTRACT command. Services A SQL Server Service Broker service is a specific Service Broker task or set of tasks. Each queue has an associated service. Conversations occur between services. The contracts associated with the service define the specific messages that will be processed by the service. Dialogs Dialogs are an essential component of Microsoft’s new SQL Server Service Broker. Essentially, dialogs provide two-way messaging between two SQL Server Service Broker services. Dialogs can be used for interserver communications for services running on different servers or instances, or they can be used for intraserver communications linking two applications running on the same server. The main purpose of a SQL Server Service Broker dialog is to provide an ordered message delivery. In other words, dialogs enable queued messages to always be read in the same order that they are put into the queue. SQL Server Service Broker dialogs maintain reliable event ordering across servers even if network, application, or other failures temporarily disrupt the communications between dialog endpoints. When the communications are restored, the events will continue to be processed in order from the point of the last processed queued entry. Dialogs can be set up to process messages in either full-duplex mode or half-duplex mode. Message TransportThe SQL Server Service Broker message transport protocol enables messages to be sent across the network. It is based on TCP/IP, and the overall architecture of the SQL Server Service Broker message transport is a bit like the architecture used by TCP/IP and FTP. By default the SQL Service Broker uses TCP/IP port 4022. The SQL Server Service Broker message transport is composed of two protocols: the Adjacent Broker Protocol, which is a lower-level protocol like TCP, and the Dialog Protocol, which is a higher-level protocol like FTP that rides on top of the lowerlevel Adjacent Broker Protocol. Adjacent Broker Protocol The Adjacent Broker Protocol is a highly efficient lowlevel TCP/IP protocol that provides the basic message transport. It is a bidirectional and multiplexed protocol and so can handle the message transport for multiple SQL Server Service Broker dialogs. It doesn’t worry about message order or confirming message delivery. That’s all handled by the Dialog Protocol. Instead, the Adjacent Broker Protocol simply sends messages across the network as quickly as it can. Dialog Protocol The Dialog Protocol is a higher-level protocol that utilizes the services of the Adjacent Broker Protocol to handle end-to-end communications for a SQL Server Service Broker dialog. It is designed to provide one-time-only, inorder delivery of messages, handling the sending and acknowledgment of messages. It also provides symmetric failure handling where both end nodes are notified of any message delivery failures. In addition, the Dialog Protocol is responsible for authentication and encryption of messages.
|
legal disclaimer
1) Our website is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringements, please read the Terms of service and contact us to investigate the problem.
2) The E-articles directory team is not responsible for inaccuracies, falsehoods, or any other types of misinformation this tutorial may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. Please read the Terms of service
Useful tools and features
If you like this article (tutorial), please link to it from your web page using the information above. Linking to this page, this is the only way to help us improve our service, the same time providing your visitors with a way to improve their online experience.
related articles
The first questions to ask are what is SQL and how do you use it with databases? SQL has three main roles: 1. Creating a database and defining its structure 2. Querying the database to obtain the data necessary to answer questions 3. Controlling database security Defining database structure includes creating new database tables and fields, setting up rules for data entry, and so on, which is expressed by a SQL sublanguage called Data Control Language (DCL). The next section discusses querying ...
2. Managing and Monitoring SQL Server 2000 Security
Authentication There are two methods of authentication offered SQL Server 2000, Windows authentication and SQL Server authentication. Windows authentication allows the SQL server authentication to be integrated directly with security on a Windows 2000/NT system. Authentication will depend on the security mode that SQL Server 2000 runs under, Windows Authentication mode, or Mixed Mode. If you are running SQL Server 2000, you will need to configure the SQL server to run in mixed mode to allow the non-Win...
3. Managing Monitoring and Troubleshooting SQL Server 2000
SQL Server Agent Jobs SQL Server Agent is a job scheduling agent that aids in the management of a SQL server. SQL Server Agent can be started when the operating system starts and is configured through the SQL Service Manager or Enterprise Manager. The SQL Server Agent is responsible for the execution of jobs. Jobs are made up of multiple steps that have instructions on what to do depending on the success or failure of each step in the job. Jobs are assigned to an operator, a user who is responsible for tha...
4. Managing Monitoring and Troubleshooting SQL Server 2000 Databases
Troubleshooting SQL Databases is an operation that supposes multiple actions. They are described below. Optimizing Database Performance Database performance is an important part of administering a SQL Server 2000 environment. There are many ways that performance can be increased including indexing, locking and recompiling. Indexing Establishing indexes can dramatically increase query performance, but can also adversely affect data modification performance. Any changes to an...
5. Tips for Designing a Better SQL Database
Keeping the following subjects in mind helps ensure that your database design and updates go smoothly. Don’t design a database that copes with the norm. Tempting as it is to design a database that covers most situations, doing so is dangerous. The unexpected happens just when you least expect it, so make sure you design your database to cover all situations that could arise, or at least ensure that it can cope with the unusual situations. Even if a client tells you not to worry about the possibility of two people attem...
6. Why and When to Use a Database
When there are a huge number of alternative ways to store data, why should you trouble yourself creating a database? What advantages does a database hold? The main advantage is fast and efficient data retrieval. A database helps you to organize your data in alogical manner. Database management systems are fine-tuned to rapidly retrieve the data you want in the way you want it. Databases also enable you to break data into specific parts. Retrieving data from a database is called querying. You’ll often see the term SQL query, which brief...
7. Creating SQL Server 2000 Databases
Attaching and Detaching Databases Detaching/attaching is used in moving a database between computers or physical disks. When a database is detached, the links from the server to the data files and transaction logs are removed. When you attach a database, you re-establish those links. When you detach and re-attach, you eliminate the need to restore the database backup manually. When a database is reattached, all files that have changed location must be specified. Filegroups Filegroups ar...
8. Developing Notification Services Applications in SQL server 2005
The process for developing Notification Services applications begins with defining the rules that govern how the application works. Next, you must compile the application. Then you need to construct an interface that allows the user to add subscriptions to the application. Finally, you’ll need to add any custom components that may be needed by the application. Let’s look at each of these steps in more detail. Defining the Application The Notification Services developer uses a combination of XML...
9. SQL Server Service Broker Activation
SQL Server Service Broker activation is another unique feature of the SQL Server Service Broker subsystem. Activation enables you to create a stored procedure that is associated with a given input queue. The purpose of the stored procedure is to automatically process messages from that queue. As each new message comes in, the associated stored procedure is automatically executed to handle the incoming messages. If the stored procedure encounters an error, it can throw an exception and be automatically recycled. ...
10. SQL Server 2005 Administrative Tools
This article gives you an overview of the SQL Server 2005 administrative tools, including: Profiler enhancements Database Tuning Advisor Assisted editors Profiler Enhancements With SQL Server 2005, Profiler gets an overhaul as well. The new Profiler now supports the ability to trace both SSIS and Analysis Services commands. SQL Server 2000 was limited to tracing relational database calls only. By having these capabilities, you can use these ...