Введение в SOAP, WSDL и UDDI

Последние несколько лет предприятия взаимодействовали с помощью специальных решений, использовавших базовую инфраструктуру Internet. Сегодня, однако формируются Web-службы, обеспечивающие систематическую и расширяемую платформу взаимодействия между приложениями, основанную на уже существующих Web-протоколах и открытых стандартах XML.

К примеру, вы хотите приобрести путевку в «электронной» турфирме. Чтобы выяснить, кто предлагает лучшие цены, фирма должна опросить несколько агентств; каждое из них, скорее всего, для определения расценок и бронирования использует разные, несовместимые приложения. Web-службы призваны упростить этот процесс за счет введения стандартизованного механизма описания, поиска и взаимодействия с Internet-приложениями. Это позволит турфирме использовать единую платформу Web-служб для подбора и бронирования элементов вашего турпакета, а также арендовать с «поклиентской» оплатой финансовую службу на базе Internet, благодаря которой деньги будут быстро передаваться между вашим счетом, счетом турфирмы и поставщиками.

Платформа Web-служб разделяется на три части — коммуникационные протоколы, описания служб и поиск услуг. Для каждой разработаны соответствующие спецификации.

  • Простой протокол доступа к объектам Simple Object Access Protocol (SOAP, www.w3.org/2000/xp), который поддерживает связь между Web-службами.
  • Язык Web Services Description Language (WSDL, www.w3.org/TR/wsdl.html), который дает формальное, воспринимаемое компьютером описание Web-служб.
  • Каталог Universal Description, Discovery, and Integration (UDDI, www.uddi.org), который представляет собой регистр описаний Web-служб.

Коммуникации: SOAP

Сегодня универсальным языком для кодирования данных, который свободен от зависимости от конкретных платформ и пригоден для международного обмена, признан XML. Создание протокола коммуникаций, поддерживающего XML, — естественное решение для Web-служб.

SOAP первоначально был создан в Microsoft, а позже доработан совместно с компаниями Developmentor, IBM, Lotus и UserLand. Протокол SOAP на базе XML предназначен для передачи сообщений и удаленных вызовов процедур (remote procedure call, RPC). Вместо того, чтобы вводить новый транспортный протокол, SOAP работает с уже существующими, такими как HTTP, SMTP и MQSeries.

Сообщение SOAP имеет очень простую структуру: элемент XML с двумя элементами-потомками, один из которых задает заголовок, а другой — тело сообщения. Заголовок и элементы тела сообщения содержат произвольный текст на XML. На рис. 1 показана структура конверта SOAP.

Рис. 1. Структура сообщения SOAP. Элементы-потомки конверта (envelope) содержат заголовок сообщения и элементы тела сообщения

Помимо базовой структуры сообщения спецификация SOAP определяет модель, предписывающую получателям, как им следует обрабатывать сообщения SOAP. Модель сообщения также включает в себя «акторы» (actor, действующий субъект), указывающие, кто должен обрабатывать сообщение. Допускается определение акторов с несколькими посредниками, каждый из которых обрабатывает предназначенную для него часть сообщения и пропускает дальше остальные.

Обмен сообщениями с помощью SOAP

На базовом уровне функциональности можно использовать SOAP как простой протокол обмена сообщениями. В данной статье мы проиллюстрируем спецификации Web-служб на простом примере из индустрии путешествий. Наш турист, Джо, планирует улететь сегодня дневным рейсом и хочет получить информацию о своем рейсе по Сети. Предположим, Джо известно о службе электронной регистрации на авиарейсы, знает он и формат кодирования билета. Это позволяет ему без труда создать и направить в эту службу сообщение SOAP.

Рис. 2. Сообщение SOAP содержит «электронный билет». Заголовок SOAPAction указывает цель сообщения. В реальной жизни сообщение может содержать дополнительную информацию, в том числе координаты отправителя

На рис. 2 приведено такое сообщение SOAP, передаваемое с помощью протокола HTTP. Заголовки HTTP расположены над элементом SOAP:Envelope. Заголовок POST показывает, что сообщение использует HTTP POST, браузеры которой также поддерживают передачу форм. После заголовка POST указан дополнительный заголовок SOAPAction, указывающий предполагаемую цель сообщения. Если на этот запрос будет получен HTTP-ответ, то он будет иметь тип text/xml, как декларирует заголовок Content-Type, и может содержать сообщение SOAP с данными ответа. Как альтернативный вариант, получатель может доставить ответное сообщение позже (асинхронно).

Заметим, сообщение на рис. 2 не имеет заголовков SOAP; тело сообщения просто содержит XML-представление «электронного билета», где указано имя пассажира и данные о рейсе. В реальном B2B-сценарии в сообщении, без сомнения, будет множество заголовков с дополнительной информацией.

Удаленный вызов процедур с помощью SOAP

Чтобы использовать SOAP для удаленного вызова процедур, необходимо определить протокол RPC, в том числе, указать:

  • значения каких типов могут циркулировать между представлением SOAP (XML) и представлением приложения (например, класс Java для билета);
  • где содержатся различные части RPC (данные об объекте, название операции и параметры).

Спецификация схем XML задает стандартный язык для определения структуры и типов данных XML-документа. Задавая такой тип, как integer, или составной тип (например, запись с двумя полями integer и string), схема XML задает стандартный способ записи типа. Чтобы поддержать передачу значений определенного типа, SOAP принимает систему типов, основанную на системе типов в схеме XML, и определяет ее каноническое кодирование в XML. Следуя такому подходу, можно закодировать структурированные данные любого типа. Аргументы и результаты RPC также представляются с помощью этого кодирования.

Скажем, Джо хочет узнать, не откладывается ли его рейс. Ему известно, что в службе электронной регистрации есть функция GetFlightInfo, которая имеет два аргумента — цепочку символов, содержащую название авиакомпании, и целое, равное номеру рейса. Эта функция возвращает структурированное значение (запись) с двумя полями — номер выхода и статус рейса. В данном случае Джо может получить статус рейса, направив в службу сообщение HTTP POST с «конвертом», аналогичным тому, как показано на рис. 3.

Рис. 3. Вызов SOAP RPC. Чтобы выяснить, отправляется ли рейс по расписанию, Джо посылает цепочку, содержащую название авиакомпании и целое, равное номеру рейса

Вызов функции GetFlightInfo в нем — это элемент XML с атрибутами, которые содержат информацию о кодировании (обратите внимание на ссылку на схему XML). Потомки этого элемента — аргументы вызова метода: airlineName и flightNumber. Их типы определены в атрибутах типа, где xsd указывает на определения схемы XML. Получая сообщение, реализация SOAP преобразует XML-тексты UL и 506 в цепочку символов и целое, а затем вызывает метод GetFlightInfo с этими аргументами.

Рис. 4. Ответ SOAP RPC. Турслужба посылает ответ на запрос Джо в виде структурированного значения, содержащего подзначения в виде номера выхода на посадку и статуса рейса

На рис. 4 приведен ответ на данный запрос; он содержит структурированное значение, компонентами которого является номер выхода и статус рейса. Джо повезло: он улетит вовремя.

Описание: WSDL

Общаться на универсальном языке с базовым набором выразительных средств не всегда удобно. Что касается Web-служб, то SOAP предлагает базовые средства коммуникации, не сообщая о том, какими сообщениями следует обменяться, чтобы с успехом взаимодействовать со службой. Эту роль выполняет WSDL, формат XML, разработанный компаниями IBM и Microsoft для описания Web-служб как набора узлов взаимодействия, способных обмениваться сообщениями из определенного набора. Другими словами, документ WSDL описывает интерфейс Web-службы и предлагает ее пользователям точку контакта.

Первое обращение, GetFlightInfo, реализуется с помощью модели SOAP RPC; этот вызов получает в качестве входных параметров название авиакомпании и номер рейса, а возвращает составной (или структурированный) тип данных с информацией о рейсе. Второй вызов, CheckIn, следует «чистой» модели обмена сообщениями SOAP; он рассчитан на получение XML-представления электронного билета.

Полное описание службы средствами WSDL содержит два блока информации: описание службы на уровне приложений, или абстрактный интерфейс, и зависящие от протокола специфические детали, которые должны учитывать пользователи, обращаясь к службе в определенных узлах. Это разделение учитывает тот факт, что сходная прикладная функциональность службы зачастую развертывается на различных концевых точках с слегка различающимися деталями протокола доступа. Разделение описания этих двух аспектов помогает WDSL представить схожую функциональность возможно различающихся узлов.

Абстрактное описание

WSDL определяет абстрактное описание службы в терминах сообщений, обмен которыми происходит при обращении к службе. У этого абстрактного интерфейса три основных компонента: словарь, сообщение и взаимодействие. Соглашение о словаре — основа любых коммуникаций. WSDL использует внешние системы типов для предоставления определений типов данных, используемых для обмена информацией. WSDL может поддерживать любую систему типов, однако большинство служб работает с XSD. На рис. 5 приведены два типа данных, определенных в XSD (string и int), и два типа данных, определенных во внешней схеме (FlightInfoType и Ticket). WSDL разрешает использование внешних определений XSD посредством элемента «импорт», указывающего их местонахождение.

Рис. 5. Абстрактное описание WSDL. В этом фрагменте показаны типы данных string и int, определенные в XSD, и два других типа данных, определенные во внешней схеме: FlightInfoType и Ticket, которые, как предполагается, ранее были импортированы в файл WSDL

WSDL определяет элементы message как совокупность частей, каждая из которых описывается посредством типов XSD или элементами из предопределенного словаря. Сообщения предоставляют абстрактное типизированное определение данных, пересылаемых в службу и из нее. Пример на рис. 5 содержит три сообщения, которые могут появиться во время обращения к Web-службам. Сообщение GetFlightInfoInput состоит из двух частей: airlineName, представляющее собой строку XSD, и flightNumber — целое XSD. Два других сообщения, GetFlightInfoOutput и CheckInInput, имеют только по одной части. Элементы operation и portType составляют сообщения для определения взаимодействий. Каждая операция задает шаблон обмена сообщениями, который поддерживает Web-служба, предоставляя пользователям доступ к определенному базовому фрагменту функциональности. Операция — просто совокупность сообщений, помеченных как input, output или fault, указывая, какая часть конкретного сообщения используется при взаимодействии.

Элемент portType представляет собой набор операций, поддерживаемых узлом. В нашем примере AirportServicePortType описывает две операции: запрос-ответная операция GetFlightInfo, которая рассматривает сообщение GetFlightInfoInput как входной параметр и возвращает сообщение GetFlightInfoOutput в качестве ответа, и однонаправленная операция CheckIn, воспринимающая сообщение CheckInInput в качестве входного параметра.

Информация о связывании

До сих пор все элементы, которые мы обсуждали, описывали функциональность службы уровня приложений. Завершая описание взаимодействия клиент-служба, необходимо остановиться еще на трех вопросах.

  • Какой протокол коммуникаций используется (например, SOAP поверх HTTP).
  • Как выполнить конкретные взаимодействия со службой с его помощью.
  • Где находятся конечные пункты коммуникаций (сетевой адрес).
Рис. 6. Конкретное связывание WSDL. Как показывает этот фрагмент, GetFlightInfo — это взаимодействие в виде SOAP RPC, а CheckIn — взаимодействие, связанное исключительно с передачей сообщений, которое использует XSD для описания передаваемых XML-данных

Элементы связывания WSDL дают ответ на первые два вопроса, информируя о протоколе коммуникаций и спецификации формата данных для portType. Короче говоря, элементы связывания сообщают, как возникает данное взаимодействие по конкретному протоколу. На рис. 6 показан фрагмент из нашего примера. Связывание описывает, как использовать SOAP для доступа к службе travelservice. В частности, документ WSDL показывает, что:

  • GetFlightInfo - это взаимодействие в стиле RPC для SOAP, при котором при всех обменах сообщениями используется стандартное кодирование SOAP;
  • CheckIn - это взаимодействие, связанное исключительно с передачей сообщений ("ориентированное на документы" в терминологии WSDL), при котором тело сообщения SOAP содержит закодированное сообщение без дополнительного кодирования типов, т.е. использует XSD для буквального описания передаваемого XML.

Все, что остается, — это определить, «где» можно получить доступ к этой комбинации абстрактного интерфейса и протокола с детальной информацией об организованных данных (связывание). Элемент port описывает узел как объединение связывания и сетевого адреса. В нашем примере один порт описывает узел, который обрабатывает запросы SOAP для службы travelservice.

Использование WSDL

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

Поиск: UDDI

Спецификация Universal Description, Discovery, and Integration (UDDI) предлагает пользователям унифицированный и систематизированный способ поиска поставщиков услуг через централизованный реестр, своеобразный автоматизированный электронный «телефонный справочник» Web-служб. Реестр UDDI Business Registry (UBR), доступ к которому можно получить посредством браузера, был создан уже вскоре после публикации спецификации. Несколько отдельных компаний и отраслевых групп начали применять «частные» каталоги UDDI для интеграции и упрощения доступа к собственным службам.

UDDI предлагает две основные спецификации, которые определяют структуры и операции над реестром служб:

  • определение информации, которую необходимо предоставить о каждой службе, и способ ее кодирования;
  • библиотека функций, которая описывает, как можно получить доступ к содержащейся в реестре информации и обновить ее.

Доступ к реестру осуществляется посредством стандартного API-интерфейса SOAP. Остановимся на запросах к реестру; это даст нам представление о том, как работает реестр.

Структура

UDDI имеет дело с тремя типами информации о Web-службах:

  • данные для "белых страниц" включают в себя название и контактную информацию;
  • данные для "желтых страниц" позволяют классифицировать службы в зависимости от рода деятельности и типов услуг;
  • данные для "зеленых страниц" содержат техническую информацию о службах.
Рис. 7. Упрощенная структура businessEntity. Этот элемент предлагает типичную для «белых страниц» информацию, в том числе контактную информацию и базовое описание служб

Реестр UDDI строится вокруг фундаментальных объектов, которые описывают компании и предоставляемые ими службы. Элемент businessEntity, показанный на рис. 7, предоставляет стандартную информацию для «белых страниц», в том числе идентификаторы (налоговые идентификаторы, номера социального страхования и т.д.), контактную информацию и простое описание. Каждая запись о компании включает в себя один или несколько элементов businessService (см. рис. 8), представляющих предлагаемые этой компанией службы. Записи о компании и о службе могут задавать признак categoryBag, используемый для классификации компании или службы.

Рис. 8. Упрощенная структура businessService. Запись о компании может содержать подобную структуру для каждой предоставляемой ею службы. Структура tModelInstanceDetails предлагает техническое описание службы (информация для «зеленых страниц»)

Рис. 7 и 8 отражают важный аспект UDDI. Уникальные ключи идентифицируют каждую запись (компании, службы и т.д.) и могут быть связаны перекрестными ссылками. Эти длинные шестнадцатеричные ключи (universally unique identifier, UUID) генерируются при формировании записи (в нашем случае, при регистрации компании). Так, атрибут businessKey уникальным образом указывает на запись о компании, а атрибут serviceKey идентифицирует службу. Помимо понятного человеку описания, имени и категории, запись о службе содержит список шаблонов bindingTemplates, которые кодируют техническую информацию о доступе к службе. Каждый шаблон связывания представляет точку доступа к службе. Предполагается, что одна и та же служба может быть предоставлена в различных узлах с разными техническими характеристиками.

Технические описания

Более внимательное рассмотрение шаблонов связывания позволяет выявить подробности того, как UDDI поддерживает описания компании и службы, использующие произвольную внешнюю информацию (т.е. информацию, не определяемую самим UDDI). В первую очередь — это адрес узла, где можно обратиться к данной службе. Это может быть адрес электронной почты, URL или даже телефонный номер.

Самое интересное поле, однако — это tModelInstanceDetails, в котором представлено техническое описание службы (информация «зеленых страниц»). Это поле содержит список ссылок на технические спецификации, которым соответствует служба. Поставщик услуг регистрирует требуемые технические спецификации в каталоге, где присваивается соответствующий уникальный ключ-идентификатор. UDDI представляет каждую зарегистрированную техническую спецификацию посредством особой информационной сущности, называемой tModel. Узлы, поддерживающие спецификацию, могут просто добавить соответствующую ссылку на список tModelInstanceDetails.

Например, предположим, что мы хотим зарегистрировать документ WSDL как tModel. Предполагая, что индустрия путешествий определяет стандартные интерфейсы и связывания WSDL для электронной регистрации и извлечения информации о рейсах, сначала мы создадим tModel как показано на рис. 9, чтобы предоставить эти определения WSDL. Узлы, которые реализуют данные интерфейсы, могут затем включать соответствующие экземпляры tModel в свои списки с подробной уточняющей информацией.

Рис. 9. Пример определения tModel. Чтобы зарегистрировать документ WSDL в качестве tModel, мы принимаем стандартные определения электронной регистрации на рейс и извлечения информации о рейсе и создаем tModel для представления этих определений WSDL
Классификация

Эффективный поиск компаний и служб определенного типа зависит от способности классифицировать имеющиеся в каталоге записи в соответствии со схемой классификации, или систематикой. Фактически, в любой реальной ситуации, чтобы классифицировать службу, которую мы ищем, нам, как правило, необходимо несколько фрагментов информации, таких как географическое положение либо тип отрасли или продукта.

Чтобы определить систематику, каждый классификатор сам регистрируется как tModel в каталоге UDDI, а затем кодируется в виде пар название-значение. В UDDI существует три стандартные систематики, которые также зарегистрированы в UBR:

  • отраслевой классификатор, соответствующий систематике North American Industry Classification System (NAICS);
  • классификатор продуктов и услуг, соответствующий систематике Universal Standard Products and Services Code System (UNSPSC);
  • географический классификатор, соответствующий систематике International Organization for Standardization Geographic taxonomy (ISO 3166).

Используя классификаторы, мы можем обратиться с запросом к каталогу UDDI в поисках конкретных типов служб. В нашем случае мы можем искать туристические службы, которые предлагают возможность составления электронных запросов и работают в том регионе, где проживает Джо. Найдя службу в UDDI, мы можем извлечь соответствующее ей описание WSDL и выяснить, как взаимодействовать с ней посредством SOAP.

Что дальше?

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

Зачем нужно создавать дополнительные средства, когда существуют такие технологии, как Secure Multipurpose Internet Mail Extensions (S-MIME), HTTP Secure (HTTPS) и Kerberos? Все дело в том, что есть разница между «сквозной» защитой и защитой «случайных» взаимодействий. Бизнес-сообщения, как правило, инициируются внутри какого-то подразделения одного предприятия и отправляются в определенное подразделение другого предприятия. Такие механизмы, как Secure Sockets Layer, прекрасно подходят для защиты поддержки конфиденциальности прямого соединения между двумя компьютерами, но они бесполезны, если сообщение будет путешествовать более чем по одному соединению. Вот почему необходима защита на уровне SOAP.

Модель защиты определяется как набор дополнительных спецификаций. Например, предложение SOAP Security Extensions: Digital Signatures (www.w3.org/TR/SOAP-dsig/) описывает, как в сообщениях SOAP можно оформить цифровую подпись.

Важный аспект реальной интеграции предприятий — надежность протокола коммуникаций. И опять-таки, мы можем использовать надежный транспорт, такой как Reliable HTTP (HTTPR), но сценарий передачи с несколькими промежуточными пунктами требует, чтобы надежность была определена на уровне SOAP.

Наконец, сложные взаимодействия между компаниями требуют поддержки функциональности более высокого уровня. В частности, необходимы описания параметров качества обслуживания, которые предлагают узлы. С другой стороны, взаимодействия между компаниями, как правило, длительны и включают в себя обмен множеством транзакций между партнерами. Чтобы развертывать и эффективно использовать такие виды служб, нужны стандартизованные и систематизированные средства представления бизнес-процессов, службы, сохраняющие состояние, а также композиции служб. Эту задачу призваны решать, в частности, такие предложения, как Web Services Flow Language (www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf) и X-Lang (www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm).

Франциско Курбера (curbera@us.ibm.com) - научный сотрудник группы компонентных систем исследовательского центра IBM T.J. Watson Research Center. Несколько лет занимается вопросами использования языков разметки при разработке приложений и создания программных компонентов. Является соавтором спецификаций WSDL и WSFL.

Мэттью Дафлер (duftler@us.ibm.com) - программный инженер группы компонентных систем того же исследовательского центра. Один из авторов Apache SOAP и соруководитель группы, разрабатывавшей JSR110, Java API для WSDL.

Рания Халаф (rkhalaf@us.ibm.com) - программный инженер группы компонентных систем того же исследовательского центра.

Уильям Наги - программный инженер группы компонентных систем того же исследовательского центра. К области его научных интересов относится разработка распределенных служб, а также инфраструктура, необходимая для их использования, и поддержки. Сейчас, в основном, занимается Web-службами и принимает участие в разработке IBM Web Services Gateway и спецификации WS-Inspection.

Нирмал Мукхи (nmukhi@us.ibm.com) - научный сотрудник группы компонентных систем того же исследовательского центра. Один из разработчиков Web Services Invocation Framework.

Санджива Вираварана (sanjiva@us.ibm.com) - научный сотрудник группы компонентных систем того же исследовательского центра. Один из авторов спецификаций WSDL и WSFL, а также Apache SOAP, WSTK, WSDL Toolkit, WSIF и WSGW.

Francisco Curbera, Matthew Duftler, Rania Khalaf, William Nagy, Nirmal Makhi, Sanjiva Weerawarana. Unraveling the Web Services Web. An Introduction to SOAP, WDSL, and UDDI. IEEE Internet Computing, March/April 2002. All rights reserved, 2002, IEEE Computer Society. Reprinted with permission.

Ресурсы

Новости, статьи и информация о программном обеспечении Web-служб www.webservices.org

Сайт IBM developerWorks (руководства, статьи, форумы и инструментарий для Web-служб) www-106.ibm.com/developerworks/webservices

Web-службы Microsoft www.gotdotnet.com/team/XMLwebservices

Семинар W3C, посвященный Web-службам www.w3.org/2001/01/WSWS

Спецификация W3C SOAP www.w3.org/2000/xp

Спецификация WSDL 1.1 www.w3.org/TR/wsdl.html

UDDI www.uddi.org

SOAP Digital Signatures Proposal www.w3.org/TR/SOAP-dsig/

Web Services Flow Language www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf

X-Lang www.gotdotnet.com/team/xml_wsspecs/xlang-c/