Обзор Message Queuing

В пространстве имен System.Messaging определены классы, которые позволяют выполнять чтение и запись сообщений с использованием такого предлагаемого в составе операционной системы Windows средства для организации сообщений, как .

Обмен сообщениями может применяться в сценарии автономной работы, в котором не требуется, чтобы клиент и сервер обязательно запускались в одно и то же время.

Прежде чем углубляться в детали программирования с использованием Message Queuing, в данной статье я предлагаю ознакомиться с основными концепциями организации очередей сообщений и сравнить их с концепциями синхронного и асинхронного программирования.

При синхронном программировании, когда вызывается метод, то вызвавший его код должен ожидать, пока метод не завершит свою работу. При асинхронном программировании вызывающий поток запускает метод и параллельно продолжает свою работу. Асинхронное программирование основано на применении делегатов, библиотек классов, которые уже поддерживают асинхронные методы (например, прокси-классы веб-служб и классы из пространств System.Net и System.IO), либо специальных потоков. Как при синхронном, так и при асинхронном программировании клиент и сервер должны работать в одно и то же время.

Хотя Message Queuing работает асинхронно, поскольку клиент (отправитель) не ожидает прочтения получателем (сервером) оправленных ему данных, между Message Queuing и асинхронным программированием существует принципиальная разница: Message Queuing может выполняться в автономной (отключенной) среде. На момент отправки данных их получатель может быть отключен. Позднее, когда получатель подключится, он получит данные без вмешательства отправляющего приложения.

Подключенное и отключенное программирование можно сравнить с разговором по телефону и отправкой почтовых сообщений. При разговоре с кем-либо по телефону оба участника должны быть подключены одновременно — это синхронная коммуникация. В случае обмена электронной почтой отправитель не знает, когда его послание будет прочитано. Люди, использующие эту технологию, работают в автономном (отключенном) режиме.

Конечно, может случиться так, что почта не будет прочитана никогда, а просто проигнорирована. Такова природа отключенных коммуникаций. Чтобы избежать этой проблемы, можно запросить ответ или подтверждение факта прочтения письма. Если ответ не придет в течение определенного времени, возможно, придется как-то справляться с таким «исключением». Все это также возможно в Message Queuing.

Message Queuing, по сути, можно считать технологией для обмена электронными сообщениями между приложениями, а не людьми. Она обладает множеством функциональных возможностей, которые в других службах обмена сообщениями не доступны: гарантированием доставки, применением транзакций, получением подтверждений, экспресс-режимом, использующим память, и т.д. Message Queuing предлагает массу полезных средств для коммуникаций между приложениями.

С помощью Message Queuing можно отправлять, принимать и маршрутизировать сообщения в подключенной и отключенной (автономной) среде. На рисунке ниже показан очень простой способ использования сообщений. Отправитель посылает сообщения в очередь сообщений, а получатель принимает их из этой очереди:

Когда следует использовать Message Queuing

Одной из ситуаций, в которых удобно применять Message Queuing — это когда клиентское приложение часто отключается от сети (например, у коммивояжера, навещающего заказчиков на местах). Коммивояжер может вводить данные заказа непосредственно у заказчика. Приложение ставит сообщение о каждом заказе в очередь сообщений, находящуюся на клиентской системе. Как только коммивояжер возвращается в свой офис, заказ автоматически передается из очереди сообщений клиентской системы в очередь сообщений целевой системы, где и обрабатывается.

Помимо портативного компьютера, коммивояжер может использовать устройство Pocket Windows, где также доступно Message Queuing.

Технология Message Queuing может быть полезна и в подключенной среде. Представьте сайт электронной коммерции (показан на рисунке ниже), где в определенные периоды времени сервер полностью загружен обработкой заказов, например, в ранний вечер и в выходные, при этом по ночам нагрузка значительно уменьшается. Решение проблемы может состоять в приобретении более быстрого сервера или в добавлении дополнительных серверов к системе, чтобы они справлялись с пиковыми нагрузками.

Однако существует более дешевое решение: сгладить пиковые нагрузки, сдвинув транзакции со времени максимальных нагрузок на время с низкой загрузкой. В такой схеме заказы отправляются в очередь сообщений, а принимающая сторона читает их тогда, когда это удобно системе базы данных. Таким образом, нагрузка на систему сглаживается по времени, так что сервер, обрабатывающий транзакции, может быть дешевле и не требовать модернизации:

Функциональные возможности Message Queuing

Технология Message Queuing является службой, которая поставляется как часть операционной системы Windows. Ниже перечислены ее основные функциональные возможности:

Сообщения могут пересылаться в автономной среде. То есть приложению-отправителю и приложению-получателю вовсе не обязательно выполняться в одно и то же время.

В экспресс-режиме сообщения могут пересылаться очень быстро. В экспресс-режиме сообщения просто сохраняются в памяти.

Для механизма восстановления сообщения могут отправляться с гарантированной доставкой. Такие сообщения сохраняются в файлах и доставляются даже в случае перезагрузки сервера.

Очереди сообщений могут защищаться с применением списков контроля доступа и указания в них, каким пользователям разрешено отправлять или получать сообщения из очереди. Кроме того, сообщения могут шифроваться для исключения вероятности их прочтения с помощью сетевых анализаторов пакетов, а также снабжаться приоритетами, чтобы те из них, которые имеют более высокий приоритет, обрабатывались быстрее.

В Message Queuing 3.0 поддерживается возможность отправки многоадресных (multicast) сообщений.

В Message Queuing 4.0 поддерживается возможность распознавания вредоносных сообщений. Для таких сообщений может быть определена специальная очередь.

Например, в случае, если после прочтения сообщения из обычной очереди, далее оно должно вставляться в базу данных, но по какой-то причине этого не происходит, это сообщение может быть отправлено в очередь вредоносных сообщений. Впоследствии этой очередью вредоносных сообщений должен кто-нибудь заняться и выяснить, по какой причине адрес сообщения не удалось преобразовать.

В Message Queuing 5.0 поддерживаются более безопасные алгоритмы аутентификации, и может обрабатываться большее количество очередей. (В Message Queuing 4.0 при обработке нескольких тысяч очередей начинали возникать проблемы с производительностью.)

Из-за того, что Message Queuing является частью операционной системы, установить версию Message Queuing 5.0 в системе Windows XP или Windows Server 2003 не получится. Эта версия входит в состав ОС Windows Server 2008 R2 и Windows 7.

Продукты Message Queuing

Версия Message Queuing 5.0 поставляется в составе Windows 7 и Windows Server 2008 R2. В Windows 2000 входила версия Message Queuing 2.0, в которой не было поддержки ни протокола HTTP, ни многоадресных сообщений. Версия Message Queuing 3.0 поставлялась в составе Windows XP и Windows Server 2003, а версия Message Queuing 4.0 — в составе Windows Vista и Windows Server 2003.

При использовании ссылки Turn Windows Features on or off (Включение или отключение компонентов Windows), которая предлагается в Windows 7 в окне Configuring Programs and Features (Программы и компоненты), можно обнаружить отдельный раздел с опциями, касающимися Message Queuing:

В этом разделе доступны для выбора перечисленные ниже компоненты:

Microsoft Message Queue (MSMQ) Server Core

Основные компоненты сервера очереди сообщений (MSMQ), которые необходимы для получения базовой функциональности Message Queuing.

Active Directory Domain Services Integration

Интеграция MSMQ доменных служб Active Directory. Это средство позволяет записывать имена очередей сообщений в Active Directory. С помощью этой опции можно находить очереди в Active Directory и защищать их на основе пользователей и групп пользователей Windows.

MSMQ HTTP Support

Поддержка протокола HTTP MSMQ. Поддержка MSMQ HTTP позволяет отправлять и принимать сообщения, используя протокол HTTP.

Triggers

С помощью триггеров создаются экземпляры приложений при поступлении нового сообщения.

Multicast Support

Поддержка многоадресной рассылки. Позволяет отправлять сообщения группам серверов.

MSMQ DCOM Proxy

С помощью DCOM-прокси система может подключаться к удаленному серверу, используя API-интерфейс DCOM.

После установки Message Queuing в системе должна быть обязательно запущена служба Message Queuing (показана на рисунке). Эта служба читает и записывает сообщения, а также взаимодействует с другими серверами Message Queuing для осуществления маршрутизации сообщений по сети:

Using Messages and Message Queues

The following code examples demonstrate how to perform the following tasks associated with Windows messages and message queues.

Creating a Message Loop

The system does not automatically create a message queue for each thread. Instead, the system creates a message queue only for threads that perform operations which require a message queue. If the thread creates one or more windows, a message loop must be provided; this message loop retrieves messages from the thread’s message queue and dispatches them to the appropriate window procedures.

Because the system directs messages to individual windows in an application, a thread must create at least one window before starting its message loop. Most applications contain a single thread that creates windows. A typical application registers the window class for its main window, creates and shows the main window, and then starts its message loop — all in the WinMain function.

You create a message loop by using the GetMessage and DispatchMessage functions. If your application must obtain character input from the user, include the TranslateMessage function in the loop. TranslateMessage translates virtual-key messages into character messages. The following example shows the message loop in the WinMain function of a simple Windows-based application.

The following example shows a message loop for a thread that uses accelerators and displays a modeless dialog box. When TranslateAccelerator or IsDialogMessage returns TRUE (indicating that the message has been processed), TranslateMessage and DispatchMessage are not called. The reason for this is that TranslateAccelerator and IsDialogMessage perform all necessary translating and dispatching of messages.

Examining a Message Queue

Occasionally, an application needs to examine the contents of a thread’s message queue from outside the thread’s message loop. For example, if an application’s window procedure performs a lengthy drawing operation, you may want the user to be able to interrupt the operation. Unless your application periodically examines the message queue during the operation for mouse and keyboard messages, it will not respond to user input until after the operation has completed. The reason for this is that the DispatchMessage function in the thread’s message loop does not return until the window procedure finishes processing a message.

You can use the PeekMessage function to examine a message queue during a lengthy operation. PeekMessage is similar to the GetMessage function; both check a message queue for a message that matches the filter criteria and then copy the message to an MSG structure. The main difference between the two functions is that GetMessage does not return until a message matching the filter criteria is placed in the queue, whereas PeekMessage returns immediately regardless of whether a message is in the queue.

The following example shows how to use PeekMessage to examine a message queue for mouse clicks and keyboard input during a lengthy operation.

Other functions, including GetQueueStatus and GetInputState, also allow you to examine the contents of a thread’s message queue. GetQueueStatus returns an array of flags that indicates the types of messages in the queue; using it is the fastest way to discover whether the queue contains any messages. GetInputState returns TRUE if the queue contains mouse or keyboard messages. Both of these functions can be used to determine whether the queue contains messages that need to be processed.

Posting a Message

You can post a message to a message queue by using the PostMessage function. PostMessage places a message at the end of a thread’s message queue and returns immediately, without waiting for the thread to process the message. The function’s parameters include a window handle, a message identifier, and two message parameters. The system copies these parameters to an MSG structure, fills the time and pt members of the structure, and places the structure in the message queue.

The system uses the window handle passed with the PostMessage function to determine which thread message queue should receive the message. If the handle is HWND_TOPMOST, the system posts the message to the thread message queues of all top-level windows.

You can use the PostThreadMessage function to post a message to a specific thread message queue. PostThreadMessage is similar to PostMessage, except the first parameter is a thread identifier rather than a window handle. You can retrieve the thread identifier by calling the GetCurrentThreadId function.

Use the PostQuitMessage function to exit a message loop. PostQuitMessage posts the WM_QUIT message to the currently executing thread. The thread’s message loop terminates and returns control to the system when it encounters the WM_QUIT message. An application usually calls PostQuitMessage in response to the WM_DESTROY message, as shown in the following example.

Sending a Message

The SendMessage function is used to send a message directly to a window procedure. SendMessage calls a window procedure and waits for that procedure to process the message and return a result.

A message can be sent to any window in the system; all that is required is a window handle. The system uses the handle to determine which window procedure should receive the message.

Before processing a message that may have been sent from another thread, a window procedure should first call the InSendMessage function. If this function returns TRUE, the window procedure should call ReplyMessage before any function that causes the thread to yield control, as shown in the following example.

A number of messages can be sent to controls in a dialog box. These control messages set the appearance, behavior, and content of controls or retrieve information about controls. For example, the CB_ADDSTRING message can add a string to a combo box, and the BM_SETCHECK message can set the check state of a check box or radio button.

Use the SendDlgItemMessage function to send a message to a control, specifying the identifier of the control and the handle of the dialog box window that contains the control. The following example, taken from a dialog box procedure, copies a string from a combo box’s edit control into its list box. The example uses SendDlgItemMessage to send a CB_ADDSTRING message to the combo box.