Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Введение. XML >Использование протокола SOAP в распределенных приложениях






XML > Использование протокола SOAP в распределенных приложениях

25 августа 2006 года

3 XML

Введение

Simple Object Access Protocol (SOAP) – основанный на XML протокол, предназначенный для обмена информацией в распределенных системах. SOAP устанавливает стандарт взаимодействия клиент-сервер и регламентирует, как должен осуществляться вызов, передаваться параметры и возвращаемые значения. Для представления любой информации, передаваемой от клиента к серверу и наоборот, используется XML.

ПРИМЕЧАНИЕ SOAP не накладывает ограничений на используемый транспорт. Для передачи сообщений могут использоваться любые протоколы и продукты, например, протоколы HTTP, HTTPS, SMTP. Данные могут передаваться через Microsoft Message Queueing, IBM MQ Series и т.д. Однако чаще всего используется протокол HTTP. Microsoft SOAP Toolkit включает в себя только поддержку HTTP.

В распределенных системах SOAP используется для обеспечения взаимодействия разных уровней. На сегодняшний день существует множество технологий и протоколов, позволяющих без труда соединять элементы распределенных систем между собой. Одна из наиболее известных технологий – DCOM, позволяющая эффективно осуществлять RPC-вызовы, передавать и принимать данные, распределять нагрузку между несколькими back-end серверами. Однако у систем, построенных на DCOM, есть очень важный недостаток, затрудняющий взаимодействие уровня представления и уровня бизнес-логики через Internet. Хотя DCOM-приложения могут использовать TCP/IP для передачи вызовов RPC, большинство современных сетевых экранов будут запрещать передачу таких пакетов из соображений безопасности. Конечно, с помощью утилиты DCOMCNFG можно настроить DCOM на использование любого порта в диапазоне от 1024 до 65535. Но при изменении настроек одного из промежуточных файрволлов DCOM может перестать работать. Можно сказать, что DCOM является доминирующей технологией для обмена информацией и передачи вызовов в пределах корпоративной локальной сети, но при выходе за ее пределы DCOM приносит большое количество хлопот, связанных с настройкой портов, файрволлов и т.д.

ПРИМЕЧАНИЕ Чтобы расширить сферу применения DCOM, Microsoft выпустила COM Internet Services (CIS). CIS использует специальный “туннельный” TCP-протокол, позволяющий DCOM-приложениям осуществлять RPC-вызовы через порт 80. На стороне сервера находится ISAPI-расширение, перехватывающее запросы, идущие на порт 80, и перенаправляющее их дальше для обработки с помощью обычного RPC. Особенностью CIS является то, что только начальное “рукопожатие” клиента с сервером происходит в соответствии с протоколом HTTP, остальной трафик не является HTTP (сделано это, видимо, из соображений эффективности). Поэтому, несмотря на использование 80-го порта, CIS не устраняет проблему сетевых экранов, которые могут запретить передачу “подозрительных” пакетов.

Альтернативой DCOM при построении распределенных систем может служить использование Web-интерфейса на основе ASP. В таких системах от клиента ничего не требуется, кроме наличия браузера, способного соединиться с корпоративным Web-сервером. Для передачи запроса от клиента к серверу можно применить, например, метод POST для HTML-формы, а обработка запроса будет происходить уже на серверной стороне. Несмотря на популярность такого подхода, у него есть недостатки – состав передаваемой информации, а главное, способ ее передачи в методе POST специфичны для конкретного приложения. А если на уровне представления необходим полноценный пользовательский интерфейс Windows-приложения, не миновать проблем.

Как в этом случае может быть построено взаимодействие клиента с сервером? И, наконец, как быть, если необходимо обеспечить поддержку не только HTTP, но, например, SMTP или MSMQ (для асинхронного взаимодействия)? Эти задачи можно решить следующим образом:

  • Преобразовать вызов в текстовое представление с сохранением информации обо всех параметрах и их значениях.
  • Передать текст на сервер по HTTP, SMTP и т.д.
  • Интерпретировать текстовое сообщение на сервере и осуществить вызов некоторого метода.
  • Преобразовать out-параметры или информацию об ошибке, возвращаемые методом, в текстовое представление.
  • Передать текст клиенту по HTTP, SMTP и т.д.
  • Интерпретировать результат.

Реализуя описанный сценарий, можно спроектировать свой собственный формат передачи параметров и информации о вызове, или использовать SOAP, тем самым снижая затраты на разработку, документирование и сопровождение системы.

Необходимо упомянуть о еще одном достоинстве протокола SOAP – он нейтрален к платформе, т.е. не накладывает ограничений на платформы, которые используются клиентом и сервером. Запрос клиента, работающего под управлением Windows 98, может быть обработан сервером под управлением Unix.






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.