Разное

Протокол soap – SOAP — Википедия

SOAP — Википедия

Материал из Википедии — свободной энциклопедии

Структура SOAP-сообщения

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Сообщение SOAP выглядит так:

SOAP-конверт 

Пример SOAP-запроса на сервер интернет-магазина:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productID>12345</productID>
     </getProductDetails>
   </soap:Body>
</soap:Envelope>


Пример ответа:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
       <getProductDetailsResult>

ru.wikipedia.org

XML веб сервисы и характеристика протокола SOAP

Вообще сегодня есть стандартные протоколы обмена 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

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.
  • Привязка методов к сообщению.
  • Описание самих сообщений.

1st-network.ru

Введение в SOAP

[Disclaimer: Данная статья была переведена в рамках "Конкурса на лучший перевод статьи" на сервисе Quizful. Ссылка на оригинал находится внизу страницы.]

Что такое SOAP?

SOAP расшифровывается как Simple Object Access Protocol (Простой Протокол Доступа к Объектам). Надеюсь по прочтении статьи вам останется только недоумевать: "Что за странное название?"

SOAP в теперешней его форме – это метод удаленного вызова (RPC, Remote procedure Call) по сети. (Да, он также используется для передачи документов в виде XML, но мы это пока опустим).

Давайте разбираться. Представьте, что у вас есть сервис, который возвращает биржевую котировку (stock quote) для заданного тикера (stock symbol). Он посылает данные на сайт Nasdaq и формирует на основе возвращенного HTML нужный результат. Дальше, чтобы позволить другим разработчикам использовать его внутри своих приложений, вы делаете из этого сервиса компонент, который через Интернет находит информацию о котировках. Работает он отлично, пока в один прекрасный день Nasdaq не меняет разметку своих страниц. Вам приходится пересмотреть всю логику работы компонента и разослать обновления всем разработчикам, использующим его. А им в свою очередь необходимо разослать обновления всем своим пользователям. Если это происходит на более-менее постоянной основе, вы можете нажить немало врагов среди коллег-разработчиков. А с программистами, как известно, шутки плохи. Вы же не хотите завтра доставать фотографию любимого кота из офисного шредера, правда?

Что же делать? Посмотрим... все, что вам нужно, это предоставить одну функцию, которая будет принимать на вход тикер (типа string) и возвращать биржевую котировку (типа float или double). Так не проще ли было бы просто позволить вашим разработчикам каким-то образом вызвать эту функцию через Интернет? Отлично! Тоже мне новость, есть же COM и Corba, и Java, которые этим занимаются уже годами... что правда – то правда, но эти методы не без изъяна. Удаленная настройка COM не тривиальна. Кроме того, нужно открыть столько портов в брандмауэре, что на системного администратора пива не напасешься. Да, и придется забыть о пользователях всех операционных систем кроме Windows. Но ведь позьзователи Linux тоже иногда интересуются биржей.

Хотя, похоже, что не все потеряно для пользователей Linux, если они используют DCOM, больше здесь: http://www.idevresource.com/com/library/res/articles/comonlinux.asp.

На счет Corba и Java я много сказать не могу, так что в качестве упражнения предлагаю читателям найти минусы в этих подходах.

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

О чем эта статья

Это первая из серии статей о SOAP, которые мы пишем в Agni Software. В этой статье я постараюсь дать вам представление о том, что такое SOAP и как написать приложение, общающееся с SOAP сервером.

Soap и XML

Если вам SOAP пока еще кажется простым, добавим XML. Теперь вместо имени функции и параметров мы получаем довольно сложный XML-конверт, как будто созданный для того, чтобы сбить вас с толку. Но не спешите пугаться. Дальше – больше, и вам нужно увидеть всю картину, чтобы оценить всю сложность SOAP.
Если вы не знаете, что такое XML, для начала прочтите мою статью об XML здесь: http://www.agnisoft.com/white_papers/xml_delphi.asp.

Все SOAP пакеты имеют XML формат. Что это значит? Посмотрим. Взгляните на эту функцию (Pascal):

function GetStockQuote( Symbol : string ) : double;
Выглядит отлично, но проблема в том, что это – Pascal. Какая польза от этого простого определения для Java-разработчика? Или для кого-то, кто работает с VB? Нам нужно что-то, что будет понятно всем, даже VB-программистам. Так дайте им XML, содержащий одну и ту же инфрмацию (параметры, значения биржевых котировок и т.д.). Вы создаете SOAP пакет, который по сути является вызовом вашей функции, обернутый в XML, чтобы любое приложения на любой платформе могло его понять. Теперь посмотрим, как выглядит наш SOAP вызов:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:GetStockQuote xmlns:ns1="urn:xmethods-quotes">

<SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<symbol xsi:type="xsd:string">IBM</symbol>
</ns1:GetStockQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.

Расшифровка тегов

Первый тег, который бросается в глаза – это . Этот тег – внешняя оболочка SOAP пакета, содержащая несколько объявлений пространств имен, которые нас особо не интересуют, но очень важны для любого языка программирования или парсера. Пространства имен определяются для того, чтобы последующие префиксы, такие как "SOAP-ENV:" или "xsd:" воспринимались парсером.

Следующий тег – <SOAP-ENV:Body>. (Мы пропустили тег, не представленный здесь – <SOAP-ENV:Header>. Его нет в этом конкретном примере, но если вы хотите почитать о нем больше, обратитесь к спецификации SOAP здесь: http://www.w3.org/TR/SOAP/). Тег <SOAP-ENV:Body> собственно и содержит SOAP вызов.

Следующий тег в списке – <ns1:GetStockQuote ...>. Имя тега, GetStockQuote и есть вызываемая функция. Согласно терминологии SOAP, это называется операцией. Таким образом GetStockQuote – операция, которая должна быть выполнена. ns1 – это пространство имен, указывающее на urn:xmethods-quotes в нашем случае.

Лирическое отступление на счет пространств имен: Пространство имен дает возможность квалифицировать XML тег. Нельзя, к примеру, иметь две переменные с одинаковым именем в одной процедуре, но если они в двух разных процедурах, проблем не возникает. Таким образом процедура – это пространство имен, так как все имена в ней уникальны. Точно так же XML теги имеют свою область видимости внутри пространств имен, так что имея пространство имен и имя тега, можно однозначно его идентифицировать. Мы определим пространство имен как URI, чтобы отличать наш NS1 от подражателей. В приведенном выше примере NS1 – это алиас, указывающий на urn:xmethods-quotes.

Обратите внимание также на атрибут encodingStyle – этот атрибут определяет каким образом сериализуется SOAP вызов.

Внутри тега <GetStockQuote> содержатся параметры. В нашем простейшем случаи у нас есть только один параметр – тег <symbol>. Обратите внимание на эту строку возле тега:

xsi:type="xsd:string"
Приблизительно так в XML и определяются типы. (Обратите внимание на то, как хитро я использовал слово "приблизительно", делая обобщение о технологии, которая может измениться как только статья будет опубликована). Что конкретно это означает: тип, определенный в пространстве имен xsi, который, как вы заметили, определен в теге – xsd:string. А это в свою очередь string, определенный в пространстве имен xsd, опять-таки, определенном ранее. (Уверен, юристы бы от этого всего просто млели).

Внутри тега <symbol> указано "IBM". Это – значение параметра symbol функции GetStockQuote.

Ну и в конце, как порядочные люди, мы закрыли все теги.

Вот и разобрались с SOAP пакетом, определяющим вызов к SOAP серверу. А SOAP сервер с помощью XML парсеров, красной кнопки и космической станции "МИР" декодирует этот вызов и определяет, что вам нужна биржевая котировка. Он тут же находит нужную котировку и возвращает вам ее в таком виде:

<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:GetStockQuoteResponse xmlns:m="urn:xmethods-quotes">
<Price>34.5</Price>
</m:GetStockQuoteResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
После разворачивания SOAP конверта, срывания ленточек и шуршания оберткой, мы узнаем, что цена акции IBM – 34.5.

Большинство коммерческих серверов вернуло бы гораздо больше информации, например, в какой валюте и за какую цену была куплена последняя акция. Да и цена акции, пожалуй, была бы поточнее.

Таким образом мы знаем, чего ожидает SOAP сервер и что он вернет. Так КАК же отправить эту информацию? Использовать можно любой транспорт. Самым освещенным является HTTP. Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.

Нужный HTTP запрос будт выглядеть приблизительно так:

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

...the soap request packet here...

Единственное, что еще стоит отметить – это заголовок SOAPAction. Этот заголовок указывает на цель запроса и является обязательным. Каждый SOAP сервер может иметь неограниченное количество функций и может использовать заголовок SOAPAction чтобы определить какую функцию вызывают. Брандмауэры и мультиплексоры также могут фильтровать контент на основании этого заголовка.

SOAP ответ от HTTP сервера будет выглядеть следующим образом:

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

...Soap Response packet here...

Почему HTTP? Во-первых, сетевым администраторам не придется открывать уйму отдельных портов для SOAP вызовов... веб-сервер может спокойно обрабатывать вызовы, т.к. 80-й порт обычно открыт для всех для приема входящих запросов. Еще одним преимуществом является расширяемость веб-серверов с помощью CGI, ISAPI и других нативных модулей. Эта расширяемость позволяет написать модуль, обрабатывающий SOAP запросы не задевая другого веб-контента.

Вот и все

Надеюсь, эта статья помогла пролить немного света на SOAP. Если вы еще здесь и хотите почитать больше на эту тему, посетите сайт авторов: http://www.agnisoft.com/soap

----------
Оригинальный текст статьи: Introduction to SOAP

www.quizful.net

Протокол SOAP | Computerworld Россия

Определение

Simple Object Access Protocol (SOAP) — это протокол на базе языка XML, который определяет правила передачи сообщений по Internet между различными прикладными системами. В основном он используется для удаленного вызова процедур. Изначально протокол SOAP разрабатывался с тем расчетом, что он будет функционировать «над» HTTP (дабы упростить интеграцию SOAP в Web-приложения), однако теперь могут быть задействованы и иные транспортные протоколы, например SMTP.

Предположим, что вы создаете в Internet службу доступа к приложениям; потребители взаимодействуют с этой службой, передавая ей информацию. Ваши серверы обрабатывают данные и возвращают результаты потребителям. Как лучше всего поддерживать обмен данными с системой?

Вы могли бы создать настраиваемое клиент-серверное приложение и потребовать, чтобы потребители использовали для доступа к вашей службе специальную клиентскую программу. Но если вы намерены всерьез найти себя в Internet-бизнесе, вам придется создать клиент, работающий на всех возможных клиентских платформах — Windows, Macintosh, Unix, Linux и т. д. Другими словами, потребуется написать множество различных клиентов.

А как вы отнесетесь к использованию Web? Такое решение, естественно, вполне приемлемо, но жестко завязано на реализации браузера, и вам опять-таки придется создавать инфраструктуру, чтобы посылать и получать входящую и исходящую информацию, а также форматировать и упаковывать данные для подобного обмена. Для реализации сложных приложений можно выбрать Java или ActiveX, но тогда некоторые пользователи откажутся от ваших услуг из-за явно завышенных требований к полосе пропускания и неадекватной защиты.

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

Достаточно подробно описанный Simple Object Access Protocol (SOAP) представляет собой простой «связующий» протокол, с помощью которого узлы могут удаленно вызывать объекты приложения и возвращать результаты. SOAP предлагает минимальный набор условий, позволяющий приложению передавать сообщения: клиент может посылать сообщение для того, чтобы вызывать программный объект, а сервер может возвращать результаты этого вызова.

SOAP довольно прост: сообщения представляют собой документы XML, содержащие команды SOAP. Хотя теоретически SOAP может быть привязан к любому транспортному протоколу для приложений, как правило, он используется вместе с HTTP.

Кеннард Скрибнер, один из авторов книги Understanding SOAP: The Authoritative Solution (Macmillan USA, 2000), говорит, что SOAP работает за счет преобразования информации, необходимой для вызова метода (например, сюда относятся значения аргументов и идентификаторы транзакций) в формат XML.

Данные инкапсулируются в HTTP или в какой-то другой транспортный протокол и передаются адресату, в качестве которого обычно выступает сервер. Этот сервер выделяет данные SOAP из пакета, выполняет требуемую обработку и возвращает результаты в виде ответа SOAP.

Скрибнер отметил, что SOAP действует как протокол удаленного вызова процедур, во многом так же, как протокол Remote Method Invocation в Java или General Inter-ORB Protocol в CORBA.

По словам Скрибнера, поскольку HTTP и XML используются практически повсюду, SOAP, по-видимому, можно назвать самым масштабируемым из созданных на сегодняшний день протоколов удаленного вызова процедур. SOAP не рассчитан на то, чтобы действовать как полная объектная архитектура.

SOAP не заменяет собой протокол Remote Method Invocation в Java, Distributed Component Object Model и CORBA; он предлагает правила, которые могут использоваться любой из этих моделей. SOAP не является полным решением. Он не поддерживает активацию объектов или защиту. По словам Скрибнера, разработчики SOAP «уверены в том, что пользователи самостоятельно добавят этот код», надстраивая его над SOAP, вместо того чтобы делать его составной частью самого протокола.

На рисунке приводится пример, взятый из спецификации SOAP 1.1, в котором хост запрашивает у службы котировок стоимость определенной акции. Запрос SOAP встраивается в HTTP POST, а в теле запроса указывается тип запроса и параметр — символ акции. Ответ также предоставляет собой объект XML, инкапсулированный в ответ HTTP с единственным возвращаемым значением (34,5 в данном случае).

Особенности SOAP

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

По мнению Марка Стивера, еще одного автора книги Understanding SOAP, именно эту цель преследует Microsoft в своей перспективной платформе .Net. «Здесь SOAP выступает во всем своем блеске. Он дает разработчикам действительно прекрасные возможности для создания приложений, избавляя их от мучений по поводу вероятной несовместимости», — утверждает он.

Пит Лошин — консультант, автор более двадцати книг об Internet. С ним можно связаться по электронной почте по адресу: [email protected]


Пример SOAP

Следующий пример иллюстрирует запрос SOAP, называемый GetLastTradePrice, который позволяет клиенту послать запрос о последних котировках определенных акций.

POST/StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

DIS

В первых пяти строчках (часть заголовка HTTP) указывается тип сообщения (POST), хост, тип и длина информационного наполнения, а заголовок SOAPAction определяет цель запроса SOAP. Само сообщение SOAP представляет собой документ XML, где сначала идет конверт SOAP, затем элемент XML, который указывает пространство имен SOAP и атрибуты, если таковые имеются. Конверт SOAP может включать в себя заголовок (но не в данном случае), за которым следует тело SOAP. В нашем примере в теле содержится запрос GetLastTradePrice и символ акций, для которых запрашиваются последние котировки. Ответ на этот запрос может выглядеть следующим образом.

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

34,5

И опять-таки первые три строки — это часть заголовка HTTP; само сообщение SOAP состоит из конверта, который содержит ответ на исходный запрос, помеченный GetLastTradePriceResponse, и включает в себя возвращаемое значение, в нашем случае 34,5.

Поделитесь материалом с коллегами и друзьями

www.osp.ru

Протокол SOAP | Мир ПК

Так, сперва программы взаимодействовали друг с другом по кабельному соединению через параллельный или последовательный порт, затем по сети, используя сетевые протоколы. Позднее были реализованы различные варианты удаленного вызова процедур (RPC, Remote Procedure Call), что давало возможности разработчику ПО в общем-то не беспокоиться о том, как информация между модулями программы передается по сети. Потом на базе RPC создали протокол ORPC, в котором используются технологии DCOM, CORBA/IIOP или RMI (Remote Method Invocation). ORPC позволяет организовать взаимодействие по сети уже на уровне объектов.

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

Новое — это хорошо переработанное старое

Если же для вызова методов и передачи информации применить стандартный протокол высокого уровня HTTP, а для описания данных — не менее распространенный стандарт XML, то появится SOAP (Simple Object Access Protocol) — способ удаленного вызова объектов по глобальным сетям.

Как он работает? Зная URL, клиент на языке описания сервиса SDL (Service Description Language) запрашивает у сервера информацию о нем (предоставляемые методы, параметры и т. д.). В ответ он получает SDL-файл с нужными сведениями о том, какие услуги (методы) ему будут предоставлены и как ими пользоваться.

Методы вызываются с помощью HTTP-запросов (Request) и ответов (Response). В запрос вкладывается XML-текст с описанием требующегося метода и перечнем передаваемых на сервер параметров, а в XML-ответе приходят обратно результаты обработки запроса или код ошибки.

Главное достоинство SOAP заключается в том, что и клиент, и сервер могут быть реализованы на всевозможных языках программирования (например, Perl, VBScript, Cи++ или Java), функционировать на любых платформах (от КПК до мэйнфреймов), работать с самым разным клиентским и серверным ПО (в частности, Apache или IIS). А поскольку они основаны на общих для разных платформ стандартах HTTP и XML, не возникает каких-либо препятствий для их успешного взаимодействия. Уже сейчас существуют реализации SOAP для множества ОС.

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

Корпорация Microsoft выпустила для разработчиков, использующих Microsoft Visual Studio, SOAP Toolkit — набор, включающий утилиты и библиотеки, существенно облегчающие процесс написания программ. Можно применять его и с другими средствами разработки, поддерживающими COM-технологию.

Процедура реализации решения на основе SOAP может быть следующей. На клиенте нужно создать объект ROPE.Proxy (объект Proxy библиотеки ROPE). Затем с применением объектной модели библиотеки ROPE (Remote Object Proxy Engine) следует запросить с сервера SDL-файл с информацией о сервере, на основе которой библиотека автоматически реализует объект-заглушку, методы и свойства которого описаны в SDL-файле.

Когда клиент примет ссылку на полученный объект, то может вызывать его методы и получать сведения о свойствах. Причем всякий вызов будет передаваться с помощью библиотеки ROPE и протокола SOAP на сервер, где любой SOAP-запрос встретит модуль Listener (Прослушиватель), определяющий его тип и должным образом реагирующий. Если происходит запрос SDL-файла, то возвращается такой файл, а если вызов метода или свойства объекта, то Listener выделяет его из пришедшего XML-файла, выполняет запрос к расположенному на сервере COM-объекту, получает результат, используя ROPE, «запаковывает» его в XML и отсылает обратно.

На клиентской машине созданием и разбором XML-сообщений занимается та же библиотека ROPE.

Создаем приложение-калькулятор

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

Начнем с программы-сервера

Пусть для простоты (ведь цель — всего лишь показать, как реализовать решение с протоколом SOAP, а не как обращаться к базе данных за текущими котировками), объект, возвращающий котировки валюты, будет передавать всегда одни и те же числа (горе биржевым спекулянтам!). Здесь будут взяты только три денежные единицы: рубль (RUR), американский доллар (USD) и Евро (EUR) в соотношении, сложившемся на текущий момент времени.

На сервере у объекта будет только один возвращающий текущие котировки спроса метод GetQuotation со следующими параметрами:

* CurID1 — идентификатор для первой валюты;
* CurID2 — для второй.

Они примут одно значение из трех возможных, заданных в Enum (листинг 1).

Листинг 1. Тип валюты
Public Enum CurrencyID
    curRUR
    curUSD
    curEUR
End Enum

Текущие значения будут передаваться через параметр возврата. Конечно, имело бы смысл приблизить этот объект к жизни и возвращать за один вызов котировки спроса и предложения. Они бы пересылались через Out-параметры (аналогично тому, как передаются параметры по ссылке в Си++). Но, к сожалению, в имеющейся версии SOAP Toolkit Out-параметры отсутствуют. (Следует учесть, что рассматривается лишь предварительный вариант этого продукта, а его широкое применение начнется тогда, когда SOAP станет неотъемлемой частью средств разработки следующего поколения — Visual Studio .Net).

Реализация объекта предельно проста и ничем не отличается от любого другого COM-объекта на Visual Basic.

Создается проект ActiveX dll, в который добавляется один класс, исходный текст которого приведен в листинге 2. Конечно, не существует препятствий для создания этого объекта на другом языке программирования и в другой среде.

Чтобы с полученным COM-объектом можно было общаться, вызывая методы по протоколу SOAP, требуется следующее:

  • сгенерировать с помощью программы SDLWizard.exe служебный ASP-файл (Active Server Pages) и XML-файл с SDL-описанием сервера. Они будут называться так же, как COM-объект, но иметь расширения asp и xml соответственно;
  • скопировать их, а также Listener (в виде ASP-файла) в отдельную папку;
  • с помощью Internet Information Services создать виртуальный каталог IIS.

Теперь SOAP-сервер готов обрабатывать запросы клиентов. Может также потребоваться незначительная настройка утилиты Component Services (настройка параметров COM+ в Windows 2000), подробно изложенная в документации к SOAP Toolkit.

Описанная выше последовательность действий относится к ситуации, когда Listener представлен в виде ASP-модуля. Если же Listener реализован на ISAPI, то инструкции подробно даны в файле помощи, поставляемом с SOAP Toolkit.

Возьмемся за клиента

Рис. 1. Экран приложения-клиента, основанного на протоколе SOAP

Если при создании объекта сервера можно вообще не задумываться о том, что с ним впоследствии будут общаться по протоколу SOAP, то для клиента все складывается несколько сложнее. Помимо вызовов объекта через промежуточный модуль-заглушку, необходимо установить связь с сервером и получить там описание предоставляемых методов.

Внешний вид окна приложения-клиента приведен на рис. 1. При нажатии на кнопку Connect устанавливается связь с SOAP-сервером. В строке URL можно ввести его имя, затем с помощью двух наборов кнопок с зависимой фиксацией выбрать тип валюты, а отметив кнопку Get Quotation, получить в поле Quotation значение курса.

Этот пример достаточно прост, но тем не менее позволяет продемонстрировать основные возможности, предоставляемые протоколом SOAP и библиотекой ROPE.

По шагам

Рассмотрим подробнее процесс взаимодействия клиента и сервера (рис. 2).

Рис. 2. Схема взаимодействия клиента и сервера по протоколу SOAP

? После нажатия на кнопку Connect происходит обращение клиента к библиотеке ROPE для установления соединения с сервером и получения SDL-файла. Текст программы, обрабатывающей нажатие на кнопку приведен в листинге 3.

Листинг 4

Библиотека ROPE посылает запрос по Web-адресу, предоставленному клиентом, и запрашивает у сервера SDL-файл. Запрос попадает к программе Listener, которая может быть написана как с использованием технологии ASP, так и с применением Internet Server API (ISAPI). Независимо от реализации клиенту будет отправлен SDL-файл.

  • Библиотека ROPE на основе SDL-файла создает объект Proxy, с помощью которого клиент может вызвать какой-либо метод серверного объекта, в частности по нажатию на кнопку Get Quotation метод Proxy.
  • Метод объекта транслируется библиотекой и отправляется в виде HTTP-запроса на сервер.
  • Listener и в этот раз перехватывает и переправляет этот запрос библиотеке ROPE, которая, разобрав посланный XML-текст, вызывает серверный объект с необходимыми параметрами и возвращает клиенту «упакованные» в XML результаты работы.

Для желающих более подробно разобраться с протоколом SOAP и инструментарием SOAP Toolkit в документации последнего приведен довольно сложный пример, демонстрирующий более тонкие вопросы взаимодействия клиента и сервера.

* * *

Протокол SOAP будет «встроен» в ожидаемую в ближайшее время версию Visual Studio, и тогда разработчики смогут использовать технологию Web-сервисов (Web Service) с помощью SOAP точно так же, как они реализуют обычные COM-серверы и COM-клиенты. Microsoft планомерно проводит в жизнь свой лозунг «Focus on business problem, not on plumbing» (сосредоточьтесь на бизнесе, а не на прокладке водопроводов), только теперь логика функционирования системы выходит на новый уровень — глобальных сетей и огромных корпоративных систем. А чтобы не затеряться в этом новом компьютерном мире, представление о нем лучше получить уже сейчас.

Дополнительные сведения

? SOAP Toolkit для Visual Studio 6.0. (В его составе есть файл справки с подробным описанием библиотеки ROPE): http://msdn.microsoft.com/xml/general/toolkit_intro.asp

? Caron R. Develop a Web Service: Up and Running with the SOAP Toolkit for Visual Studio//MSDN Magazine.2000. N8. (Посвящена использованию SOAP Toolkit. Снабжена интересным примером.): http://msdn.microsoft.com/msdnmag/issues/0800/ webservice/webservice.asp

? Box D. A Young Person?s Guide to The Simple Object Access Protocol: SOAP Increases Interoperability Across Platforms and Languages//MSDN Magazine. 2000. N8. (Статья известного автора с подробным описанием SOAP.): http://msdn.microsoft.com/msdnmag/ issues/0300/soap/soap.asp

? Спецификация протокола SOAP: http://msdn.microsoft.com/xml/general/soapspec.asp

? Конференция, посвященная SOAP и SOAP Toolkit: news://msnews.microsoft.com/ microsoft.public.msdn.soaptoolkit

? Информация о следующей версии Visual Studio: http://msdn.microsoft.com/vstudio/nextgen/

Об АВТОРЕ

Александр Ложечкин — системный аналитик компании Digital Design, e-mail: [email protected]


Требования к конфигурации компьютера для использования SOAP Toolkit

  • Microsoft Windows 2000 + Service Pack 1.
  • Microsoft Visual Studio 6.0 + Service Pack 3.
  • Internet Information Services 5.0.

Для тестирования взаимодействия по SOAP совсем не нужно быть подключенным к Internet или локальной сети — достаточно настроить эмулятор драйвера MS LoopBack Adapter в качестве сетевой платы и обратиться к хосту localhost.

www.osp.ru

SOAP — Википедия. Что такое SOAP

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Пример SOAP-запроса на сервер интернет-магазина:

 
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productID>12345</productID>
     </getProductDetails>
   </soap:Body>
</soap:Envelope>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
       <getProductDetailsResult>
         <productID>12345</productID>
         <productName>Стакан граненый</productName>
         <description>Стакан граненый. 250 мл.</description>
         <price>9.95</price>
         <currency>
             <code>840</code>
             <alpha3>USD</alpha3>
             <sign>$</sign>
             <name>US dollar</name>
             <accuracy>2</accuracy>
         </currency>
         <inStock>true</inStock>
       </getProductDetailsResult>
     </getProductDetailsResponse>
   </soap:Body>
</soap:Envelope>

wiki.sc

SOAP — Википедия

Материал из Википедии — свободной энциклопедии

Структура SOAP-сообщения

SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.

SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP.

SOAP является одним из стандартов, на которых базируются технологии веб-служб.

Структура протокола

Сообщение SOAP выглядит так:

SOAP-конверт 

Пример

Пример SOAP-запроса на сервер интернет-магазина:

 
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetails xmlns="http://warehouse.example.com/ws">
       <productID>12345</productID>
     </getProductDetails>
   </soap:Body>
</soap:Envelope>

Пример ответа:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
     <getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
       <getProductDetailsResult>
         <productID>12345</productID>
         <productName>Стакан граненый</productName>
         <description>Стакан граненый. 250 мл.</description>
         <price>9.95</price>
         <currency>
             <code>840</code>
             <alpha3>USD</alpha3>
             <sign>$</sign>
             <name>US dollar</name>
             <accuracy>2</accuracy>
         </currency>
         <inStock>true</inStock>
       </getProductDetailsResult>
     </getProductDetailsResponse>
   </soap:Body>
</soap:Envelope>

Недостатки

  • Использование SOAP для передачи сообщений увеличивает их объём и снижает скорость обработки. В системах, где скорость важна, чаще используется пересылка XML-документов через HTTP напрямую, где параметры запроса передаются как обычные HTTP-параметры.

См. также

Ссылки

wikipedia.green

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *