Примеры сервисов использующих soap. Тестирование с помощью языков программирования
10 ответов
WSDL - это XML-документ, описывающий веб-службу. Это фактически означает язык определения веб-сервисов.
SOAP - это протокол на основе XML, который позволяет обмениваться информацией по определенному протоколу (например, HTTP или SMTP) между приложениями. Это означает простой протокол доступа к объектам и использует XML для его формата обмена сообщениями для передачи информации.
REST - это архитектурный стиль сетевых систем и выступает за передачу репрезентативного состояния. Это не стандарт сам, но использует такие стандарты, как HTTP, URL, XML и т.д.
Каждый раз, когда кто-то упоминает SOAP/WSDL, я думаю о объектах и классах, определенных в xml...
"Вы используете SOAP так же, как и любой PHP-класс. Однако в этом случае класс не существует в локальной файловой системе приложений, а на удаленном узле, доступ к которому осуществляется через http."... "Если мы думаем использовать SOAP-сервис как еще один класс PHP, тогда документ WSDL является списком всех доступных методов и свойств класса".
И всякий раз, когда кто-то говорит о REST, я думаю о HTTP-командах (методах запроса), таких как POST, GET и DELETE
Пример: простыми словами, если у вас есть веб-сервис калькулятора.
WSDL: WSDL рассказывает о функциях, которые вы можете реализовать или подвергнуть действию клиенту. Например: добавление, удаление, вычитание и т.д.
SOAP: где, используя SOAP, вы фактически выполняете действия, такие как doDelete(), doSubtract(), doAdd(). Таким образом, SOAP и WSDL являются яблоками и апельсинами. Мы не должны сравнивать их. Они оба имеют свою собственную функциональность.
Почему мы используем SOAP и WSDL: для обмена независимыми данными на платформе.
РЕДАКТИРОВАТЬ: В обычной повседневной жизни:
WSDL: Когда мы идем в ресторан, мы видим пункты меню, это WSDL.
Прокси-классы: Теперь, после просмотра элементов меню, мы составляем наш разум (обрабатываем наш взгляд на порядок): Итак, в основном мы делаем классы Proxy на основе документа WSDL.
SOAP: Затем, когда мы фактически заказываем пищу на основе меню: подразумевается, что мы используем прокси-классы для вызова методов обслуживания, которые выполняются с использованием SOAP.:)
SOAP → SOAP (Простой прототип доступа к объектам) - это протокальный уровень приложения, созданный для взаимодействия машины с машиной. Протокол определяет стандартные правила. Все стороны, которые используют конкретный протокол, должны придерживаться правил протокола. Как и TCP, он разматывается на транспортном уровне. Протокол SOAP будет пониматься на уровне приложения (любое приложение, поддерживающее SOAP - Axis2,.Net).
WSDL → SOAP-сообщение состоит из SoapEnevelope- > SoapHeader и SoapBody. Он не определяет, какой будет формат сообщений? какие все транспорты (HTTP, JMS) поддерживаются? без этой информации. Для любого клиента, который хочет использовать конкретный веб-сервис для создания SOAP-сообщения, трудно. Даже если они это сделают, они не будут уверены, это будет работать все время. WSDL - это спасение. WSDL (язык описания веб-служб) определяет операции, форматы сообщений и данные о транспортировке для сообщения SOAP.
REST → REST (передача состояния представления) основана на транспорте. В отличие от SOAP, который нацелен на действия, REST больше относится к ресурсам. REST находит ресурсы с помощью URL-адреса (пример -http://{serverAddress}/employees/employeeNumber/12345) и зависит от транспортного протокола (с HTTP-GET, POST, PUT, DELETE,...) для действий для выполнения ресурсов. Служба REST находит ресурс на основе URL-адреса и выполняет действие на основе глагола действия транспорта. Это больше архитектурный стиль и условности.
SOAP означает простой (sic) протокол доступа к объектам. Он предназначался для того, чтобы делать удаленные вызовы процедур для удаленных объектов, отправляя XML через HTTP.
WSDL - это язык описания веб-сервисов. Запрос, заканчивающийся на ".wsdl" конечной точке, приведет к представлению XML-сообщения, описывающего запрос и ответ, который может ожидать использование. Он описывает контракт между сервисом и клиентом.
REST использует HTTP для отправки сообщений в службы.
SOAP - спецификация, REST - это стиль.
Вы не собираетесь "просто" понимать что-то сложное.
WSDL - это язык, основанный на XML, для описания веб-службы. В нем описываются сообщения, операции и информация о транспортной сети, используемые службой. Эти веб-службы обычно используют SOAP, но могут использовать другие протоколы.
WSDL читается программой и поэтому может использоваться для генерации всего или части кода клиента, необходимого для вызова веб-службы. Это то, что означает вызов SOAP-ориентированных веб-сервисов "самоописанием".
REST вообще не связан с WSDL.
Wikipedia говорит: "Язык описания веб-служб - это язык на основе XML, который предоставляет модель для описания веб-сервисов". Другими словами, WSDL относится к веб-службе, так как javadoc относится к библиотеке java.
Однако очень приятная вещь в WSDL заключается в том, что программное обеспечение может генерировать клиент и сервер, используя WSDL.
Вообще сегодня есть стандартные протоколы обмена 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.
- Привязка методов к сообщению.
- Описание самих сообщений.
Как уже говорилось в предыдущей главе, Web-службы обмениваются информацией с клиентами и между собой, посылая сообщения на языке XML. Теги этой реализации XML, правила оформления документа XML и порядок обмена документами определены протоколом SOAP. Протокол SOAP создан в 1998 году командой разработчиков под руководством Дейва Винера (Dave Winer), работавшей в корпорации Microsoft и фирме Userland. Название протокола - "Простой протокол доступа к объектам" - отражает его первоначальное назначение - обращаться к методам удаленных объектов. Назначение протокола изменилось, сейчас это протокол всякого взаимодействия Web-служб и компонентов слабо связанных распределенных приложений. Он уже не совсем прост, да и об объектах он ничего не говорит. Многие разработчики предлагают назвать его "Service Oriented Architecture Protocol", оставив прежнее сокращение. Чтобы прекратить эти попытки, в спецификации SOAP 1.2 указано, что слово "SOAP" отныне никак не будет расшифровываться.
В конце 1999 года разработка протокола была передана в консорциум W3C (http: //www.w3.org/ ).
В мае 2000 года консорциум выпустил свою версию SOAP 1.1. Послание, написанное по протоколу SOAP, оформляется документом XML, активно использующим пространства имен. Имена элементов XML версии SOAP 1.1 относятся к пространству имен с идентификатором http://schemas.xmlsoap.org/soap/envelope/.
Черновик второй версии SOAP 1.2 был выпущен в 2001 году, его пространство имен называлось в то время http://www.w3.org/2001/06/soap-envelope.
Заметьте, что именно идентификатор пространства имен, а не номер 1.1 или 1.2 определяет версию SOAP. Сервер не станет рассматривать SOAP- послание и вернет сообщение об ошибке если заметит
несоответствие пространства имен.
В то время как я пишу эти строки, версия SOAP 1.1 остается рабочей. Версия 1.2 никак не может выйти из подготовительной стадии, но уже используется, например, в SOAP::Lite, Apache SOAP 2.3, Apache Axis. Поэтому в этой главе я буду излагать версию 1.2, отмечая ее отличия от версии 1.1.
Спецификация рабочей версии SOAP всегда хранится по адресу http://www.w3.org/TR/SOAP/. Документы, лежащие по этому адресу, заменяются новыми при замене рабочей версии.
Черновая версия SOAP постоянно обновляется, при этом меняется идентификатор пространства имен. Новейший вариант черновой версии на время написания книги хранился по адресу http://www.w3.org/TR/soapl2-partl/, а пространство используемых ею имен называлось http://www.w3.org/2002/06/soap-envelope. Заметьте, что спецификация SOAP 12 состоит из двух частей: part 1 и part2. Вторая часть спецификации - приложение - содержит правила записи сложных типов данных. У спецификации есть еще одна часть partO - примеры посланий, составленных по правилам SOAP 1.2.
Структура SOAP-послания
Спецификация определяет SOAP-послание как документ XML, не содержащий объявление типа документа и инструкций по обработке. Корневой элемент этого документа XML называется
и другие атрибуты, снабженные префиксами. В корневой элемент вкладывается один необязательный элемент содержащий заголовок послания, и один обязательный элемент
, в который записывается содержимое послания. Версия 1.1 позволяла после тела записать произвольные элементы, их имена обязательно следовало снабжать префиксами. Версия 1.2 запрещает писать что-либо после элемента . Короче говоря, общая структура SOAP-послания такова: xmlns:env="http://www.w3.org/2002/06/soap-envelope"> < ! - Блоки заголовка ->
Элемент
Дело в том, что SOAP-послание может пройти через несколько SOAP- серверов или через несколько приложений на одном сервере. Эти приложения выполняют предварительную обработку блоков заголовка послания и передают его друг другу. Все эти серверы и/или приложения называются SOAP-узлами (SOAP nodes). Спецификация SOAP не определяет правила прохождения послания по цепочке серверов. Для этого разрабатываются другие протоколы, например, Microsoft WS-Routing.
Атрибут actor задает целевой SOAP-узел - тот, который расположен в конце цепочки и будет обрабатывать заголовок полностью. Значение
атрибута actor показывает, что обрабатывать заголовок будет первый же сервер, получивший Атрибут actor может встречаться в отдельных блоках заголовка, указывая узел- обработчик этого блока. После обработки блок удаляется из SOAP- послания.
В версии 1.2 атрибут actor заменен атрибутом role, потому что в этой версии SOAP каждый узел играет одну или несколько ролей. Спецификация пока определяет три роли SOAP-узла.
Роль http://^^.w3.org/2002/06/soap-envelope/role/ultimateReceiver играет конечный, целевой узел, который будет обрабатывать заголовок.
Роль http://www.w3.org/2002/06/soap-envelope/role/next играет промежуточный или целевой узел. Такой узел может играть и другие, дополнительные роли.
Роль http://www.w3.org/2002/06/soap-envelope/role/none не должен играть ни один SOAP-узел.
Распределенные приложения, исходя из своих нужд, могут добавить к этим ролям другие роли, например, ввести промежуточный сервер, проверяющий цифровую подпись и определить для него эту роль какой-нибудь строкой URI.
Значением атрибута role может быть любая строка URI, показывающая роль узла, которому предназначен данный блок заголовка. Значением по умолчанию для этого атрибута служит пустое значение, то есть, просто пара кавычек, или строка URI http://\vw\v.w3.org/2002/06/soap-envelope/rale/ultimateReceiver.
Значение атрибута role показывает, что блок должен быть обработан узлом, играющим роль, определенную такой же строкой.
Еще один атрибут элемента
В версии SOAP 1.2 вместо цифры о надо писать слово false, а вместо цифры 1 писать слово true.
В тело заголовка
Листинг 3.1. Заголовок с одним блоком
xmlns:t="http://some.com/transaction" env:role= "http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver" env:mustUnderstand="1">
Элементы, вложенные в блоки заголовка, уже не называются блоками. Они не могут содержать атрибуты role, actor И mustunderstand.
Элемент
обязательно записывается сразу за элементомСообщение об ошибке
Если SOAP-сервер, обрабатывая поступившее к нему SOAP-послание, заметит ошибку, то он прекратит обработку и отправит клиенту SOAP- послание, в тело которого запишет один элемент
В сообщении, записанном в теле элемента версии SOAP 1.1 выде
ляются четыре части, описанные следующими вложенными элементами.
Код ошибки
Описание ошибки
Место обнаружения ошибки
Детали ошибки
Например: xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
Версия SOAP 1.2 изменила содержание элемента Как описано в
пространстве имен http://www.w3.org/2002/06/soap-envelope, в него входят два обязательных элемента и три необязательных элемента.
Обязательные элементы.
Код ошибки . Он содержит обязательный вложенный элемент <:value> с кодом ошибки и необязательный вложенный элемент
Причина ошибки
Необязательные элементы.
?
?
?
Листинг 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’> xmlns:e="http://www.example.org/faults"> Типы ошибок
Список кодов ошибок постоянно меняется и расширяется. Версия 1.1 определяет четыре типа ошибок. VersionMismatch - пространство имен неопознано. Может быть, оно устарело или его имя написано неправильно. MustUnderstand - блок заголовка, помеченный атрибутом mustUnderstand со значением 1, не отвечает своему синтаксису, определенному в схеме документа. Client - документ XML, содержащий послание, неправильно сформирован и по этой причине сервер не может его обработать. Клиенту следует изменить послание. Server - сервер не может обработать правильно записанное послание по своим внутренним причинам. Версия 1.2 определяет пять типов ошибок. VersionMismatch - пространство имен неопознано. Может быть, оно устарело или его название написано неправильно, или в послании встретилось имя элемента XML, не определенное в этом пространстве имен. В заголовок ответа сервер записывает элемент MustUnderstand - блок заголовка, помеченный атрибутом mustunderstand со значением true, не отвечает своему синтаксису, определенному в схеме документа. Сервер записывает в заголовок ответа элементы DataEncodingUnknown - в послании встретились непонятные данные, может быть, они записаны в неизвестной кодировке. Sender - документ XML, содержащий послание, неправильно сформирован и по этой причине сервер не может его обработать. Клиенту следует изменить послание. Receiver - сервер не может обработать правильно записанное послание по своим внутренним причинам, например, отсутствует нужный XML- парсер. Сервер может добавить к этим типам ошибок какие-то свои типы. Обычно они детализируют стандартные типы, и сообщения о них появляются в элементах ? Листинг 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/"/> ЛистонгЗ.4. Ответ сервера с сообщением об ошибке типа MustUnderstand
xmlns:t=’http://some.com/transaction’ /> One or more mandatory headers not understood
Литература:
Хабибуллин И. Ш. Разработка Web-служб средствами Java. - СПб.: БХВ-Петербург, 2003. - 400 с: ил.
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 выступает во всем своем блеске. Он дает разработчикам действительно прекрасные возможности для создания приложений, избавляя их от мучений по поводу вероятной несовместимости», - утверждает он.
Пример 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"
В первых пяти строчках (часть заголовка 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
И опять-таки первые три строки - это часть заголовка HTTP; само сообщение SOAP состоит из конверта, который содержит ответ на исходный запрос, помеченный GetLastTradePriceResponse, и включает в себя возвращаемое значение, в нашем случае 34,5.
Заголовок топика – это действительно вопрос, т.к. я сам не знаю, что это и впервые попробую поработать с этим в рамках настоящей статьи. Единственное, что могу гарантировать, что код, представленный ниже, будет работать, однако мои фразы будут лишь предположениями и догадками о том, как я сам все это понимаю. Итак, поехали…
Введение
Начать надо с того, для чего создавалась концепция веб-сервисов. К моменту появления этого понятия в мире уже существовали технологии, позволяющие приложениям взаимодействовать на расстоянии, где одна программа могла вызвать какой-нибудь метод в другой программе, которая при этом могла быть запущена на компьютере, расположенном в другом городе или даже стране. Все этого сокращенно называется RPC (Remote Procedure Calling – удаленный вызов процедур). В качестве примеров можно привести технологии CORBA, а для Java – RMI (Remote Method Invoking – удаленный вызов методов). И все вроде в них хорошо, особенно в CORBA, т.к. с ней можно работать на любом языке программирования, но чего-то все же не хватало. Полагаю, что минусом CORBA является то, что она работает через какие-то свои сетевые протоколы вместо простого HTTP, который пролезет через любой firewall. Идея веб-сервиса заключалась в создании такого RPC, который будет засовываться в HTTP пакеты. Так началась разработка стандарта. Какие у этого стандарта базовые понятия:- SOAP . Прежде чем вызвать удаленную процедуру, нужно этот вызов описать в XML файле формата SOAP. SOAP – это просто одна из многочисленных XML разметок, которая используется в веб-сервисах. Все, что мы хотим куда-то отправить через HTTP, сначала превращается в XML описание SOAP, потом засовывается в HTTP пакет и посылается на другой компьютер в сети по TCP/IP.
- WSDL . Есть веб-сервис, т.е. программа, методы которой можно удаленно вызывать. Но стандарт требует, чтобы к этой программе прилагалось описание, в котором сказано, что «да, вы не ошиблись – это действительно веб-сервис и можно у него вызвать такие-то такие-то методы». Такое описание представляется еще одним файлом XML, который имеет другой формат, а именно WSDL. Т.е. WSDL – это просто XML файл описания веб-сервиса и больше ничего.
Общий подход
В веб-сервисах всегда есть клиент и сервер. Сервер – это и есть наш веб-сервис и иногда его называют endpoint (типа как, конечная точка, куда доходят SOAP сообщения от клиента). Нам нужно сделать следующее:- Описать интерфейс нашего веб-сервиса
- Реализовать этот интерфейс
- Запустить наш веб-сервис
- Написать клиента и удаленно вызвать нужный метод веб-сервиса