XML веб сервисы. Протокол SOAP. Основные концепции. Структура SOAP-сообщения

Причина ошибки . Содержит необязательный атрибут xml: lang, указывающий язык сообщения (см. главу Г), и произвольное число вложенных элементов с описанием ошибки.

Необязательные элементы.

? - адрес URI промежуточного SOAP-узла, заметившего ошибку.

? - роль SOAP-узла, заметившего ошибку.

? - описание ошибки, замеченной при обработке тела послания, но не заголовка.

Листинг 3.2 показывает сообщение об ошибке, возникшей при попытке выполнения процедуры. Ошибка заключается в том, что имена аргументов процедуры неправильно записаны в SOAP-послании и процедура не может их понять.

Листинг 3.2. Сообщение об ошибке

xmlns:env="http://www.w3.org/2002/06/soap-envelope" xmlns:rpc=’http://www.w3.org/2002/06/soap-rpc’>

env:Sender

rpc:BadArgumentsc/env:Value>

Ptocessing ETror

xmlns:e="http://www.example.org/faults"> №me does not match 999

Типы ошибок

Список кодов ошибок постоянно меняется и расширяется. Версия 1.1 определяет четыре типа ошибок.

VersionMismatch - пространство имен неопознано. Может быть, оно устарело или его имя написано неправильно.

MustUnderstand - блок заголовка, помеченный атрибутом mustUnderstand со значением 1, не отвечает своему синтаксису, определенному в схеме документа.

Client - документ XML, содержащий послание, неправильно сформирован и по этой причине сервер не может его обработать. Клиенту следует изменить послание.

Server - сервер не может обработать правильно записанное послание по своим внутренним причинам.

Версия 1.2 определяет пять типов ошибок.

VersionMismatch - пространство имен неопознано. Может быть, оно устарело или его название написано неправильно, или в послании встретилось имя элемента XML, не определенное в этом пространстве имен. В заголовок ответа сервер записывает элемент , перечисляющий вложенными элементами правильные названия пространств имен, понимаемые сервером. Ответ сервера показан в листинге 3.3.

MustUnderstand - блок заголовка, помеченный атрибутом mustunderstand со значением true, не отвечает своему синтаксису, определенному в схеме документа. Сервер записывает в заголовок ответа элементы , атрибут qname которых содержит имя неправильного блока. Листинг 3.4 содержит пример ответа, который будет сделан сервером, если заголовок листинга 3.1 окажется неправильно записанным.

DataEncodingUnknown - в послании встретились непонятные данные, может быть, они записаны в неизвестной кодировке.

Sender - документ XML, содержащий послание, неправильно сформирован и по этой причине сервер не может его обработать. Клиенту следует изменить послание.

Receiver - сервер не может обработать правильно записанное послание по своим внутренним причинам, например, отсутствует нужный XML- парсер.

Сервер может добавить к этим типам ошибок какие-то свои типы. Обычно

они детализируют стандартные типы, и сообщения о них появляются в элементах , как было показано выше в листинге 3.2.

? Листинг 3.3. Ответ сервера с сообщением об ошибке типа VersionMismatch

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

xmlns:upg="http://www.w3.org/2002/06/soap-upgrade">

xmlns:nsl="http://www.w3.org/2002/06/soap-envelope"/>

xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>

env:VersionMismatch

Version Mismatch

ЛистонгЗ.4. Ответ сервера с сообщением об ошибке типа MustUnderstand

xmlns:t=’http://some.com/transaction’ />

env:MustUnderstand

One or more mandatory headers not understood

Литература:

Хабибуллин И. Ш. Разработка Web-служб средствами Java. - СПб.: БХВ-Петербург, 2003. - 400 с: ил.

Вообще сегодня есть стандартные протоколы обмена XML данными:

• XML-RPC – вы передаете пакет и указываете, какой метод на сервере хотите вызвать.
• REST - есть некие объекты на сервере. Каждый объект характеризуется каким-то идентификатором. У каждого элемента свой url. С любым элементов можно сделать: insert, delete, update, select. Вы просто посылаете нужный запрос на сервер (например, вставить такой-то элемент). Обмен клиент-сервер базируется либо на JSON, либо на XML.

Именно на RPC базируется SOAP (сервис ориентированная архитектура, набор слабосвязанных сервисов, взаимодействующих друг с другом). Главное достоинство RPC - небольшое количество сетевых ресурсов (точек входа) и много задействованных методов. Несмотря на это достоинство, у RPC - это устаревший протокол, у которого ряд недостатков:

• Нельзя проверить правильность XML-RPC сообщения. Старый протокол, создавался до того, как в XML были стандартизированы схемы (способы проверки данных). Т.е. сервер принимает запросы, он должен убедиться, что эти запросы для него, и что данные не противоречивы. В XML-RPC для этого типы данных декларируются, но это проверка типа данных, а согласованность данных не проверяется (что вы получили структуру со всеми нужными параметрами).
• Нельзя создавать комбинированные сообщения.
• Нельзя использовать пространство и время (появилось позже создания RPC).
• Нельзя расширять сообщение, т.е. добавлять дополнительную информацию.

Все эти недостатки были решены в XML Schema. Это промышленный стандарт описания XML документа. Т.е. это способ моделирования произвольных данных. XML схема может описывать модель (отношения между элементами и атрибутами, и их структура), типы данных (характеризует типы данных) и словарь (названия элементов и атрибутов).

Исходя из всех недостатков XML-RPC создали протокол SOAP.

SOAP (Simle Object Access Protocol) - протокол доступа к объекту (к точке входа). Сегодня это основной промышленный стандарт построения распределенных приложений.

Он представляет собой расширения языка XML-RPC. Т.е. он построен по принципу: 1 точка входа и любые методы. Сам протокол в плане транспорта (как передать данные) дает широкий выбор: SMTP, FTP, HTTP, MSMQ.

SOAP лежит в основе реализации XML веб-сервисов (XML веб служб). Недостаток SOAP - сложен в изучении.

SOAP базируется на обмене сообщениями между клиентом и сервером (синхронно и асинхронно). Каждое сообщение несет информацию о данных (какие данные передаются-получаются). SOAP заранее описывает всю структуру сообщения с помощью XML схем: что должно быть в сообщении, как оно будет передаваться. Это дает возможность, не зная сервер, понять, что там происходит, и дает возможность серверу проверить, для него ли это сообщение.

XML схема

Задача схемы - описать структуру данных, т.е. что у нас есть. Все данные делятся на простые и сложные типы (скаляры и структуры). Простой тип (строка, число, boolean, дата) никогда внутри ничего содержать не будет. А структура (объект) может содержать свойства.

Основные операции SOAP

• Не только простой обмен информацией клиент-сервер. Но и автоматическое распознавание сервера и поиск этого сервера, т.е. клиент может даже ничего не знать про сервер. Т.е. клиент сначала выполняет поиск сервера, найдет подходящие службы, поймет какие там методы, что на сервера есть, и произведет его вызов.
• Сервер производит публикацию своей информации (расположение, какие методы поддерживает), чтобы клиент нашел этот сервер. Публикация происходит в UDDI каталог.

Структура SOAP сообщений:

• SOAP Envelope (конверт) - сюда входит все сообщение. Состоит из заголовка и тела.
• SOAP Header (заголовок) - дополнительная информация (авторизация, например).
• SOAP Body (тело) - само сообщение.
• SOAP Fault (ошибка) - способ передачи ошибки от сервера к клиенту.

WSDL

WSDL (Web Services Description Language) - язык описания веб служб. Применяется в SOAP. Это некий докуент, который описывает все: какие пространства имен использовались, какие схемы данных использовались, какие типы сообщений сервер ждет от клиента, какие конверты к какому методу принадлежат, какие методы вообще есть, на какой адрес отправлять и т.д. Собственно, WSDL и есть веб сервис. Достаточно клиенту изучить содержимое этого документа, он уже знает о сервере все.

Любой сервер должен публиковать WSDL.

WSDL состоит из блоков:

• Определение самой службы, т.е. точки входа, указывается порт.
• Формат методов. Происходит привязка точки входа к операциям, т.е. какие методы поддерживает. Указывается тип вызова, способ передачи. Внутри каждого метода происходит объяснение - в каком виде передаются данные - в виде SOAP.
• Привязка методов к сообщению.
• Описание самих сообщений.

Лирическая часть.

Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.

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

Другие системы, обращаясь к этому серверу уже могут распоряжаться полученными от этого сервера данными по своему усмотрению - обрабатывать, накапливать, выдавать своим клиентам и т.д.

Ну вот, один из вариантов общения с такими серверами - это SOAP. SOAP протокол обмена xml-сообщениями.

Практическая часть.

Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты) дает возможность общения с сервером четко структурированными сообщениями. Дело в том, что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).

WSDL (Web Services Description Language). Правила, по которым составляются сообщения для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е. если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.

В качестве параметров могут передаваться не только простые типы, но и объекты, коллекции объектов. Описание объекта сводится к описанию каждой составляющей объекта. Если объект состоит из нескольких полей, значит описывается каждое поле какой у него тип, название (какие возможные значения). Поля также могут быть сложного типа и так далее пока описание типов не закончится на простых - строка, булево, число, дата... Впрочем простыми могут оказаться какие-то специфические типы, важно чтоб клиенты могли понять какие значения могут в них содержаться.

Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.

Какие плюсы у всех этих наворотов:

• В большинстве систем описание методов и типов происходит в автоматическом режиме. Т.е. программисту на сервере достаточно сказать, что данный метод можно вызывать через веб-сервис, и wsdl-описание будет сгенерировано автоматом.

Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding"и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):

NewUser:=TSoapUser.Create("Вася","Пупкин","odmin"); soap.AddUser(NewUser);

• Автоматическая валидация.

  • xml-валидация. xml должен быть well-formed. невалидный xml - сразу ошибка клиенту, пусть разбирается.
  • schema-валидация. xml должен иметь определенную структуру. xml не соответствует схеме - сразу ошибка клиенту, пусть разбирается.
  • проверка данных осуществляется soap-сервером, чтобы типы данных, ограничения соответствовали описанию.
• Авторизация и аутентификация может быть реализована отдельным методом. нативно. либо, используя http-авторизацию.
• Веб-сервисы могут работать как по soap-протоколу, так и по http, то есть через get-запросы. То есть, если в качестве параметров идут простые данные (без структуры), то можно вызвать просто обычный get www.site.com/users.asmx/GetUser?Name=Vasia или post. Впрочем это не везде и не всегда.
• ... см. в википедии

Минусов тоже полно:

• Неоправданно большой размер сообщений. Ну тут сама природа xml такова, что формат избыточный, чем больше тэгов, тем больше неполезной информации. Плюс soap добавляет своей избыточности. Для intranet-систем вопрос трафика стоит менее остро, чем для internet, поэтому soap для локальных сетей более востребован, в частности у Sharepoint есть soap веб-сервис, с которым с успехом (и некоторыми ограничениями) можно общаться.
• Автоматическая смена описания веб-сервиса может сломать все клиенты. Ну это как бы для любой системы так, если не поддерживается обратная совместимость со старыми методами, все отвалится...
• Не минус, но недостаток. Все действия по вызову методов должны быть атомарными. Например, работая с субд мы можем начать транзакцию, выполнить несколько запросов, потом откатиться или закоммитить. В soap транзакций нет. Один запрос-один ответ, разговор закончен.
• Разбираться с описанием, что на стороне сервера (все ли правильно описано у меня?), что на клиенте (что мне тут наописывали?) бывает довольно сложно. Было несколько раз, когда мне приходилось разбираться с клиентской стороны, и убеждать серверного программера, что у него неверно описаны данные, а он в них вообще ничего понять не мог, ибо автоматическая генерация и он как бы и не должен, это дело софта. А ошибка естественно была в коде метода, программер ее не видел просто.
• Практика показывает, что разработчики веб-сервисов страшно далеки от народа, использующего эти веб-сервисы. В ответ на какой-либо запрос (валидный со стороны) может прийти невразумительная ошибка "Ошибка 5. Все плохо". Все зависит от совести разработчиков:)
• еще наверняка что-то не вспомнил...

В качестве примера есть открытый веб-сервис belavia:

• http://86.57.245.235/TimeTable/Service.asmx - точка входа, там же текстовое описание методов для сторонних разработчиков.
• http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl описание методов и типов принимаемых и возращаемых данных.
• http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - описание конкретного метода с примером вида xml-запроса и xml-ответа.

Можете вручную создать и послать запрос типа:

POST /TimeTable/Service.asmx HTTP/1.1 Host: 86.57.245.235 Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://webservices.belavia.by/GetAirportsList" ru

в ответ придет:

HTTP/1.1 200 OK Date: Mon, 30 Sep 2013 00:06:44 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 Cache-Control: private, max-age=0 Content-Type: text/xml; charset=utf-8 Content-Length: 2940

ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.

История создания

С появлением персональных компьютеров появилась и необходимость их объединения. Сначала были простые кабельные соединения, потом появились сетевые протоколы объединяющие компьютеры работающие на одной ОС, с развитием технологий отпала необходимость иметь одну ОС на всех компьютерах и появилась возможность объединения компьютеров работающих под разными ОС. Интернет изменил скорость движения по пути объединения.

Но и на сегодняшний день еще не все проблемы интеграции решены к сожалению не было единого протокола для коммуникационной связи между Интернет-приложениями и сервисами. Для решения этой проблемы объединились такие компании как Microsoft, DevelopMentor, UserLand Software, IBM и Lotus Development и в результате их совместной деятельности получился (Simple Object Access Protocol) простой протокол доступа к объектам описывает стандарт удаленного вызова процедур на основе языка XML (Extensible Markup Language - расширяемый язык разметки). SOAP призван предельно упростить разработку межъязыковых приложений и средств интеграции бизнеса. Начало было положено SOAP 1.0 для работы которого требовался протокол НТТР.

После появления начальной версии SOAP, созданной, как уже отмечалось, объединенными усилиями Microsoft, DevelopMentor и UserLand, к разработке продукта подключились IBM и Lotus. В результате спецификация подверглась существенной переделке и стала лучше подходить для интеграции разнородных сред. Главным отличием следующей версии SOAP 1.1 от начальной версии стал переход с XML-Data корпорации Microsoft на XML Schema. К тому же в новом варианте спецификация перестала зависеть от транспортных протоколов. Для работы SOAP 1.0 требовался протокол НТТР, тогда как для SOAP 1.1 разновидность транспорта значения не имеет: для пересылки сообщений можно воспользоваться электронной почтой или указателями на очереди сообщений (massage queving links). Компании, уже взявшие на вооружение SOAP 1.0, оказались привязанными к нестандартной технологии Microsoft. Впрочем, ряд перспективных продуктов этой корпорации, включая BizTalk Server и SQL Server 7.0, также опирается на XML-Data. С появлением версии 1.1 круг сторонников протокола SOAP расширяется

Первоначальная версия SOAP 1.1, представленная в Целевую группу технической поддержки Интернета IETF, имела в своей основе технологию XML-Data, предложенную корпорацией Microsoft в январе 1998 г. Однако в процессе рассмотрения стандартов в консорциуме W3C базовая структура была заменена на XML Schema. World Wide Web Consortium было предложено рассмотреть SOAP 1.1 в качестве потенциального стандарта.

Новейшая версия спецификации протокола Simple Object Access Protocol (SOAP) доступна на веб-сервере, обслуживающем участников программы MSDN™ для разработчиков (http://msdn.microsoft.com/). SOAP - это открытый, построенный на стандартах протокол, который определяет на основе XML (Extensible Markup Language) общий формат для коммуникационной связи между любыми Интернет-приложениями и сервисами. Эта версия расширяет возможности SOAP в асинхронной коммуникационной связи и теперь включает поддержку не только HTTP, но и таких Интернет-протоколов, как SMTP, FTP и TCP/IP. Последняя версия спецификации SOAP встретила широкую поддержку со стороны таких компаний, как ActiveState Tool Corp., Ariba Inc., BORN Information Services Inc., Commerce One Inc., Compaq Computer Corp., DevelopMentor Inc., Extensibility Inc., IBM, IONA Technologies PLC, Intel Corp., Lotus Development Corp., ObjectSpace Inc., Rogue Wave Software Inc., Scriptics Corp., Secret Labs AB, UserLand Software и Zveno Pty. Ltd. Спецификация SOAP предоставляет общий механизм для интеграции сервисов в Интернете и/или интрасетях независимо от применяемой операционной системы, модели объектов или языка программирования. Основанный на Интернет-стандартах XML и HTTP, протокол SOAP позволяет взаимодействовать друг с другом любым новым или существующим приложениям. Web-узлы, поддерживающие SOAP, могут стать Web- сервисами, доступными чисто программным путем и не требующими участия человека. Единая инфраструктура, обеспечивающая прямое взаимодействие связанных с Интернетом приложений, открывает новые возможности в интеграции сервисов и устройств - в какой бы точке Интернета они ни находились.

Веб-сервисы и SOAP

Веб-сервисы и SOAP призваны решить проблемы кросс-платформенного взаимодействия приложений. Статья поможет получить представление об этих новых перспективных технологиях.

Что такое SOAP

В настоящее время используемые технологии удаленного вызова методов (DCOM, CORBA/IIOP и RMI) довольно сложны в настройке и организации взаимодействия. Это влечет за собой проблемы в эксплуатации и функционировании распределенных систем (проблемы безопасности, транспорт через брандмауэры и т.д.). Существующие проблемы успешно решены созданием SOAP (Simple Object Access Protocol), простого протокола, основанного на XML, для обмена сообщениями в распределенных средах (WWW). Он предназначен для создания веб-сервисов и удаленного вызова методов. SOAP можно использовать с разными транспортными протоколами, включая HTTP, SMTP и т.д.

Что такое веб-сервисы

Веб-сервисы - это функциональность и данные, предоставляемые для использования внешними приложениями, которые работают с сервисами посредством стандартных протоколов и форматов данных. Веб-сервисы полностью независимы от языка и платформы реализации. Технология веб-сервисов является краеугольным камнем программной модели Microsoft .NET. Для демонстрации возможностей SOAP я использовал недавно вышедшую реализацию SOAP Toolkit версии 2.0 от Microsoft. Следует заметить, что текущая версия Toolkit заметно отличается от предыдущей (Microsoft SOAP Toolkit for Visual Studio 6.0) и от бета версии SOAP Toolkit 2.0.

Механизм взаимодействия клиента и сервера

1. Клиентское приложение создает экземпляр объекта SOAPClient
2. SOAPClient читает файлы описания методов веб-сервиса (WSDL и Web Services Meta Language - WSML). Эти файлы могут храниться и на клиенте.
3. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет на сервер. Возможно использование любого транспортного протокола, но, как правило, используется HTTP.
4. Пакет принимает серверное приложение Listener (может представлять собой ISAPI приложение или ASP страницу), создает объект SOAPServer и передает ему пакет запроса
5. SOAPServer читает описание веб-сервиса, загружает описание и пакет запроса в XML DOM деревья
6. SOAPServer вызывает метод объекта/приложения, реализующего сервис
7. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту
8. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.

WSDL файл это документ в формате XML, описывающий методы, предоставляемые веб-сервисом. Также параметры методов, их типы, названия и местонахождение Listener`а сервиса. SOAP Toolkit визард автоматически генерирует этот документ.

SOAP Envelope (Пакет) - XML документ, который содержит в себе запрос/ответ на выполнение метода. Удобнее всего рассматривать его как почтовый конверт, в который вложена информация. Тэг Envelope должен быть корневым элементом пакета. Элемент Header не обязателен, а Body должен присутствовать и быть прямым потомком элемента Envelope. В случае ошибки выполнения метода сервер формирует пакет, содержащий в тэге Body элемент Fault, который содержит подробное описание ошибки. Если вы пользуетесь высокоуровневыми интерфейсами SOAPClient, SOAPServer, то вам не придется вдаваться в тонкости формата пакета, но, при желании, можно воспользоваться низкоуровневыми интерфейсами или же вообще создать пакет "руками".

Объектная модель SOAP Toolkit дает возможность работать с объектами низкоуровневого API:

• SoapConnector - Обеспечивает работу с транспортным протоколом для обмена SOAP пакетами
• SoapConnectorFactory - Обеспечивает метод создания коннектора для транспортного протокола, указанного в WSDL файле (тэг)
• SoapReader - Читает SOAP сообщения и строит XML DOM деревья
• SoapSerializer - Содержит методы создания SOAP сообщения
• IsoapTypeMapper, SoapTypeMapperFactory - Интерфейсы, позволяющие работать со сложными типами данных

Используя объекты высокоуровневого API можно передавать данные только простых типов (int, srting, float …), но спецификация SOAP 1.1 допускает работу с более сложными типами данных, например с массивами, структурами, списками и их комбинациями. Для работы с такими типами приходится использовать интерфейсы IsoapTypeMapper и SoapTypeMapperFactory.