Веб сервисы wsdl. Описание Web Services на языке WSDL. Создаем интерфейс и класс сервиса

Предисловие

Заказчики заказчиков попросили заказчиков xsd файлы для структур, передаваемых реализуемыми Web-сервисами. Заказчики в ответ предложили заказчикам заказчиков сделать WSDL-ки. Т.о. неожиданно «на ровном месте» возникла необходимость сделать не просто xsd-схемы для валидации данных, а «целые WSDL-ки». Обычно WSDL-ки используются для SOAP, а у нас REST…

Ранее я уже писал про

Введение

Термин Web-сервисы обычно ассоциируется с operation- или action-based сервисами, базирующимися на SOAP или WS* стандартах, таких как WS-Addressing или WS-Security. Термин REST Web-сервисы обычно относится к resource-based архитектуре Web-сервисов, передающих XML через HTTP. Каждый из этих архитектурных стилей имеет собственное место, но до недавнего времени, WSDL стандарт не поддерживал оба эти стиля. WSDL 1.1 HTTP binding был неадекватен для описания взаимодействия с помощью XML по HTTP, т.о. не было формального способа описать REST Web-сервисы с помощью WSDL. Публикация стандарта WSDL 2.0 (который был разработан с учётом необходимости описания REST Web-сервисов) в статусе рекомендации World Wide Web Consortium (W3C) дала язык для описания REST Web-сервисов.

REST — архитектурный стиль трактующий Web как resource-centric приложение. Практически, это означает, что каждый URL в RESTful приложении представляет собой ресурс. URL-и просто понимать и запоминать. Например, книжный магазин может определить URL http://www.bookstore.com/books/ для списка продаваемых книг и http://www.bookstore.com/books/0321396855/ для деталей о конкретной книге с ISBN 0321396855. Это контрастирует с action-centric приложениями, обычно имеющими длинные сложношифованные URL-и, описывающими действия, которые необходимо выполнить, например http://www.bookstore.com/action/query?t=b&id=11117645532&qp=0321396855 . Параметры запроса используются для выбора необходимых данных. Используя пример книжного магазина, указание параметра subject ограничивает тематику книги. Например физика или детективы или к примеру URL http://www.bookstore.com/books/?subject=computers/eclipse — запрос возвращающий список книг про платформу Eclipse.

Термин REST придумал Roy Fielding в своей кандидатской диссертации. Он рассматривал гиперссылки как средство для изменения (хранения) состояния приложения. Гиперлинки хранятся в ресурсах приложения и являются методом изменения состояния приложения, редиректа из одного состояния в другое. Обычно гиперлинки в (X)HTML предназначены для использования людьми, они не использовались в XML, который был предназначен для машинной обработки. Также как и (X)HTML, REST Web-сервисы испльзуют гиперлинки в XML.

Традиционные Web-приложения получают доступ к ресурсам посредством HTTP GET или POST операций. RESTfull приложения работают с ресурсами в стиле «create, read, update, and delete (CRUD)» используя полные возможности HTTP протокола (POST, GET, PUT, and DELETE).

Ещё одно важное замечание о REST приложении: RESTful приложения должны быть stateless. Это означает, что REST приложение не сохраняет никакого состояния сессии на стороне сервера. Вся информация, необходимая для выполнения запроса, передается в самом запросе. (Поэтому на повторяющиеся запросы сервер обязан отвечать одинаково прим. переводчика). Соответственно клиент может кешировать полученные ресурсы, что может значительно ускорить скорость работы приложения там, где сервис явно разрешает это. Чтобы узнать больше про REST, см ссылки к статье.

WSDL и REST

WSDL содержит все детали о веб-сервисе, включая:

URL веб-сервиса
Механизмы коммуникации, корые понимает веб-сервис
Операции, которые может выполнять веб-сервис
Структура сообщений веб-сервиса

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

WSDL 2.0 был объявлен рекомендацией W3C в июне 2007. Эта версия WSDL стандарта была выпущена для решения проблем стандарта WSDL 1.1, многие из которых были обнаружены организацией Web Services Interoperability (WS-I). Кроме того в WSDL 2.0 улучшена поддержка HTTP bindings.

WSDL сам является XML — подмножеством формально описывающим веб-сервис. Рассматривайте WSDL описание веб-сервиса как его API контракт с клиентом. В WSDL указывается адрес, допустимые способы передачи информации, интерфейса и типы сообщений веб-сервиса. Короче говоря, описание WSDL содержит всю информацию, необходимую клиенту для использования веб-сервиса.

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

• Генерирование исходного кода клиентского приложения и сервера для веб-сервиса на разных языках программирования
• Публикация веб-сервиса
• Динамическое тестирование веб-сервиса

Большинство программных средств для работы с веб-сервисами включают в себя поддержку WSDL 1.1. Последнее время растёт количество средств разработки веб-сервисов, поддерживающих WSDL 2.0. Проект Apache Web services состоит из двух подпроектов, которые в настоящее время поддерживают WSDL 2.0. Woden — парсер-валидатор WSDL 2.0 на базе Java. Apache Web services проект также предоставляет XSL (XSLT) трансформацию WSDL 2.0 под названием WSDL 2.0 pretty printer , обеспечивающую лучшую человекочитаемость документа WSDL. Axis2 популярный engine веб-сервисов, (тоже от Apache) реализующий генерацию клиентского и серверного Java кода из документа WSDL 2.0.

Описание REST веб-сервиса с помощью WSDL 2.0

Вы создаете книжный магазин, который с продвинутым URL: http://www.bookstore.com . Вы уже создали две службы REST Web:

• book list — сервис получает список продаваемых у вас книг.
• book details — сервис получает информацию о конкретной книги.

Ответ возвращается в XML-документах.

Элемент interface определяет список операций веб-сервиса, включая описание входных, выходных сообщений и сообщений об ошибках для операций, а также порядка передачи.

Элемент binding определяет, средства коммуникации клиента с веб-сервисом. В случае REST веб-сервисов, в качестве средства коммуникации указывается HTTP.

Элемент service ассоциирует адреса веб-сервиса с конкретными интерфейсами (interface) и средствами коммуникации (binding). (Т.е. задает соответствие URL операции веб-сервиса и элементу binding ).

Привязываем book list к HTTP

Элемент binding задает привязку веб-сервиса к конкретному протоколу передачи данных. Для привязки book list сервиса к HTTP нужно указать значение http://www.w3.org/ns/wsdl/http для атрибута type элемента binding .

Элемент binding может опционально ссылаться на interface . Оставьте атрибут interface пустым. Вы создадите его в следующем разделе. Если interface ассоциирован с binding , тогда binding элемент может опционально определять дочерний элемент operation , являющийся зеркальным для interface operation элемента. Вам нужно создать заглушку элемента operation и заполнить ссылку на operation позже после создания interface .

Существует 4 HTTP communication метода

• DELETE

Book list сервис читает запрос и соответственно оперирует с помощью HTTP GET. Установите метод GET для элемента operatioin используя атрибут method из WSDL 2.0 HTTP namespace. Для использования этого атрибута, вам нужно сначала определить namespace http://www.w3.org/ns/wsdl/http в элементе description .

Book list сервис binding определен на нижеследующем листинге. Укажите теперь binding в элементе endpoint : tns:BookListHTTPBinding.

The bookstore"s book list service.

Определение book list service operation

So far you’ve learned how to address and communicate with the book list Web service. Next you specify the book list service operation, which describes what the book list service does.

Итак, вы научились задавать address и задавать binding (способ коммуникации) для веб-сервиса. Далее необходимо задать service operation, определяющую что делает book list веб-сервис.

Элемент interface и его дочерний operation элемент используются для определения сервисных операций. В случае с book list, вы определяете одну операцию getBookList, возвращающую список книг.

Затем определите три атрибута для элемента operation:

Pattern

Используется для указания шаблона обмена сообщениями message exchange pattern (MEP) для операции. MEP определяет последовательность сообщений для операции и их направление. В этом случае необходимо указать значение http://www.w3.org/ns/wsdl/in-out чтобы указать, что веб-сервис получает одно входное сообщение просьбой о списке книг, и посылает одно выходное сообщение со списком книг. Для поддержки этого MEP, указажите дочерние элементы input и output для элемента operation . Эти элементы используют элементы описанные в XML schema, определяющие структуры сообщений. Подробности в следующем разделе.

Style

Используется для указания дополнительной информации о работе. Укажите значение http://www.w3.org/ns/wsdl/style/iri , накладывающее ограничения на содержание входных элементов, такие как требование, что это только использовать XML schema элементы.

wsdlx:safe

wsdlx:safe: From the WSDL extensions namespace, this attribute declares that this operation is idempotent. This type of operation doesn’t modify the resource and can therefore be called many times with the same results. To make use of this element, declare the WSDL extensions namespace http://www.w3.org/ns/wsdl-extensions on the description element.

Этот атрибут из WSDL extentions namespace. Он определяет, что операция является idempotent . Эта операция не модифицирует ресурс, поэтому может быть вызвана многократно с одинаковыми результатами. Чтобы использовать этот элемент, нужно объявить namespace WSDL extentions http://www.w3.org/ns/wsdl-extensions в корневом элементе (элементе description).

Вы можете найти предопределенные Message Exchange Patterns, styles и wsdlx:safe определения по ссылке WSDL 2.0 Part 2: Adjuncts

Ниже приведено определение book list сервиса с добавленным описанием interface . После добавления interface теперь можно изменить binding operation элемент чтобы указать ссылки на описанные interface и operation.

The RESTful HTTP binding for the book list service. The bookstore"s book list service.

Определение сообщений сервиса book list operation

Веб-сервис book list использует два сообщения: входное и выходное. Вы должны описать структуры этих сообщений, чтобы клиентские программы знали что отправлять в адрес сервиса и что ожидать обратно.

WSDL 2.0 supports multiple type systems for describing the message content, but XML schema is the only one in use. This section doesn’t cover the details of XML schema. XML schema is used in many other applications, like WSDL 1.1, and there are many good articles about it. This section highlights how to use XML schema for the book list REST Web service and how to use additional attributes defined by WSDL 2.0 to annotate a schema attribute.

WSDL 2.0 поддерживает множество систем определения типов, но на практике используются только XML schema. Эта статья не вдается в детали XML schema. XML schema используется во многих других приложениях, например, WSDL 1.1, и есть много хороших статей о нем. (). В этом разделе демонстрируется, применение XML schema применительно к конкретному примеру REST сервиса book list, а также использование дополнительных атрибутов определенных в WSDL 2.0 для аннотации schema атрибута.

Чтобы описать 2 сообщения для book list, необходимо описать 2 глобальных элемента.

• getBookList представляет собой входное сообщение. Он содержит последовательность элементов, включая каждый параметр запроса, позволенный для сервиса: uthor, title, publisher, subject и language . Внутри getBookList сообщения могут использоваться только элементы, потому что выбран IRI style для interface operation.
• bookList представляет собой выходное сообщение. Он содержит последовательность book элементов. Каждый book элемент в свою очередь содержит title и url атрибуты. Атрибут title не требует пояснений. Атрибут url это линк на сервис book details, возвращающий детальную информацию о конкретной книге.

Ваше определение атрибута url использует в свою очередь 2 атрибута из WSDL extensions namespace. Атрибуты wsdlx:interface и wsdlx:binding задают interface и binding для сервиса. Программное обеспечение может использовать эту информацию для автоматического нахождения сервиса. Для использования этих атрибутов, укажите WSDL extentions namespace для элемента schema . Также включите book details namespace из его WSDL 2.0 описания.

XML schema для book list сервиса приведена ниже.

The request element for the book list service. The response element for the book list service.

Для ссылки на input и output элементы, вы должны импортировать схему в ваш WSDL документ. Для импортирования сземы, используйте schema import элемент в разделе types как показано на листинге ниже. Кроме того, необходимо добавить ссылки на getBookList и Booklist элементы в interface operation input и output элементах и добавить пространства имен book list XML schema в корневой элемент WSDL.

Готовый WSDL для book list веб-сервиса.

This is a WSDL 2.0 description of a sample bookstore service listing for obtaining book information. This operation returns a list of books. The RESTful HTTP binding for the book list service. The bookstore"s book list service.

Примечание переводчика

Я позволил себе не переводить summary и ссылки. И то и другое смотреть у автора. в оригинальной статье . Надо сказать язык оригинала весьма тяжёл. Однако, надеюсь, статья окажется полезной.

XSD: определение схемы XML.

XML: расширяемый язык разметки.

WSDL: язык определения веб-сервисов.

Я не собираюсь отвечать технически. Я направляю это объяснение на новичков.

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

XSD - это определение схемы. Под этим я имею в виду, что он говорит пользователям разрабатывать свой XML в такой схеме. Пожалуйста, смотрите ниже изображения и внимательно следите за ним с помощью элемента "load-on-startup" и его типа, который является целым числом. В изображении XSD вы можете видеть, что оно предназначено для целочисленного значения для "load-on-startup" и, следовательно, когда пользователь создал свой XML-код, он передал значение int этому конкретному элементу. Напомним, что XSD - это схема и стиль, тогда как XML - это форма для связи с другим приложением или системой. Нужно видеть XSD и создавать XML таким образом, иначе он не будет связываться с другим приложением или системой, которая была разработана с использованием другой технологии. Компания в Чикаго предоставляет шаблон XSD для компании в Техасе, чтобы писать или генерировать свой XML в данном формате XSD. Если компания в Техасе не смогла придерживаться тех правил или схем, упомянутых в XSD, тогда невозможно ожидать правильной информации от компании в Чикаго. После вышеупомянутой истории есть так много всего, что любитель или новичок должен знать, кодируя некоторые вещи, как я сказал выше. Если вы действительно хотите узнать, что будет дальше, тогда лучше посидеть с старшими инженерами программного обеспечения, которые фактически разработали веб-службы. Далее идет WSDL, пожалуйста, следуйте изображениям и попытайтесь выяснить, куда будет вписываться WSDL.

*************** ======== Ниже представлено частичное изображение XML ========== ********* ******

*************** ======== Ниже представлено частичное изображение XSD ========== ********* ******

*************** ======== Ниже представлено частичное изображение WSDL ======= *********** **

Мне пришлось создать образец WSDL для веб-службы под названием "Книга". Обратите внимание, что это XSD, но вы должны назвать его WSDL (язык определения веб-сервисов), потому что он очень специфичен для веб-служб. Ниже WSDL (или, другими словами, XSD) создается для класса Book.java, и он создал службу SOAP. Как создала веб-служба SOAP, это другая тема. Нужно написать класс Java, и перед выполнением его создания в качестве веб-службы пользователь должен убедиться, что Axis2 API установлен, и Tomcat для размещения веб-службы на месте.

В качестве сервис-провайдера (тот, кто позволяет другим (клиентам) получать доступ к информации или данным из своих систем) фактически дает клиенту (тем, кто должен использовать информацию или данные сервис-провайдера) полный доступ к данным через веб-службу, ни одна компания на земле не готова предоставить свою базу данных для посторонних. Как и моя компания, я решил предоставить некоторую информацию о продуктах через веб-службы, поэтому нам пришлось создать шаблон XSD и передать некоторые из наших клиентов, которые хотят работать с нами. Они должны написать код для полного использования данного XSD и сделать вызовы Web Service для извлечения данных из servicer и преобразования данных, возвращенных в их подходящее требование, а затем отображать или публиковать данные или информацию о продукте на своем веб-сайте. Простым примером может служить бронирование авиабилетов FLIGHT. Авиакомпания позволит третьим сторонам использовать данные рейса на своем сайте для продажи билетов. Но опять-таки есть намного больше, просто не позволяя стороннему агентству по авиабилетам продавать билеты, там будут синхронизация и безопасность на месте. Если нет синхронизации, то вероятность 100% более одного клиента может купить тот же авиабилет из разных источников.

Я надеюсь, что эксперты будут способствовать моему ответу. Для новичков или новичков очень сложно понять XML, XSD, а затем работать с веб-службами.

В главе 2 мы говорили о том, что после создания Web-службы на сервере в виде сервлета, страницы JSP, JWS-файла, компонента EJB или другого объекта, следует описать состав и возможности Web-службы на языке, не зависящем от платформы, операционной системы, системы программирования, использованной при создании Web-службы. Это описание регистрируется в общедоступном месте Интернета, например, реестре UDDI или ebXML, или хранится на сервере Web-службы. Описание должно содержать полную и точную информацию обо всех услугах, предоставляемых Web-службой, способы получения услуг, содержимое запроса на получение услуги, формат предоставляемой информации.

Одно из средств точного и единообразного описания Web-услуг - язык WSDL, созданный консорциумом W3C. Этот язык - еще одна реализация XML. Его последняя рекомендованная спецификация всегда публикуется на странице http://www.w3.org/TR/wsdI . Во время написания книги на черновой стадии была версия WSDL 1.2, которую мы и опишем в этой главе.

Состав документа WSDL

Корневым элементом документа XML - описания WSDL - служит элемент . В этом элементе необязательным атрибутом name можно дать имя описанию. Кроме того, это удобное место для введения используемых в описании пространств имен.

Описания WSDL активно используют различные пространства имен. Кроме собственных имен, язык WSDL часто использует имена типов и элементов языка описания схем XSD (см. главу 1) и имена языка протокола SOAP. Пространство имен языка WSDL часто описывается как пространство имен по умолчанию. Идентификатор пространства имен последней на время написания этих строк версии WSDL 1.2 был равен http://www.w3.org/2002/07/wsdl . Целевое пространство имен, идентификатор которого определяется атрибутом обычно получает префикс tns (target namespace).

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

? - определяет сложные типы, используемые Web-службой, с помощью языка XSD или другого языка описания типов. Этот элемент не нужен, если Web-служба применяет только простые типы, описанные в языке XSD.

? - описывает каждое SOAP-послание: запрос, ответ, пересылку документов. В этот элемент вкладываются элементы Описывающие неделимые с точки зрения WSDL части послания. Для посланий процедурного типа каждый элемент Может описывать имя и тип одного аргумента запроса или тип возвращаемого значения. Для посланий документного типа элементы Могут описывать каждую часть послания "multipart/related". Это абстрактное описание затем конкретизируется элементами .

? Описывает интерфейс Web-службы, называемый в языке WSDL пунктом назначения (endpoint) или портом (port) прибытия послания. Он описывается как набор Web-услуг, называемых в языке WSDL операциями. Переводя это описание на язык программирования можно заметить, что порт хорошо соотносится с интерфейсом Java, а каждая операция - с методом этого интерфейса. Операции описываются вложенными элементами , описывающими каждую отдельную услугу. Услуга описывается действиями, которые разбиты на четыре вида. Это два простых действия: "получение послания", "отправка ответа", и два комбинированных действия: "отправка послания - получение ответа" или, наоборот, "получение послания - отправка ответа". Получение и отправка, в свою очередь, описываются вложенными элементами и

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

И ссылаются на НИХ СВОИМ атрибутом message.

? - перечисляет вложенными элементами Набор портов, связанных с одной Web-службой. Один и тот же порт может быть связан с несколькими службами.

? - описывает конкретный формат пересылки послания: протоколы, такие как SOAP или HTTP, способы упаковки послания, тип его содержимого: HTML, XML или другой MIME-тип послания. Каждый элемент может быть связан с несколькими такими элементами, по одному для каждого способа пересылки. В этот элемент вкладываются элементы, определенные в схеме выбранного протокола.

? < service > - указывает местоположение Web-службы как один или несколько портов. Каждый порт описывается вложенным элементом Содержащим адрес интерфейса Web-службы, заданный по правилам выбранного в элементе способа пересылки.

Кроме этих шести основных элементов есть еще два вспомогательных элемента.

? - включает файл с XSD-схемой описания WSDL или другой WSDL-файл.

Комментарий. Его можно включить в любой элемент

описания WSDL.

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

Элементы объясняют, КАК реализована Web-служба, каков протокол передачи посланий: HTTP, SMTP или какой-то другой, а также задает технические характеристики передачи данных.

Наконец, элементы показывают, ГДЕ находится Web-служба, связывая описание с конкретными адресами Web-службы.

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

Символ [?] означает, что элемент или атрибут может появиться в документе нуль или один раз;

Символ [*] означает, что элемент может появиться нуль или несколько раз;

Символ [+] означает, что элемент может появиться один или несколько раз;

Отсутствие символа в квадратных скобках означает, что атрибут должен появиться ровно один раз.

j Листинг 4.1. Схема WSDL-документа

targetNamespace="nfleH l ra«iij

location="URI-aflpec" /> [*]

Произвольный комментарий

Описания сложных и нестандартных типов.

[*]

[*]

[? ]

Абстрактное описание SOAP-послания как набора составляющих его частей.

[*]

Абстрактное описание Web-службы как набора операций (услуг).

[*]

Описание услуги как получения (input) и отправки (output, fault) посланий.

[?]

Получаемое послание.

[?] [?]

Отправляемое

message="nMH соотв. элемента "> [*] [?]

Отправляемое сообщение об ошибке.

[*]

[+]

type="MMH соотв. элемента "> [*]

[?]

Детали конкретного протокола. Они определяются в схеме

этого протокола. ->

[*]

[?]

Сюда записываются элементы, описывающие детали

конкретной операции. ->

[?]

Сюда записываются элементы, описывающие

детали конкретного получаемого послания. ->

[?]

[?]

Сюда записываются элементы, описывающие

детали конкретного отправляемого послания. ->

[*]

[?]

Сюда записываются элементы, описывающие

детали конкретного сообщения об ошибке. ->

serviceType="MMH соотв. элемента "> [*]

Описание интерфейса Web-службы как набора портов.

binding="nMH соотв. элемента "> [*]

[?]

Сюда записывается обязательный и единственный адрес интерфейса Web-службы, записанный по правилам

протокола, указанного в элементе . ->

Каждый конкретный протокол пересылки посланий - SOAP, HTTP, FTP, SMTP - добавляет к шести основным и двум вспомогательным элементам языка WSDL свои дополнительные элементы, описывающие особенности данного протокола.

Приведем простой пример. В листинге 3.14 мы записали в виде класса Java простейшую Web-службу, возвращающую без всякой обработки присланный запрос:

public class EchoService{

public String getEcho (String req) { return req;

В листинге 4.2 приведено описание этой Web-службы на языке WSDL, использующее протокол SOAP.

Листинг 4.2. Описание Web-службы EchoService

version="1.0" encoding="UTF-8" ?>

name="EchoServService">

Binding="tns:EchoServiceSoapBinding" name="EchoService"> location=

"http://localhost:8080/axis/EchoService.jws" />

В листинге 4.2 мы в элементе определили префиксы всех нужных нам пространств имен. Далее мы описали запрос и ответ в двух элементах . Мы дали ИМ имена "getEchoRequest" И "getEchoRe- sponse". В запросе один аргумент типа xsd: string. Этот тип определен в языке XSD. Мы дали аргументу имя req, совпадающее с именем аргумента метода getEcho () . Значению, возвращаемому методом, мы дали имя return, его тип тоже xsd: string.

Имена "getEchoRequest" И "getEchoResponse" ИСПОЛЬЗОВаны В следующем элементе Для указания входных и выходных параметров Web- услуги. В него вложен один элемент . Это означает, что Web- служба предоставляет одну услугу, имя которой "getEcho" совпадает с именем метода, выполняющего эту услугу. В элементе указаны входной и выходной

параметры услуги. Затем, элементом мы указали один способ пересылки посланий - SOAP-послания в процедурном стиле, пересылаемые по протоколу HTTP, на что указывает элемент

txarspcrt^=^"ht:tp^://?cheпas^.>пlscap^.c^rc^/?cap^/ht:tp^" />

Если применяется документный стиль SOAP, то в атрибуте style записывается значение "document".

Наконец, в элементе вложенным элементом Связываем элемент с элементом