Данная статья описывает метод доставки сообщений Soap (простой протокол доступа к объектам), преобразуемых в последовательную форму с помощью сервисов веб-клиента ASP.NET через MSMQ (очередь сообщений Майкрософт) и MQ (очередь сообщений)

 •    Скачать исходные файлы и исполняемые файлы – 792Кб

Введение

Данная статья описывает использование подключаемой транспортной инфраструктуры, входящей в состав веб-сервисов ASP.NET, позволяющей разработчикам доставлять сообщения Soap, встроенные в документ/буквенный формат, к конечной точке посредством механизмов, отличных от стандартной передачи HTTP.

В данной статье рассматривается каркас, поддерживающий добавление альтернативных механизмов физической доставки, и включены две такие реализации – MSMQ и Websphere MQ, выбранные для демонстрации возможности промежуточного хранения для более гарантированной доставки запроса веб-сервисов. Разрабатываемый каркас включает в себя модернизацию веб-сервисов (WSE) 1.0 для защищенной двусторонней передачи сообщений посредством механизмов не HTTP, тем самым позволяя разработчику выбирать 'доверенную' (незашифрованное сообщение) или 'сомнительную' (зашифрованное сообщение) доставку до выбранной конечной точки.

Soap был разработан как транспортный нейтральный протокол – для использования в сочетании с различными транспортными протоколами, такими как HTTP(S), SMTP, FTP и т.д. – для доставки структурированных и типизированных данных между двумя участниками. Много работы ушло на встраивание в веб-сервисы ASP.NET поддержки формирования сообщений Soap способом, способствующим взаимодействию в разнородных средах (например, .NET, использующий сервер BEA Weblogic, на котором размещается веб-сервис), но до сих пор стандартный доступ к веб-сервисам в сфере Microsoft был связан практически исключительно с HTTP.

Soap посредством HTTP

Передача HTTP имеет достоинства и недостатки. Несомненный плюс – развитость связанной с ней инфраструктуры безопасности, появившейся в результате повсеместности интернета. Недостатком же, наоборот, является отсутствие какой-либо формы гарантированной и надежной (только одиночное сообщение) доставки внутри протокола, породившего такие решения, как HTTPR от IBM. К тому же серверная служба должна быть физически подключена к сети, чтобы запрос был получен по HTTP, и существуют веские причины для поиска альтернативных способов передачи сообщения.

Soap посредством альтернативных способов передачи

Хотя ASP.NET делает много для продвижения ориентированного на HTTP связывания с веб-сервисами, HTTP – не единственный протокол, доступный для передачи Soap. В среде разработки .NET имеется инфраструктура веб-сервисов, позволяющая  изменять механизм доставки сообщения и конечную точку статически (время разработки) или динамически (время выполнения). Настоящая мощь этой инфраструктуры – называемой "подключаемыми протоколами" Microsoft – в том, что метод передачи может изменяться под запрос логического клиента для направления Soap через любую оптимальную среду, которую разработчик реализует.

Данный разбор примеров показывает возможность эффективно переключать средства передачи под клиентом ASP.NET между HTTP, MSMQ и Websphere MQ. Он покажет, как просто поменять цель запроса веб-сервиса Soap со стандартного размещенного на IIS типа на слушателя, ожидающего очереди MSMQ или MQ. Демонстрируется применение API с использованием стандартных типов, таких как строки, массивы, двоичные данные и пользовательские упорядочиваемые типы. Также демонстрируется реализация данной поддержки в асинхронном режиме.

Обеспечение безопасности Soap

Протоколы передачи с организацией очередей годятся для использования внутри предприятия, т.е. внутри надежной сети организации с соизмеримыми (обычно уменьшенными) требованиями защиты. Однако при использовании средства доставки не по HTTP потенциально убирается слой испытанной защиты, которому нужно создать замену. К счастью, было разработано несколько единых стандартов для нового поколения протоколов веб-сервисов, охватывающих (среди прочего) защиту, маршрутизацию сообщений и вложения. Эта инициатива сосредоточена на обеспечении защиты сообщений между множеством узлов обработки, участвующих в бизнес-операции независящим от передачи образом – не опираясь на такие технологии, как SSL, работающих хорошо лишь в двухточечном режиме. Эти усилия недавно завершились выпуском реализации Microsoft вышеупомянутых стандартов в форме пакета модернизации веб-сервисов (WSE) 1.0. Разбор примеров также покажет, как реализация защиты WS внутри WSE 1.0 может применяться для защиты (в нашем случае цифровой подписью и симметричным шифрованием) сообщений, генерируемых клиентами и серверами ASP.NET, вместо использования собственных механизмов безопасности, присущих двум продуктам формирования очередей. Также рассматривается поддержка DIME, предоставляемая WSE в качестве альтернативного метода отправки двоичных данных, разработанная для передачи больших потоков двоичных данных.

Цели статьи

К концу разбора примеров будут разъяснены следующие аспекты:
•    Как писать новые протоколы доставки в рамках инфраструктуры подключаемых протоколов ASP.NET
•    Как подключаться к MSMQ и Websphere MQ из C# изнутри данной инфраструктуры
•    Как объединять WSE 1.0 с веб-сервисами на высоком и низком (прямое использование конвейеров программы работы с файлами WSE) уровнях для защиты данных
•    Как использовать WSE при передаче двоичных данных
•    Как запускать асинхронную доставку сообщений Soap с организацией очередей от клиента

Смысл работы

Подлинный смысл работы подразумевал пробный проект, направленный на определение того, насколько легко клиент .NET может подключиться к существующему ориентированному на Java-серверу с использованием веб-сервисов для взаимодействия, но через IBM Websphere MQ, а не HTTP. Эта статья дает ориентированный на .NET сервер на том основании, что при этом для усвоения статьи нужны лишь навыки работы с .NET, и что при наличии WSE на обоих концах легче продемонстрировать защищенную связь. Но особенности взаимодействия с реализацией сервиса Java указываются в соответствующих местах по всей статье.

Системные требования

Собранное решение требует следующей среды развертывания:
1. Windows 2000 SP2 или Windows XP Pro с установленными MSMQ и IIS
2. Среда разработки .NET 1.0 (SP1 или выше)
3. Среда выполнения WSE 1.0 SP1
4. (Только для поддержки MQ) Пробная версия Websphere MQ 5.3
5. (Только для поддержки MQ) Среда выполнения VB6
Для повторной сборки двоичных файлов решения необходимы следующие дополнительные инструменты:
6. VS.NET (C#)
7. WSE 1.0 SP1 – рекомендуется полная установка
8. Инструмент установки VS.NET WSE (по желанию)

Требуемые навыки

Читатель должен иметь следующие навыки:
•    знание C# на среднем уровне, знакомство с написанием и использованием базового веб-сервиса в .NET, так как будет довольно подробно рассматриваться клиентская инфраструктура (включая посредник, генерируемый WSDL).
•    желательно наличие опыта работа в области веб-сервисов второго поколения, таких как защита WS и вложения WS / DIME.
•    если вы хотите использовать Websphere MQ в качестве средства передачи (его можно отключить в конфигурационном файле пробного приложения), настоятельно рекомендуется установить пробную версию и настроить стандартные настройки.
•    начальное понимание обозначений унифицированного языка моделирования (UML).

Цели статьи

Цель – добиться успеха в следующих сферах:
•    Разделить то, что на первый взгляд кажется прочной связью между преобразованием сообщения Soap в последовательную форму и доставкой упомянутого сообщения посредством http до конечной точки.
•    Повторно использовать блок сериализации веб-сервисов .NET, чтобы не пришлось самостоятельно вручную делать Soap.
•    Подключиться к части доставки инфраструктуры с целью доставки запросов Soap к очереди и получению ответов Soap от очереди. Поддерживать MSMQ и Websphere MQ.
•    Для реализации этого клиент должен уметь отправлять нужную ему очередь, чтобы доставлять запросы к очереди максимально стандартным способом, т.е. с минимальными отличиями от способа описания URL.
•    После достижения этого нужно выяснить, какое влияние / выгоды дает использование WSE для обработки сообщений Soap – в обеспечении безопасности потоков сообщений и в обеспечении передачи двоичных вложений вне оболочки Soap.
•    Научиться упаковывать результирующий код способом, минимизирующим работу разработчиков, желающих включить ориентированные на формирование очередей средства передачи в свои решения.
•    Убедиться, что основной каркас функционирует в среде множественного одновременного использования.