Что такое SOAP?
Объясните, пожалуйста, простыми словами, что такое SOAP, для чего нужен, и, если можно, пару примеров использования.
6 ответов 6
Лирическая часть.
Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.
Этот сервер может выполнять множество действий, работать с базой, выполнять какие-то сторонние запросы к другим серверам, заниматься каким-то вычислениями и т.д. жить и возможно развиваться по ему известному сценарию (т.е. по сценарию разработчиков). С таким сервером общаться человеку неинтересно, потому что он может не уметь/не хотеть отдавать красивые странички с картинками и прочим юзер-френдли контентом. Он написан и работает чтобы работать и выдавать на запросы к нему данные, не заботясь, чтоб они были человекочитаемые, клиент сам с ними разберется.
Практическая часть.
Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты) дает возможность общения с сервером четко структурированными сообщениями. Дело в том, что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).
WSDL (Web Services Description Language). Правила, по которым составляются сообщения для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е. если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.
Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.
Какие плюсы у всех этих наворотов:
Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding’и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):
Минусов тоже полно:
В качестве примера есть открытый веб-сервис belavia:
Можете вручную создать и послать запрос типа:
ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.
Soap для чего нужен
Применение SOAP при интеграции систем
Для начинающих аналитиков,
не имеющих опыта web-разработки
В предыдущей статье мы говорили про то, что REST — это архитектурный стиль, который Рой Филдинг сформулировал в своей диссертации в 2000 году.
С протоколом SOAP дела обстоят несколько иначе.
SOAP — это не стиль, а протокол. Аббревиатура SOAP так и расшифровывается: Simple Object Access Protocol — простой протокол доступа к объектам. То есть правила передачи информации в SOAP строго стандартизированы, есть спецификация, которой нужно соответствовать.
SOAP появился 1998 году и был передан в организацию World Wide Web Consortium (W3C) — международная организация, которая курирует развитие интернета.
Если сравнить это с тем фактом, что Рой Филдинг просто представил 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 пользуется достаточно большим спросом.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?
Оглавление цикла статей:
REST vs SOAP. Часть 1. Почувствуйте разницу.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?
Зачем все это?
Зачем вообще нужно взаимодействие приложений, тем более написанных на разных платформах? Глупый вопрос, конечно. В мире программирования параллельно существуют и развиваются несколько абсолютно независимых, а местами и враждующих платформ. Кроме того, огромное количество софта уже написано и успешно работает, поэтому переписывать его под каждую новую платформу никто не будет. Возьмем банк для примера. Все in-house программисты банка всегда писали на JAVA, поэтому у банка есть сервис, который уже 5 лет прекрасно работает, недавно появились красивые мобильные приложения на Android, которые стабильно работают почти на всех версиях ОС, и остался даже сайт с апплетом, которых преподаватели в харьковских вузах до сих показывают в качестве примера передовых веб-технологий (jk). А теперь появилась задача разработки десктопного банковского приложения под Windows. Банк заказал WPF-приложение аутсорсинговой компании. Как же организовать общение платформ?
Немного истории
SOAP также появился в 1998 году стараниями Microsoft. Он был анонсирован как революция в мире ПО. Нельзя сказать, что все пошло по плану Microsoft, было огромное количество критики из-за сложности и тяжеловесности протокола. В то же время были и те, кто считал SOAP настоящим прорывом. Сам же протокол продолжал развиваться и плодиться десятками новых и новых спецификаций, пока в 2003 года W3C не утвердила в качестве рекомендации SOAP 1.2, который и сейчас является последним. Семейство у SOAP получилось внушительное, вот их семейная фотография: 
(на фото — WS-Addressing, WS-Enumeration, WS-Eventing, WS-Transfer, WS-Trust, WS-Federation, Web Single Sign-On… А того второго справа вообще не вспомнить, как зовут)
За более десяти лет споры по поводу SOAP не утихли, он по прежнему яростно критикуется за перегруженность, за низкую скорость работы. Однако протокол не умер, скорее даже наоборот, хотя и мир тоже не захватил. Критика протокола во многом справедлива: не используются заложенные в HTTP фичи, длина сообщений больше, чем у REST, от всех этих WS-Federation и WS-AtomicTransaction часто нету никакой пользы.
Но я хочу заострить внимание на другом – как же быстро можно разрабатывать распределенные приложения, используя семейство протоколов SOAP! Это ли не революция, которую нам обещал Microsoft? По-моему, это именно она. Где еще можно порасставлять аттрибуты в коде, нажать кнопку Publish на сервисе, нажать кнопку Generate Proxy на клиенте и вызывать код, как будто он находится в том же проекте? Поэтому на передний план выходит вопрос о том, в каких языках и средах программирования такая сказка возможна. Попробую свести эти данные в таблицу:
А как же REST, неужели он не нужен?
Дни SOAP сочтены?
Сейчас REST и SOAP оба успешно используются, однако может произойти так, что SOAP действительно исчезнет, как пишут его критики. Такое, по моему мнению, возможно, если для RESTful сервисов начнет использоваться WSDL или подобный протокол, который позволит генерировать клиентские прокси. Поползновения такие были, протокол назывался WADL, однако на данный момент ничего такого не существует. Конечно, для такого сценария потребуется желание и приличные усилия хотя бы одного из основных игроков в мире IT, но я бы не стал исключать такой вариант. И будет у нас тогда лучшее из двух миров – простота и бенефиты от архитектуры сети и автоматизация взаимодействия приложений с помощью клиентских прокси.
Пример
Все уже забыли о примере из начала статьи? Он взят из жизни. Напомню, там разрабатывается WPF приложение, которое должно получать данные из существующего сервиса, написанного на JAVA. В каком формате он мог бы нам отдавать данные чтобы все выглядело бы красиво в соответствии с этой статьей? Правильно, в SOAP. А он отдает json. Надеюсь, ни у кого не возникло мысли «какой json, это в смысле REST?». Конечно REST! REST может возвращать данные в простом XML, json или любом другом запрошенном формате, даже в формате «как Вася попросил», если вам конечно удастся сделать этот формат одним рекомендуемых стандартов W3C или хотя бы договориться с разработчиками сервиса, чтобы они знали, что делать с этим:
Content-Type: application/as-Vasya-asked; charset=utf-8
Мы отвлеклись от дела. Ну возвращает сервис данные в json, и чем это нам грозит? А вот чем: прокси клиента сгенерить не сможем, придется вручную посылать запросы и парсить ответы. Придется использовать HttpWebRequest или надстройки над ним. А был бы SOAP – деньги заказчика были бы сэкономлены.
Заключение
Обзор SOAP
SOAP позволяет объектам любого вида, т.е. написанным под любую платформу и на любом языке, перекрестно взаимодействовать. В настоящее время SOAP реализован в более 60 языках и более 20 платформах. Неожиданно все объекты, локальные и удаленные, маленькие и большие, получили возможность взаимодействия друг с другом.
Том Клементс
Январь 2002
Теперь перейдем к сценарию другого рода, действие которого происходит в Internet и представителями второго “я” являются компании Microsoft и Sun. Каждая из этих компаний имеет свою четкую точку зрения, пытается ликвидировать разрыв и наладить контакты с другой. Узнайте о SOAP (Simple Object Access Protocol – Простой Объектный Протокол Доступа).
Содержание
Введение
Выражаясь просто, SOAP позволяет Java и COM объектам взаимодействовать друг с другом в распределенной, децентрализованной Web-среде.
В более общем смысле, SOAP позволяет объектам (или коду) любого вида, т.е. написанным под любую платформу и на любом языке, перекрестно взаимодействовать. В настоящее время SOAP реализован в более 60 языках и более 20 платформах. Неожиданно все объекты, локальные и удаленные, маленькие и большие, получили возможность взаимодействия друг с другом. Брэд Питт и Эдвард Нортон, как два объекта различных типов, в конце концов тоже стали способны взаимодействовать.
В данном обзоре SOAP будет первоначально представлен в более широком контексте Web-сервисов, как протокол, соединенный с UDDI (Universal Description, Discovery and Integration – Универсальное Описание, Открытие и Интеграция) с целью обеспечения регистрационных сервисов и сервисов передачи сообщений между предприятиями. Также будут обсуждаться Web обоснования появляющейся парадигмы “публиковать, находить, связывать”, и будут показаны механизмы организации пакетов, транспортировки и доставки в SOAP.
Эволюция Web-сервисов
Не смотря на все возражения, SOAP – это всего один компонент (хотя и центральный) в новом представлении Web, как структуры для бизнес-операций, основанной на стандартах и не зависящей от языка и платформы. Эти операции обычно собраны в универсальном понятии “Web-сервисы”, но Web-сервисы сами по себе хороши настолько, насколько хороша инфраструктура, поддерживающая их. Соответственно, мы имеем быстрый многоуровневый взгляд на основу Internet.
Сетевые уровни
В эволюции Web-сервисов ярко выражены три сетевых уровня: TCP/IP, HTTP/HTML и XML. Эти уровни надстроены последовательно друг над другом и по сегодняшний день остаются совместимыми.
Первый уровень, протокол TCP/IP, связан прежде всего с передачей данных в пакетах по кабелю. Будучи протоколом, который гарантирует пересылку данных по общественным сетям, TCP/IP придает особое значение надежности транспортировки данных и физическому обеспечению связи. Первоначально TCP/IP являлся “замазкой”, скрепляющей отдельные сети, тогда как сейчас это базовый протокол Web, на котором основаны высокоуровневые стандартные протоколы типа HTTP.
Второй уровень, HTML над HTTP, является уровнем представления и занимается поиском с броузерным интерфейсом, выборкой и совместным использованием информации. Здесь основное внимание уделяется GUI-навигации и манипуляции форматов представления. Во многих отношениях HTML носит больше демонстративный, чем функциональный характер, и испытывает недостаток как в расширяемости, так и в истинной программной мощности. Тем не менее, совместное использование гипертекстовых документов в среде с броузерным интерфейсом полностью реконструировало способ передачи текстовой информации между людьми. Сетевые настольные среды, обремененные собственными операционными системами и платформно-зависимым программным обеспечением, медленно но верно уступают основанной на стандартах, открыто-системной обработке данных в Internet.
Погружение в этот новый прекрасный стандартизованный мир возглавляет XML, третий и возможно наиболее неотразимый уровень в Internet. XML – формат обмена данными со строгим контролем типов – предоставляет новое измерение уровню HTTP/HTML, в котором осуществление межкомпьютерного взаимодействия возможно посредством стандартных интерфейсов. Этот уровень, описываемый как A2A (application to application), B2B (business to business) или C2C (computer to computer), позволяет программам обмениваться данными независимо от платформы и представления. Таблицы стилей XSLT могут быть добавлены как дополнительные компоненты представления и/или трансформации.
XML: ключ к описанию Web-сервисов
Ключом к осуществлению всех этих возможностей является межкомпьютерное взаимодействие – область, в которой преобладает XML. Будучи синтаксисом для описания данных, XML управляется определением (при помощи DTD или схем) и позволяет программно управлять информацией. Это означает, что большая часть предполагаемой работы может быть получена из B2B-взаимодействий. Теги могут быть согласованы, интерфейсы определены, а обработка данных стандартизована. Web-сервисы – это компонентные программы многократного пользования, которые используют XML как стандартную расширяемую сетевую структуру, с целью облегчения этого вида межкомпьютерного взаимодействия.
Web-сервисы предоставляют интерфейсы для передачи компонентных данных и бизнес-логики по HTTP. Огромное количество данных располагается сразу за скриптами, выполняемыми на стороне сервера, в традиционных репозиториях, ожидая доступа к данным из Web-броузеров и клиентских приложений. Web-сервисы обещают восстановить ценные свойства корпоративных приложений, неиспользуемые в настоящее время во многих областях предприятия.
XML играет ключевую роль в интеграции Web-резидентных данных в корпоративные приложения, а также в координировании бизнес-логики, соединяющей составные части. Определенные бизнес-задачи и услуги (включая логику автоматизации, бизнес-логику, логику упорядочения компонентов, логику формирования транзакций и т.д.) могут быть включены в XML-документ и интегрированы в существующие бизнес-среды. Это позволяет предприятиям усилить существующие ценные свойства и процессы, а также представить эту информацию в виде Web-сервисов, упрощая деловые операции и поддерживая цепное взаимодействие во всей сети WWW.
Поскольку XML удобен для чтения и основан на тексте, он идеально подходит в качестве транспортной структуры для слабосвязанных Web-сервисов. Основным моментом является то, что автоматизированные транзакции увеличивают производительность, уменьшают затраты и улучшают услуги. Присутствие стандартов в сети делают возможными автоматизированные транзакции, приводя к росту производительности.
SOAP – это технология, которая произошла от раннего XML-стандарта (XML-RPC) и, в некотором смысле, стремится к появляющемуся стандарту ebXML (electronic business XML). ebXML – это незавершенная технология, направленная на обеспечение всестороннего определения общедоступных бизнес-сообщений между торговыми партнерами. SOAP является менее обширным и менее сложным в выполнении.
Слабосвязанные системы
Web-сервисы отделяют объекты от связывающей их платформы. То есть Web-сервисы облегчают взаимодействие между платформно-независимыми объектами, способными обращаться к данным из любой точки Web. Осуществляя удаление от частных платформ, Web-сервисы полагаются скорее на слабые, чем сильные связи между Web-компонентами. Согласно Брайану Трэвису, консультанту и автору SOAP, системы, которые полагаются на специфичные для одной платформы объекты, называются сильносвязанными системами, т.к. они опираются на однозначный, но хрупкий интерфейс. Если какая-либо часть соединения между объектом-приложением и серверным объектом разорвана, или если вызов некорректен, это может привести к непредсказуемым результатам. EDI (Electronic Data Interchange – Электронный Обмен Данными) является примером сильносвязанной структуры для осуществления электронной коммерции. В свою очередь слабосвязанные системы учитывают гибкий и динамический обмен в открытых распределенных Web-средах.
Второе пришествие CORBA
В настоящее время многие компании (например, IBM, BEA, Sun и др.) совместно сотрудничают с теми же компаниями, с которыми они конкурируют. Стандартизованные сетевые транспортные протоколы, платформно-независимые языки программирования (такие как Java, XML, диалекты, характерные для той или иной промышленности) и открытые компонентные серверные архитектуры способствуют этой антисобственнической общедоступности. Сегодня Web-сервисы (с их обещаниями всеобъемлющей прикладной функциональной совместимости) представляются как окончательный “клей”, заставляющий взаимодействовать все эти технологии, если не без швов, то хотя бы без избыточного багажа, который сопровождал предыдущие технологии, такие как CORBA и RMI.
В каком-то смысле Web-сервисы представляют второе пришествие CORBA. Однако CORBA была объектно-ориентированной структурой бинарных IIOP коммуникаций, загруженной заглушками, скелетами программ и зависящими от поставщика брокерами объектных запросов. Web-сервисы в свою очередь являются легкими, основанными на HTTP, XML-управляемыми и полностью независящими от платформы и языка. Тогда как CORBA была 600-фунтовой полузапертой гориллой, Web-сервисы – это газель, легко скачущая по обширным просторам Internet.
Публикация, нахождение, связывание
Структура Web-сервисов состоит из цикла “публиковать-находить-связывать”, посредством которого поставщики сервисов делают данные, содержимое или услуги доступными для зарегистрированных запрашивающих сторон, потребляющих ресурсы, локализуя сервисы и соединяясь с ними. Запрашивающие приложения настраиваются на Web-сервисы при помощи WSDL (Web Services Definition Language – язык описания Web-сервисов), который предоставляет низкоуровневую техническую информацию о желаемом сервисе, допускает обращение приложений к информации XML Schema для кодировки данных и гарантирует, что правильные операции будут осуществлены по правильным протоколам.
Механизмы публикации, нахождения и связывания имеют соответствующие аналоги в трех отдельных (но отчасти эквивалентных) протоколах, которые составляют сетевой набор Web-сервисов: WSDL, SOAP и UDDI.
Погружаясь немного глубже в аналогию с CORBA, отметим, что SOAP играет роль IIOP в CORBA (или JRMP в RMI). Это связующий механизм между противоположными конечными точками. С другой стороны, WSDL играет роль IDL (Interface Definition Language – Язык Описания Интерфейсов). В этом смысле WSDL определяет Web-сервисы как совокупность портов и операций. WSDL-порт аналогичен интерфейсу, а WSDL-операция аналогична методу. WSDL публикует интерфейсы Web-сервисов сторонам, заинтересованным в коммуникации через гетерогенные платформы.
Однако WSDL не только является языком описания интерфейсов, он также включает конструкции, позволяющие описывать информацию об адресе и протоколе публикуемого Web-сервиса. Интересно то, что WSDL описывает абстрактный интерфейс для Web-сервиса, одновременно позволяя (в мучительных подробностях) связывать Web-сервис с определенным транспортным механизмом, таким как HTTP. Абстрагируя интерфейс, WSDL функционирует как технология многократно используемых Web-сервисов. Связывая Web-сервис с определенным транспортным механизмом, WSDL делает абстракцию конкретной. Если это покажется вам слегка шизофреничным, подумайте о космическом шатле: многократно используемая, полностью функциональная космическая капсула связана со специализированными, но одноразовыми стартовыми ракетными двигателями. Транспортный механизм может измениться, но полезный груз сохраняется.
Наконец, UDDI действует как реестр для публикации и локализации Web-сервисов. Выставляя информацию о сервисе и связывая интерфейсы в Web-реестре, UDDI предоставляет совместно используемую директорию для предпринимателей и клиентов, размещающих в этой директории Web-сервисы друг друга.
Создание Web-сервисов
SOAP позволяет создавать приложения, удаленно вызывая методы объектов. SOAP устраняет требование того, что две системы должны запускаться на одной платформе или быть написаны на одном языке программирования. Вместо вызова методов по определенному бинарному протоколу, пакет SOAP использует XML, основанный на тексте синтаксис для осуществления вызова методов. Вся информация между запрашивающим приложением и принимающим объектом пересылается в виде данных, заключенных между тегами, в XML-потоке по HTTP. С точки зрения Web-сервисов SOAP может быть реализован в качестве как клиента, так и сервера.
SOAP клиенты и серверы
Клиент SOAP – это программа, которая создает XML-документ, содержащий информацию, необходимую для удаленного вызова метода в распределенной системе. Клиенты SOAP не должны быть традиционными. В дополнение к тому, что они пополняют разнообразие ваших настольных приложений, клиенты SOAP могут служить Web-серверными или основанными на серверной технологии приложениями.
Сообщения и запросы от клиентов SOAP обычно пересылаются по HTTP. В результате документы SOAP способны обойти почти любой брандмауэр (firewall), допуская обмен информацией между разными платформами.
Сервер SOAP – это специальный код, который слушает SOAP сообщения и действует как распределитель и интерпретатор SOAP документов. Внешние Web-сервисы могут взаимодействовать с приложениями-серверами, основанными на технологии J2EE, которые обрабатывают запросы SOAP от множества клиентов.
Серверы SOAP гарантируют, что документы, полученные по HTTP соединению, преобразованы к языку, который понятен объекту и всем окружающим. Поскольку все коммуникации осуществляются в форме XML, объекты, написанные на одном языке (скажем, Java), могут связываться через SOAP с объектами, написанными на другом языке (например, C++). Работа SOAP сервера заключается в том, чтобы удостовериться, что конечные пункты понимают обслуживающий их SOAP.
SOAP и Java технология
Согласно спецификации SOAP 1.1, SOAP является легким протоколом для обмена информацией в децентрализованной, распределенной среде.
SOAP не устанавливает единую модель программирования, также как и не делает привязки к определенному языку программирования. В контексте языка программирования Java установление привязки к конкретному языку зависит от Java-сообщества. В настоящее время привязки к языку Java преследуются по инициативе JAX-RPC.
В недавнем обсуждении SOAP, состоявшемся на конференции разработчиков JavaOne(sm), инженеры компании Sun Роберто Чинници (Roberto Chinnici) и Рауль Шарма (Rahul Sharma) определили семейство технологий JAX как “дающее возможность создания Web-сервисов при помощи уже известных компонентных технологий JSP(tm) и EJB(tm) для платформы Java”. Сервлеты и сессионные компоненты, не имеющие состояния, были отмечены как две технологии, наиболее пригодные для инкапсулирования Web-сервисов.
Так что же такое в действительности SOAP?
Полностью подготовив платформу для изучения SOAP и описав решающую роль SOAP в создании Web-сервисов, рассмотрим более детально, что же такое в действительности SOAP, что и как делает этот протокол.
SOAP – это расширяемая, основанная на тексте структура для предоставления связи между разными сторонами (вообще говоря, объектами), которые не знают заранее друг о друге или о платформе, на которой работает противоположная сторона. С точки зрения объектов в сети SOAP – это изначально “свидание вслепую”. Клиентские приложения могут взаимодействовать в слабосвязанных средах, обнаруживать сервисы и динамически подсоединяться к ним без установления каких-либо предварительных соглашений.
SOAP является расширяемым, потому что SOAP клиенты, серверы и сам протокол могут развиваться, не разрушая уже существующие приложения. Более того, SOAP богат в плане поддерживаемых посредников и многоуровневых архитектур. Это означает, что узлы обработки могут находиться на пути запроса между клиентом и сервером. Эти промежуточные узлы обрабатывают части сообщений при помощи использования заголовков, которые позволяют клиентам определять, какая часть сообщения обрабатывается данным узлом. Такой метод обработки промежуточных заголовков выполняется по приватному соглашению между клиентским приложением и промежуточным узлом обработки. SOAP предоставляет заголовкам атрибут mustUnderstand, который позволяет клиенту определить, является обработка обязательной или опциональной. Если mustUnderstand установлен в 1, сервер должен либо выполнить промежуточную обработку, указанную в заголовке, либо выдать ошибку.
SOAP также устанавливает правила кодирования данных, называемые основными уровнями кодирования или кодированием “Section 5” (по названию раздела в спецификации SOAP, посвященного кодированию). Надо отметить, что кодирование в SOAP занимает большую часть сорокастраничной спецификации SOAP 1.1. Не слишком углубляясь в специфику типов данных XML, можно сказать, что кодирование SOAP может быть вкратце описано как коллекция простых или сложных значений.
Простые значения – это либо простые типы данных (например, int, float, string), либо встроенные типы, описанные в разделе 2 спецификации XML Schema. Сюда входят такие типы как байтовые массивы и перечисления.
Сложные значения включают структуры, массивы и сложные типы, определенные группой XML Schema. И последнее, однако немаловажное замечание: кодирование данных в SOAP определяет правила для сериализации объектов, т.е. для механизмов маршалинга и демаршалинга потоков данных. Стоит отметить, что кодирование “Section 5” необязательно, поэтому клиенты и серверы могут использовать различные соглашения по кодированию данных, если есть договоренность о формате.
И наконец, SOAP устанавливает набор правил, которые дают возможность клиентам и серверам осуществлять вызов удаленных процедур, используя SOAP как структуру коммуникаций. Будучи по сути протоколом, ориентированным на работу с сообщениями, SOAP может хорошо работать как RPC-протокол. Объектная сериализация – это механизм, обуславливающий эффективность SOAP-RPC.
Формат сообщений
Все вышеперечисленное выполняется в контексте стандартизованного формата сообщений. Основная часть сообщения имеет MIME тип “text/xml” и содержит SOAP конверт. Этот конверт является XML документом. Конверт содержит заголовок (опционально) и тело (обязательно). Тело конверта всегда предназначено конечному получателю сообщения, тогда как записи в заголовке могут быть адресованы узлам, выполняющим промежуточную обработку. К телу также могут быть присоединены бинарные или какие-либо другие вложения.
SOAP предоставляет клиенту возможность определить, какой из промежуточных узлов обрабатывает ту или иную запись заголовка. Поскольку заголовки ортогональны основному содержимому SOAP сообщения, они полезны для добавления к сообщению той информации, которая не влияет на обработку его тела.
Заголовки, к примеру, могут быть использованы для предоставления цифровой подписи к запросу, находящемуся в теле сообщения. В этом случае сервер аутентификации или авторизации может обработать запись заголовка (независящего от тела), разбирая информацию для проверки правильности подписи. Как только проверка правильности прошла успешно, остальная часть конверта будет передана на SOAP сервер, который обработает тело сообщения. Более детальное рассмотрение конверта SOAP поможет выяснить расположение и цель заголовка и элементов тела.
Анализ конверта SOAP
Спецификация SOAP 1.1 предоставляет следующий образец конверта:
В этом примере запрос GetLastTradePrice посылается службе котировки акций на Web. Запрос принимает строковый параметр, аббревиатуру акции, и возвращает число с плавающей точкой в ответе SOAP.
Конверт SOAP – это верхний элемент XML документа, который представляет сообщение SOAP. Пространства имен XML используются для отделения идентификаторов SOAP от специфичных идентификаторов приложения. Пространства имен XML используются в основном для того, чтобы квалифицировать элементы в сообщении или отнести их к определенной области. Для понимания пространств имен SOAP необходимо быть знакомым со спецификацией пространств имен XML. Если же вы не знакомы с ней, представляйте себе пространство имен, как идентификатор некоторой окрестности элементов, который помогает уникально идентифицировать элементы SOAP, ассоциируя их с определенным местоположением, действительным или воображаемым.
Пространства имен
Первое пространство имен в примере указывает на схему SOAP, которая определяет элементы и атрибуты сообщения SOAP. Второе пространство имен ссылается на кодирование SOAP: типы данных “Section 5”, обсужденные ранее. Поскольку никакого дополнительного поэлементного кодирования не определено, данное кодирование применяется ко всему документу.
Заголовок
Первый элемент в заголовке нашего конверта SOAP является элементом транзакций, имеющим два атрибута: атрибут пространства имен и атрибут mustUnderstand со значением 1. Так как mustUnderstand установлен в 1, сервер, принимающий данное сообщение, должен выполнять промежуточную обработку на данном узле транзакций. Вы можете интерпретировать это следующим образом: сервер и клиент предварительно договорились о семантике, которая управляет обработкой данного элемента заголовка, поэтому сервер точно знает, что делать с содержимым элемента (в данном случае, со значением 5).
Если сервер, получающий сообщение, не понимает семантику обрабатываемого заголовка, он потребует полностью отменить запрос и выдаст ошибку. Элемент ошибки – это специальная часть тела сообщения SOAP и однозначный механизм отправки информации об ошибке клиенту.
Узлы промежуточной обработки, подобные данному, являются примером расширяемости SOAP. Клиенты включают такие узлы в сообщение SOAP, чтобы указать, что прежде чем обрабатывать тело сообщения, необходимо провести специальную обработку. Обеспечение обратной совместимости с серверами, неспособными осуществлять такую обработку, является всего лишь вопросом установки mustUnderstand в 0, что делает эту операцию необязательной.
Кроме того, SOAP сообщения могут содержать в заголовке записи, которые определяют узлы, осуществляющие авторизацию, шифрование, обработку персистенции состояния, обработку бизнес-логики и т.д. Заголовки помогают сделать SOAP модульной расширяемой моделью организации пакетов. Однако следует иметь в виду, что обработка заголовка полностью независима от тела сообщения SOAP.
Тело сообщения
Тело сообщения SOAP в примере содержит полезную нагрузку XML (XML payload), которая, предположим, выполняет RPC (Remote Procedure Calling – вызов удаленной процедуры). SOAP – это не только модульная, но также и довольно скрытая модель организации пакетов.
Здесь ничего явно не указывает на то, что был начат RPC. Все, что мы видим в теле, – это пара XML элементов, один из которых квалифицирован пространством имен. Задачей SOAP сервера является понимание семантики документа и осуществление правильных действий. В действительности, сервер предоставляет структуру для работы с полезной нагрузкой XML (XML payload) “значимым” способом. Слово “значимый” в данном случае подразумевает, что сервер осуществляет вызов удаленной процедуры в некоторой вспомогательной базе данных, чтобы получить готовую цену за элемент готового символа, содержащийся в теле сообщения. Вся магия происходит за занавесом SOAP RPC.
SOAP-RPC
Сообщения SOAP по существу являются односторонними пересылками информации от отправителя к получателю, однако SOAP сообщения часто объединяются для того, чтобы улучшить механизмы запроса и ответа. Для осуществления RPC в SOAP необходимо соблюдать некоторые соглашения. Прежде всего, сообщения запроса и ответа должны быть закодированы как структуры. Для каждого входного параметра операции должен существовать элемент (или член входной структуры) с таким же именем, как у параметра. И для каждого выходного параметра должен существовать элемент (или член выходной структуры) с соответствующим именем.
Далее следует укороченный вид SOAP-RPC сообщения, представленного ранее. Показаны только тела сообщений конвертов запроса и ответа SOAP.
Запрос вызывает метод GetLastTradePrice. Обратите внимание, что ответ определяет операцию GetLastTradePriceResponse. Общее соглашение SOAP требует, чтобы в конце операции запроса (Request) добавлялось слово Response для создания структуры ответа (Response). Данная выходная структура содержит элемент с названием price (цена), который возвращает результат вызова метода, возможно, в виде числа с плавающей точкой.
Важно отметить, что нигде в конверте SOAP не выражены явно типы данных, поэтому мы действительно не знаем тип символа или тип результирующего параметра цены, только лишь смотря на сообщение SOAP. Клиентские приложения определяют типы данных либо открыто посредством кодирования “Section 5”, либо частным образом через согласованные контакты с сервером. В обоих случаях эти определения не включены явно в SOAP сообщение.
И наконец, для осуществления RPC необходим низкоуровневый протокол, такой как HTTP. Хотя спецификация SOAP 1.0 предписывает использование HTTP, как транспортного протокола, SOAP 1.1 (а также спецификация “Сообщение SOAP с вложениями”) разрешает использовать FTP, SMTP и даже (возможно) TCP/IP сокеты. Все правила сериализации и кодирования SOAP относятся также и к RPC-параметрам.
Случай использования SOAP
Теперь, когда мы подробно рассмотрели конверт SOAP, сделаем небольшое отступление и рассмотрим SOAP с позиции случая использования, чтобы уловить смысл спускоподъемной обработки, которая имеет место в распределенном Web-окружении. Ниже приведено несколько основных итоговых суждений, формирующих концептуальную основу Web-сервисов и SOAP.
Клиентское приложение где-либо в Internet потребляет Web-сервисы.
Web-сервисы (через SOAP) выставляют объектные методы.
Объектные методы обращаются к удаленным данным где угодно на Web.
Применяя транзитивную логику к этим сетевым высказываниям, мы можем вывести итоговое суждение о Web-сервисах и SOAP: “Клиенты повсюду потребляют данные, находящиеся где угодно на Web”. Что и требовалось доказать.
Далее случай использования рассмотрен более детально.
Клиент SOAP использует UDDI реестр для локализации Web-сервиса. В большинстве случаев, вместо управления WSDL напрямую, приложение SOAP будет сконструировано так, чтобы использовать специфичный тип порта и стиль связывания, и будет динамически конфигурировать адрес сервиса, вызываемого с целью согласования с сервисом, найденным посредством UDDI.
Клиентское приложение создает сообщение SOAP, которое является XML документом, способным осуществлять необходимые операции запроса/ответа.
Клиент посылает SOAP сообщение JSP или ASP странице на Web-сервере, слушающем запросы SOAP.
Сервер SOAP анализирует пакет SOAP и вызывает соответствующий метод объекта в его области, передаваемой в параметрах SOAP документа. Перед принятием сообщения SOAP сервером узлы промежуточной обработки могут выполнять специальные функции, как указано в заголовках SOAP.
Запрашиваемый объект выполняет обозначенную функцию и возвращает данные SOAP серверу, который запаковывает ответ в конверт SOAP. Затем сервер “кладет” конверт SOAP в объект ответа (например, сервлет или COM-объект), который посылается обратно запрашивающей машине.
Клиент получает объект, “снимает” конверт SOAP и посылает ответный документ программе, первоначально запросившей его, завершая цикл запроса/ответа.
Заключение
SOAP – это основанный на XML протокол для отправки сообщений и осуществления вызовов удаленных процедур в распределенной среде. При использовании SOAP данные могут быть сериализованы безотносительно любого транспортного протокола, хотя обычно выбирается протокол HTTP.
SOAP хорошо подходит для создания взаимодействующих систем, не зависящих от платформы и языка. В целом SOAP и Web-сервисы отвечают за все необходимое при построении инфраструктуры распределенных приложений на вершине XML. SOAP минимизирует проблему межплатформенной совместимости в организации доступа к данным, разрешая конфликт между моделями компонентных объектов COM и Java.
Возвращаясь к метафоре, с которой начиналось обсуждение, отметим, что SOAP – это идеальная среда для объектов любых типов (даже голливудских: Брэда Питта и Эдварда Нортона), используемая в качестве коммуникационной среды. Ожидается, что результаты этой новой технологии (так же, как и в фильме) сотрясут землю.
Ссылки
“Структура для использования Web-сервисов”, Симеон Симонов, XML Journal, том 2, изд. 6.
“SOAP 1.1 и платформа Java: введение в технологию JAX-RPC”, Роберто Чинници и Рауль Шарма, из выступления на конференции разработчиков JavaOne, июнь 2001.
Понимание SOAP, Кеннард Скрайбнер и Марк К. Стайвер, издательство Sams, 2000. (Чрезвычайно подробное, низкоуровневое представление SOAP и сетевых технологий. Великолепная книга для опытных разработчиков XML и Web-сервисов, желающих стать экспертами в SOAP.)
“Написание вашего первого Web-сервиса”, Энди Маккрайт, Web Services Journal, 1-й выпуск, июнь 2001.
XML и SOAP программирование для серверов BizTalk, Брайан Е. Трэвис, издательство Microsoft, 2000. (Пусть название не отпугивает вас. Это превосходный обзор Web-сервисов и SOAP, блестяще написанный и чрезвычайно хорошо организованный. BizTalk отходит на задний план по сравнению с начальными сведениями, которые занимают большую часть текста. Великолепная книга для начинающих.)
Об авторе
Том Клементс является внештатным техническим писателем, специализирующимся на документации по Java API, XML/XSLT, драйверам устройств и беспроводной связи.