Обзор SOAP
SOAP позволяет объектам любого вида, т.е. написанным под любую платформу и на любом языке, перекрестно взаимодействовать. В настоящее время SOAP реализован в более 60 языках и более 20 платформах. Неожиданно все объекты, локальные и удаленные, маленькие и большие, получили возможность взаимодействия друг с другом.
Том Клементс
Январь 2002
В фильме “Бойцовский клуб” Брэд Питт и Эдвард Нортон играют роль второго “я” - противоположные стороны психологического спектра – два парня, которые пытаются общаться друг с другом и с трудом заставляют себя это делать. Довольно интересно (и в этом вся соль), что основные события фильма развиваются вокруг производства мыла. Оказалось, что буквы английского слова soap (мыло) соединяются уникальным и неожиданным образом.
Теперь перейдем к сценарию другого рода, действие которого происходит в Internet и представителями второго “я” являются компании Microsoft и Sun. Каждая из этих компаний имеет свою четкую точку зрения, пытается ликвидировать разрыв и наладить контакты с другой. Узнайте о SOAP (Simple Object Access Protocol – Простой Объектный Протокол Доступа).
Содержание
Введение
Эволюция Web-сервисов
Сетевые уровни
XML: ключ к описанию Web-сервисов
Слабосвязанные системы
Второе пришествие CORBA
Публикация, нахождение, связывание
Создание Web-сервисов
SOAP клиенты и серверы
SOAP и Java технология
Так что же такое в действительности SOAP?
Формат сообщений
Анализ конверта SOAP
Пространства имен
Заголовок
Тело сообщения
SOAP-RPC
Случай использования SOAP
Заключение
Ссылки
Об авторе
Введение
Выражаясь просто, 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 предоставляет следующий образец конверта:
<SOAP-ENV: Envelope xmlns: SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI"> SOAP-ENV:mustUnderstand="1" 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="some-URI"> <symbol>DEF</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-Envelope>
В этом примере запрос 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.
Request (Запрос) <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="some-URI"> <symbol>DEF</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> Response (Ответ) <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="some-URI"> <price>22.50</price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body>
Запрос вызывает метод 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, драйверам устройств и беспроводной связи.