Modern e-commerce systems demand scalable, database-level functionality to handle complex business-process workloads. In many organizations, for example, taking a sales order is much more complex than taking a customer's money and shipping the product. In addition, systems that handle these transactions aren't always scalable or working in synch. To handle the needs of highly scalable business applications, SQL Server Service Broker, a new technology in SQL Server Yukon, will let internal and external processes send and receive reliable, asynchronous messages through extensions to T-SQL Data Manipulation Language (DML). With Service Broker, systems can send messages to a queue in the same database as the sender, to another database in the same SQL Server instance, or to another SQL Server instance on either the same server or a remote server.
Why use asynchronous, queued messaging? Queues enable flexible work scheduling, which can translate into big improvements in both performance and scalability. Take order entry, for example. Your system needs to process some parts of an order—such as order header, available to promise, and order lines—before you can consider the order complete. But other parts of the order—such as billing, shipping, and inventory—realistically don't have to happen before the system commits the order. If a system can process the parts of the order that can be delayed in a guaranteed but asynchronous manner, your organization can process the core part of the order faster.
Asynchronous queued messaging can also provide opportunities for increased parallelism. For example, if you need to check a customer's credit and the availability of ordered items, doing both processes simultaneously can improve overall response time. Queuing can also let systems distribute processing more evenly, reducing the server's required peak capacity.
What Service Broker can do. With Service Broker, Yukon becomes a platform for building loosely coupled, asynchronous database applications. Most large database applications have one or more tables that they use as queues. Although using a table as a queue is useful for improving performance and scalability, keeping transactional accuracy is difficult. Service Broker addresses the complexity of building table queues by implementing queues as built-in database objects. The queue-handling code built into the database kernel handles the locking, ordering, and multithreading processes that cause problems in most homegrown database queues.
To scale out asynchronous database applications, Service Broker includes reliable, transactional messaging between SQL Server instances. Service Broker uses a dialog mechanism that transmits the message between two services exactly once and in order, preventing duplicate messages. To ensure that an application is always running to process received messages, Service Broker includes an activation feature that increases the number of processing stored procedures as the workload increases and decreases the number of stored procedures as the queue workload decreases or becomes inactive.
What Service Broker isn't. Service Broker isn't a general-purpose messaging system. Service Broker supports only transactional messaging. Transactional messaging is the only way to ensure that messages are processed exactly once and in order, but not all messaging applications need these guarantees. Although no other transactional messaging system offers the reliability and performance that Service Broker provides for SQL Server applications, the fact that Service Broker is built into SQL Server means that it works only for SQL Server applications.
Service Broker also isn't a workflow engine. Service Broker's conversation groups, activation feature, and reliable transactional messaging would be useful to someone building a workflow application, but Service Broker doesn't do any workflow itself.
Finally, Service Broker isn't just a messaging system. Although Service Broker's messaging features might be valuable, many Service Broker applications don't require messaging at all. The ability to do asynchronous, queued database actions is useful, even if your database application isn't distributed.
Note that SQL Server's normal maintenance and operational aspects also apply to Service Broker applications. Service Broker applications can take advantage of failover clustering, for example. And SQL Server logs, backs up, and restores queued data along with the rest of your data, so messages have the same reliability and serviceability that all SQL Server data enjoys.
