Интернет-журнал 'Домашняя лаборатория', 2007 №6 - Вязовский
Шрифт:
Интервал:
Закладка:
♦ Формирует цифровую подпись для данного сообщения
Ранее полученное хешированное значение шифруется личным ключом отправителя.
♦ Сообщение с прикрепленными сертификатом и цифровой подписью отправляется в очередь назначения.
Что делает менеджер очереди назначения по получении сообщения:
♦ Вычисляет хешированное значение определенных полей полученного сообщения Используется указанный в этом же сообщении алгоритм,
♦ Извлекает публичный ключ из сертификата, полученного с сообщением, о
♦ Расшифровывает цифровую подпись
Для расшифровки используется публичный ключ. Результатом является хешированное значение отправленного сообщения,
♦ Сравнивает хешированные значения отправленного и полученного сообщений:
• Хешированные значения равны
Если SID отправителя содержится в сообщении (в одном из его свойств, в сертификате), то это означает, что отправитель желает, чтобы получатель не только проверил целостность полученного сообщения, но и выяснил, пришло ли это сообщение от заявленного отправителя.
Без данной проверки возможен следующий сценарий. Некто перехватывает сообщение, модифицирует его и формирует новую цифровую подпись, пользуясь своим личным ключом. В этом случае он должен поменять и сертификат, посылаемый с сообщением, включив в него свой собственный публичный ключ. Если он сохранит в сообщении SID первоначального отправителя, то получатель получит искаженное сообщение не заметив подмены.
Проблема решается проверкой владельца сертификата в Active Directory. Злоумышленник не может зарегистрировать свой публичный ключ под чужим SID. Это позволяет менеджеру очереди назначения сравнить SID владельца сертификата и SID, включенный в сообщение. Если они совпадают, то аутентификация прошла успешно. В противном случае сообщение уничтожается и отправителю высылается соответствующее уведомление (если он об этом просил).
• Хешированные значения различны
Сообщение уничтожается и отправителю посылается соответствующее уведомление (при наличие его просьбы)
♦ Если сообщение еще не уничтожено, проверяется право отправителя на включение сообщения в данную очередь
При формировании очереди ей приписывается свой ACL — Access Control List. Если известен SID отправителя, то выполняется просмотр списка ACL до тех пор, пока не выяснится, что данный отправитель имеет или не имеет право на включение сообщения в данную очередь. Если SID отправителя не задан, то сообщение будет включено в очередь только при отсутствии каких-либо ограничений на эту операцию в ACL.
♦ Сообщение включается в очередь, если успешно завершилась проверка в ACL. В противном случае сообщение уничтожается. Отправителю посылается соответствующее уведомление (по его просьбе).
По запросу отправителя выполняется шифрование тела сообщения. Информация об использованном алгоритме содержится в специальном свойстве сообщения. На стороне отправителя шифровку выполняет либо MSMQ, либо приложение-отправитель. На стороне получателя расшифровку выполняет менеджер очереди назначения, и в очередь сообщение включается уже в расшифрованном виде.
• Очередь
Сообщения посылаются и извлекаются из очередей, которые в свою очередь могут создаваться, открываться, закрываться, удаляться. Все очереди на одной машине управляются менеджером очереди, роль которого отчасти уже обсуждалась при изучении свойств сообщений. Рассмотрим два класса очередей:
♦ Очереди, создаваемые приложением
При создании новой очереди необходимо определить, будет ли создаваемая очередь публичной (public) или личной (private), и будет ли она транзакционной (transactional) или нетранзакционной (non-transactional):
— Публичная очередь
Регистрируется в Active Directory и, следовательно, может быть обнаружена любым приложением. Интересно отметить, что среди параметров, приписываемых очереди при ее создании, имеется параметр, задающий тип очереди в виде GUID. Это позволяет приложениям искать публичные очереди нужного типа (например, очередь печати).
— Личная очередь
Регистрируется только на локальной машине. Другие приложения могут узнать об этой очереди от создавшего ее приложения (например, через свойство Response Queue полученного сообщения).
— Транзакционная очередь и нетранзакционная очередь
Важная роль распределенных транзакций уже обсуждалась ранее. Напомним, что основными игроками в распределенной транзакции являются прикладные объекты, менеджеры ресурсов и менеджер транзакций. Транзакционная очередь является менеджером транзакций. Сообщения из контекста транзакции посылаютя только в транзакционную очередь. Сообщения, посылаемые извне контекста транзакции могут посылаться только в нетранзакционную очередь.
Если необходимо гарантировать доставку сообщения от отправителя до получателя, причем только одной копии такого сообщения, следует использовать транзакционную очередь назначения на машине получателя, отправлять сообщение из контекста транзакции и получать сообщение из контекста транзакции.
♦ Очереди приложения делятся на
— Очередь назначения
В эту очередь приложение получает сообщения от других приложений. Для минимизации трафика обычно локальна по отношению к приложению (обязательно локальна, если транзакционна).
— Административная очередь
В этом качестве можно использовать любую нетранзакционную очередь, обычно локальную. Именно в эту очередь MSMQ отправляет положительные и отрицательные подтверждения относительно доставки сообщений, отправляемых данным приложением другим приложениям.
— Очередь ответов
В эту очередь приложения-получатели сообщений, отправляемых данным приложением, отправляют свои ответы,
♦ Системные очереди
Среди системных очередей, создаваемых MSMQ, отметим
— Журнал
Служит для хранения всех сообщений, удаяемых из некоторой очереди, или для хранения всех сообщений, отправляемых с данного компьютера.
— Dead-letter
Сообщения, которые не удалось отправить.
Завершая краткий обзор MSMQ, осталось рассмотреть типы MSMQ приложений:
• MSMQ сервер
Поддерживаются и используются очереди, менеджер очередей, MSMQ API, маршрутизация сообщений между очередями. Хотя бы один такой сервер должен иметься в любом распределенном приложении, поддерживающем обмен сообщениями.
• Независимый клиент
Поддерживаются и используются очереди, менеджер очередей, MSMQ API. Благодаря наличию собственных очередей независимый клиент может отправлять сообщения даже будучи отключенным от сети. Отправляемые сообщения накапливаются в некоторой очереди и передаются в очередь назначения автоматически при подключении к сети.
• Зависимый клиент
Поддерживается и используется только MSMQ API. Такой клиент может работать только при подключении к сети.
Архитектура асинхронных компонент
Вновь обратимся к рассмотрению технологии асинхронных компонент. Основными элементами ее архитектуры являются:
• Клиент
Интересно отметить, что клиент может вызывать экземпляр асинхронного компонента либо обычным, синхронным образом, либо асинхронно. Все зависит от способа активации объекта.
При явном использовании стандартного для СОМ способа (функции CoGetClassObject или CoCreateInstance [Ex]) будет создан экземпляр асинхронного компонента, пригодный только для обычных синхронных вызовов. Точнее, на стороне клиента будет сформирован обычный прокси, а на стороне сервера — стаб, которые и обеспечат вызовы методов экземпляра асинхронного компонента в реальном времени.
Для использования возможностей технологии асинхронных компонент клиент должен инициировать формирование экземпляра асинхронного компонента посредством использования моникеров ТИПОВ queue, new И функции CoGetObject. Например,
hr = CoGetObject(L" queue:/new: My_App.My_Class",
NULL, IID_My_interface, (void**)&ppv);
Моникер иногда называют интеллектуальным именем. Моникер — это объект, который знает как найти, активировать, инициализировать другой СОМ объект. Моникеры бывают как встроенные (нескольких типов), так и пользовательские. Используя встроенные моникеры и их композицию можно получить бесконечно много новых моникеров, что практически позволяет обойтись без разработки и реализации пользовательских моникеров, которые
