Учебное пособие по теме "Протокол SOAP"

2.10. Протокол SOAP, применение и преимущества

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

Подобное деление вызвано тем, что в общем виде SOAP создает свою виртуальную транспортную среду. SOAP-сообщение способно следовать по маршруту, содержащему несколько узлов, каждый из которых может вносить в него изменения или как-то еще его обрабатывать. Статус этих изменений отражается в блоках заголовка сообщения. Заголовок представляет собой механизм расширения, при помощи которого можно передавать в SOAP-сообщении данные, не являющиеся собственно основной рабочей нагрузкой (к примеру: директивы и/или информация о контексте, необходимые для обработки сообщения). Это позволяет расширять сообщения специфическим для конкретного приложения способом. Второй большой и обязательный раздел - "тело", в нем содержится XML-блок с информацией, которая должна быть доставлена конечному адресату. Оба этих раздела содержатся внутри конверта.

SOAP является простым "мостиком", обеспечивающим взаимодействие приложений: в него заложена парадигма однонаправленного обмена сообщениями, без поддержки сохранения состояния этого обмена. Потому для создания систем со сложными последовательностями обмена информацией требуются дополнительные средства, обеспечивающие пересечение границ брандмауэров, многоузловую маршрутизацию, гарантированную доставку. Однако SOAP задает инфраструктуру, в рамках которой частная для каждого приложения инфраструктура может быть описана в относительно унифицированной форме. Кроме того, в стандарте изложены общие принципы, по которым может быть осуществлена привязка SOAP-сообщений к абстрактному транспортному протоколу (необходимая для этого информация будет содержаться в заголовке сообщений), описана общая схема создания SOAP-оболочек для RPC-ориентирированных интерфейсов (удаленный вызов процедур), приведены конкретные механизмы (в первую очередь способы возврата сообщений о сбоях), а также зафиксирована конкретная реализация способа оформления сообщений SOAP в качестве содержимого команд GET и POST протокола HTTP.

Примечание 1. Привязка к определенному транспортному протоколу позволяет сократить объем программирования, необходимого для написания SOAP-ориентированного приложения, а также уменьшить объем трафика. Иначе говоря, в точке отправления из исходного сообщения изымается определенная информация и размещается средствами транспортного протокола в его пакетах, а в точке получения сообщение реконструируется в исходном виде.

Например, протокол HTTP уже имеет средства для обеспечения корреляции сообщений (т. е. средства логического связывания запроса и ответа), и программисту не нужно заботиться о корреляции запрос - ответ. Привязка к HTTP также позволяет сделать Web-сервисы более соответствующими общему стилю WWW и четче передавать сообщения об ошибках. Скажем, сервис класса "только для чтения" может идентифицироваться в Web некоторым адресом URI и по команде GET, не имеющей параметров, выдавать уже SOAP-отформатированную информацию. Но такая привязка действительна только между двумя соседними узлами, поддерживающими транспортный протокол.

Примечание 2. Группа спецификаций SOAP 1.2 сегодня содержит две основные части (SOAP 1.2 Part 1: Messaging Framework и SOAP 1.2 Part 2: Adjuncts), три вспомогательных документа (SOAP 1.2 Message Normalization, SOAP 1.2 E-mail Bindings, Specification Assertions and Test Collection) и "Введение" (SOAP 1.2 Primer).

Типичное SOAP-сообщение (пример из SOAP Version

1.2 Message Normalization)

WSDL (Web Services Description Language) - описывает сервисы в виде неких абстрактных ресурсов, способных принимать на вход документы определенных типов и инициировать отправление документов других типов. WSDL определяет сервис с двух точек зрения: абстрактной и конкретной. На абстрактном уровне сервис задается в терминах посылаемых и принимаемых им сообщений, которые описываются средствами XML Schema в виде, независимом от конкретного транспортного протокола. На конкретном уровне определяются привязки к транспортным форматам и точкам физического размещения.

Согласно этому стандарту WSDL-описание сервиса состоит из пяти частей.

1. При помощи нотаций XML Schema описываются типы данных, используемые сервисом (раздел <wsdl:types>).

2. Задается описание входных WSDL-сообщений (<wsdl:message>), состоящих из элементов, имеющих типы, описанные в <wsdl:types>.

3. Описываются порты (<wsdl:portType>) - их имена, названия и спецификации допустимых по ним операций (<wsdl:operation>). Каждая такая операция характеризуется тройкой сообщений - входным, выходным и сообщением о сбое. В стандарте задано четыре типа операций - однонаправленные, запрос - ответ, подтверждение - ответ и уведомление (две последние являются инверсиями двух первых). Соответственно, WSDL-порт может быть однонаправленным и двунаправленным. Информирование о сбоях - функция двунаправленных портов.

4. Задается привязка (<wsdl:binding>) к транспортному протоколу. Здесь происходит переход от логической модели данных к реальной физической модели, т. е. тому, как именно передаются данные по SOAP. Для описания перехода используются так называемые SOAP-расширения WSDL (определены также привязки WSDL к HTTP и MIME). С помощью этих расширений можно, например, просто указать серверу, что для формирования реального SOAP-документа в его тело требуется скопировать тела описанных WSDL-сообщений. Здесь же задается адрес сервиса в WWW.

5. Группируются описания сервиса (<wsdl:service>) - сводятся вместе имя сервиса, данные о портах, привязках и человеко-читаемый комментарий о целях сервиса. С помощью этого раздела сервис можно привязать к нескольким альтернативным зеркалам.

Примечание. Группа спецификаций WSDL 2.0 состоит из трех основных документов - WSDL Part 1:Core language ("Основной язык"), WSDL Part 2: Message exchange patterns ("Шаблоны обмена сообщениями"), WSDL Part 2: Bindings ("Привязки"). Имеется также неоконченное "Введение".

UDDI (Universal Description Discovery & Integration)

Вместе с SOAP и WSDL образует тройку базовых стандартов Web-сервисов. Представляет собой стандарт на внутреннее устройство и внешние интерфейсы базы данных (репозитория), хранящей описания сервисов. Задает модель данных и стандартизует API, в том числе Web-сервисный. Все описания в БД хранятся в виде XML-записей.

Последняя версия (3.01) обеспечивает репликацию репозиториев со сложными моделями их подчиненности друг другу, построение репозитория из нескольких узлов (и репликацию данных между ними), глобальную уникальность записей и ключей, API публикации описаний и подписки на изменения, средства обеспечения целостности данных, интернационализации записей, шифрования содержимого.

В то время как версия UDDI 2.0 предназначалась для поддержки каталогов электронного бизнеса, версия 3.0 ориентирована и на внутрикорпоративное использование - для построения корпоративных систем в рамках идеологии Service Oriented Architecture. Поэтому она допускает создание реестров нескольких типов (общедоступный, частный и с разделяемым доступом).

Пример репликации реестров UDDI

Для упрощения поиска UDDI-реестр предлагает стандартные механизм для классификации, каталогирования, поиска и управления web-сервисами:

1) он позволяет задать разные таксономии (классификаторы) в одном реестре, т. е. один элемент может быть одновременно классифицирован по-разному в рамках разных логических моделей;

2) UDDI позволяет публикаторам информации расширять число способов классифицирования любого элемента. При этом есть возможность проверки соотвествия данных элемента требованиям классификатора;

3) UDDI Inquiry API позволяет указывать в параметрах поиска классификатор и классификационные признаки, а также проводить соединение данных разных поисковых запросов.

Примечание. UDDI опирается на WSDL и XML Schema.

Оптимизации базовых спецификаций

В стандартном виде SOAP оказался очень неэффективной с точки зрения потребления вычислительных ресурсов технологией. Например, сообщение EDI (electronic data interchange - электронный обмен данными), описывающее данные накладной, имеет длину около 80 байт, в то время как аналогичное XML-сообщение уже 1,5 Кб. SOAP добавит к нему заголовок и теги разметки, что еще больше увеличит его размер. Если в теле SOAP-сообщения оказываются мультимедийные данные, то ситуация становится совсем катастрофической.