Клиент soap: Клиент web-сервиса SOAP

PHP: SoapClient::SoapClient — Manual

Массив настроек. Если работа происходит в режиме WSDL, то этот параметр необязательный.
Если в не-WSDL режиме, то должны быть установлены опции
location и uri,
где location — URL сервера SOAP, к которому отправляется запрос, а
uri — целевое пространство имен SOAP-сервиса.

Опции style и use
используются только в не-WSDL режиме. В режиме WSDL они поступают из WSDL-файла.

Опция soap_version должна быть равна
либо SOAP_1_1, либо SOAP_1_2,
чтобы использовать соответственно SOAP 1.1 или 1.2. Если параметр пропущен,
то используется 1.1.

Для HTTP-аутентификации могут быть использованы опции
login и password для предоставления учетных данных.
Для реализации HTTP-соединения через прокси-сервер доступны настройки
proxy_host, proxy_port,
proxy_login и proxy_password.
Для аутентификации сертификата клиента HTTPS используются
опции local_cert и passphrase.
Аутентификация может быть предоставлена в опции authentication.
Метод аутентификации может быть
SOAP_AUTHENTICATION_BASIC (по умолчанию) или
SOAP_AUTHENTICATION_DIGEST.

Опция compression позволяет использовать
сжатие запросов и ответов HTTP SOAP.

Опция encoding определяет внутреннюю кодировку.
Опция не меняет кодировку SOAP-запросов (она всегда utf-8),
но преобразует строки в нее.

Опция trace включает отслеживание запроса и в случае ошибки
можно получить обратную трассировку. По умолчанию имеет значение FALSE.

Опция classmap может использоваться для сопоставления
некоторых WSDL-типов с PHP-классами. Опция должна представлять собой массив,
в качестве ключей которого указаны WSDL-типы, а в качестве значений — имена классов PHP.

Установленная булевая опция trace
позволяет использовать следующие методы:

SoapClient->__getLastRequest,

SoapClient->__getLastRequestHeaders,

SoapClient->__getLastResponse и

SoapClient->__getLastResponseHeaders.

Опция exceptions принимает логическое значение, определяющее,
будут ли SOAP-ошибки бросать исключения типа
SoapFault.

Опция connection_timeout определяет тайм-аут в секундах
для соединения с SOAP-сервисом. Опция не устанавливает тайм-аут для сервисов с
медленными ответами. Для ограничения времени ожидания вызовов используется
default_socket_timeout.

Опция typemap является массивом сопоставления типов.
Массив сопоставления типов — это массив с ключами type_name,
type_ns (URI пространства имен), from_xml
(функция обратного вызова принимает один строковый параметр) и
to_xml (функция обратного вызова принимает объект в качестве параметра).

Опция cache_wsdl принимает одно из значений:
WSDL_CACHE_NONE,
WSDL_CACHE_DISK,
WSDL_CACHE_MEMORY или
WSDL_CACHE_BOTH.

Опция user_agent определяет строку для использования
в заголовке User-Agent.

Опция stream_context — это resource для
context.

Опция features является битовой маской
SOAP_SINGLE_ELEMENT_ARRAYS,
SOAP_USE_XSI_ARRAY_TYPE,
SOAP_WAIT_ONE_WAY_CALLS.

Опция keep_alive является логическим значением, определяющим,
какой заголовок отправлять: Connection: Keep-Alive или
Connection: close.

Опция ssl_method должна быть равной
SOAP_SSL_METHOD_TLS,
SOAP_SSL_METHOD_SSLv2,
SOAP_SSL_METHOD_SSLv3 или
SOAP_SSL_METHOD_SSLv23.

Обзор SOAP — JavaTutor.net

SOAP позволяет объектам любого вида, т.е. написанным под любую платформу и на любом языке, перекрестно взаимодействовать. В настоящее время SOAP реализован в более 60 языках и более 20 платформах. Неожиданно все объекты, локальные и удаленные, маленькие и большие, получили возможность взаимодействия друг с другом.

Том Клементс
Январь 2002

В фильме “Бойцовский клуб” Брэд Питт и Эдвард Нортон играют роль второго “я” — противоположные стороны психологического спектра – два парня, которые пытаются общаться друг с другом и с трудом заставляют себя это делать. Довольно интересно (и в этом вся соль), что основные события фильма развиваются вокруг производства мыла. Оказалось, что буквы английского слова soap (мыло) соединяются уникальным и неожиданным образом.

Теперь перейдем к сценарию другого рода, действие которого происходит в Internet и представителями второго “я” являются компании Microsoft и Sun. Каждая из этих компаний имеет свою четкую точку зрения, пытается ликвидировать разрыв и наладить контакты с другой. Узнайте о SOAP (Simple Object Access Protocol – Простой Объектный Протокол Доступа).

Содержание

Введение
Эволюция Web-сервисов
Сетевые уровни
XML: ключ к описанию Web-сервисов
Слабосвязанные системы
Второе пришествие CORBA
Публикация, нахождение, связывание
Создание Web-сервисов
SOAP клиенты и серверы
SOAP и Java технология
Так что же такое в действительности SOAP?
Формат сообщений
Анализ конверта SOAP
Пространства имен
Заголовок
Тело сообщения
SOAP-RPC
Случай использования SOAP
Заключение
Ссылки
Об авторе

Введение

Выражаясь просто, SOAP позволяет Java и COM объектам взаимодействовать друг с другом в распределенной, децентрализованной Web-среде.

В более общем смысле, SOAP позволяет объектам (или коду) любого вида, т.е. написанным под любую платформу и на любом языке, перекрестно взаимодействовать. В настоящее время SOAP реализован в более 60 языках и более 20 платформах. Неожиданно все объекты, локальные и удаленные, маленькие и большие, получили возможность взаимодействия друг с другом. Брэд Питт и Эдвард Нортон, как два объекта различных типов, в конце концов тоже стали способны взаимодействовать.

В данном обзоре SOAP будет первоначально представлен в более широком контексте Web-сервисов, как протокол, соединенный с UDDI (Universal Description, Discovery and Integration – Универсальное Описание, Открытие и Интеграция) с целью обеспечения регистрационных сервисов и сервисов передачи сообщений между предприятиями. Также будут обсуждаться Web обоснования появляющейся парадигмы “публиковать, находить, связывать”, и будут показаны механизмы организации пакетов, транспортировки и доставки в SOAP.

Эволюция Web-сервисов

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

Сетевые уровни

В эволюции Web-сервисов ярко выражены три сетевых уровня: TCP/IP, HTTP/HTML и XML. Эти уровни надстроены последовательно друг над другом и по сегодняшний день остаются совместимыми.

Первый уровень, протокол TCP/IP, связан прежде всего с передачей данных в пакетах по кабелю. Будучи протоколом, который гарантирует пересылку данных по общественным сетям, TCP/IP придает особое значение надежности транспортировки данных и физическому обеспечению связи. Первоначально TCP/IP являлся “замазкой”, скрепляющей отдельные сети, тогда как сейчас это базовый протокол Web, на котором основаны высокоуровневые стандартные протоколы типа HTTP.

Второй уровень, HTML над HTTP, является уровнем представления и занимается поиском с броузерным интерфейсом, выборкой и совместным использованием информации. Здесь основное внимание уделяется GUI-навигации и манипуляции форматов представления. Во многих отношениях HTML носит больше демонстративный, чем функциональный характер, и испытывает недостаток как в расширяемости, так и в истинной программной мощности. Тем не менее, совместное использование гипертекстовых документов в среде с броузерным интерфейсом полностью реконструировало способ передачи текстовой информации между людьми. Сетевые настольные среды, обремененные собственными операционными системами и платформно-зависимым программным обеспечением, медленно но верно уступают основанной на стандартах, открыто-системной обработке данных в Internet.

Погружение в этот новый прекрасный стандартизованный мир возглавляет XML, третий и возможно наиболее неотразимый уровень в Internet. XML – формат обмена данными со строгим контролем типов – предоставляет новое измерение уровню HTTP/HTML, в котором осуществление межкомпьютерного взаимодействия возможно посредством стандартных интерфейсов. Этот уровень, описываемый как A2A (application to application), B2B (business to business) или C2C (computer to computer), позволяет программам обмениваться данными независимо от платформы и представления. Таблицы стилей XSLT могут быть добавлены как дополнительные компоненты представления и/или трансформации.

XML: ключ к описанию Web-сервисов

Ключом к осуществлению всех этих возможностей является межкомпьютерное взаимодействие – область, в которой преобладает XML. Будучи синтаксисом для описания данных, XML управляется определением (при помощи DTD или схем) и позволяет программно управлять информацией. Это означает, что большая часть предполагаемой работы может быть получена из B2B-взаимодействий. Теги могут быть согласованы, интерфейсы определены, а обработка данных стандартизована. Web-сервисы – это компонентные программы многократного пользования, которые используют XML как стандартную расширяемую сетевую структуру, с целью облегчения этого вида межкомпьютерного взаимодействия.

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

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

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

SOAP – это технология, которая произошла от раннего XML-стандарта (XML-RPC) и, в некотором смысле, стремится к появляющемуся стандарту ebXML (electronic business XML). ebXML – это незавершенная технология, направленная на обеспечение всестороннего определения общедоступных бизнес-сообщений между торговыми партнерами. SOAP является менее обширным и менее сложным в выполнении.

Слабосвязанные системы

Web-сервисы отделяют объекты от связывающей их платформы. То есть Web-сервисы облегчают взаимодействие между платформно-независимыми объектами, способными обращаться к данным из любой точки Web. Осуществляя удаление от частных платформ, Web-сервисы полагаются скорее на слабые, чем сильные связи между Web-компонентами. Согласно Брайану Трэвису, консультанту и автору SOAP, системы, которые полагаются на специфичные для одной платформы объекты, называются сильносвязанными системами, т.к. они опираются на однозначный, но хрупкий интерфейс. Если какая-либо часть соединения между объектом-приложением и серверным объектом разорвана, или если вызов некорректен, это может привести к непредсказуемым результатам. EDI (Electronic Data Interchange – Электронный Обмен Данными) является примером сильносвязанной структуры для осуществления электронной коммерции. В свою очередь слабосвязанные системы учитывают гибкий и динамический обмен в открытых распределенных Web-средах.

Второе пришествие CORBA

В настоящее время многие компании (например, IBM, BEA, Sun и др.) совместно сотрудничают с теми же компаниями, с которыми они конкурируют. Стандартизованные сетевые транспортные протоколы, платформно-независимые языки программирования (такие как Java, XML, диалекты, характерные для той или иной промышленности) и открытые компонентные серверные архитектуры способствуют этой антисобственнической общедоступности. Сегодня Web-сервисы (с их обещаниями всеобъемлющей прикладной функциональной совместимости) представляются как окончательный “клей”, заставляющий взаимодействовать все эти технологии, если не без швов, то хотя бы без избыточного багажа, который сопровождал предыдущие технологии, такие как CORBA и RMI.

В каком-то смысле Web-сервисы представляют второе пришествие CORBA. Однако CORBA была объектно-ориентированной структурой бинарных IIOP коммуникаций, загруженной заглушками, скелетами программ и зависящими от поставщика брокерами объектных запросов. Web-сервисы в свою очередь являются легкими, основанными на HTTP, XML-управляемыми и полностью независящими от платформы и языка. Тогда как CORBA была 600-фунтовой полузапертой гориллой, Web-сервисы – это газель, легко скачущая по обширным просторам Internet.

Публикация, нахождение, связывание

Структура Web-сервисов состоит из цикла “публиковать-находить-связывать”, посредством которого поставщики сервисов делают данные, содержимое или услуги доступными для зарегистрированных запрашивающих сторон, потребляющих ресурсы, локализуя сервисы и соединяясь с ними. Запрашивающие приложения настраиваются на Web-сервисы при помощи WSDL (Web Services Definition Language – язык описания Web-сервисов), который предоставляет низкоуровневую техническую информацию о желаемом сервисе, допускает обращение приложений к информации XML Schema для кодировки данных и гарантирует, что правильные операции будут осуществлены по правильным протоколам.

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

Погружаясь немного глубже в аналогию с CORBA, отметим, что SOAP играет роль IIOP в CORBA (или JRMP в RMI). Это связующий механизм между противоположными конечными точками. С другой стороны, WSDL играет роль IDL (Interface Definition Language – Язык Описания Интерфейсов). В этом смысле WSDL определяет Web-сервисы как совокупность портов и операций. WSDL-порт аналогичен интерфейсу, а WSDL-операция аналогична методу. WSDL публикует интерфейсы Web-сервисов сторонам, заинтересованным в коммуникации через гетерогенные платформы.

Однако WSDL не только является языком описания интерфейсов, он также включает конструкции, позволяющие описывать информацию об адресе и протоколе публикуемого Web-сервиса. Интересно то, что WSDL описывает абстрактный интерфейс для Web-сервиса, одновременно позволяя (в мучительных подробностях) связывать Web-сервис с определенным транспортным механизмом, таким как HTTP. Абстрагируя интерфейс, WSDL функционирует как технология многократно используемых Web-сервисов. Связывая Web-сервис с определенным транспортным механизмом, WSDL делает абстракцию конкретной. Если это покажется вам слегка шизофреничным, подумайте о космическом шатле: многократно используемая, полностью функциональная космическая капсула связана со специализированными, но одноразовыми стартовыми ракетными двигателями. Транспортный механизм может измениться, но полезный груз сохраняется.

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

Создание Web-сервисов

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

SOAP клиенты и серверы

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

Сообщения и запросы от клиентов SOAP обычно пересылаются по HTTP. В результате документы SOAP способны обойти почти любой брандмауэр (firewall), допуская обмен информацией между разными платформами.

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

Серверы SOAP гарантируют, что документы, полученные по HTTP соединению, преобразованы к языку, который понятен объекту и всем окружающим. Поскольку все коммуникации осуществляются в форме XML, объекты, написанные на одном языке (скажем, Java), могут связываться через SOAP с объектами, написанными на другом языке (например, C++). Работа SOAP сервера заключается в том, чтобы удостовериться, что конечные пункты понимают обслуживающий их SOAP.

SOAP и Java технология

Согласно спецификации SOAP 1.1, SOAP является легким протоколом для обмена информацией в децентрализованной, распределенной среде.

SOAP не устанавливает единую модель программирования, также как и не делает привязки к определенному языку программирования. В контексте языка программирования Java установление привязки к конкретному языку зависит от Java-сообщества. В настоящее время привязки к языку Java преследуются по инициативе JAX-RPC.

В недавнем обсуждении SOAP, состоявшемся на конференции разработчиков JavaOne(sm), инженеры компании Sun Роберто Чинници (Roberto Chinnici) и Рауль Шарма (Rahul Sharma) определили семейство технологий JAX как “дающее возможность создания Web-сервисов при помощи уже известных компонентных технологий JSP(tm) и EJB(tm) для платформы Java”. Сервлеты и сессионные компоненты, не имеющие состояния, были отмечены как две технологии, наиболее пригодные для инкапсулирования Web-сервисов.

Так что же такое в действительности SOAP?

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

SOAP – это расширяемая, основанная на тексте структура для предоставления связи между разными сторонами (вообще говоря, объектами), которые не знают заранее друг о друге или о платформе, на которой работает противоположная сторона. С точки зрения объектов в сети SOAP – это изначально “свидание вслепую”. Клиентские приложения могут взаимодействовать в слабосвязанных средах, обнаруживать сервисы и динамически подсоединяться к ним без установления каких-либо предварительных соглашений.

SOAP является расширяемым, потому что SOAP клиенты, серверы и сам протокол могут развиваться, не разрушая уже существующие приложения. Более того, SOAP богат в плане поддерживаемых посредников и многоуровневых архитектур. Это означает, что узлы обработки могут находиться на пути запроса между клиентом и сервером. Эти промежуточные узлы обрабатывают части сообщений при помощи использования заголовков, которые позволяют клиентам определять, какая часть сообщения обрабатывается данным узлом. Такой метод обработки промежуточных заголовков выполняется по приватному соглашению между клиентским приложением и промежуточным узлом обработки. SOAP предоставляет заголовкам атрибут mustUnderstand, который позволяет клиенту определить, является обработка обязательной или опциональной. Если mustUnderstand установлен в 1, сервер должен либо выполнить промежуточную обработку, указанную в заголовке, либо выдать ошибку.

SOAP также устанавливает правила кодирования данных, называемые основными уровнями кодирования или кодированием “Section 5” (по названию раздела в спецификации SOAP, посвященного кодированию). Надо отметить, что кодирование в SOAP занимает большую часть сорокастраничной спецификации SOAP 1.1. Не слишком углубляясь в специфику типов данных XML, можно сказать, что кодирование SOAP может быть вкратце описано как коллекция простых или сложных значений.

Простые значения – это либо простые типы данных (например, int, float, string), либо встроенные типы, описанные в разделе 2 спецификации XML Schema. Сюда входят такие типы как байтовые массивы и перечисления.

Сложные значения включают структуры, массивы и сложные типы, определенные группой XML Schema. И последнее, однако немаловажное замечание: кодирование данных в SOAP определяет правила для сериализации объектов, т.е. для механизмов маршалинга и демаршалинга потоков данных. Стоит отметить, что кодирование “Section 5” необязательно, поэтому клиенты и серверы могут использовать различные соглашения по кодированию данных, если есть договоренность о формате.

И наконец, SOAP устанавливает набор правил, которые дают возможность клиентам и серверам осуществлять вызов удаленных процедур, используя SOAP как структуру коммуникаций. Будучи по сути протоколом, ориентированным на работу с сообщениями, SOAP может хорошо работать как RPC-протокол. Объектная сериализация – это механизм, обуславливающий эффективность SOAP-RPC.

Формат сообщений

Все вышеперечисленное выполняется в контексте стандартизованного формата сообщений. Основная часть сообщения имеет MIME тип “text/xml” и содержит SOAP конверт. Этот конверт является XML документом. Конверт содержит заголовок (опционально) и тело (обязательно). Тело конверта всегда предназначено конечному получателю сообщения, тогда как записи в заголовке могут быть адресованы узлам, выполняющим промежуточную обработку. К телу также могут быть присоединены бинарные или какие-либо другие вложения.

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

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

Анализ конверта SOAP

Спецификация SOAP 1.1 предоставляет следующий образец конверта:

<SOAP-ENV: Envelope
  xmlns: 
    SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV: 
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <SOAP-ENV:Header>
        <t:Transaction xmlns:t="some-URI">
                SOAP-ENV:mustUnderstand="1" 
                      5
        </t:Transaction>
      </SOAP-ENV:Header>
      <SOAP-ENV:Body>
        <m:GetLastTradePrice xmlns:m="some-URI">
                <symbol>DEF</symbol>
        </m:GetLastTradePrice>
      </SOAP-ENV:Body>
</SOAP-Envelope>

В этом примере запрос GetLastTradePrice посылается службе котировки акций на Web. Запрос принимает строковый параметр, аббревиатуру акции, и возвращает число с плавающей точкой в ответе SOAP.

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

Пространства имен

Первое пространство имен в примере указывает на схему SOAP, которая определяет элементы и атрибуты сообщения SOAP. Второе пространство имен ссылается на кодирование SOAP: типы данных “Section 5”, обсужденные ранее. Поскольку никакого дополнительного поэлементного кодирования не определено, данное кодирование применяется ко всему документу.

Заголовок

Первый элемент в заголовке нашего конверта SOAP является элементом транзакций, имеющим два атрибута: атрибут пространства имен и атрибут mustUnderstand со значением 1. Так как mustUnderstand установлен в 1, сервер, принимающий данное сообщение, должен выполнять промежуточную обработку на данном узле транзакций. Вы можете интерпретировать это следующим образом: сервер и клиент предварительно договорились о семантике, которая управляет обработкой данного элемента заголовка, поэтому сервер точно знает, что делать с содержимым элемента (в данном случае, со значением 5).

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

Узлы промежуточной обработки, подобные данному, являются примером расширяемости SOAP. Клиенты включают такие узлы в сообщение SOAP, чтобы указать, что прежде чем обрабатывать тело сообщения, необходимо провести специальную обработку. Обеспечение обратной совместимости с серверами, неспособными осуществлять такую обработку, является всего лишь вопросом установки mustUnderstand в 0, что делает эту операцию необязательной.

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

Тело сообщения

Тело сообщения SOAP в примере содержит полезную нагрузку XML (XML payload), которая, предположим, выполняет RPC (Remote Procedure Calling – вызов удаленной процедуры). SOAP – это не только модульная, но также и довольно скрытая модель организации пакетов.

Здесь ничего явно не указывает на то, что был начат RPC. Все, что мы видим в теле, – это пара XML элементов, один из которых квалифицирован пространством имен. Задачей SOAP сервера является понимание семантики документа и осуществление правильных действий. В действительности, сервер предоставляет структуру для работы с полезной нагрузкой XML (XML payload) “значимым” способом. Слово “значимый” в данном случае подразумевает, что сервер осуществляет вызов удаленной процедуры в некоторой вспомогательной базе данных, чтобы получить готовую цену за элемент готового символа, содержащийся в теле сообщения. Вся магия происходит за занавесом SOAP RPC.

SOAP-RPC

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

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

Request (Запрос)
<SOAP-ENV:Body>
     <m:GetLastTradePrice xmlns:m="some-URI">
          <symbol>DEF</symbol>
     </m:GetLastTradePrice>
</SOAP-ENV:Body>

Response (Ответ)
<SOAP-ENV:Body>
     <m:GetLastTradePriceResponse xmlns:m="some-URI">
          <price>22.50</price>
     </m:GetLastTradePriceResponse>
</SOAP-ENV:Body>

Запрос вызывает метод GetLastTradePrice. Обратите внимание, что ответ определяет операцию GetLastTradePriceResponse. Общее соглашение SOAP требует, чтобы в конце операции запроса (Request) добавлялось слово Response для создания структуры ответа (Response). Данная выходная структура содержит элемент с названием price (цена), который возвращает результат вызова метода, возможно, в виде числа с плавающей точкой.

Важно отметить, что нигде в конверте SOAP не выражены явно типы данных, поэтому мы действительно не знаем тип символа или тип результирующего параметра цены, только лишь смотря на сообщение SOAP. Клиентские приложения определяют типы данных либо открыто посредством кодирования “Section 5”, либо частным образом через согласованные контакты с сервером. В обоих случаях эти определения не включены явно в SOAP сообщение.

И наконец, для осуществления RPC необходим низкоуровневый протокол, такой как HTTP. Хотя спецификация SOAP 1.0 предписывает использование HTTP, как транспортного протокола, SOAP 1.1 (а также спецификация “Сообщение SOAP с вложениями”) разрешает использовать FTP, SMTP и даже (возможно) TCP/IP сокеты. Все правила сериализации и кодирования SOAP относятся также и к RPC-параметрам.

Случай использования SOAP

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

• Клиентское приложение где-либо в Internet потребляет Web-сервисы.

• Web-сервисы (через SOAP) выставляют объектные методы.

• Объектные методы обращаются к удаленным данным где угодно на Web.

Применяя транзитивную логику к этим сетевым высказываниям, мы можем вывести итоговое суждение о Web-сервисах и SOAP: “Клиенты повсюду потребляют данные, находящиеся где угодно на Web”. Что и требовалось доказать.

Далее случай использования рассмотрен более детально.

1. Клиент SOAP использует UDDI реестр для локализации Web-сервиса. В большинстве случаев, вместо управления WSDL напрямую, приложение SOAP будет сконструировано так, чтобы использовать специфичный тип порта и стиль связывания, и будет динамически конфигурировать адрес сервиса, вызываемого с целью согласования с сервисом, найденным посредством UDDI.

2. Клиентское приложение создает сообщение SOAP, которое является XML документом, способным осуществлять необходимые операции запроса/ответа.

3. Клиент посылает SOAP сообщение JSP или ASP странице на Web-сервере, слушающем запросы SOAP.

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

5. Запрашиваемый объект выполняет обозначенную функцию и возвращает данные SOAP серверу, который запаковывает ответ в конверт SOAP. Затем сервер “кладет” конверт SOAP в объект ответа (например, сервлет или COM-объект), который посылается обратно запрашивающей машине.

6. Клиент получает объект, “снимает” конверт SOAP и посылает ответный документ программе, первоначально запросившей его, завершая цикл запроса/ответа.

Заключение

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

SOAP хорошо подходит для создания взаимодействующих систем, не зависящих от платформы и языка. В целом SOAP и Web-сервисы отвечают за все необходимое при построении инфраструктуры распределенных приложений на вершине XML. SOAP минимизирует проблему межплатформенной совместимости в организации доступа к данным, разрешая конфликт между моделями компонентных объектов COM и Java.

Возвращаясь к метафоре, с которой начиналось обсуждение, отметим, что SOAP – это идеальная среда для объектов любых типов (даже голливудских: Брэда Питта и Эдварда Нортона), используемая в качестве коммуникационной среды. Ожидается, что результаты этой новой технологии (так же, как и в фильме) сотрясут землю.

Ссылки

“Структура для использования Web-сервисов”, Симеон Симонов, XML Journal, том 2, изд. 6.

“SOAP 1.1 и платформа Java: введение в технологию JAX-RPC”, Роберто Чинници и Рауль Шарма, из выступления на конференции разработчиков JavaOne, июнь 2001.

Понимание SOAP, Кеннард Скрайбнер и Марк К. Стайвер, издательство Sams, 2000. (Чрезвычайно подробное, низкоуровневое представление SOAP и сетевых технологий. Великолепная книга для опытных разработчиков XML и Web-сервисов, желающих стать экспертами в SOAP.)

“Написание вашего первого Web-сервиса”, Энди Маккрайт, Web Services Journal, 1-й выпуск, июнь 2001.

XML и SOAP программирование для серверов BizTalk, Брайан Е. Трэвис, издательство Microsoft, 2000. (Пусть название не отпугивает вас. Это превосходный обзор Web-сервисов и SOAP, блестяще написанный и чрезвычайно хорошо организованный. BizTalk отходит на задний план по сравнению с начальными сведениями, которые занимают большую часть текста. Великолепная книга для начинающих.)

Об авторе

Том Клементс является внештатным техническим писателем, специализирующимся на документации по Java API, XML/XSLT, драйверам устройств и беспроводной связи.

SoapClient::SoapClient — Конструктор SoapClient | Руководство по PHP

Массив настроек. Если работа происходит в режиме WSDL, то этот параметр необязательный.
Если в не-WSDL режиме, то должны быть установлены опции
location и uri,
где location — URL сервера SOAP, к которому отправляется запрос, и
uri — целевое пространство имен SOAP-сервиса.

Опции style и use
используются только в не-WSDL режиме. В WSDL режиме они берутся из WSDL файла.

Опция soap_version должна быть равна
либо SOAP_1_1 либо SOAP_1_2,
чтобы использовать соответственно SOAP 1.1 или 1.2. Если параметр пропущен,
то используется 1.1 .
будет ли использоваться SOAP-клиент версии 1.1 (по умолчанию) или 1.2.

Для HTTP аутентификации могут быть использованы опции
login и password для получения полномочий.
Для реализации HTTP соединения через proxy-сервер используются настройки
proxy_host, proxy_port,
proxy_login и proxy_password.
Для HTTPS сертификата аутентификации клиента используются
опции local_cert и passphrase.
Аутентификация может быть передана через authentication.
Метод аутентификации может быть
SOAP_AUTHENTICATION_BASIC (по умолчанию) или
SOAP_AUTHENTICATION_DIGEST.

Опция compression позволяет
сжимать запросы и ответы HTTP SOAP.

Опция encoding определяет внутреннюю кодировку.
Опция не меняет кодировку SOAP-запросов (она всегда utf-8),
но преобразует строки в нее.

Опция trace включает отслеживание запроса и в случае ошибки
можно получить обратную трассировку. По умолчанию имеет значение FALSE.

Опция classmap может использоваться для перевода
некоторых WSDL-типов в PHP классы. Опция должна представлять собой массив,
в качестве ключей которого указаны WSDL-типы, а в качестве значений — имена PHP классов.

Установленная булевая опция trace
позволяет использовать следующие методы:

SoapClient->__getLastRequest,

SoapClient->__getLastRequestHeaders,

SoapClient->__getLastResponse и

SoapClient->__getLastResponseHeaders.

Опция exceptions принимает булевые значения и
определяет будут ли SOAP-ошибки бросать исключения типа
SoapFault.

Опция connection_timeout определяет тайм-аут в секундах
для соединения с SOAP-сервисом. Опция не устанавливает тайм-аут для сервисов с
медленными ответами. Для ограничения времени ожидания вызовов используется
default_socket_timeout.

Опция typemap является массивом сопоставления типов.
Массив сопоставления типов — это массив с ключами type_name,
type_ns (URI пространства имен), from_xml
(функция обратного вызова принимает один строковый параметр) и
to_xml (функция обратного вызова принимает объект в качестве параметра).

Опция cache_wsdl принимает одно из значений:
WSDL_CACHE_NONE,
WSDL_CACHE_DISK,
WSDL_CACHE_MEMORY или
WSDL_CACHE_BOTH.

Опция user_agent определяет строку для использования
в User-Agent заголовке.

Опция stream_context — это resource для
context.

Опция features является битовой маской
SOAP_SINGLE_ELEMENT_ARRAYS,
SOAP_USE_XSI_ARRAY_TYPE,
SOAP_WAIT_ONE_WAY_CALLS.

Опция keep_alive принимает булево значение, определяющее
какой заголовок отправлять: Connection: Keep-Alive или
Connection: close.

Опция ssl_method должна быть равной
SOAP_SSL_METHOD_TLS,
SOAP_SSL_METHOD_SSLv2,
SOAP_SSL_METHOD_SSLv3 или
SOAP_SSL_METHOD_SSLv23.

Различия REST и SOAP / Хабр

Эта вторая статья в серии постов о разработке REST API:
В этой статье рассматриваются некоторые аспекты основных различий между REST и SOAP.

Упс… на самом деле, сравнивать их немного похоже на сравнение яблок с апельсинами, поскольку SOAP — это формат протокола, основанный на XML, тогда как REST — это архитектурный подход.

Вы изучите

• Что такое REST?
• Что такое SOAP?
• Чем отличаются REST и SOAP?

REST и SOAP

REST и SOAP на самом деле не сопоставимы. REST — это архитектурный стиль. SOAP — это формат обмена сообщениями. Давайте сравним популярные реализации стилей REST и SOAP.

• Пример реализации RESTful: JSON через HTTP
• Пример реализации SOAP: XML поверх SOAP через HTTP

На верхнем уровне SOAP ограничивает структуры ваших сообщений, тогда как REST — это архитектурный подход, ориентированный на использование HTTP в качестве транспортного протокола.

• Специфика SOAP — это формат обмена данными. С SOAP это всегда SOAP-XML, который представляет собой XML, включающий:
  
  — Envelope (конверт) – корневой элемент, который определяет сообщение и пространство имен, использованное в документе,
  
  — Header (заголовок) – содержит атрибуты сообщения, например: информация о безопасности или о сетевой маршрутизации,
  
  — Body (тело) – содержит сообщение, которым обмениваются приложения,
  
  — Fault – необязательный элемент, который предоставляет информацию об ошибках, которые произошли при обработке сообщений. И запрос, и ответ должны соответствовать структуре SOAP.
• Специфика REST — использование HTTP в качестве транспортного протокола. Он подразумевает наилучшее использование функций, предоставляемых HTTP — методы запросов, заголовки запросов, ответы, заголовки ответов и т. д.

Формат обмена сообщениями

• В SOAP вы используете формат SOAP XML для запросов и ответов.
• В REST такого фиксированного формата нет. Вы можете обмениваться сообщениями на основе XML, JSON или любого другого удобного формата. JSON является самым популярным среди используемых форматов.

Определения услуг

• SOAP использует WSDL (Web Services Description Language) — язык описания веб-сервисов и доступа к ним, основанный на языке XML.
• REST не имеет стандартного языка определения сервиса. Несмотря на то, что WADL был одним из первых предложенных стандартов, он не очень популярен. Более популярно использование Swagger или Open API.

Транспорт

SOAP не накладывает никаких ограничений на тип транспортного протокола. Вы можете использовать либо Web протокол HTTP, либо MQ.

REST подразумевает наилучшее использование транспортного протокола HTTP

Простота реализации

RESTFful веб-сервисы, как правило, гораздо проще реализовать, чем веб-сервисы на основе SOAP.

• REST обычно использует JSON, который легче анализировать и обрабатывать. В дополнение к этому, REST не требует наличия определения службы для предоставления веб-службы.
• Однако в случае SOAP вам необходимо определить свой сервис с использованием WSDL, и при обработке и анализе сообщений SOAP-XML возникают большие накладные расходы.

По этому вопросу также имеется авторское видео.

Резюме

В этой статье мы подробно рассмотрели различия между REST и SOAP.

Дополнительное чтение

5 Courses to Learn RESTful Web Services With Java and Spring in 2019

10 API Testing Tips for Beginners (SOAP and REST)

Тестирование веб сервисов или как пользоваться SoapUI

Допустим, вы интегрируете системы, используя веб-сервисы, или ваши клиентские приложения взаимодействуют с сервером посредством веб-сервисов, в этом случае вам просто необходимо использовать инструмент SoapUI для тестирования веб-сервисов и клиентов. Работа с программой SoapUI очень проста и позволяет воочию увидеть передаваемые и получаемые данные. Кроме того вы сможете провести нагрузочное тестирование вашего веб-сервиса и симулировать работу веб-сервиса.

О SoapUI

Итак, что же такое SoapUI? Это кроссплатформенное клиентское оконное приложение, написанное на языке Java. Использовать основной функционал приложения можно бесплатно. В платной версии программы, которая называется SoapUI Pro, вы сможете делать чуть больше, например, устанавливать плагины с помощью менеджера плагинов, проводить тесты драйверов данных, перехватывать трафик, оценивать покрытие ваших веб-сервисов тестами и создавать отчёты. Официальная страничка проекта находится здесь, скачать дистрибутив бесплатной версии программы можно здесь. Если бесплатной версии вам не хватает, вы можете скачать пробную версию SoapUI Pro здесь.

Если для разработки вы используете IDE IntelliJ, NetBeans или Eclipse, то вы можете интегрировать SoapUI прямо в IDE используя плагины. Как это сделать написано здесь. Я не буду останавливаться на этом варианте. Здесь я опишу лишь вариант использования SoapUI, как самостоятельного приложения. Установка на компьютер под управлением Windows проходит быстро и не вызывает вопросов, поэтому на этом этапе я тоже не буду заострять внимание.

Тестирование веб-сервиса

Прежде чем продолжить изучать программу SoapUI сделаем тестовый веб-сервис. Я сделаю это в Visual Studio, у моего сервиса будет только две функции GetSum1 и GetSum2, которые работают одинаково, но принимают и отдают результат по-разному.

using System;
using System.Collections.Generic;
using System.Data;
using System.Threading;
using System.Web;
using System.Web.Services;
 
namespace SoapUITester
{
   /// <summary>
   /// Веб-сервис для тестирования программы SoapUI.
   /// </summary>
   [WebService(Namespace = "http://www.proghouse.ru/SoapUITester")]
   [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
   [System.ComponentModel.ToolboxItem(false)]
   public class Service1 : System.Web.Services.WebService
   {
 
      [WebMethod]
      public int GetSum1(int a, int b, int? c)
      {
         //Сделаем задержку для отрицательных чисел
         if (a < 0 || b < 0 || (c.HasValue && c.Value < 0))
            Thread.Sleep(100);
         //Искуственно заложим здесь ошибку при вычислениях
         if (a == 5)
            return -1;
         return a + b + (c.HasValue ? c.Value : 0);
      }
 
      [WebMethod(EnableSession = true)]
      [System.Web.Services.Protocols.SoapDocumentMethodAttribute(ParameterStyle = System.Web.Services.Protocols.SoapParameterStyle.Bare)]
      public ContrAgInvoiceResponse GetSum2(ContrAgInvoiceRequest request)
      {
         //Сделаем задержку для всей функции
         Thread.Sleep(200);
         ContrAgInvoiceResponse response = new ContrAgInvoiceResponse();
         response.sessionID = Session.SessionID;
         response.sum = request.a + request.b + (request.c.HasValue ? request.c.Value : 0);
         return response;
      }
 
   }
 
   public class ContrAgInvoiceRequest
   {
      public int a;
      public int b;
      public int? c;
   }
 
   public class ContrAgInvoiceResponse
   {
      public string sessionID;
      public int sum;
   }
}

Теперь запустите программу SoapUI и создайте новый проект. Для этого в меню выберите пункт «File -> New SOAP Project». В появившемся окне задайте имя проекту и путь к WSDL. При включенной галочке «Create Requests» при создании проекта автоматически создадутся шаблоны для запросов к веб-сервису, эту галку мы оставим. Если установлена галка «Create TestSuite», то при создании проекта создадутся тесты. Нажмите кнопку «OK».

После этого мы увидим, что для нашего тестового веб-сервиса создались запросы, причём для версий протокола SOAP 1.1 и 1.2. Дважды щёлкните на запрос «Request 1» и справа откроется дочернее окошко «Request 1», в котором вы увидите сформированный запрос.

Чтобы теперь проверить, как работает наш тестовый веб-сервис, замените вопросительные знаки значениями и нажмите на зелёный треугольник (сверху слева в этом же дочернем окне), чтобы отправить запрос. Когда запрос выполнится, в правой части отобразится ответ сервера (на картинке веб-служба вернула число 7), а снизу слева время выполнения (на картинке 3 миллисекунды) и количество полученных байт (на картинке 358 байт).

Теперь вычислим сумму с отрицательным числом. Как видно на картинки, функция GetSum1 с отрицательными числами работает дольше. Это ожидаемый результат, т.к. в функции GetSum1 специально стоит задержка 100мс, если хотя бы одно из полученных чисел отрицательное.

Если вместо числа передать строку, то вы увидите ошибку.

Третий параметр у нас необязательный. Проверим, что будет, если мы его уберём из запроса. После выполнения мы увидим, что сумма посчиталась, ошибок нет.

Как видите, проверить работу веб-сервиса можно очень просто и быстро.

Тесты

Теперь попробуем создать тесты для сервиса. Сначала добавьте в проект набор тестов (TestSuite).

Затем в набор тестов добавьте тестовый случай (TestCase).

Теперь в новый тестовый случай можно добавить шаги для теста. Добавим тестовый запрос «Test Request».

В диалоге «New TestRequest» выбираем тестируемую функцию «GetSum1».

На следующем диалоге можно выбрать дополнительные утверждения, которые будут проверяться при проведении тестов: Add SOAP Response Assertion (добавляет утверждение, что ответ является SOAP-сообщением), Add Schema Assertion (добавляет утверждение, что ответ соответствует схеме), Add NOT SOAP Fault Assertion (добавляет утверждение, что ответ не является SOAP-ошибкой). Также здесь можно указать, нужно ли создать шаблон для необязательных элементов в запросе. Поставьте первую и третью галочку.

После добавления шага теста можно задать параметры и выполнить тест. Для выполнения теста также нажимаем зелёный треугольник.

Как видите после тестирования слева от названия шага «Test Request» отобразилась зелёная картинка-статус, сигнализирующая, что тест выполнен успешно. Теперь в первом параметре передайте строку и запустите тест. После тестирования вы можете увидеть, что картинка-статус поменяла цвет на красный, а на нижней левой панели отображается, что пошло не так. В нашем примере – это SOAP-ошибка «Not SOAP Fault — FAILED». Там же на закладке «Request Log» вы можете посмотреть, когда выполнялся тест, сколько по времени и сколько байт было возвращено.

Теперь сделаем тестирование диапазона значений. Будем подставлять в параметр «a» значения от 1 до 5 и проверять сумму. Для этого сначала нужно добавить свойство, которое будет хранить текущее значение параметра «a», например, в тестовый случай «TestCase 1». Для этого дважды щёлкните по нему на панели «Navigator». Затем в открывшемся дочернем окне «TestCase 1» откройте вкладку «Properties», щёлкните на кнопку с плюсом и задайте новому свойству имя «aValue» и значение 1.

Теперь переключитесь в тестовый запрос «Test Request» (дважды щёлкнув по нему на панели «Navigator») сотрите значение в параметре «a» и щёлкните по тому месту, где нужно будет вставить значение свойства, правой клавишей мышки и в меню выберите только что добавленный параметр «Get Data… -> TestCase: [TestCase 1] -> Property [aValue]».

После этого вместо статического значения параметра вы увидите текст ${#TestCase#aValue}. Можете теперь запустить тест и удостовериться, что при тестировании будет подставлена единица вместо строки ${#TestCase#aValue} и сумма получится равная 7.

После выполнения запроса вы можно посмотреть, что было передано веб-сервису, в частности, какое значение параметра «a» было передано на сервер, на закладке «Raw» (сырые данные). Здесь вы увидите HTTP-запрос полностью вместе с заголовочной частью. Аналогично можно посмотреть HTTP-ответ от веб-сервиса.

Кстати, для более удобного доступа к свойствам вы можете включить режим отображения свойств на панели навигатора (маленькая кнопка слева сверху на панели). Тогда свойства можно просматривать прямо на панели «Navigator». После этого дважды щёлкнув на свойство в навигаторе, вы можете поменять его значение.

Как видите из картинки, свойства могут быть заданы для проекта в целом, для отдельного набора тестов (TestSuite) или для отдельной тестовой ситуации (TestCase).

Теперь сделаем установку свойству «aValue» значения 1 в начале тестирования. Для этого откройте тестовый случай «TestCase 1», откройте вкладку «Setup Script» (скрипт инициализации вызывается перед выполнением тестового случая) и добавьте сюда следующий код:

log.info "Инициализация свойства aValue"
testRunner.testCase.setPropertyValue("aValue", "1")

Здесь же сразу можно проверить, как выполняется скрипт. Для этого нажмите на зелёный треугольник. Если при выполнении возникнут ошибки, то появится диалоговое окно с их описанием. В нашем случае всё отработало нормально. Откройте вкладку «script log», чтобы увидеть наше сообщение.

Здесь нужно сразу заметить, что все скрипты в SoapUI по умолчанию пишутся на языке Groovy, и в статье я буду использовать этот скрипт. Справку по языку можно получить здесь. По желанию вы можете использовать JavaScript для написания скриптов, тогда для правильной интерпретации ваших скриптов нужно установить в свойстве проекта «Script Language» значение «Javascript». В этом случае для интерпретации скриптов будет использоваться движок Rhino.

Также обратите внимание, что над каждым окошком для написания скрипта перечислены доступные глобальные переменные. На картинке сверху – это переменные log, testCase, context и testRunner.

Теперь после каждого шага «Test Request» нам нужно увеличивать значение свойства «aValue» на единицу. Чтобы это сделать, добавьте в тестовую ситуацию (TestCase) шаг «Groovy Script» — пункт контекстного меню «Add Step -> Groovy Script».

После добавления шага напишите следующий скрипт для изменения значения свойства:

Integer curValue = new Integer(testRunner.testCase.getPropertyValue( "aValue" ))
log.info "Текущее значение: " + curValue
curValue += 1
testRunner.testCase.setPropertyValue("aValue", curValue.toString())
log.info "Значение после изменения: " + curValue

Здесь вы сразу можете выполнить скрипт и увидеть на панели навигатора изменённое значение свойства «aValue», а на вкладке «Log Output» увидите наш лог.

Теперь попробуем циклично выполнять шаги «Test Requset» и «Groovy Script». Для того чтобы это сделать добавьте к скрипту следующие строчки:

if (curValue < 10)
   testRunner.gotoStepByName( "Test Request")

Как видите, цикл будет выполняться пока значение свойства «aValue» меньше 10. Теперь откройте тестовый случай «TestCase 1» и выполните его. Как видите на вкладке «TestCase Log», всего выполнилось 18 шагов (9 «Test Request» и 9 «Groovy Script»).

Теперь нужно отловить ошибку в вычислениях, которую мы специально заложили в веб-сервисе. Сервис должен вернуть -1, если первый параметр функции «GetSum1» равен 5. Для этого будем проверять результат работы функции. Чтобы добавить утверждение, которое будет проверять SoapUI, щёлкните по кнопке «Add an assertion to this item» (см. картинку), и в диалоге выбора утверждения выберите «Script Assertion».

И в диалоге «Script Assertion» пропишите скрипт проверки результата.

import com.eviware.soapui.support.XmlHolder
//Парсим запрос и ответ
def resp = new XmlHolder( messageExchange.responseContentAsXml )
def req = new XmlHolder( messageExchange.requestContentAsXml )
//Прописываем пространства имён
resp.namespaces["xmlns"] = "http://www.proghouse.ru/SoapUITester"
req.namespaces["soap1"] = "http://www.proghouse.ru/SoapUITester"
//Считываем результат из ответа
Integer result = new Integer(resp.getNodeValue('//xmlns:GetSum1Result'))
//Считываем параметры из запроса
Integer a = new Integer(req.getNodeValue('//soap1:a'))
Integer b = new Integer(req.getNodeValue('//soap1:b'))
Integer c = new Integer(req.getDomNode('//soap1:c') == null ? 0 : req.getNodeValue('//soap1:c'))
//Проверяем утверждение
assert result == a + b + c

Здесь же сразу можно проверить результат, выполнив скрипт. На картинке видно, что скрипт выполнился успешно – утверждение истинно.

Теперь поменяем в качестве эксперимента параметр «aValue» – установим значение 5 и выполним тест «Test Request». После выполнения вы увидите, что тест провален (красная иконка в навигаторе) и увидите, какое утверждение не выполнено. В нашем случае – это утверждение «Script Assertion».

Теперь выполним всю ситуацию «TestCase 1». После выполнения на вкладке «TestCase Log» мы видим, что тестирование прошло с ошибкой. Выполнение было прервано на шаге 9. Предыдущие шаги были выполнены без ошибок. Дважды щёлкнув на шаг 9 в логе, мы можем узнать, какой запрос был передан веб-сервису и что было возвращено (в нашем случае сумма посчиталась неправильно).

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

Нагрузочное тестирование

Чтобы проверить, выдерживает ли сервер требуемую нагрузку, или понять, какие функции выполняются медленно, мы можем провести нагрузочное тестирование. В нашем примере умышленно сделана большая задержка в функции «GetSum2». Давайте обнаружим эту задержку с помощью нагрузочного тестирования.

Сначала сделайте новую тестовую ситуацию «TestCase 2», добавьте в неё тестовый запрос «Test Request 1» для функции веб-сервиса «GetSum1» и тестовый запрос «Test Request 2» для функции «GetSum2». Вместо статических значений параметров поставьте следующий скрипт: ${=(int)(Math.random() * 100) — 50}. Так в качестве значений параметров будут устанавливаться отрицательные и положительные числа подобранные случайным образом. У вас должны получиться следующие SOAP-запросы:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:soap1="http://www.proghouse.ru/SoapUITester">
   <soap:Header/>
   <soap:Body>
      <soap1:GetSum1>
         <soap1:a>${=(int)(Math.random() * 100) - 50}</soap1:a>
         <soap1:b>${=(int)(Math.random() * 100) - 50}</soap1:b>
         <soap1:c>${=(int)(Math.random() * 100) - 50}</soap1:c>
      </soap1:GetSum1>
   </soap:Body>
</soap:Envelope>

для функции «GetSum1» и для функции «GetSum2»:

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:soap1="http://www.proghouse.ru/SoapUITester">
   <soap:Header/>
   <soap:Body>
      <soap1:request>
         <soap1:a>${=(int)(Math.random() * 100) - 50}</soap1:a>
         <soap1:b>${=(int)(Math.random() * 100) - 50}</soap1:b>
         <soap1:c>${=(int)(Math.random() * 100) - 50}</soap1:c>
      </soap1:request>
   </soap:Body>
</soap:Envelope>

Теперь добавьте нагрузочный тест (пункт контекстного меню «New LoadTest»).

После добавления нагрузочного теста сразу всё готово к его запуску. Здесь вы можете задать количество потоков, стратегию выполнения и параметры для каждой стратегии (вы можете параллельно выполнять несколько тестов, используя разную стратегию). Выполните тест.

После выполнения в таблице вы увидите минимальное и максимальное время выполнения теста, среднее значение, количество ошибок и пр. На вкладке «LoadTest Log» будет указано время начала и окончания теста. Также вы можете посмотреть статистику и историю на графиках.

По таблице вы можете заметить, что тест «Test Request 2» выполняется дольше. В среднем 203,55 мс, а тест «Test Request 1» выполняется быстрее примерно в 2 раза. Вот мы и обнаружили, что в функции «GetSum2» есть задержка при выполнении.

Тестирование клиента

Теперь давайте попробуем создать имитацию веб-сервиса с помощью программы SoapUI. Это может пригодиться для тестирования клиента веб-сервиса. Ведь с помощью такого имитатора веб-сервиса вы сможете протестировать все возможные ситуации на клиенте.

Чтобы создать веб-сервис, щёлкните по SOAP-интерфейсу и в контекстном меню выберите пункт «Generate SOAP Mock Service».

В поднявшемся диалоге вы можете выбрать функции, для которых нужно создать операции сервиса, путь к сервису и порт. Нажмите «OK».

После того как сервис создан, дважды щёлкните по запросу, который хотите поправить, например, по «Response 1» и задайте параметр, который должна вернуть функция GetSum1. Вы можете здесь задать статическое значение, которое будет получать клиент или вычислять его в зависимости от входных параметров. Также здесь вы можете задать ответ-ошибку и протестировать, как клиент будет обрабатывать сообщение с ошибкой.

Мы здесь сделаем расчёт суммы и возврат результата с помощью скрипта. Откройте вкладку «Script» и напишите следующий код:

import com.eviware.soapui.support.XmlHolder
//Парсим запрос и ответ
def req = new XmlHolder( mockRequest.getContentElement() )
//Прописываем пространства имён
req.namespaces["soap1"] = "http://www.proghouse.ru/SoapUITester"
//Считываем параметры из запроса
Integer a = new Integer(req.getNodeValue('//soap1:a'))
Integer b = new Integer(req.getNodeValue('//soap1:b'))
Integer c = new Integer(req.getDomNode('//soap1:c') == null ? 0 : req.getNodeValue('//soap1:c'))
//Сохраняем значение в свойстве "result"
context.setProperty("result", a + b + c)

После этого в SOAP-ответе вместо вопроса можно подставить следующую строку: ${=result}. У вас должен получиться такой ответ:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://www.proghouse.ru/SoapUITester">
   <soapenv:Header/>
   <soapenv:Body>
      <soap:GetSum1Response>
         <soap:GetSum1Result>${=result}</soap:GetSum1Result>
      </soap:GetSum1Response>
   </soapenv:Body>
</soapenv:Envelope>

Вот так это выглядит в программе:

Теперь, можете запустить сервис. Для этого переключитесь в навигаторе на сервис, у меня это «Service1Soap MockService» и щёлкните по зелёному треугольнику. После запуска сверху будет двигаться бегунок показывающий, что сервис работает.

Теперь можно тестировать клиента. Я для примера сделал консольное приложение в Visual Studio, добавил в проект ссылку, указав ссылку на WSDL (WSDL можно получить, щёлкнув по кнопке с изображением зелёной фигуры, на картинке сверху она обведена зелёным кружком). Далее можно вызывать функцию сервиса «GetSum1». Вот код консольного приложения:

using SoapUITesterClient.localhost;
using System;
using System.Collections.Generic;
using System.Text; 
 
namespace SoapUITesterClient
{
   class Program
   {
      static void Main(string[] args)
      {
         Service1 service = new Service1();
         Console.WriteLine(service.GetSum1(1, 2, 4));
      }
   }
}

После выполнения приведённого кода программы в консоль будет выведен результат 7.

Также при создании сервиса вы можете тестировать его здесь же прямо из программы SoapUI.

Заключение

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

REST vs SOAP. Часть 1. Почувствуйте разницу / Хабр

Некоторое время назад я гуглил интернет по поводу “REST vs SOAP”, прочитал пару статей и вроде бы все понял, но не почувствовал от этого никакого удовлетворения. Что-то было не так, то ли я не почувствовал основную идею, то ли просто читал, одновременно слушая новый музон и думая о новой фиче в проекте. Как появилось время, решил восполнить этот пробел, заодно написав полезную статью по этому поводу.

Оглавление цикла статей:

REST vs SOAP. Часть 1. Почувствуйте разницу.
REST vs SOAP. Часть 2. Как проще и эффективнее организовать общение платформ?

Пару месяцев назад при беглом изучении вопроса я понял о REST примерно следующее:

• Все является ресурсами с уникальным идентификатором (URL)
• Все операции клиента с сервером stateless, т.е. сервер не должен хранить вообще никакой информации о клиенте – никакой сессии
• Все запросы можно поделить на 4 типа в соответствии с CRUD, причем каждому типу сопоставляется HTTP метод – Post, Get, Put и Delete
• Вся логика крутится вокруг ресурсов, а не операций

Вот с такими воспоминаниями я начал бороздить просторы интернета. Первой мыслью было, а почему выбрано название REST? Representational State Transfer, в переводе википедии «передача состояния представления»… Никакой картинки в голове не вырисовывается даже при четвертом вчитывании. Здесь пытаются ответить на мой вопрос и даже приводят то, как Рой Филдинг (человек, сформулировавший принципы REST) сам объяснял происхождение названия. Мысль сводится к тому, что запрос ресурса с сервера переводит клиентское приложение в определенное состояние (state), а запрос следующего ресурса меняет состояние приложения (transfer). А “Representational” означает то, что ресурс возвращается не просто так, а в каком-то представлении, например в представлении для машины или в представлении для человека. Сложно, как по мне, и сбивает с толку, т.к. состояние – это как раз то, что отсутвует в отношениях клиент-сервер в архитектуре REST. Я бы назвал как-то вроде «Стандартизированное оперирование данными», вот только сначала надо что-то придумать, а потом уже яркое название выбирать. А Филдинг в своей диссертации признается, что название придумано не для того, чтобы было понятно, о чем речь, а «is intended to evoke an image of how a well-designed Web application behaves». Но это ничего, не будем обижаться на уважаемого человека, мы тоже в дипломных работах часто формулировали все так, чтобы было как можно непонятнее и нельзя было придраться. Нашлась и неплохая формулировка идеи по-русски – «представление данных в удобном для клиента формате». Справедливости ради надо отметить, что пока я формулировал свои доводы о нелогичности названия, я увидел в нем некоторую логику, по крайней мере в английском варианте.

Важно понимать, что REST – это не протокол и не стандарт, а архитектурный стиль. У этого стиля есть свои принципы. Позволю себе скопировать их с понравившегося источника и прокомментировать:

1. Give every “thing” an ID.
   
   Очччень желательно.
2. Link things together.
   
   Например, в страницу (представление) о Mercedes C218 хорошо бы добавить ссылку на страницу конкретно о двигателе данной модели, чтобы желающие могли сразу туда перейти, а не тратить время на поиск этой самой страницы.
3. Use standard methods.
   
   Имеется в виду, экономьте свои силы и деньги заказчика, используйте стандартные методы HTTP, например GET

   http://www.example.com/cars/00345

   для получения данных вместо определения собственных методов вроде getCar?id=00345.

4. Resources can have multiple representations.
   
   Одни и те же данные можно вернуть в XML или JSON для программной обработки или обернутыми в красивый дизайн для просмотра человеком.
5. Communicate statelessly.
   
   Да, RESTful сервис должен быть как идеальный суд – его не должно интересовать ни прошлое подсудимого (клиента), ни будущее – он просто выносит приговор (отвечает на запрос).

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

1. SOAP – это целое семейство протоколов и стандартов, откуда напрямую вытекает, что это более тяжеловесный и сложный вариант с точки зрения машинной обработки. Поэтому REST работает быстрее.
2. SOAP используют HTTP как транспортный протокол, в то время как REST базируется на нем. Это означает, что все существующие наработки на базе протокола HTTP, такие как кеширование на уровне сервера, масштабирование, продолжают так же работать в REST архитектуре, а для SOAP необходимо искать другие средства. Взамен этого SOAP сервисы получают такое мифическое свойство, как возможность работать с любым протоколом транспортного уровня вместо HTTP, однако практической пользы от него зачастую не больше, чем сотрудникам Челябинского трубопрокатного завода от большого количесва статей в википедиях на мертвых языках.
3. Есть мнение, что разработка RESTful сервисов намного проще. Наверное, это правда, если использовать Notepad в качестве основной среды разработки, но вот с использованием наших чудесных средств разработки, я позволю себе усомниться в верности этого утверждения.
4. В первом гугловском результате по запросу «REST vs SOAP» акцентируется внимание на том, что ответ REST может быть представлен в различных форматах, а SOAP привязан к XML. Это действительно важный фактор, достаточно представить себе вызов сервиса из javascript, ответ на который мы определенно хотим получать в JSON.
5. «REST vs SOAP» можно перефразировать в «Простота vs Стандарты», что проявляется в том, что для SOAP мы имеем протокол WSDL для исчерпывающего описания веб-сервиса, который с использованием все тех же чудесных средств разработки прото-таки волшебным образом делает почти всю работу за нас. Со стороны REST мы имеем загадочный и неиспользуемый протокол WADL, который, в принципе, и не нужен – он мешает простоте.
6. Второй аспект предыдущего пункта – обработка ошибок. В SOAP она полностью стандартизована, а REST может использовать давно известные коды ошибок HTTP (если здесь Вас посетила мысль, что это же очевидно и зачем я это пишу, то значит Вы внимательно читаете статью).
7. То, с чего можно было бы начать, но я припас напоследок. Это одна из ключевых мыслей. SOAP работает с операциями, а REST – с ресурсами. Этот факт в совокупности с отсутствием клиентского состояния у RESTful сервисов приводит нас к тому, что такие вещи как транзакции или другая сложная логика должна реализовываться «SOAP-но».

Приведу пару примеров на понимание разницы между подходами. Букмекерская контора заказала сервис для работы с футбольной статистикой. Пользовательский функционал – получить список матчей, получить детали о матче. Для редакторов – редактировать (Create, Edit, Delete) список матчей, редактировать детали матча. Для такой задачи однозначно надо выбирать подход REST и получать бенефиты от его простоты и естественности во взаимодействии с HTTP. Не нужны нам здесь SOAP-конверты, SOAP-главпочтамты и SOAP-авиапочта, которая может использовать любую марку самолета. Нам всего лишь надо реализовать следующее:

Все очень просто! Теперь пример посложнее. Та же букмекерская контора захотела API для ставок на live матчи. Эта процедура включает в себя многочисленные проверки, например, продолжает ли ставка быть актуальной, не изменился ли коэффициент, не превышена ли максимальная сумма ставки для маркета. После этого происходит денежная транзакция, результаты которой записываются в основную и в резервные базы данных. Лишь после этого клиенту приходит ответ об успешности операции. Здесь явно прослеживается ориентация на операции, имеются повышенные требования к безопасности и устойчивости приложения, поэтому целесообразно использовать SOAP.

И еще пару задач для того, чтобы почувствовать тему:

• Футбольный клуб заказывает CMS для подробных сведений об игроках команды-неприятеля. Нужен функционал добавления характеристик игрока простыми пользователями прямо во время матча с последующей интеграцией с табло стадиона, на котором необходимо в реальном времени отображать комментарии.
• Мексиканский наркобарон Педро Гонсалес заказывает API для учета продаж героина в Юго-Западных штатах США. Он особо просит мобильное приложение под эту задачу, т.к. его бизнес часто проходит на открытом воздухе, где нету других вариантов выхода в сеть.
• Анонимный миллиардер очень хочет такую программу, которая бы ему показывала всех его любовниц в городе, в котором он сейчас находится и то, какой текущий статус отношений. Он хочет интегрировать эту программу с уже существующим его личным десктопным приложением для подбора мест для отдыха, он очень хочет большую красную надпись о возможных неприятностях в окошке, где предлагаются варианты авиаперелета.

Какие подходы Вы бы использовали в данных задачах?

Хотел я еще написать про то, что это все дает .NET разработчику и как это использовать в своих целях, однако вижу, что индекс нудности статьи приближается к критическому, поэтому буду закругляться. С целью понижения все того же показателя я намеренно избегал аспектов безопасности и, например, ответа на вопрос ”А как вообще возможна аутентификация в архитектуре REST, если читателю на протяжении всей этой статьи внушалось, что RESTful сервис должен быть stateless?”.

А выводы статьи будут следующими:

1. Филдинг со своими принципами REST ничего не изобрел, а просто собрал в одну диссертацию то, что уже существовало в каком-то виде и изложил то, как можно получать максимальную выгоду из уже сформировавшейся архитектуры сети.
2. SOAP и REST – не конкуренты. Они представляют разные весовые категории и вряд ли найдется задача, для которой будет сложно сказать, какой подход рациональнее использовать – SOAP или REST. Поэтому «религиозные» убеждения в вопросах выбора архитектуры для веб-сервиса вряд ли будут полезны. Для тех, кто не знает, с чего начать анализ задачи, могу порекомендовать эту презентацию. У них чаще побеждает REST.

Обработка ошибок в SOAP веб-сервисе на стороне клиента

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<wsdl:definitions xmlns:xsd=»http://www.w3.org/2001/XMLSchema» xmlns:wsdl=»http://schemas.xmlsoap.org/wsdl/» xmlns:tns=»http://soap.ws.javastudy.ru/» xmlns:soap=»http://schemas.xmlsoap.org/wsdl/soap/» xmlns:ns1=»http://schemas.xmlsoap.org/soap/http» name=»HelloSoap» targetNamespace=»http://soap.ws.javastudy.ru/»>

<wsdl:types>

<xs:schema xmlns:xs=»http://www.w3.org/2001/XMLSchema» xmlns:tns=»http://soap.ws.javastudy.ru/» attributeFormDefault=»unqualified» elementFormDefault=»unqualified» targetNamespace=»http://soap.ws.javastudy.ru/»>

<xs:element name=»exceptionTest» type=»tns:exceptionTest»/>

<xs:element name=»exceptionTestResponse» type=»tns:exceptionTestResponse»/>

<xs:element name=»getGoods» type=»tns:getGoods»/>

<xs:element name=»getGoodsResponse» type=»tns:getGoodsResponse»/>

<xs:element name=»goods» type=»tns:goods»/>

<xs:element name=»sayHelloTo» type=»tns:sayHelloTo»/>

<xs:element name=»sayHelloToResponse» type=»tns:sayHelloToResponse»/>

<xs:element name=»testService» type=»tns:testService»/>

<xs:element name=»testServiceResponse» type=»tns:testServiceResponse»/>

<xs:complexType name=»testService»>

<xs:sequence/>

</xs:complexType>

<xs:complexType name=»testServiceResponse»>

<xs:sequence>

<xs:element minOccurs=»0″ name=»return» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

<xs:complexType name=»getGoods»>

<xs:sequence/>

</xs:complexType>

<xs:complexType name=»getGoodsResponse»>

<xs:sequence>

<xs:element minOccurs=»0″ name=»return» type=»tns:goods»/>

</xs:sequence>

</xs:complexType>

<xs:complexType name=»goods»>

<xs:sequence>

<xs:element name=»id» type=»xs:int»/>

<xs:element minOccurs=»0″ name=»name» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

<xs:complexType name=»sayHelloTo»>

<xs:sequence>

<xs:element minOccurs=»0″ name=»text» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

<xs:complexType name=»sayHelloToResponse»>

<xs:sequence>

<xs:element minOccurs=»0″ name=»return» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

<xs:complexType name=»exceptionTest»>

<xs:sequence>

<xs:element minOccurs=»0″ name=»text» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

<xs:complexType name=»exceptionTestResponse»>

<xs:sequence/>

</xs:complexType>

<xs:complexType name=»exceptionTrace»>

<xs:sequence>

<xs:element minOccurs=»0″ name=»trace» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

<xs:element name=»MyWebserviceException» type=»tns:MyWebserviceException»/>

<xs:complexType name=»MyWebserviceException»>

<xs:sequence>

<xs:element minOccurs=»0″ name=»exceptionTrace» type=»tns:exceptionTrace»/>

<xs:element minOccurs=»0″ name=»message» type=»xs:string»/>

</xs:sequence>

</xs:complexType>

</xs:schema>

</wsdl:types>

<wsdl:message name=»testService»>

<wsdl:part element=»tns:testService» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:message name=»exceptionTestResponse»>

<wsdl:part element=»tns:exceptionTestResponse» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:message name=»getGoods»>

<wsdl:part element=»tns:getGoods» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:message name=»testServiceResponse»>

<wsdl:part element=»tns:testServiceResponse» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:message name=»sayHelloTo»>

<wsdl:part element=»tns:sayHelloTo» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:message name=»exceptionTest»>

<wsdl:part element=»tns:exceptionTest» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:message name=»getGoodsResponse»>

<wsdl:part element=»tns:getGoodsResponse» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:message name=»MyWebserviceException»>

<wsdl:part element=»tns:MyWebserviceException» name=»MyWebserviceException»></wsdl:part>

</wsdl:message>

<wsdl:message name=»sayHelloToResponse»>

<wsdl:part element=»tns:sayHelloToResponse» name=»parameters»></wsdl:part>

</wsdl:message>

<wsdl:portType name=»WebserviceSEI»>

<wsdl:operation name=»testService»>

<wsdl:input message=»tns:testService» name=»testService»></wsdl:input>

<wsdl:output message=»tns:testServiceResponse» name=»testServiceResponse»></wsdl:output>

</wsdl:operation>

<wsdl:operation name=»getGoods»>

<wsdl:input message=»tns:getGoods» name=»getGoods»></wsdl:input>

<wsdl:output message=»tns:getGoodsResponse» name=»getGoodsResponse»></wsdl:output>

</wsdl:operation>

<wsdl:operation name=»sayHelloTo»>

<wsdl:input message=»tns:sayHelloTo» name=»sayHelloTo»></wsdl:input>

<wsdl:output message=»tns:sayHelloToResponse» name=»sayHelloToResponse»></wsdl:output>

</wsdl:operation>

<wsdl:operation name=»exceptionTest»>

<wsdl:input message=»tns:exceptionTest» name=»exceptionTest»></wsdl:input>

<wsdl:output message=»tns:exceptionTestResponse» name=»exceptionTestResponse»></wsdl:output>

<wsdl:fault message=»tns:MyWebserviceException» name=»MyWebserviceException»></wsdl:fault>

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name=»HelloSoapSoapBinding» type=»tns:WebserviceSEI»>

<soap:binding transport=»http://schemas.xmlsoap.org/soap/http»/>

<wsdl:operation name=»testService»>

<soap:operation soapAction=»»/>

<wsdl:input name=»testService»>

<soap:body use=»literal»/>

</wsdl:input>

<wsdl:output name=»testServiceResponse»>

<soap:body use=»literal»/>

</wsdl:output>

</wsdl:operation>

<wsdl:operation name=»getGoods»>

<soap:operation soapAction=»»/>

<wsdl:input name=»getGoods»>

<soap:body use=»literal»/>

</wsdl:input>

<wsdl:output name=»getGoodsResponse»>

<soap:body use=»literal»/>

</wsdl:output>

</wsdl:operation>

<wsdl:operation name=»sayHelloTo»>

<soap:operation soapAction=»»/>

<wsdl:input name=»sayHelloTo»>

<soap:body use=»literal»/>

</wsdl:input>

<wsdl:output name=»sayHelloToResponse»>

<soap:body use=»literal»/>

</wsdl:output>

</wsdl:operation>

<wsdl:operation name=»exceptionTest»>

<soap:operation soapAction=»»/>

<wsdl:input name=»exceptionTest»>

<soap:body use=»literal»/>

</wsdl:input>

<wsdl:output name=»exceptionTestResponse»>

<soap:body use=»literal»/>

</wsdl:output>

<wsdl:fault name=»MyWebserviceException»>

<soap:fault name=»MyWebserviceException» use=»literal»/>

</wsdl:fault>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name=»HelloSoap»>

<wsdl:port binding=»tns:HelloSoapSoapBinding» name=»HelloSoapPort»>

<soap:address location=»http://localhost:8080/soap/webserviceSEI»/>

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

SOAPClient.com, ресурсы и услуги для SOAP

.

Общий клиент SOAP

Советы для пользователей:

• Если вы знаете файл WSDL, вы
  можно настроить быструю ссылку на клиентские формы, используя
  http://www.soapclient.com/soapclient?template=/clientform.html&fn=soapform
  & SoapTemplate = none & SoapWSDL = Your_WSDL_File
  или
  http: // www.soapclient.com/soapTest.html?SoapWSDL=Your_WSDL_File
  

• Сервер кэширует файлы WSDL в
  нормальные операции для повышения производительности. Если вы сделаете что-нибудь
  изменения в файл WSDL, выберите №
  флажок.

Советы разработчикам:

• Используйте < документацию >
  по возможности в файле WSDL для предоставления инструкций.Он будет отображаться в форме клиента.

• Используйте тип перечисления, если
  элемент имеет фиксированное количество значений. Они будут отображаться как
  выпадающие списки.

Основные характеристики:

• Поддерживает XML-схему 1999 и 2001 годов. В
  инструмент использует схему, определенную в файле WSDL, для создания SOAP
  Запросы.

• Поддержка массива и массива структур. Только
  поддерживаются одномерные массивы. Извините, не редкость
  массивы.

• Возможность сериализации сложных типов данных и
  массив сложных типов данных, даже многоуровневые встроенные структуры.

• Обработка ID / HREF как в сообщениях SOAP, так и в
  определения схемы.

• Поддерживает как раздел SOAP 5/7, так и
  документ / буквальные кодировки ..

Технические характеристики — Динамический
Привязка служб SOAP

Обвязка — это договор между клиентом
логика и логика сервера. Есть два типа привязок в
SOAP: привязка объекта (или привязка SOAP) и привязка параметров.Большинство наборов инструментов SOAP выполняет привязку статических объектов с помощью
создание прокси-объектов на стороне клиента. Проблема в том, что,
в отличие от традиционного модуля программирования, где объекты / интерфейсы
стабильны, веб-сервисы могут быть изменены в любой момент
без предварительного уведомления, потому что они часто принадлежат / контролируются
третье лицо. Другая проблема возникает, когда количество веб-
количество доступных сервисов увеличивается, сгенерированный исходный код
может быстро превратиться в кошмар обслуживания.Наконец, когда
веб-сервисы, к которым будет осуществляться доступ, неизвестны, что чаще всего
тогда скорее всего раннее связывание станет невозможным, или, по крайней мере,
сложно. Создание прокси-объекта для создания сервиса
в будущем интересный исследовательский проект.

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

Инструмент, написанный менее чем на 20 строках
код с SOAP
Клиентская библиотека — живой пример того, как
создавать общие приложения SOAP с использованием позднего связывания
техника.

Прочие инструменты:

.

новых вопросов о мыльных клиентах — Stack overflow на русском

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

.

PHP: SoapClient :: SoapClient — Руководство

Ein Array aus Optionen. Венн им WSDL-Modus gearbeitet wird, ist dieser
Параметр необязательный. Im non-WSDL-Modus müssen die Optionen
адрес и uri gesetzt sein.
Dabei enthält location den URL des SOAP-Servers, an den die Anfrage gesendet werden soll, und
uri den Zielnamensraum des SOAP-Dienstes.

Опция матрицы , стиль и , используйте
работает без WSDL-Modus.Im WSDL-Modus werden sie durch das
WSDL-файл bestimmt.

Опция матрицы soap_version sollte entweder
SOAP_1_1 или SOAP_1_2 sein, um
SOAP 1.1 bzw. 1.2 zu wählen. Wird sie ausgelassen, wird 1.1 verwendet.

Die Optionen логин и пароль
können verwendet werden, um Daten für die HTTP-Authentifizierung zu
übergeben.Прокси-сервер Um eine Verbindung über einen
herzustellen, stehen die Optionen proxy_host ,
proxy_port , proxy_login
und proxy_password zur Verfügung.
Für Authentifizierung über HTTPS-Client-Zertifikate nutzen Sie die
Optionen local_cert и парольная фраза .
Eine Authentifizierung kann in der
аутентификация -Option mit Werten befüllt werden. Умереть
Authentifizierungsmethode kann dabei entweder
SOAP_AUTHENTICATION_BASIC (Standardvorgabe) или
SOAP_AUTHENTICATION_DIGEST sein.

HTTP-SOAP-Anfragen und -Antworten können mit Hilfe von
компрессия komprimiert werden.

Опция матрицы , кодирование , определено die intern verwendete
Zeichenkodierung. Sie ändert nicht die Kodierung der SOAP-Anfrage selbst
(die bleibt immer utf-8), es werden lediglich die Zeichenketten
конвертьерт.

Die trace -Option schaltet das Tracing von Anfragen
ein.Damit können Fehler zurückverfolgt werden. Der Standardwert ist
ЛОЖЬ .

Die classmap -Option kann verwendet werden, um
WSDL-Typen auf PHP-Klassen abzubilden. Die Option muss ein Array mit den
WSDL-Typen als Schlüssel und den PHP-Klassennamen als Wert sein.

Das Setzen der trace -Option aktiviert den Gebrauch
der Methoden SoapClient -> __ getLastRequest, SoapClient -> __ getLastRequestHeaders, SoapClient -> __ getLastResponse и SoapClient -> __ getLastResponseHeaders.

Die Option исключения ist ein boolscher Wert. Sie
Определенный, полученный из SOAP-Fehlern Exceptions vom Typ SoapFault geworfen werden sollen.

Zeitüberschreitung in Sekunden für Verbindungen zu einem SOAP-Service
können mit der Option connection_timeout angegeben
Верден. Diese Option Definiert keine Zeitüberschreitung für Dienste mit
langsamen Antwortzeiten. Um zu Definieren, wie lange auf die Beendung
einer Anfrage gewartet werden soll, steht die Einstellung default_socket_timeout
zur Verfügung.

Die Option typemap ist ein Array mit Typabbildungen.
Jede Abbildung ist ein Array mit den Schlüsseln
имя_типа , тип_ns (URI пространства имен),
from_xml (Строковый параметр обратного вызова akzeptiert einen)
und to_xml (обратный вызов akzeptiert einen Objekt-Parameter).

Die Option cache_wsdl ist eine der folgenden Konstanten:
WSDL_CACHE_NONE ,
WSDL_CACHE_DISK ,
WSDL_CACHE_MEMORY или заказать
WSDL_CACHE_BOTH .

Die Option user_agent gibt die Zeichenkette an, die
im User-Agent -Header verwendet werden soll.

Die Option stream_context ist eine
Ресурс в контексте.

Параметр features — это битовая маска
SOAP_SINGLE_ELEMENT_ARRAYS ,
SOAP_USE_XSI_ARRAY_TYPE ,
SOAP_WAIT_ONE_WAY_CALLS .

Die keep_alive Option ist ein boolescher Wert, der
Definiert, ob der Подключение: Keep-Alive или
Подключение: закрыть Заголовок gesendet werden soll.

Die ssl_method Опция ist entweder
SOAP_SSL_METHOD_TLS ,
SOAP_SSL_METHOD_SSLv2 ,
SOAP_SSL_METHOD_SSLv3 или заказать
SOAP_SSL_METHOD_SSLv23 .

.

No related posts.