• Вызовы от клиента к серверу могут накапливаться на стороне клиента и отправляться серверу все за один раз.

• Клиент может вызывать метод сервера даже в тот момент, когда сервер еще не запущен.

Рассмотрим ситуации, когда предпочтительно использовать асинхронные компоненты:

• В рамках бизнес-логики данного приложения в одних случаях коммуникация клиент/сервер должна выполняться в режиме реального времени, а в других допустима асинхронная коммуникация.

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

• Возникает проблема масштабируемости приложения

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

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

• Клиентское приложение работает на устройстве, не подключенном к сети

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

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

Технология асинхронных компонент основана на технологии MSMQ (Microsoft Message Queuing), которая для полноты изложения и рассматривается кратко в следующем разделе (изложение основано на статье David Chappell "Microsoft Message Queue Is a Fast, Efficient Choice for Your Distributed Applications" в MSJ, July 1998 и материалах из MSDN).

MSMQ

Синхронная коммуникация удаленных клиента и сервера в СОМ+ основана на использовании протокола DCOM — объектно-ориентированной версии RPC. MSMQ предоставляет новую возможность — обмен сообщениями. Эта технология имеет следующие преимущества:

• Отправитель сообщения не блокируется в ожидании ответа от получателя.

• Отправитель и получатель могут работать в различные непересекающиеся интервалы времени.

• Отправитель может направить сообщение сразу же целой группе получателей.

• Сообщение можно сохранить на диске и повторить его обработку при сбое.

• Возможна пересылка сообщений по цепочке (аналог делегирования).

Таким образом, MSMQ (вместе с другими подобными технологиями) представляет особую парадигму проектирования распределенных систем. В качестве примера можно напомнить, что обмен сообщениями используется в распределенных вычислениях (MPI в кластерах ЭВМ). Можно предположить, что основанные на сообщениях технологии будут особенно популярны при проектировании распределенных систем на уровне выше предприятия, т. е. систем, отдельные части которых слабо или вообще не связаны друг с другом организационно.

Основными элементами технологии MSMQ являются:

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

Данный API имеется в двух видах: множество С функций и множество СОМ объектов. MSMQ API обеспечивает следующие возможности:

? Создание и уничтожение очереди сообщений

? Открытие и закрытие существующей очереди сообщений

? Получение сообщения из очереди синхронно, асинхронно, с удалением из очереди, чтение некоторых элементов сообщения без удаления его из очереди и т. п.

• Сообщение

Многое о возможностях MSMQ можно узнать просто просмотрев список свойств, которые могут быть приписаны сообщению. Эти свойства хранятся в специальной структуре, передаваемой как входной параметр в API функции, связанные с отправлением и получением сообщения. Рассмотрим некоторые из этих свойств:

? Body

Здесь размещается основное содержание сообщения (объемом до 4 МЬ). Передавать можно даже СОМ объект, поддерживающий интерфейс IPersistStream, методы которого позволяют записать состояние объекта в некоторый поток, а затем восстановить объект, инициировав его данными из потока,