Asynchronous messaging is not a new concept. Developers often use message queuing products such as Microsoft Message Queuing (MSMQ) to post a message to a queue and defer parts of processing to create scalable applications.
Asynchronous messaging offers the following benefits:
Improved performance and shortened interactive response time Responsiveness and overall throughput of the system is improved because much of the work is now done asynchronously, so the user doesn't have to wait for it to complete before receiving a response. Queuing and asynchronous messaging also allow developers to design an application to scale when the load increases.
Load distribution An application can send a message in a queue, which can be asynchronously received and processed by another application on a different machine to complete the rest of the processing.
Batch or deferred processing An application can send a message in a queue, which can be later received by an end-of-day batch process to complete the rest of the processing.
Scale out An application can send a message, which can be received and processed at different servers.
Parallelism Asynchronous messaging can also provide opportunities for increased parallelism. For instance, if you need to check inventory and verify a customer's credit, you can post messages to two queues. The queue messages can be processed asynchronously and in parallel to perform both tasks and to improve overall response time.
Loose coupling Messaging can be used to integrate applications. For instance, one application can post a message to a queue on which another application is listening. In addition, loose coupling (which involves breaking an application into sets of independent tasks) can also simplify deployment and upgrade scenarios.
At first it might seem simple to build your own asynchronous and queued messaging solution: Just post a message in a queue and then receive and parse the message to determine what processing needs to be done. However, it is not as simple as it seems. Asynchronous messaging frameworks such as MSMQ provide a lot of services to application developers, enabling them to focus on solving business problems. Messaging frameworks such as MSMQ have to guarantee the message delivery, ensure the message integrity, make sure that each message is received only once and received in the order sent, manage message routing and security, and handle situations where there are multiple queues and multiple readers or a single queue and multiple readers, and so on.
Asynchronous Messaging in a Database
Having an asynchronous messaging platform built into the database system offers following benefits:
Integrated management, deployment, and operations You do not have to worry about deploying, configuring, and administering two separate systems for data and messages. With SQL Server 2005, administration of messaging applications is part of the routine administration of the database. The high-availability solutions (such as clustering) protect the database and messages from failures. Familiar T-SQL and XQuery syntax can be used to query and find out things like total number of messages in a queue, the message text, what messages have not been delivered yet, and so on. Familiar trace events (from Profiler) can be used to monitor and debug the messages. The same connection can be used to manipulate data and to send/receive messages.
Unified programming model The same T-SQL language is used for data access and messaging. Database programmers find it convenient to use the same language (T-SQL) and tools to access data and to implement messaging.
Transactional distributed processing without the need for a complex two-phase commit Asynchronous messaging within a database can use message acknowledgements to provide reliable and transactional messaging without distributed (that is, two-phase commit) transactions.
Performance advantages By avoiding the use of external messaging system, which includes avoiding the two-phase commit requirement and optimizing ininstance messaging (the sender and receiver database are in the same instance), developers can get a significant performance advantage.
The asynchronous reliable messaging functionality is now built in to the SQL Server 2005 database engine in the form of Service Broker. You can use Service Broker technology in applications to send messages within the same database, between different databases on the same instance, between different instances on the same machine, or to a different server. Note that Service Broker is not based on MSMQ, and there are differences between the two technologies. Service Broker is compared with other messaging platforms later in this chapter, in the section "Service Broker and Other Messaging Technologies."