Wsdl soap что это
Спецификация языка WSDL 1.1
Введение
Эти элементы будут детально описаны в следующем разделе. Важно отметить, что WSDL не вводит нового языка определения типов. WSDL признает потребность в развитом механизме типизации для описания формата сообщений и поддерживает спецификацию XML Schema (XSD) как каноническую систему типизации. Однако это вовсе не означает, что выбор грамматики ограничивается только одной XSD — использование других грамматик допустимо посредством использования механизма расширения.
Кроме того WSDL определяет общий механизм связывания. Он используется для ассоциации специфичных параметров протокола или формата и структуры данных с абстрактными сообщениями, операциями или конечными точками, что позволяет переиспользовать абстрактные определения.
В дополнение к описанию самого механизма определения служб эта спецификация даёт введение в расширения связывания (binding extension) для следующих протоколов и форматов сообщений:
Несмотря на то, что указанные выше расширения описываются в этом документе и наслаиваются на описание ядра механизма определения служб, никто не запрещает использовать другие расширения связывания вместе с WSDL.
Пример WSDL-документа
Соглашение об обозначениях
В этом документе используются следующие пространства имен с префиксами:
В текущей спецификации используется свободный синтаксис для описания XML-грамматики WSDL:
Определение службы
Структура WSDL-документа
Для определения службы используются шесть основных XML-элементов:
Эти элементы будут детально описаны в разделах 2.2-2.7. В завершение этого раздела будут описаны устанавливаемые WSDL правила именования документов, включения (импорта) документов с определениями, использования расширений и добавления контекстной документации.
Именование и включение документов
WSDL позволяет ассоциировать пространство имён (namespace) с адресом размещения документа (location) с помощью конструкции импорта:
Адресация определений из подключенного документа выполняются по QName. Можно обращаться к следующим определениям импортированного документа:
Области имён определений разных видов не пересекаются — так, например, допустимо существования порта и сообщения с одинаковыми именами, но имена однотипных определений должны быть уникальны в рамках WSDL-документа.
Разрешение QName в WSDL выполняется аналогично их разрешению, описанному в спецификации XML Schema.
Стиль составления документа
Использование элемента import позволяет разнести различные элементы определения службы по разным документам. Хорошим подходом является разделение определений в соответствии с их уровнем абстракции, что позволяет создавать более структурированные, следовательно проще читаемые, понимаемые и поддерживаемые определения служб. К тому же подход способствует переиспользованию определений всех уровней.
Доработаем определение службы из первого примера — разнесём его по трём документам: определение базовых типов данных, абстрактное определение службы и связывание абстрактного определения со специфичными параметрами формата сообщений и транспорта.
Возможности механизма импорта не ограничиваются работой с видами определений, явно установленными этой спецификацией. Любые другие определения, созданные посредством механизма расширения, могут быть переиспользованы подобным образом.
Расширение языка и связывание
Термин «связывание» в WSDL означает ассоциацаю параметров транспорта и формата данных с абстрактными определениями — сообщениями, операциями, типами портов. Под определёнными спецификацией стандартными элементами разрешается размещать элементы расширения, представляющие специфичные технологии. Как правило, эти точки расширения используются для задания параметров транспортного протокола и формата сообщений, однако их область применения этим не ограничивается. Пространство имён элементов расширения должно быть отличным от пространства имён WSDL.
Механизм расширения позволяет поддержать новые сетевые протоколы без внесения изменений в базовую спецификацию WSDL. Рекомендуется, чтобы спецификации этих протоколов и форматов также содержали определение необходимых WSDL-расширений.
Документирование
Элемент types содержит определения типов данных, соответствующих сообщениям. С целью унификации WSDL использует XSD как встроенную систему типизации и рассматривает ее как каноническую и основную.
Система типизации XSD может быть использована для определения типов данных в сообщениях независимо от того, будут ли сообщения передаваться в формате XML, или в каком-либо специфическом формате — в любом случае XSD-схема может быть использована для проверки структуры сообщений. Возможны случаи, когда для одного абстрактного сообщения имеются различные связывания, либо одно связывание, но не имеющее своей распространённой системы типизации. В этих случаях рекомендуется придерживаться следующих правил при описании абстрактных типов данных с помощью XSD:
Необоснованно ожидать, что в настоящем и будущем для определения типов данных будет использоваться только одна грамматика. Поэтому WSDL позволяет подключать другие системы типизации с помощью элементов расширения. Элемент расширения может быть добавлен под элемент types — он будет служить для идентификации системы типизации и для организации контейнера для определений типов. Роль такого элемента аналогична элементу schema языка XML Schema.
Сообщение
Другие атрибуты типизации сообщений могут быть определены в пространстве имён, отличном от WSDL. Элементы расширения связывания также могут использовать атрибуты типизации.
Атрибут name элемента message должен содержать уникальное имя сообщение в рамках текущего WSDL-документа. Атрибут name элемента part — уникальное имя части в рамках сообщения.
Часть сообщения
— это гибкий механизм для описания абстрактного логического содержимого сообщения. Связывание может ссылаться на часть по имени для указания дополнительных специфичных параметров. Например, при определении сообщения для RPC часть может соответствовать одному аргументу вызываемой процедуры. Однако часть — абстрактное определение, и для работы с её реальным значением придётся обращаться к связыванию.
Если сообщение состоит из нескольких цельных компонентов, то в WSDL его можно определить как состоящее из нескольких частей. Например, следующее сообщение состоит их платежного ордера и накладной:
Однако если содержимое сообщения достаточно сложное, то определение типа можно полностью перенести на уровень системы типизации. В следующем примере сообщение содержит платежный ордер, либо набор накладных:
Абстрактные / конкретные сообщения
Определение сообщения всегда рассматривалось как абстрактное определение содержимого. Связывание сообщения описывает соответствие между абстрактным содержимым и конкретным форматом / представлением. Однако в некоторых случаях, абстрактное определение может очень близко, или даже однозначно, соответствовать какому-либо формату. Связывание для такого формата поставляет мало дополнительной информации, либо не поставляет совсем. Однако связывание для того же сообщения, но для другого формата, может потребовать обширных данных. Поэтому без изучения связывания невозможно сказать «насколько абстрактным» является определение сообщения.
Тип порта
— это именованный набор абстрактных операций, ссылающихся на задействованные в обмене абстрактные сообщения.
В WSDL имеется четыре примитива организации способа взаимодействия, которые может поддерживать конечная точка:
Запрос / просьба и ответ связаны в WSDL логически, а конкретный механизм их корреляции описывает связывание. Например, запрос и ответ могут быть частью одного сетевого взаимодействия, либо являться физически разными сетевыми посылками.
Хотя WSDL и поддерживает связывания для всех четырёх примитивов, но определяет их только для примитивов однонаправленный запрос и запрос-ответ. Ожидается, что спецификации, определяющие протоколы для взаимодействий просьба-ответ и уведомление, также должны поставлять связывания для WSDL, что позволит использовать эти примитивы.
Операции просьба-ответ и уведомление искусственные, вносящие сложность и путаницу, но не приносящие дополнительную полезность. В них инициатором обмена сообщениями является служба: она первая отправляет уведомление или запрос-просьбу и получает ответ для обработки. Например, web-служба, реализующая операцию типа уведомление, будет технически реализована как HTTP-клиент, а её клиент — как HTTP-сервер.
Распространения эти операции не получили, поддерживаются только теоретически на уровне спецификации. Поэтому web-службу следует разрабатывать как обработчик запросов с соответствующим использованием в её WSDL-документе примитивов однонаправленный запрос и запрос-ответ.
Однонаправленный запрос
Грамматика определения операции следующая:
Элемент input задает абстрактное содержание сообщения-запроса.
Запрос-ответ
Элементы input и output задают абстрактное содержание запроса и ответа соответственно. Опциональные элементы fault задают абстрактное содержание сообщений об ошибках, которые могут происходить в результате выполнения операции (сверх тех, что специфичны для протокола).
Обратите внимание, что операция запрос-ответ — это абстрактное представление. Нужно рассмотреть конкретное связывание, чтобы определить, как в действительности будет передано сообщение: в рамках одного взаимодействия (как HTTP запрос и ответ), либо в рамках двух независимых взаимодействий (например, как два разных HTTP-запроса).
Просьба-ответ
Элементы output и input задают абстрактное содержание запроса-просьбы и ответа соответственно. Опциональные элементы fault задают содержание возможных сообщений об ошибках. Операция просьба-ответ также является абстрактным представлением, и для определения реального способа передачи сообщений необходимо обратиться к соответствующему связыванию.
Уведомление
Элемент output задает абстрактное содержание сообщения-уведомления.
Имена элементов в рамках операции
Атрибут name элементов input и output содержит уникальное имя среди всех таких элементов в рамках типа порта.
Так как элементов fault может быть несколько, то каждый из них должен иметь имя, чтобы ссылаться на него из связывания для задания конкретного формата сообщения. Имя должно быть уникальным среди всех элементов fault в рамках операции.
Порядок параметров в рамках операции
Обратите внимание, что эта информация служит только как «подсказка», поэтому может быть безопасно проигнорирована в случае незаинтересованности в RPC-сигнатуре. Кроме того она является необязательной даже в случае использования операции с RPC-связыванием.
Связывание
Связывание определяет формат сообщений и детали протокола для операций и сообщений конкретного типа порта. Одному типу порта могут соответствовать несколько разных связываний. Грамматика определения связывания следующая:
Атрибут name задаёт имя связывания, уникальное среди всех связываний WSDL-документа. Связывание ссылается на тип порта с помощью атрибута type типа QName (см. Раздел 2.1.1).
Элементы расширения связывания используются для указания конкретной грамматики для входящих (3) и исходящих (4) сообщений, сообщений об ошибках (5). Также может указываться информация уровня операции (2) и уровня связывания (1).
Связывание должно устанавливать только один протокол.
Связывание не должно содержать информации об адресе.
Порт определяет отдельную конечную точку посредством установки адреса для связывания.
Атрибут name задаёт уникальное имя среди всех портов в рамках WSDL-документа. Атрибут binding типа QName содержит ссылку на связывание (см. Раздел 2.1.1).
Элементы расширения (1) используются для задания адреса.
Порт не должен задавать более одного адреса.
Порт не должен содержать любую информацию связывания, отличную от адреса.
Служба
Служба объединяет вместе набор связанных портов.
Атрибут name задаёт уникальное имя среди всех служб, определённых в рамках WSDL-документа.
Порты внутри службы связаны следующим образом:
Wsdl soap что это
Применение SOAP при интеграции систем
Для начинающих аналитиков,
не имеющих опыта web-разработки
В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.
С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.
SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.
Почему разница в 2 года в появлении REST и SOAP так сказалась на их популярности?
Если сравнить это с тем фактом, что Рой Филдинг просто представил REST в своей диссертации, то вы поймете, почему SOAP завоевал популярность очень быстро.
Тем не менее на данный момент можно говорить о том, что в основном для интеграции систем используется REST.
Для того, чтобы наглядно показать отличие REST от SOAP, приведем вот такую аналогию. Представьте себе дерево, в котором есть дупло, и из этого дупла выглядывает птичка. Когда вы обращаетесь к какому-то приложению, вы как будто обращайтесь к такому дереву и стучитесь в окошко. Условно можно считать, что в это окошко выглядывает некоторая функция.
Если вы работаете с REST, то можно себе представить дерево, в котором есть много таких окошек — большое количество птичек, каждая из которых выглядывает из своего дупла. Это дупло называется Endpoint, но это отдельный разговор. Важно, что каждый раз, обращаясь к дуплу, вы обращаетесь только к одной функции.
SOAP основывается на технологии удаленного вызова процедур. Сервис, который работает на базе SOAP — это дерево с одним-единственным дуплом. Но каждый раз, обращаясь к этому дуплу, вы должны указать название процедуры, то есть название функции, которую вы хотите вызвать, потому что функций там может быть несколько. И, разумеется, вы должны передать те входные данные, которые нужны для процедуры, которую вы собираетесь вызвать.
В SOAP передача данных идет по протоколу HTTP, то есть также, как это происходит и в случает REST-запросов.
Давайте рассмотрим на примере. Если я зайду на сайт какой-нибудь биржи акций, то могу узнать курс интересующей меня акции. Откуда поступает эта информация? Давайте разберемся.
Я открываю на своем компьютере браузер, который является клиентом. По протоколу HTTP он обращается к серверу (назовем его HTTP-server).
На этом HTTP-сервере живёт приложение, которое отдает мне информацию, о том, что акция Facebook стоит, к примеру, 252 доллара. Однако, откуда само приложение, живущее на HTTP-сервере, знает стоимость акции?
А все очень просто — приложение в данном случае выступило как SOAP-client и запросило эту информацию на другом сервере (назовем его SOAP-server).
Взаимодействие SOAP-client и SOAP-server происходит по протоколу SOAP поверх HTTP. Что значит поверх? Это значит, что клиент и сервер общаются по протоколу HTTP, но по этому протоколу передаётся не просто стандартное сообщение HTTP, а некий конвертик с письмом, причем это письмо написано по правилам протокола SOAP.
То есть сайт, который передал мне информацию о Facebook, сам запросил SOAP-server (то есть биржу акций) по протоколу HTTP и вложил сообщение в конвертик SOAP.
Таким образом, информация о курсе акции пришла ко мне не напрямую с биржи, а через посредника — через SOAP-client.
Когда мы работаем по сети, мы работаем с протоколами TCP/IP — это нижний, сетевой уровень протоколов. Весь интернет базируется на протоколе HTTP, который мы рассматривали в предыдущей статье. HTTP является просто транспортом, с помощью которого информация передается по сети.
Чтобы передать какое-либо сообщение по сети, оно должно соответствовать правилам протокола HTTP. А дальше в пакетик, передаваемый по протоколу HTTP, вкладывается сообщение по протоколу SOAP. И все это живет по правилам, описанным в файле WSDL.
Представьте себе, что вы хотите передать по сети некоторую записочку. И вы хотите, чтобы информация в ней была структурирована так, чтобы записку могла прочитать программа.
В качестве примера приведу записку, которую Анна пишет Марии: «Приходи ко мне в гости в воскресенье!». И заголовок: «Напоминалка» (Reminder). Здесь могла бы быть ещё подпись signature, но, как видите, подпись оказалась пустой, информация в теге не передана (такое тоже возможно).
Тег — это текстовая строка, завернутая в уголочки (<>).
То есть, когда мы передаем XML-документ, мы информацию «заворачиваем» в теги. Они предназначены для того, чтобы объяснять, что лежит внутри. Теги бывают открывающие (перед текстовым содержимым) и закрывающие (начинается с символа «/»).
В HTML такие же теги, но они применяются немного по-другому: в языке XML эти теги предназначены для того, чтобы объяснить приложению, которое принимает сообщение, что именно вложено внутрь.
Приложение, которое принимает записку, заранее знает, какие должны прийти данные внутри каких тегов. И знает оно это благодаря WSDL.
Что такое WSDL? В SOAP для описания своего сервиса нужно использовать строгие правила в виде файлов WSDL. Ниже мы разберем это подробнее, но вообще WSDL — это Web Services Description Language, ещё один язык описания веб-сервисов и доступа к ним.
Разберем приведенный ранее пример детальнее.
Первая строка документа — XML-декларация, она указывает на версию XML ( version=»1.0″ ) и тип кодировки документа ( encoding=»utf-8″ ).
Что ещё есть в xml-документе?
Всё XML-сообщение (наша записочка) заворачивается в так называемый корневой тег. В данном случае, корневым является тег note, который выделен зеленым.
Правильно оформленный XML это такой XML, который соответствует стандартам языка и может быть разобран приложением, то есть приложение его получит, проверит синтаксис и начнет разбирать.
Важно понимать, что приложение не будет разбирать XML если он не будет правильно оформлен. В этом случае приложение придёт к выводу, что XML повредили или подменили по дороге.
Если мы посмотрим на XML-документ внимательно, то сможем построить вот такое дерево:
То есть с точки зрения приложения XML представляет собой дерево, состоящее из узлов. Например на картинке вы можете видеть имена узлов: note, to, from, heading, body, signature.
Узлы вкладываются друг друга, и получается, что XML-документ можно представить в виде перевернутого дерева, только дерево растет вниз. Тeг note является корнем и в него вложены остальные теги, все они являются детьми этого корня. Кроме того, есть ещё текстовых узлы Мария, Анна и т. д.
Разговоры о том, что какая-то буква потерялась, не очень актуальны сейчас, так как современные протоколы обеспечивают целостную доставку. Данный пример призван продемонстрировать, что XML-документ в первую очередь создаётся для того, чтобы информацию вкладывать в теги.
Атрибуты — это пары имя/значение, поставленные в соответствие одному из элементов. Они должны находиться при открывающем теге, но не при закрывающем.
Атрибуты всегда должны иметь значение, даже если значением является всего лишь пустая строка. Значения атрибутов должны заключаться в кавычки. При этом согласно синтаксису XML допускаются как двойные, так и одинарные кавычки.
Если вам придется руками формировать XML-документ, никогда не пишите в одном документе и двойные и одинарные кавычки, просто потому что вам лень аккуратненько расставить однотипные, поскольку это может привести к ошибкам.
Чтобы наглядно объяснить, что такое пространство имён, рассмотрим следующий пример.
Например, в первом случае тег table — это текст, который используется в языке HTML для указания того факта, что дальше идет описание таблицы. А во втором — предназначен для того, чтобы описать африканский кофейный стол и его размеры.
Как сделать так, чтобы приложение определило, что это разные теги table?
Чтобы раскрыть тему, давайте рассмотрим бытовую аналогию: как учителя различают детей, которые приходят в класс.
У себя дома имя мальчика Серёжи, скорее всего, является уникальным идентификатором. То есть, вероятнее всего, ни одного Серёжи в семье больше нет. Но когда Серёжа приходит в школу, он обнаруживает, что в классе ещё три Серёжи, и учителю их надо как-то различать.
Как это сделать? Как правило, в классе для этого используется фамилия ребенка. Но если в классе есть однофамильцы Серёжи? Что ж, и такое бывает. В этом случае отличать Серёж можно по их домашнему адресу.
Интересный момент: если учитель знает, что Серёжа Васильев живёт по этому адресу, а тут в класс приходит некая Аня Васильева, живущая по этому же адресу, то можно сделать логичный вывод, что, скорее всего, Серёжа и Аня — брат и сестра. Именно адрес и указывает учителю на то, какая это семья и где она живёт. В XML-документах точно такая же логика.
Если нам нужно определить пространство имён (семью), к которому относится тег, мы заводим специальный атрибут. Этот атрибут называется XML namespace, сокращенно xmlns. Именно в xmlns мы пишем адрес — то место, где публикуется стандарт стандарта языка (то есть в атрибуте xmlns указывается адрес документа, в котором явно описано, что такое table для документа HTML).
В случае с кофейным столиком мы, разумеется, пишем другой адрес. Интересно, что это может быть абсолютно любой адрес, он может даже не существовать на самом деле, поскольку используется только для идентификации. То есть, вот этот тег table живет по этому конкретному адресу, и там же живёт вся его семья.
Что из себя представляет семья тегов?
Правило такое: если тег, у которого указано пространство имён, содержит вложенные теги, то эти вложенные теги относятся к тому же пространству имён.
Ранее в примерах мы говорили про обмен данными между сайтом и биржей акций. Как это происходит?
Чтобы отправить запрос в биржу акций, нужно ответить на простой вопрос. Facebook и сайт биржи акций должны ответить «252.36» — это содержимое, которое надо передать. Протокол SOAP предполагает, что это текстовое содержимое вложено внутрь XML-тегов и прописано в стандарте в виде XML-дерева.
Давайте разберем на составляющие данный запрос.
Envelope и Body — теги, которые прописаны в протоколе SOAP. То есть, если вы отправляете запрос по протоколу SOAP, то у вас должен быть тег Envelope и вложенный в него тег Body. Это нужно просто запомнить.
SOAP-ENV — обозначение пространства имён, то есть теги Envelope и Body относятся к пространству имён SOAP-овского окружения и это не что иное, как краткое указание на то, что есть определенное семейство тегов. А где описывается пространство имён, мы разберем немного позже.
getQuote (получить котировку) — имя процедуры, которую мы хотим вызвать. Она относится уже к другому пространству имён, а именно «ns1».
« Faсebook » — это входной параметр, который мы передаем, и он завернут в тег Symbol. Обратите внимание на атрибут, который есть в этом теге «string» — он описывает, что передаваться должно не число, а строка.
Давайте теперь вернемся к WSDL — документу, благодаря которому приложение заранее знает, какие должны прийти данные внутри каких тегов.
Основные теги с которыми вы столкнетесь в описании WSDL-сервера:
Как все это выглядит?
На веб-сервисе лежит файл WSDL. И клиент, и сервер руководствуются в своей работе этим файлом: читают его и разбираются, как устроен сервис. И клиент, и сервер умею читать этот файл и получать из него информацию, так как они знают стандарт SOAP и то, как должен быть устроен файл WSDL.
Давайте разберем этот wsdl-файл:
Operation — это тег, который описывает функции. То есть он указывает на имя функции и то, как должен выглядеть запрос и ответ.
Вложенные в operation теги input и output содержат информацию о входных и выходных параметрах функции. То есть getQuoteRequest — это запрос, который представляет собой строку и должен иметь вид числа с плавающей точкой.
Тег binding описывает все технические сведения, о том, что из себя представляет сервис.
Тег servisce описывает, где живет наш сервис. Если бы мы установили веб-сервисом на локальной машине, то адрес написали бы следующим образом: localhost/server1. php/.
Если вы захотите расписать WSDL в виде дерева, то получите следующую картину:
Корневой тег definitions содержит 2 тега message, описывающие входной и выходной параметры.
Далее идет тег portType, включающий в себя тег operation, который также описывает входной и выходной параметры. PortType же собирает вместе информацию из двух тегов message.
Тег binding описывает все технические особенности нашего сервера. Считается довольно сложным в прочтении для начинающих.
Тег service содержит описание нашего сервера.
Главным недостатком SOAP является то, что при его использовании для передачи сообщений, он увеличивает их объём и снижает скорость обработки.
Мы смогли в этом убедиться на примере вопроса «Facebook» и ответа «252.36», которые требуют огромного количества тегов, в которые заворачивается вопрос.
Для того, чтобы еще раз сравнить SOAP и REST, я привела преимущества приложения, созданного на основании REST:
Для SOAP необходимо специальное приложение, чтобы разобрать XML-документ, распарсить его, как говорят в ИТ-среде.
Относительно легкости внесения изменений хочется заметить: для того, чтобы изменить WSDL, мы, разумеется, можем изменить адрес, но это непросто. SOAP — консервативный протокол, он используется преимущественно в Legacy-системах, но, тем ни менее, знание SOAP пользуется достаточно большим спросом.