Структура SOAP

Лабораторная работа № 16

Язык SOAP

Основы

В лабораторной работе №12 мы рассматривали создание WEB-сервиса, сообщающегося со своими клиентами посредством платформенно-независимого способа передачи данных с использованием метода POST. Подобных способов три, но протокол для них используется один — HTTP. Два способа основаны на методах GETи POST,присущих HTTP, но самым интересным и прогрессивным, пожалуй, является использование языка XML для передачи данных от сервиса к клиенту и обратно. При этом используется не "сырой" XML, а основанный на нем SOAP (Simple Object Access Protocol).

SOAP, как следует из его названия, это простой протокол доступа к объектам. Microsoft давно лелеяла надежду создать сервисы, к которым клиенты могли бы обращаться по общим правилам запроса. Первая попытка была сделана задолго до внедрения технологии Microsoft.NET. Протокол SOAP применялся дня создания сервисов на базе сервера BizTalk. Попытку внедрения этой достаточно сильно связанной пары технологических решений вряд ли можно назвать успешной. Но с появлением феноменальной плат­формы Microsoft.NET протокол SOAP обрел второе дыхание. Он действи­тельно удобен.

Буквально с самых первых версий операционной системы Windows был взят курс на как можно более плотную интеграцию различных приложений. Каждый шаг на этом тернистом пути, будь то DDE (Dynamic Data Exchange) или OLE (Object Linking and Embedding), объявлялся серьезным прорывом. Впрочем, будем объективны, почти всегда именно так и было. Любое усо­вершенствование в этой области давалось очень нелегко.

Однако впервые свет в конце тоннеля (хотя еще не известно, существует ли вообще из этого тоннеля выход) забрезжил с внедрением технологии СОМ (Common Object Model). Эта объектная модель позволяла создавать различные функциональные объекты, которые предоставляли иным программам при помощи специализированных интерфейсов средства работы с собой. Так, если некий COM-объект был способен проверять, орфографию в тексте, любое приложение могло использовать эту его способность, воспользовавшись стандартным интерфейсом объекта СОМ. Таким образом, СОМ-объекты становились чем-то вроде блоков конструктора Лего, из которых умелый разработчик собирал в короткие сроки мощное приложение.

Основным ограничением подобных объектов служила их привязанность к одной платформе — Windows. Конечно, она очень сильно распространена в компьютерной индустрии (причем, в данном случае, слово "очень может оказаться преуменьшением), но все равно, область распространения СОМ-объектов ограничена. Следует также осознавать, что существуют объективные трудности с их использованием в среде Интернет.

Однако идея унифицированных вызовов и стандартизованного доступа к самым различным функциональным объектам на самом деле хороша. И ущемлять интернет-приложения в этой области нет никакого резона. Однако в Интернете много ярче, чем в любой другой области компьютерной индустрии, проявляется именно многоплатформенность. А она никогда не была сильной стороной Microsoft. Но, если решение необходимо найти, скорее всего, оно будет найдено. Особенно, если это решение действительно нужно такой крупной корпорации. И она его нашла.

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

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

SOAP — это протокол, то есть набор правил для создания приложений, которые могут вызывать методы удаленных объектов. Где именно находятся эти удаленные объекты: в другом каталоге, где-то в корпоративной интрасети или в Интернете — для клиентских программ, использующих SOAP, аб­солютно неважно. SOAP основан на XML. По сути дела, каждая передача информации между клиентом и сервисом является отдельным XML- документом, который написан по правилам SOAP.

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

Структура SOAP

Любой документ SOAP (хотя в данном случае лучше все-таки называть их не документами, а сообщениями, так как это лучше передает их предназначение) состоит из двух основных частей: заголовка и собственно тела документа. Причем все это упаковывается в некий "конверт” и в таком виде передается по протоколу HTTP.

Естественно, все эти уровни иерархии создаются при помощи определенных тегов. Простейший пример того, как выглядит SOAP-запрос, упакованный в протокол HTTP, показан в листинге 16.1.