Страница 201 из 372
IServerSecurity::ImpersonateClient и IServerSecurity::RevertToSeif, текущий поток будет делать удаленные вызовы то от имени клиента С, то от имени сервера S.
Асинхронные компоненты (Queued Components)
Вначале несколько слов о терминологии. Термин Queued Components сложно перевести на русский язык, сохраняя стоящий за ним (в рамках СОМ+) смысл. Дословный перевод "организованные в очередь компоненты", который иногда используется в русскоязычной литературе, заставляет предполагать, что имеется в виду некоторая очередь различных компонентов, тогда как все совершенно иначе — имеется очередь вызовов к одному компоненту. В данном курсе выбран термин "асинхронные компоненты", который должен подчеркивать возможность коммуникации клиента и сервера, функционирующих в различные, непересекающиеся интервалы времени.
Здесь же необходимо отметить, что в СОМ+ появилась новая возможность объявить некоторый интерфейс как асинхронный. Асинхронные интерфейсы и асинхронные компоненты (Queued Components) — это разные технологии. Использование асинхронного интерфейса позволяет клиенту сделать вызов некоторого метода асинхронного интерфейса сервера и сразу же заняться чем-нибудь еще (при использовании обычного синхронного интерфейса клиент блокируется до получения ответа от сервера). Но при этом и клиент и сервер должны функционировать одновременно. В случае вызова, направленного асинхронному компоненту, клиент также не блокируется, как и при вызове асинхронного интерфейса. И, кроме того, клиент может делать вызов сервера в тот момент, когда сервер еще не запущен.
Теперь перейдем к более подробному рассмотрению именно технологии асинхронных компонент.
До сих пор мы рассматривали только синхронную коммуникацию клиента и сервера — клиент делает вызов и ждет ответа сервера. Только после получения ответа от сервера продолжается выполнение клиента. Иначе такая коммуникация называется коммуникацией в режиме реального времени.
В случае вызова асинхронного компонента
• Клиент может не дожидаться ответа сервера и продолжать свою работу.
• Вызовы от клиента к серверу могут накапливаться на стороне клиента и отправляться серверу все за один раз.
• Клиент может вызывать метод сервера даже в тот момент, когда сервер еще не запущен.
Рассмотрим ситуации, когда предпочтительно использовать асинхронные компоненты:
• В рамках бизнес-логики данного приложения в одних случаях коммуникация клиент/сервер должна выполняться в режиме реального времени, а в других допустима асинхронная коммуникация.
Чаще всего в литературе приводится следующий пример. Клерк принимает заказы от клиентов по телефону. Коммуникация клерка и приложения, обеспечивающего прием заказа, должна выполняться в режиме реального времени. Например, может оказаться, что нужного товара нет на складе, и клерк может попытаться уговорить клиента купить другой товар. Однако, коммуникация приложения, принявшего заказ, и приложения, обеспечивающего доставку товара покупателю, может выполняться не в режиме реального времени, а, например, ночью, когда спадет поток заказов по телефону.
• Возникает проблема масштабируемости приложения
Предположим, что в рамках рассмотренного в предыдущем пункте примера, для оформления каждого нового заказа серверное приложения формирует объект, представляющий покупателя, в который и заносятся такие данные как имя покупателя, название товара, его стоимость, форма оплаты, адрес покупателя и т. п. В течении всего времени оформления заказа для некоторого покупателя соответствующий ему объект живет на сервере и связывает определенные ресурсы (например, соединения с базами данных). При большом числе одновременно оформляемых заказов, ресурсы, необходимые для поддержания всех представляющих покупателей объектов, могут оказаться недоступными.
Масштабируемое решение связано с использованием асинхронных компонент. Во время оформления заказа данные о заказе накапливаются в клиентском приложении и только потом, все вместе, направляются в только что созданный объект, представляющий покупателя, который обрабатывает все пришедшие запросы и удаляется из памяти.
• Клиентское приложение работает на устройстве, не подключенном к сети
Клерк из рассматриваемого примера может собирать заказы с помощью клиентского приложения, установленного на мобильном, не подключенном к сети компьютере.
Позже он может подключить свой компьютер к сети, и все аккумулированные вызовы поступят к удаленным асинхронным компонентам.
Технология асинхронных компонент основана на технологии 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, методы которого позволяют записать состояние объекта в некоторый поток, а затем восстановить объект, инициировав его данными из потока,
♦ Арр Specific
Это свойство можно использовать для передачи специфичной для приложения информации. Так как отдельные свойства сообщения можно просматривать не извлекая сообщение из очереди, наличие такого поля весьма полезно при программировании сложной бизнес-логики.
♦ Delivery
Данное свойство определяет, где очередь должна хранить данное сообщение — на диске (значение Express), либо в оперативной памяти (значение Recoverable). В последнем случае сообщение не пропадет если, например, произойдет отключение питания. Но в первом случае минимизируются накладные расходы. Time То Be Received