Пишем SOAP клиент-серверное приложение на PHP. Simple Object Access Protocol (SOAP) - общее описание
SOAP (Simple Object Access Protocol)
является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).
Тестирование SOAP с точки зрения техник тестирования ничем принципиально не отличается от работы с другими API, но для его проведения требуются предварительная подготовка (в плане теории протокола) и специальные инструменты для тестирования. В данной статье я хотела бы сформулировать небольшой чек-лист необходимых знаний и навыков, который будет одинаково полезен как тестировщику SOAP (зачастую не представляющему, «за что хвататься» после постановки задачи), так и менеджеру, вынужденному оценивать знания тестировщиков и разрабатывать планы по обучению.
Теоретическая база
Тот факт, что SOAP является протоколом, имеет большое значение для тестирования: нужно изучить сам протокол, «первичные» стандарты и протоколы, на которых он базируется, а также (по мере необходимости) существующие расширения.
XML
XML – язык разметки, схожий с HTML. Любое сообщение, отправляемое/получаемое через SOAP, – это XML-документ, в котором данные удобно структурированы и легко читаемы, например:
Не забудь написать статью!
Более подробно про XML можно узнать на w3schools или codenet (по-русски) . Обязательно обратите внимание на описание namespaces (метод разрешения конфликтов при описании элементов в XML) – в SOAP их использование необходимо.
XSD
При работе всегда удобно иметь стандартизированное описание возможных XML-документов и проверять их на корректность заполнения. Для этого существует XML Schema Definition (или сокращенно XSD). Две главные фичи XSD для тестировщика – это описание типов данных и наложение ограничений на возможные значения. Например, элемент из предыдущего примера можно сделать необязательным для заполнения и ограничить его размер 255 символами с помощью XSD:
...
...
Расширения SOAP
В работе вам также могут встретиться различные «расширения» SOAP – стандарты типа WS-*
. Одним из самых распространенных является WS-Security позволяющий работать с шифрованием и электронными подписями. Нередко вместе с ним применяется WS-Policy, с помощью которого можно управлять правами на использование вашего сервиса.
Пример использования WS-Security:
Все эти расширения – достаточно сложные конструкции, используемые далеко не в каждом SOAP-сервисе; их подробное изучение на начальном этапе освоения тестирования SOAP вряд ли будет актуально.
Инструменты
Как вы уже поняли, SOAP – дело серьезное, для работы с ним нужно знать теорию и многочисленные стандарты. На практике такая сложность привела бы к весьма ощутимым трудозатратам (например, нужно было бы каждый раз смотреть схему в блокнотике и слать запросы curl-ом). Поэтому были созданы инструменты, облегчающие работу с SOAP.
Редакторы XML / XSD
Хороший тестировщик начинает тестирование еще на стадии написания документации, поэтому для проверки схем удобно использовать специальные редакторы. Два самых известных – Oxygen (кроссплатформенный) и Altova (только для Windows); оба они являются платными. Это очень мощные программы, которыми активно пользуются аналитики при описании сервисов.
В моей практике полезными оказались три фичи редакторов: визуализация XSD, генерация XML на основе XSD и валидация XML по XSD.
1. Визуализация XSD нужна для наглядного представления схемы, позволяющего быстро вычленить обязательные элементы и атрибуты, а также существующие ограничения. Например, для запроса CheckTextRequest обязательным является элемент text, а необязательными – все три атрибута (при этом у атрибута options установлено значение по умолчанию – ноль).
Визуализация необходима в том случае, когда типов и ограничений в схеме много. Если вам нужна только она, и вы не хотите платить за специальные редакторы, то можно рассмотреть бесплатные альтернативы (например, JDeveloper).
2. Генерация XML на основе XSD полезна тогда, когда вы хотите увидеть корректный пример сообщения. Я пользуюсь ей для того, чтобы быстро поэкспериментировать с возможным заполнением сообщения и проверить нюансы работы ограничений.
3. После использования фичи из пункта 2 полезно провести валидацию XML по XSD – то есть проверить сообщение на корректность. Вместе фичи 2 и 3 позволяют отлавливать хитрые дефекты в XSD еще тогда, когда сам сервис находится в разработке.
Инструмент тестирования – SoapUI
Тестирование SOAP практически всегда подразумевает использование SoapUI . Прочитать про использование этого инструмента можно в разных источниках ( , ), но эффективнее всего будет ознакомиться с официальной документацией . Я выделяю 8 условных уровней владения SoapUI:
Уровень 1 – умею отправлять запросы
Научитесь создавать проект на основе WSDL. SoapUI может сгенерировать все необходимые запросы для вас; вам останется лишь проверить правильность их заполнения и нажать кнопочку «Send». После выработки навыков создания корректных запросов вы должны овладеть искусством формирования некорректных запросов, вызывающих появление ошибок.
Уровень 2 – умею делать Test Suites и Test Cases
Начните делать мини-автотесты. Тест-комплекты и тест-кейсы позволяют создавать сценарии тестирования API, подготавливать данные для запросов и автоматически проверять полученный ответ на соответствие ожидаемому. На первых порах их можно использовать просто как коллекции запросов. Например, если вы завели дефект и хотите быстро проверить его после фикса, можно выделить отдельный тест-комплект конкретно под запросы-дефекты.
Уровень 3 – умею писать Assertions
После освоения тест-кейсов вам будет полезно научиться делать их автоматически проверяемыми. После этого вам уже не нужно будет искать «глазами» информацию об ответе: при наличии автоматической проверки кейсы будут помечаться зеленым (если проверка пройдена) или красным (если не пройдена). SoapUI предоставляет большой набор возможных проверок (assertions), но самые удобные и простые – это Contains и Not Contains. С их помощью можно проверить факт наличия конкретного текста в полученном ответе. Эти проверки также поддерживают поиск с помощью регулярных выражений.
Уровень 4 – использую XPath и/или XQuery в Assertions
Для тех, кто немного знаком с UI с помощью Selenium, язык XPath – знакомая вещь. Грубо говоря, XPath позволяет искать элементы в XML-документе. XQuery – похожая технология, которая может использовать XPath внутри себя; этот язык гораздо мощнее, он напоминает SQL. Оба эти языка можно использовать в Assertions. Проверки с их помощью получаются более прицельными и стабильными, поэтому ваши кейсы будут пользоваться большим доверием.
Уровень 5 – умею писать сложные тесты с помощью специальных шагов
В тест-кейсах может содержаться не только один запрос, но и несколько (к примеру, когда вы хотите эмулировать стандартный сценарий работы пользователя «создать сущность» → «экспортировать сущность»). Между запросами могут находиться другие специальные шаги, например:
- Properties и Property Transfer (помогают переиспользовать данные и передавать их между запросами);
- JDBC Request (используется для получения данных из базы данных);
- Conditional Goto (позволяет сделать разветвления или циклы в тест-кейсе);
- Run TestCase (помогает вынести какие-то типовые запросы в отдельные тест-кейсы и вызывать их там, где нужно).
Уровень 6 – использую скрипты на Groovy
SoapUI позволяет писать скрипты на Groovy в различных местах. Простейший случай – это генерация данных в самом запросе с помощью вставок ${=}. Я постоянно пользуюсь такими вставками:
- ${=new Date().format(«yyyy-MM-dd’T’HH:mm:ss»)} – для вставки текущей даты и времени в необходимом формате;
- ${=java.util.UUID.randomUUID()} – для вставки корректно сформированного случайного GUID.
Полноценные скрипты можно использовать в качестве шагов в кейсах и проверках. В какой-то момент вы обнаружите, что сразу несколько специальных шагов из пятого уровня можно заменить одним скриптом.
Уровень 7 – использую MockServices
SoapUI на основе WSDL может генерировать Mock-объекты . Mock-объект – это простейшая симуляция сервиса. С помощью «моков» можно начать писать и отлаживать тест-кейсы еще до того, как сервис реально будет доступен для тестирования. Также их можно использовать в качестве «заглушек» для временно недоступных сервисов.
Уровень 8 – бог SoapUI
Вы знаете разницу между платной и бесплатной версиями SoapUI и используете SoapUI API в коде. Вы используете плагины и запускаете выполнение кейсов через командную строку и/или CI. Ваши тест-кейсы просты и легко поддерживаются. В общем, вы «съели собаку» на этом инструменте. Я бы с радостью пообщалась с тем, кто освоил SoapUI на таком уровне. Если вы являетесь таковым – отпишитесь в комментариях!
Тестирование с помощью языков программирования
Приведу пример того, как выглядит запрос к YandexSpeller API, выполненный с помощью groovy-wslite:
import wslite.soap.*
def client = new SOAPClient("http://speller.yandex.net/services/spellservice?WSDL")
def response = client.send(SOAPAction: "http://speller.yandex.net/services/spellservice/checkText") {
body {
CheckTextRequest("lang": "ru", "xmlns":"http://speller.yandex.net/services/spellservice") {
text("ошипка")
}
}
}
assert "ошибка" == response.CheckTextResponse.SpellResult.error.s.text()
assert "1" == [email protected]()
Насколько я знаю, высокоуровневых фреймворков (по типу Rest-assured) для тестирования SOAP пока не существует, но недавно появился интересный инструмент – karate . С его помощью можно описывать кейсы для тестирования SOAP и REST в виде сценариев по типу Cucumber / Gherkin . Для многих тестировщиков обращение к karate будет идеальным решением, ведь такие сценарии по сложности написания и поддержки кейсов будут лежать где-то посередине между использованием SoapUI и написанием собственного фреймворка для тестирования SOAP.
Заключение
Вряд ли вам когда-либо захочется тестировать SOAP просто так, для себя (как могло бы получиться с REST-ом). Это тяжеловесный протокол, который используется в серьезных корпоративных решениях. Но его тяжеловесность одновременно является подарком тестировщику: все используемые технологии стандартизированы, имеются качественные инструменты для работы. От тестировщика требуется лишь желание их изучить и использовать.
Давайте соберем воедино тот самый чек-лист необходимых навыков для тестировщика. Итак, если вы только начинаете тестировать SOAP сервисы, вам нужно знать и уметь использовать:
- WSDL.
- SOAP.
- Редакторы XML / XSD (на уровне визуализации XSD).
- SoapUI на уровне 1.
Как видите, основной упор приходится на изучение стандартов, в SoapUI достаточно просто уметь выполнять запросы. По мере погружения в тестирование SOAP перед вам будут возникать задачи, которые потребуют уже более серьезных навыков и знаний, но не стоит пытаться изучить всё и сразу. Гораздо важнее последовательность в повышении уровня сложности выполняемых задач. Следуя этой рекомендации, в один прекрасный момент вы поймете, что стали хорошим специалистом в этой области!
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 сообщения от клиента). Нам нужно сделать следующее:- Описать интерфейс нашего веб-сервиса
- Реализовать этот интерфейс
- Запустить наш веб-сервис
- Написать клиента и удаленно вызвать нужный метод веб-сервиса
Сервер
Запустим IDEA и создадим новый проект Create New Project . Укажем имя HelloWebService и нажмем кнопку Next , далее кнопку Finish . В папке src создадим пакет ru.javarush.ws . В этом пакете создадим интерфейс HelloWebService: package ru. javarush. ws; // это аннотации, т.е. способ отметить наши классы и методы, // как связанные с веб-сервисной технологией import javax. jws. WebMethod; import javax. jws. WebService; import javax. jws. soap. SOAPBinding; // говорим, что наш интерфейс будет работать как веб-сервис @WebService // говорим, что веб-сервис будет использоваться для вызова методов @SOAPBinding (style = SOAPBinding. Style. RPC) public interface HelloWebService { // говорим, что этот метод можно вызывать удаленно @WebMethod public String getHelloString (String name) ; } В этом коде классы WebService и WebMethod являются так называемыми аннотациям и ничего не делают, кроме как помечают наш интерфейс и его метод, как веб-сервис. Это же относится и к классу SOAPBinding . Разница лишь в том, что SOAPBinding – это аннотация с параметрами. В данном случае используется параметр style со значением, говорящим, что веб-сервис будет работать не через сообщения-документы, а как классический RPC, т.е. для вызова метода. Давайте реализуем логику нашего интерфейса и создадим в нашем пакете класс HelloWebServiceImpl . Кстати, замечу, что окончание класса на Impl – это соглашение в Java, по которому так обозначают реализацию интерфейсов (Impl – от слова implementation, т.е. реализация). Это не требование и вы вольны назвать класс как хотите, но правила хорошего тона того требуют: package ru. javarush. ws; // таже аннотация, что и при описании интерфейса, import javax. jws. WebService; // но здесь используется с параметром endpointInterface, // указывающим полное имя класса интерфейса нашего веб-сервиса @WebService (endpointInterface = "ru.javarush.ws.HelloWebService" ) public class HelloWebServiceImpl implements HelloWebService { @Override public String getHelloString (String name) { // просто возвращаем приветствие return "Hello, " + name + "!" ; } } Запустим наш веб-сервис как самостоятельный сервер, т.е. без участия всяких Tomcat и серверов приложений (это тема отдельного разговора). Для этого в структуре проекта в папке src создадим пакет ru.javarush.endpoint , а в нем создадим класс HelloWebServicePublisher с методом main: package ru. javarush. endpoint; // класс, для запуска веб-сервера с веб-сервисами import javax. xml. ws. Endpoint; // класс нашего веб-сервиса import ru. javarush. ws. HelloWebServiceImpl; public class HelloWebServicePublisher { public static void main (String. . . args) { // запускаем веб-сервер на порту 1986 // и по адресу, указанному в первом аргументе, // запускаем веб-сервис, передаваемый во втором аргументе Endpoint. publish ("http://localhost:1986/wss/hello" , new HelloWebServiceImpl () ) ; } } Теперь запустим этот класс, нажав Shift+F10 . В консоли ничего не появится, но сервер запущен. В этом можно убедиться набрав в браузере строку http://localhost:1986/wss/hello?wsdl . Открывшаяся страница, с одной стороны, доказывает, что у нас на компьютере (localhost) запустился веб-сервер (http://) на порту 1986, а, с другой стороны, показывает WSDL описание нашего веб-сервиса. Если вы остановите приложение, то описание станет недоступно, как и сам веб-сервис, поэтому делать этого не будем, а перейдем к написанию клиента.Клиент
В папке проекта src создадим пакет ru.javarush.client , а в нем класс HelloWebServiceClient с методом main: package ru. javarush. client; // нужно, чтобы получить wsdl описание и через него // дотянуться до самого веб-сервиса import java. net. URL; // такой эксепшн возникнет при работе с объектом URL import java. net. MalformedURLException; // классы, чтобы пропарсить xml-ку c wsdl описанием // и дотянуться до тега service в нем import javax. xml. namespace. QName; import javax. xml. ws. Service; // интерфейс нашего веб-сервиса (нам больше и нужно) import ru. javarush. ws. HelloWebService; public class HelloWebServiceClient { public static void main (String args) throws MalformedURLException { // создаем ссылку на wsdl описание URL url = new URL ("http://localhost:1986/wss/hello?wsdl" ) ; // Параметры следующего конструктора смотрим в самом первом теге WSDL описания - definitions // 1-ый аргумент смотрим в атрибуте targetNamespace // 2-ой аргумент смотрим в атрибуте name QName qname = new QName ("http://ws.сайт/" , "HelloWebServiceImplService" ) ; // Теперь мы можем дотянуться до тега service в wsdl описании, Service service = Service. create (url, qname) ; // а далее и до вложенного в него тега port, чтобы // получить ссылку на удаленный от нас объект веб-сервиса HelloWebService hello = service. getPort (HelloWebService. class ) ; // Ура! Теперь можно вызывать удаленный метод System. out. println (hello. getHelloString ("JavaRush" ) ) ; } } Максимум комментариев по коду я дал в листинге. Добавить мне нечего, поэтому запускаем (Shift+F10). Мы должны в консоли увидеть текст: Hello, JavaRush! Если не увидели, то видимо забыли запустить веб-сервис.Заключение
В данном топике был представлен краткий экскурс в веб-сервисы. Еще раз скажу, что многое из того, что я написал – это мои догадки по поводу того, как это работает, и поэтому мне не стоит сильно доверять. Буду признателен, если знающие люди меня поправят, ведь тогда я чему-нибудь научусь. UPD.Вообще сегодня есть стандартные протоколы обмена 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.
- Привязка методов к сообщению.
- Описание самих сообщений.
Лирическая часть.
Представьте что у вас реализована или реализуется некая система, которая должна быть доступна извне. Т.е. есть некий сервер, с которым вам надо общаться. Например веб-сервер.
Этот сервер может выполнять множество действий, работать с базой, выполнять какие-то сторонние запросы к другим серверам, заниматься каким-то вычислениями и т.д. жить и возможно развиваться по ему известному сценарию (т.е. по сценарию разработчиков). С таким сервером общаться человеку неинтересно, потому что он может не уметь/не хотеть отдавать красивые странички с картинками и прочим юзер-френдли контентом. Он написан и работает чтобы работать и выдавать на запросы к нему данные, не заботясь, чтоб они были человекочитаемые, клиент сам с ними разберется.
Другие системы, обращаясь к этому серверу уже могут распоряжаться полученными от этого сервера данными по своему усмотрению - обрабатывать, накапливать, выдавать своим клиентам и т.д.
Ну вот, один из вариантов общения с такими серверами - это SOAP. SOAP протокол обмена xml-сообщениями.
Практическая часть.
Веб-сервис (так называется то, что предоставляет сервер и то, что используют клиенты) дает возможность общения с сервером четко структурированными сообщениями. Дело в том, что веб-сервис не принимает абы какие данные. На любое сообщение, которое не соответствует правилам, веб-сервис ответит ошибкой. Ошибка будет, кстати, тоже в виде xml с четкой структурой (чего нельзя сказать правда о тексте сообщения).
WSDL (Web Services Description Language). Правила, по которым составляются сообщения для веб-сервиса описываются так же с помощью xml и также имеют четкую структуру. Т.е. если веб-сервис предоставляет возможность вызова какого-то метода, он должен дать возможность клиентам узнать какие параметры для данного метода используются. Если веб-сервис ждет строку для метода Method1 в качестве параметра и строка должна иметь имя Param1, то в описании веб-сервиса эти правила будут указаны.
В качестве параметров могут передаваться не только простые типы, но и объекты, коллекции объектов. Описание объекта сводится к описанию каждой составляющей объекта. Если объект состоит из нескольких полей, значит описывается каждое поле какой у него тип, название (какие возможные значения). Поля также могут быть сложного типа и так далее пока описание типов не закончится на простых - строка, булево, число, дата... Впрочем простыми могут оказаться какие-то специфические типы, важно чтоб клиенты могли понять какие значения могут в них содержаться.
Для клиентов достаточно знать url веб-сервиса, wsdl всегда будет рядом, по которому можно получить представление о методах и их параметрах, которые предоставляет этот веб-сервис.
Какие плюсы у всех этих наворотов:
- В большинстве систем описание методов и типов происходит в автоматическом режиме. Т.е. программисту на сервере достаточно сказать, что данный метод можно вызывать через веб-сервис, и wsdl-описание будет сгенерировано автоматом.
Автоматическая валидация.
- xml-валидация. xml должен быть well-formed. невалидный xml - сразу ошибка клиенту, пусть разбирается.
- schema-валидация. xml должен иметь определенную структуру. xml не соответствует схеме - сразу ошибка клиенту, пусть разбирается.
- проверка данных осуществляется soap-сервером, чтобы типы данных, ограничения соответствовали описанию.
- Авторизация и аутентификация может быть реализована отдельным методом. нативно. либо, используя http-авторизацию.
- Веб-сервисы могут работать как по soap-протоколу, так и по http, то есть через get-запросы. То есть, если в качестве параметров идут простые данные (без структуры), то можно вызвать просто обычный get www.site.com/users.asmx/GetUser?Name=Vasia или post. Впрочем это не везде и не всегда.
- ... см. в википедии
Описание, имеющее четкую структуру, читается любым soap-клиентом. Т.е. какой бы ни был веб-сервис, клиент поймет какие данные веб-сервис принимает. По этому описанию клиент может построить свою внутреннюю структуру классов объектов, т.н. binding"и. В итоге программисту, использующему веб-сервис, остается написать что-то типа (псевдокод):
NewUser:=TSoapUser.Create("Вася","Пупкин","odmin"); soap.AddUser(NewUser);
Минусов тоже полно:
- Неоправданно большой размер сообщений. Ну тут сама природа xml такова, что формат избыточный, чем больше тэгов, тем больше неполезной информации. Плюс soap добавляет своей избыточности. Для intranet-систем вопрос трафика стоит менее остро, чем для internet, поэтому soap для локальных сетей более востребован, в частности у Sharepoint есть soap веб-сервис, с которым с успехом (и некоторыми ограничениями) можно общаться.
- Автоматическая смена описания веб-сервиса может сломать все клиенты. Ну это как бы для любой системы так, если не поддерживается обратная совместимость со старыми методами, все отвалится...
- Не минус, но недостаток. Все действия по вызову методов должны быть атомарными. Например, работая с субд мы можем начать транзакцию, выполнить несколько запросов, потом откатиться или закоммитить. В soap транзакций нет. Один запрос-один ответ, разговор закончен.
- Разбираться с описанием, что на стороне сервера (все ли правильно описано у меня?), что на клиенте (что мне тут наописывали?) бывает довольно сложно. Было несколько раз, когда мне приходилось разбираться с клиентской стороны, и убеждать серверного программера, что у него неверно описаны данные, а он в них вообще ничего понять не мог, ибо автоматическая генерация и он как бы и не должен, это дело софта. А ошибка естественно была в коде метода, программер ее не видел просто.
- Практика показывает, что разработчики веб-сервисов страшно далеки от народа, использующего эти веб-сервисы. В ответ на какой-либо запрос (валидный со стороны) может прийти невразумительная ошибка "Ошибка 5. Все плохо". Все зависит от совести разработчиков:)
- еще наверняка что-то не вспомнил...
В качестве примера есть открытый веб-сервис belavia:
- http://86.57.245.235/TimeTable/Service.asmx - точка входа, там же текстовое описание методов для сторонних разработчиков.
- http://86.57.245.235/TimeTable/Service.asmx?WSDL - wsdl описание методов и типов принимаемых и возращаемых данных.
- http://86.57.245.235/TimeTable/Service.asmx?op=GetAirportsList - описание конкретного метода с примером вида xml-запроса и xml-ответа.
Можете вручную создать и послать запрос типа:
POST /TimeTable/Service.asmx HTTP/1.1
Host: 86.57.245.235
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://webservices.belavia.by/GetAirportsList"
в ответ придет:
HTTP/1.1 200 OK
Date: Mon, 30 Sep 2013 00:06:44 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 2940
ЗЫ Раньше был открыт веб-сервис аэрофлота, но после того как 1C добавили поддержку soap в 8ку, куча 1с-бета-тестеров с успехом положили его. Сейчас что-то там поменяли (адреса не знаю, можно поискать, если интересно).
ЗЗЫ Дисклеймер. Рассказал на бытовом уровне. Пинать можно.
