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

Пробное приложение

Базовая демонстрационная программа показывает взаимодействие двух консольных приложений – клиента и сервера – обменивающихся сообщениями с помощью разработанного выше каркаса.

Демо показывает передачу незашифрованных и зашифрованных WSE сообщений Soap на основе различных стандартных типов данных и комбинаций DIME API. Несмотря на то, что демо простое, оно хорошо иллюстрирует различные принципы.

Рисунок 17. Демо, выполняющее двух клиентов и одну серверную службу MQ / MSMQ

Демо показывает серверную службу, обрабатывающую входящие сообщения Soap в очередях MSMQ и MQ и возвращаемые ответы. Обработка нетривиальных типов данных (вещественные сериализованные пользовательские объекты) также включена в демо. Снимок экрана показывает обработку составных типов на основе произвольного класса под именем "продукт". Он показывает сериализацию и передачу массивов «продуктов» между сервером и клиентом. На снимке экрана выше два клиента выполняют вызовы Soap на очередях и через HTTP.

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

Знакомство с приложением

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

Рисунок 18. Результаты статьи

Существует два веб-сервиса ASP.NET (один с поддержкой WSE), поддерживающих базовый API, состоящий из:
•    вариантов HelloWorld, возвращающих строки и массивы строк
•    операций с двоичными данными – отправка и прием изображений
•    сериализации составных типов данных – ProductService, обслуживающий экземпляры продукта
•    [для версии сервиса с WSE] Отправка изображений с использованием поддержки DIME в WSE

Виртуальные каталоги IIS для этих сервисов называются WSAltRoute и WSAltRouteWSE.

Холостой сервис (WSAltRouteBEFake.exe) существует в области сервера – он функционально работает, подобно вышеупомянутым веб-сервисам ASP.NET, но реагирует на сообщения, принимаемые в очередях, а не через HTTP.
Код каркаса, реализующий подключаемые протоколы с формированием очередей, хранится в единственной сборке (WSQTransports.dll), чтобы его можно было использовать во множестве проектов.

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

Поддержка асинхронной работы (не показана) обеспечивается сборкой под именем AsyncHelper.dll.

Очереди MSMQ и MQ конфигурируются с помощью инструмента под названием WSQSetup.exe (не показан).

Установка приложения

zip архив содержит несколько проектов, описанных в разделе ниже. Основные действия при развертывании следующие:
•    Убедитесь, что требуемые ресурсы (особенно MQ и WSE) установлены
•    Разархивируйте файл, сохранив структуру папок
•    Найдите папку \Bin
•    Запустите исполняемый файл WSQSetup.exe для создания соответствующих очередей. Следуйте подсказкам на экране.
•    Найдите подпапку \Client
•    Отредактируйте файл WSAltRouteTest.exe.config, проверьте и внесите любые изменения.

Список элементов следующий:

Элемент	Описание
NoTrace	Если “Истина”, не делает дамп трассировки стека при возникновении исключения
EnableHTTPCalls	Если “Истина”, делает вызовы API через протокол передачи HTTP
EnableMSMQCalls	Если “Истина”, делает вызовы API через протокол передачи MSMQ
EnableMQCalls	Если “Истина”, делает вызовы API через протокол передачи MQ
HTTPUriNonWSE	Конечная точка веб-сервиса WSAltRoute
HTTPUriWSE	Конечная точка веб-сервисаWSAltRouteWSE
MSMQRequestQ	Конечная точка очереди запросов MSMQ
MSMQResponseQ	Конечная точка очереди ответов MSMQ
MQRequestQ	Конечная точка очереди запросов MQ
MQResponseQ	Конечная точка очереди ответов MQ
LocationOfImages	Путь для чтения и записи изображений

•    Например, если вы не хотите работать через HTTP, установите значение EnableHTTPCalls в “Ложь”.
•    Переместите папку \Bin
•    Найдите подпапку \Server
•    Отредактируйте файл WSAltRouteBEFake.exe.config, проверьте и внесите любые изменения.

Список элементов следующий:

Элемент	Описание
NoTrace	Если “Истина”, не делает дамп трассировки стека при возникновении исключения
QueueToMonitor1	Имя 1-й очереди для отслеживания на сообщения Soap
QueueToMonitor2	Имя 2-й очереди для отслеживания на сообщения Soap
QueueToMonitorX	Имя X-й для отслеживания на сообщения Soap
PollDelayTime	Задержка приема в мс.
LocationOfImages	Путь для чтения и записи изображений

•    Например, если вы хотите добавить очередь для отслеживания, добавьте QueueToMonitor3 и установите соответствующее значение в имени Uri очереди.
•    Если хотите протестировать протокол передачи HTTP:

o    найдите папку \WebServices
o    скопируйте две подпапки (WSAltRoute и WSAltRouteWSE) в вашу главную папку веб-сайта (обычно c:\inetpub\wwwroot).
o    Для первой папки создайте новый виртуальный каталог IIS под именем WSAltRoute для стандартного веб-сайта (порт 80), указывающий на целевую папку WSAltRoute.
o    Для второй папки создайте новый виртуальный каталог IIS под именем WSAltRouteWSE для стандартного веб-сайта (порт 80), указывающий на целевую папку WSAltRouteWSE.

•    Если хотите протестировать протокол передачи MSMQ:

o    Убедитесь, что очереди запросов и ответов MSMQ, определенные в WSAltRouteTest.exe.config клиентского приложения, существуют. Используйте средство управления компьютером Windows 2000 или Windows XP для проверки этого.

•    Если хотите протестировать протокол передачи MQ:

o    Убедитесь, что очереди запросов и ответов MQ, определенные в WSAltRouteTest.exe.config клиентского приложения, существуют. Используйте инструмент ‘Проводник’ Websphere MQ для проверки этого.

•    Переместите папку \Bin
•    Найдите подпапку \Images
•    Скопируйте два файла .gif, CD.gif и Help.gif в папку, заданную в WSAltRouteTest.exe.config клиента и WSAltRouteBEFake.exe.config сервера под ключевым именем LocationOfImages.
•    Чтобы запустить демо, сначала запустите серверный процесс WSAltRouteBEFake.exe, следя за правильным появлением пускового сообщения. Затем запустите клиентский процесс WSAltRouteTest.exe. После этого активность должна отобразиться в обеих консолях в течение следующих нескольких секунд, по мере того как различные API веб-сервиса выполняются через выбранные протоколы передачи. Не должно появляться никаких исключений.
•    Если исключения появляются, могут показываться сообщения, содержащиеся в исключении. Если это имеет место, можно включить трассировку стека путем изменения значения NoTrace в соответствующем конфигурационном файле приложения (обычно клиентского) на “Ложь”.

Компоновка приложения

Решение состоит из следующих проектов:

Имя проекта	Назначение
WSAltRouteTest	Программа клиента, тестирующая новые протоколы передачи.
WSAltRouteBEFake	Холостая программа сервера, отвечающая на запросы.
WSQTransports	Код, поддерживающий подключаемый транспортный каркас и реализации протоколов с формированием очередей.
AsyncHelper	Асинхронная поддержка бизнес-объектов из статьи MSDN
WSAltRoute	Веб-сервис ASP.NET сконфигурирован без WSE
WSAltRouteWSE	Веб-сервис ASP.NET сконфигурирован для работы с WSE
WSQSetup	Программа настройки для очередей – запускайте ее после установки MSMQ (и по желанию MQ), но до запуска демо.
WSSetupMQ	Поддержка создания очередей MQ – требует среду выполнения VB6

Файл решения должен загружаться мгновенно. Вам может понадобиться заново указать местоположение файлов .webinfo для двух ориентированных на HTTP веб-сервисов (по умолчанию занимающих порт 80), но в остальном проекты должны компилироваться прямо в подпапках \Bin\Client и \Bin\Server (при условии, что файлы внутри них не заблокированы).

Обзор разбора примеров

Ниже кратко перечислены главные характеристики решения:

Базовая поддержка

•    На первый взгляд, сгенерированный посредник Soap выглядит тесно связанным с протоколом передачи HTTP. В действительности дело обстоит не так.
•    Веб-сервисы ASP.NET включают в себя инфраструктуру, специально предназначенную для обеспечения поддержки альтернативных протоколов передачи, основанных на System.Net.WebRequest и System.Net.WebResponse.
•    Для поддержки новых протоколов в составе инфраструктуры предоставляется механизм регистрации схемы. После того как новые "схемы сети" зарегистрированы, клиент может использовать их при задании конечной точки.
•    MSMQ и Websphere MQ легко упаковываются в протокол передачи, и клиент просто задает конечную точку на основе схемы. Это минимизирует изменения кода, требуемые для наделения клиента возможностью использовать новый протокол передачи.

Поддержка защиты

•    WSE легко встраивается в клиенты и серверы ASP.NET, и в более необработанной форме в произвольные серверные службы .NET. В первом случае SoapWebRequest выполняет большую часть работы, такую как управление сериализацией сообщений Soap и последующая передача их конкретному протоколу передачи для доставки.
•    В код требуется внести немного изменений (каркас и клиент), чтобы перейти от режима незашифрованного текста к режиму защиты WSE.

Поддержка двоичных вложений

•    При наличии установленного WSE поддержка двоичных вложений посредством SoapWebRequest легко обеспечивается.

Дальнейшая работа

Данный раздел создается проще простого! Набор фактов для обдумывания включает:
•    В коде есть места, где строки соединяются, а не строятся с помощью StringBuilder. Можно попробовать использовать другую технику!
•    Нужно выполнить много действий  для защиты различных аспектов решения. Сразу на ум приходят два следующих:

o    Использовать StrongNameIdentityPermissionAttribute для явного контроля за тем, кто вызывает важные сборки (только вызывающие программы, подписанные конкретным сильным именным ключом)
o    Ключи шифрования должны храниться за пределами кода, в (хорошо защищенном) файле или в защищенной области реестра

•    Демонстрационная программа была построена на базе похожего на RPC протокола сообщений, в котором предполагаются ответы на сообщения. Изучение односторонних сообщений Soap было бы интересным – они лучше соответствуют операции отправки в форме очереди без необходимости приема соответствующего ответа и были бы полезным дополнением к библиотеке.
•    Данный каркас использовался для взаимодействия с сервером на Java, использующим набор инструментов Axis Toolkit 1.1 RC1 под J2SE 1.4.1.  К сожалению, добавление Java в набор привело бы к удвоению размера копии! В зависимости от реакции на данную статью, возможно написание новой статьи, более детально рассматривающей вопрос функциональной совместимости.
•    Было бы интересно добавить средство сжатия, как в библиотеке сжатия SmartLib  , в секцию DIME для больших вложений.
•    В каркасе можно реализовать другие протоколы передачи – SMTP, FTP, SQL2000 и т.д. являются хорошими кандидатами. Например, реализация TCP/IP в данном каркасе была выполнена весьма просто.