Глава 6 SOAP

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

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

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

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

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

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

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

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

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

Листинг 6.1

POST /MyService HTTP/1.1

Host: www.servicesite.com

Content-Type:text/xml; charset="utf-8"

Content-Length: xxxx

SOAPAction: "www.servicesite.com/action"

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/ envelope" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding">

<SOAP-ENV:Body>

<m:GetSomeValue xmlns:m=" www.servicesite.com/action ">

<symbol>SYM</symbol>

</m:GetSomeValue>

</SOAP-ENV:Body>

</Soap-ENV:Envelope>

Естественно, первые пять строк относятся не к самому SOAP-запросу, а к протоколу HTTP, по которому он доставляется. Шестая строка объявляет конверт SOAP-запроса. В данном примере показан запрос без заголовка, так как в седьмой строке объявляется тело SOAP-запроса, внутри которого располагаются некоторые данные.

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

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

Как было сказано, в SOAP применяются два стандартных пространства имен. Все содержимое SOAP-конверта использует пространство имен, располагающееся по адресу http://shemas.xmlsoap.org/soap/envelope. А применяемые кодировки определены в пространстве имен, находящемся по адресу http://schemas.xmlsoap.org/soap/encoding. В нашем первом примере мы видели ссылки на них.

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

Теперь попробуем определить соотношения между тремя основными блоками SOAP-сообщения. Начнем с более-менее формального описания конверта.

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

Заголовок сообщения SOAP объявляется при помощи элемента Header. Данный компонент не является обязательным. Он используется в тех случаях, когда необходимо расширить стандартную функциональность SOAP-сообщения. В заголовке находятся элементы, которые будут подсказывать приложению, обрабатывающему SOAP-запрос, какие именно функции будут реализованы при помощи данного SOAP-сообщения. Заголовок SOAP-сообщения является прямым потомком конверта, т. е. на уровне тегов он просто вкладывается в теги с наименованием Envelope.

Тело SOAP-сообщения объявляется при помощи элемента Body. Этот компонент является обязательным. Так же, как и заголовок, он является прямым потомком конверта. Естественно, как тело, так и заголовок могут существовать в сообщении SOAP только в единственном экземпляре. В том случае, если у сообщения есть заголовок, тело сообщения должно объявляться сразу после заголовка, т. е. открывающий тег тела сообщения должен вплотную примыкать к закрывающему тегу заголовка сообщения.

Во всех компонентах SOAP-сообщения, на любом уровне вложенности тегов может использоваться атрибут encodingstyle, который сообщает, какой набор правил должен применяться для представления данных компонента. Чаще всего при помощи этого атрибута указывают используемую кодировку символов. В качестве значений атрибута используются элементы уже упоминавшегося пространства имен http://schemas.xmlsoap.org/soap/encoding. Если для какого-либо компонента SOAP-сообщения не указан явным образом данный атрибут, то используются атрибуты родительских компонентов. Проще говоря, если разработчик или приложение задали правила отображения в заголовке, то они будут распространены на все приложение, за исключением тех его элементов. в которых явным образом установлено другое значение данного атрибута.

Теперь перейдем к более детальному рассмотрению правил создания заголовка и тела SOAP-сообщений.

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

<SOAP-ENV:Header>

<trans .-Transaction xmlns : trans="http: //www.myhost. com/namespaces/ myspace/"

SOAP-ENV:mustUnderstand="l">

12

</trans:Transaction>

</SOAP-ENV:Header>

В этом маленьком примере мы объявили элемент заголовка с наименованием Transaction. При этом пространство имен, в котором описан данный элемент, находится по адресу http://www.myhost.com/naraespaces/rayspace/. Значение элемента Transaction в данном случае равно двенадцати. Также данный элемент обладает атрибутом mustunderstand с единичным значением. Об этом атрибуте следует поговорить несколько подробнее.

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

Подобный атрибут может принимать всего два значения — единичное и нулевое. Атрибут mustunderstand с нулевым значением эквивалентен отсутствию этого атрибута.

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

Помимо атрибута mustunderstand, у элементов заголовка SOAP-сообщения может быть атрибут actor. Как говорилось несколько ранее, одно и то же сообщение может обрабатываться несколькими приложениями. При этом оно передается между ними по цепочке, т. е. приложение, обработавшее сообщение, передает его следующему получателю. При этом в заголовке сообщения могут находиться элементы, предназначенные для разных приложений. И далеко не факт, что элементы, помеченные как mustunderstand, будут "понятны" каждому приложению в цепочке. Приложения потому и разные, что у каждого своя функциональность, и для каждого есть свой набор элементов, которые они обязаны "понимать". Поэтому необходимо каким-либо образом указывать, для какого именно приложения предназначен тот или иной элемент. Именно для этой цели и существует атрибут actor.