Introduction to SQL Server 2005 message-based applications

A messaging application is not a new concept, but it has always been difficult to write such an application from scratch. I'll discuss a new platform for building asynchronous messaging applications in a series of three articles, the first of which I'll explain the concept of a messaging application and a new infrastructure for building these applications in SQL Server 2005.

Messaging-based application introduction

Applications that process messages are generally successful applications. In fact, most large applications have some kind of message processing applied. This processing can be quite simple, for example, by placing a file on a network share so that another application can process the file, and then you can check the network share to see if the file is being processed.

Although this is not a very complex messaging application, the concept behind it is the same: Submit a message that the application performs its work. Then, check to see if you receive information that the confirmation message has been processed. This approach has a number of unique advantages:

Deferred processing: Sometimes it is impractical to handle all the work of a task at a given time. Many times, when your application can handle tasks that reach a bottleneck, it's best to leave the remaining tasks to another application for processing.

This is the case for buying tickets online. When you buy a ticket to a website, you enter information such as Departure city, arrival city, date of travel and number of passengers accompanying. After you enter your credit card information, you will receive a confirmation email. In the background, some type of message has been submitted to another service that executes the request for processing. If you can't meet the booking request, the email you receive will illustrate this point.

The benefit of this process is that it eases the pressure on the backend database system to jam. And if customers are asked to wait a long time for confirmation, most customers will feel very dissatisfied. In addition, if all processing tasks are completed in a single function transaction, a serious deadlock situation can occur that negatively affects the purchase experience of the customer who buys the ticket on the website.

Distributed processing: Generally, it is best to deal with a task as quickly as possible. However, it is sometimes difficult to determine how many tasks are to be processed, and how much resources will be consumed to complete those tasks. Let's look at an example of such a process.

There are many checkout lanes in the supermarket. The number of channels is generally based on the resources of the supermarket. Sometimes, for example, in the afternoon of Saturday, the checkout aisle became very crowded and the customer had to wait in line. As long as the supermarket resources are not depleted, supermarkets can allocate more cashiers to customers to pay the bill. This can speed up the checkout, without affecting the overall operation of the supermarket.

Similarly, messaging applications operate in a similar way. If your application is full of pending requests, you should usually add another processing queue to mitigate the overall processing pressure of the system.

Microsoft Message Queuing

Now that you may have realized the value of a message based application, you may wonder why you don't often hear about this application. The main reason is that the development of this application is a very difficult task. If you plan to write your own message based applications, you will spend most of your time developing the infrastructure to process messages.

The good news is that you no longer need to develop your own messaging infrastructure. Microsoft Message Queuing (MSMQ) provides a framework for developing such applications. It enables applications to communicate across different kinds of networks, and requires the assurance of messaging (guaranteed message delivery), routing, and configurable security. MSMQ applications are typically developed in applications written in Visual Basic, C #, or C + +, but can also be written in other programming languages. These applications perform well when dealing with tasks that typically require a few steps to complete. At this point, each step of a task requires logic to reach the next step in the task, such as a business workflow application.

Database--no longer just for storing data

Our reliance on relational database systems has increased significantly over the past 20 years. Initially, storing and processing data is the main purpose of establishing a business relational database system. With the development of relational database system, changes in its functionality and complexity, its main use has been transformed from a single data store to more mainstream business intelligence purposes, more complex ETL processing, data reporting, and data notification; In SQL Server 2005, it has even been written to execute in the database engine. The ability of the NET CLR language code. Therefore, it is entirely certain that the database engine is no longer used only for data storage.

Service Broker

Microsoft believes it makes sense to allow you to build a message-based application within a database. Service Broker is a newly added base program in SQL Server 2005 that is primarily used to build a messaging application within the database engine. These applications are developed using a new TSQL structure within the database engine.

Service broker applications are developed with loosely connected applications that are highly scalable and provide functionality that other messaging platforms do not have, such as message group coordination and locking. These applications fully support transactions and are able to span database instances and servers.

Follow-up discussion

In the next article in this series, I'll introduce the Service Broker application components and explore how they interact to form a Service Broker application model.