soapui-tutorial [Тестирование ПО]


Лабораторная работа № 4.
Знакомство с веб-сервисами

Цель работы:

  • получить практические знания по работе с существующими веб-сервисами.

Задание:
В данной лабораторной работе необходимо научиться работать с веб-сервисами с помощью Eclipse. Для этого необходимо:

  1. установить для Eclipse плагин soapUI для работы с веб-сервисами
  2. найти в сети Интернет один из общедоступных веб-сервисов (или выбрать один из списка на сайтах XMethods, WebserviceX.NET)
  3. создать в soapUI проект для работы с выбранным веб-сервисом
  4. изучить работу выбранного веб-сервиса
  5. изучить реакцию веб-сервиса на некорректный запрос

Пример выполнения

1. Установка плагина soapUI

Для работы с веб-сервисами мы будем использовать программу soapUI. soapUI — бесплатное программное обеспечение с открытым исходным кодом, предназначенное для функционального тестирования. soapUI поддерживает множество технологий и протоколов, но нас в данной работе будет интересовать его возможность работать с WSDL и SOAP. soapUI может быть установлено как отдельное приложение или как плагин к Eclipse. Мы выбрали второй вариант.

Установить soapUI плагин можно двумя способами — скопировав заранее скачанный плагин в папку с Eclips’ом или средствами Eclipse установить его через Интернет. При выборе первого способа архив из \\hero\software\eclipse\eclipse plugins\eclipse plugins\soapui-eclipse-plugin-3.6.1.zip необходимо распаковать в папку с Eclips’ом и перезапустить его.
Для установка плагина средствами Eclipse необходимо добавить в Eclipse soapUI репозитарий. Для этого нужно выбрать пункт меню Help -> Install New Software, нажать кнопку Add и в появившемся окне Add Repository ввести имя репозитория (например soapUI) в поле Name и его адрес (http://www.soapui.org/eclipse/update) (рис. 1).

Рисунок 1.

Веб-сервисы. Шаг 1. Что такое веб-сервис и как с ним работать?

Добавление нового репозитория

Затем следует поставить галочку возле soapUI (рис. 2) и далее следовать инструкциям мастера.
Рисунок 2. Установка soapUI

После установки плагина в Eclips’е появится новая перспектива soapUI (пункт меню Window -> Open Perspective -> Other…) (рис.3).

Рисунок 3. Выбор перспективы soapUI

2. Выбор веб-сервиса

На сайте XMethods представлен список общедоступных веб-сервисов с кратким описанием каждого из них. Мы выбрали сервис Countries web service, позволяющий получить информацию по странам и регионам. Описание веб-сервиса (WSDL) доступно по адресу http://www.mobilefish.com/services/web_service/countries.php?wsdl. Сервис предоставляет три метода:

  1. — возврашает массив, содержащий — IANA код страны и — название страны. IANA (Internet Assigned Numbers Authority, Администрация адресного пространства Интернет) — американская некоммерческая организация, управляющая пространствами IP-адресов, доменов верхнего уровня, а также регистрирующая типы данных MIME и параметры прочих протоколов Интернета.
  2. — возвращает IANA код (), имя (), широту () и долготу () страны, переданной в качестве параметра метода.
  3. — возвращает массив, содержащий информацию о регионах страны, переданной в качестве параметра метода в виде IANA кода. Каждый элемент массива содержит IANA код (), имя региона (), широту () и долготу () региона.

3. Создание проекта в soapUI и работа с выбранным веб-сервисом

Для работы с выбранным веб-сервисом создадим новый проект в soapUI. Для этого переключимся на soapUI перспективу, щелкнем правой кнопкой мыши по строке «Projects» в панеле «soapUI Navigator» и выберем пункт New soapUI Project (рис. 4).

Рисунок 4. Создание нового soapUI проекта
В появившемся окне «New soapUI Project» в поле «Project Name» зададим имя проекта, а в поле «Inital WSDL/WADL» — адрес веб-сервиса (рис. 5).
Рисунок 5. Создание нового soapUI проекта
Опция «Create Requests» (по умолчанию выбрана) отвечает за создание шаблона запроса для каждого метода веб-сервиса.

После создания проекта он и его методы появятся в панели «soapUI Navigator» (рис. 6).

Рисунок 6. soapUI проект
Выполним вначале метод , для чего дважды щелкнем по соответствующей строке «Request 1» панели «soapUI Navigator». Появится новая вкладка, состоящая из трех частей. В верхней части находится панель иструментов и выпадающий список с адресами веб-сервисов (по умолчанию там только один адрес — нашего веб-сервиса). Оставшее пространство вкладки разбито на две части — в левой находится запрос, который будет отсылаться веб-сервису (Request), в правой — ответ веб-сервиса (Response). Для отсылки запроса на панели инструментов предусмотрена кнопка — Submit request to specified endpoint URL. Метод не имеет входных параметров, поэтому сразу отсылаем ему запрос. В ответ получаем список стран с их AINA кодами (рис. 7):
Рисунок 7. Результат выполнения метода
Среди списка стран присутствует и Украина, ее IANA код — ua.

Далее получим информацию по Украине с помощью метода . Для этого дважды щелкнем по соответствующей строке «Request 1» панели «soapUI Navigator» и в появившейся вкладке зададим в качестве значения параметра строку «ua». После выполнения метода мы получим следующий результат: широта — 48.379433, долгота — 31.165581 (рис. 8).

Рисунок 8. Результат выполнения метода

Наконец, получим информацию и широте и долготе городов Украниы, для чего выполним метод , также передав в качестве значения параметра строку «ua». Результат представлен на рис. 9:

Рисунок 9. Результат выполнения метода

Проанализируем теперь реакцию веб-сервиса на некорректные запросы на примере метода . Отправим вначале SOAP, удалив предварительно элемент . Веб-сервис возвратил SOAP с элементом Fault, из которого следует, что в методе отсутствует один аргумент (рис. 10):

Рисунок 10. Ответ веб-сервиса с элементом Fault
Далее зададим в качестве параметра метода несуществующий IANA код. Метод вернет SOAP с элементом Fault, который говорит нам о том, что мы должны задать правильный IANA код и указывает на сайт со списком IANA кодов (рис. 11).
Рисунок 11. Ответ веб-сервиса с элементом Fault

Содержание отчета:

  • краткое описание выбранного веб-сервиса (URL, назначение, методы)
  • WSDL-описание веб-сервиса
  • пример вызова метода/методов веб-сервиса и ответ веб-сервиса
  • примеры Fault ответов веб-сервиса на некорректные запросы

[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):
Выглядит отлично, но проблема в том, что это – Pascal. Какая польза от этого простого определения для Java-разработчика? Или для кого-то, кто работает с VB? Нам нужно что-то, что будет понятно всем, даже VB-программистам. Так дайте им XML, содержащий одну и ту же инфрмацию (параметры, значения биржевых котировок и т.д.). Вы создаете SOAP пакет, который по сути является вызовом вашей функции, обернутый в XML, чтобы любое приложения на любой платформе могло его понять. Теперь посмотрим, как выглядит наш SOAP вызов:
Информативно, правда? SOAP упрощается на глазах. Ладно, шутки в сторону. Теперь я постараюсь объяснить вам, как разобраться в этом SOAP вызове.

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

Первый тег, который бросается в глаза – это <SOAP-ENV:Envelope …>. Этот тег – внешняя оболочка 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>. Обратите внимание на эту строку возле тега:
Приблизительно так в XML и определяются типы. (Обратите внимание на то, как хитро я использовал слово «приблизительно», делая обобщение о технологии, которая может измениться как только статья будет опубликована). Что конкретно это означает: тип, определенный в пространстве имен xsi, который, как вы заметили, определен в теге <SOAP-ENV:Envelope> – xsd:string. А это в свою очередь string, определенный в пространстве имен xsd, опять-таки, определенном ранее. (Уверен, юристы бы от этого всего просто млели).

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

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

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

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

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

WSDL-файл: с чем это едят? SoapUi

Я не стану вдаваться в подробности HTTP, для тех, кто не знает – это то, что использует ваш браузер, чтобы общаться с сайтами, на которые вы заходите.

Нужный HTTP запрос будт выглядеть приблизительно так:
Единственное, что еще стоит отметить – это заголовок SOAPAction.

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

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

Вот и все

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

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

Если Вам понравилась статья, проголосуйте за нее

Голосов: 14  

SCA генерирует WSDL для компонентов, которые содержат аннотацию @binding.soap после аннотации @service. Чтобы создать WSDL, SCA во время исполнения с помощью Reflection отражает компонент и анализирует аннотации @param и @return для каждого публичного метода, а также любые аннотации @types в компоненте. Информация из аннотаций @param и @return используется для построения раздела WSDL <types>. Любые аннотации @types, которые указывают на отдельный файл схемы, приведут к созданию элемента <import> в схеме WSDL.

Аттрибут location элемента <service>

Внизу WSDL присутствует элемент <service>, который использует аттрибут location для идентификации URL сервиса. К примеру он может быть таким:

Пример #1 Аттрибут location

<service name="ConvertedStockQuote" … location="http://localhost/ConvertedStockQuote/ConvertedStockQuote.php"/>

Обратите внимание, что местоположение является относительным для корня документов веб-сервера и не может быть обработано заранее. Оно может быть создано только после того, как компонент поместили в нужное место работающего веб-сервера, и когда имя и порт хоста становятся известны и могут быть помещены в WSDL. Подробности из URL-адреса, который запрашивает WSDL, используется, например, если WSDL в ответ на запрос http://www.example.com:1111/ConvertedStockQuote/ConvertedStockQuote.php?wsdl генерирует адрес http: //www.example.com:1111/ConvertedStockQuote/ConvertedStockQuote.php — это то, что будет вставлено в атрибут location в WSDL.

Обертка WSDL документ/литерал и позиционные параметры

SCA генерирует WSDL в стиле обертки документ/литерал.

Этот стиль помещает параметры и возвращаемые типы метода в "обертки", которые названы в честь соответствующего метода. Элемент WSDL <types> каждую из этих оберток. Если мы рассмотрим метод getQuote() примера ConvertedStockQuote:

Пример #2 Метод с двумя аргументами

WSDL создастся с описанием этого метода и его параметров и выдаст XML-схему для этих параметров. Секция типов будет выглядеть как-то так:

Пример #3 Секция типов с именованными параметрами

<types> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://ConvertedStockQuote"> <xs:element name="getQuote"> <xs:complexType> <xs:sequence> <xs:element name="ticker" type="xs:string"/> <xs:element name="currency" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="getQuoteResponse"> <xs:complexType> <xs:sequence> <xs:element name="getQuoteReturn" type="xs:float"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema> </types>

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

Когда SCA генерирует WSDL для SCA-компонента, он включает комментарий в WSDL, который отмечает, что WSDL является интерфейсом для SCA-компонента.

Как использовать мыльный интерфейс без wsdl?

В этом случае, когда один компонент SCA вызывает другой через веб-сервис, SCA на вызывающем конце во время исполнения принимает список позиционных параметров из вызова и, один за другим, присваивает значения названным элементам в SOAP-запроса. Например, вызов метода getQuote(), определенного выше, которому передаются значения "IBM" и "USD", выглядит так:

В результате SOAP-запрос будет выглядеть так:

На стороне предоставляющей сервис, SCA будет брать параметры по очереди из SOAP-запроса и создавать из него список аргументов ('IBM','USD').

Предостережение

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

<getQuote> <ticker>IBM</ticker> <currency>USD</currency> </getQuote>

SOAP WS поддерживает как удаленные процедуры вызова (т.е. RPC), так и стили интеграции среднего уровня (ориентированные на сообщения). Restful Web Service поддерживает только стиль интеграции RPC.

SOAP WS является нейтральным транспортным протоколом. Поддерживает несколько протоколов, таких как HTTP (S), Messaging, TCP, UDP SMTP и т. Д. REST — это специфический транспортный протокол. Поддерживает только протоколы HTTP или HTTPS.

SOAP WS разрешает только формат данных XML. Вы определяете операции, которые туннелируются через POST. Основное внимание уделяется доступу к именованным операциям и раскрытию логики приложения как службы. REST разрешает использование нескольких форматов данных, таких как XML, данные JSON, текст, HTML и т. Д. Любой браузер может использоваться, поскольку подход REST использует стандартные операции GET, PUT, POST и DELETE Web. Основное внимание уделяется доступу к указанным ресурсам и предоставлению данных в виде службы. REST поддерживает AJAX. Он может использовать объект XMLHttpRequest. Хорошо подходит для операций CRUD (создание, чтение, обновление и удаление) без гражданства.

Использование SoapUi для работы с веб-сервисами. Часть1

GET — представлять () POST — acceptRepresention () PUT — storeRepresention () DELETE — removeRepresention ()

Чтение на основе SOAP не может быть кэшировано. Чтения на основе REST могут быть кэшированы. Выполняет и масштабирует лучше. SOAP WS поддерживает как защиту SSL, так и WS-security, которая добавляет некоторые функции безопасности предприятия, такие как поддержание безопасности вплоть до того момента, когда она необходима, поддерживая идентификаторы через посредников, а не только для точки только SSL, обеспечивая защиту отдельных частей сообщения. различные алгоритмы безопасности и т. д. REST поддерживает только двухточечную защиту SSL. SSL шифрует все сообщение, независимо от его чувствительности или нет. SOAP имеет всестороннюю поддержку как для управления транзакциями на основе ACID для краткосрочных транзакций, так и для управления транзакциями на основе компенсации для долгосрочных транзакций. Он также поддерживает двухфазное согласование распределенных ресурсов. REST поддерживает транзакции, но он не совместим с ACID и не может обеспечить двухфазное согласование распределенных транзакционных ресурсов, поскольку он ограничен его протоколом HTTP.

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

источникhttp://java-success.blogspot.in/2012/02/java-web-services-interview-questions.html

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

Закрыть меню