69049

Web-службы. Общие концепции Web-служб

Лекция

Информатика, кибернетика и программирование

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

Русский

2014-09-29

236.5 KB

1 чел.

 22

Лекция 4-15

Тема 6.2. Web-службы

6.2.1. Общие концепции Web-служб

 6.2.1.1. Технологии распределенных приложений

 6.2.1.2. Архитектура Web-служб

6.2.2. Протокол SOAP

 6.2.2.1. Модель обработки сообщения SOAP

6.2.2.2. Структура сообщения SOAP

 6.2.2.2.1. Конверт SOAP

 6.2.2.2.2. Сообщение об ошибке

  6.2.2.2.2.1. Элемент env:Code

  6.2.2.2.2.2. Элемент env:Reason

  6.2.2.2.2.3. Элементы env:Node и env:Role

  6.2.2.2.2.4. Элемент env:Detail

  6.2.2.2.2.5. Пример сообщения об ошибке

 6.2.2.3. Типы данных SOAP

 6.2.2.3.1. Простые типы данных и ссылки

 6.2.2.3.2. Массивы

 6.2.2.3.3. Структуры

 6.2.2.4. Представление удаленного вызова процедур в SOAP

 6.2.2.4.1. Вызов процедуры

 6.2.2.4.2. Возврат результатов выполнения процедуры

 6.2.2.4.3. Ошибки при вызове процедур

 6.2.2.5. Связывание с протоколами обмена

6.2.2.5.1. Пересылка сообщения по протоколу HTTP

  6.2.2.5.1.1. Использование метода POST

  6.2.2.5.1.2. Использование метода GET

  6.2.2.5.1.3. Прикрепления в запросах и ответах HTTP

 6.2.2.5.2. Пересылка сообщений по протоколу SMTP

 

Тема 6.2. Web-службы

6.2.1. Общие концепции Web-служб

6.2.1.1. Технологии распределенных приложений

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

Однако Web-сервер, в принципе, может предоставлять и другие услуги, в частности,  свои программные средства – процедуры и объекты для выполнения их клиентскими программами (Web-браузерами).

Такие процедуры и объекты для Web-сервера являются распределенными (distributed), а для Web-браузера – удаленными (remote). Программные средства, реализующие удаленный доступ к распределенным процедурам и объектам Web-сервера называются распределенными приложениями.

Распределенные приложения используют «прозрачный» (скрытый от пользователя) доступ к распределенным процедурам и объектам Web-сервера, т.е. для пользователя такое приложения как бы выполняется на его компьютере.

В рассмотренной ранее технологии вызова удаленных методов – RMI (Remote Method Invocation) языка Java для этой цели используются компоненты заглушки (stub) и каркаса (skeleton), перехватывающие вызовы метода клиентом к ссылочной переменной и передающие эти вызовы распределенной службе RMI. Аналогичным образом работают и другие технологии удаленного доступа: технология удалённого вызова процедур – RPC (Remote Procedure Call),  технология .NET фирмы Microsoft и архитектура общего посредника запросов объекта – CORBA  (Common Object Request Broker Architecture).

Однако использование этих технологий обладает одним существенным недостатком: на всех клиентах и серверах должны быть установлены компоненты распределенного приложения именно этой технологии, т.е. компоненты разных технологий не могут взаимодействовать друг с другом. Распределенные приложения реализованные на этих технологиях называются тесно связанными (tightly coupled).

Кроме того, эти технологии накладывают ограничения на компьютерные платформы, используемые в клиентских и серверных компьютерах. Так, использование технологии .NET требует использования операционных систем Microsoft и процессора семейства Intel.

В том случае если компоненты распределенного приложения могут работать на разных платформах и заменять друг друга, приложение является слабо связанным (loosely coupled). Такими приложениями являются, например, Web-приложения и приложения электронной почты, компоненты которых могут быть реализованы с использованием разных технологий и на разных компьютерных платформах. Общими для их компонент фактически является только протокол обмена (HTTP, SMTP, POP3 или IMAP4).

Технология Web Services (Web-службы) – это новая технология создания совместимых программных продуктов для неоднородных распределенных телекоммуникационных систем. Эта технология  предложена и развивается консорциумом W3.

Консорциум W3C определяет Web-службу как программное приложение, идентифицируемое строкой URI, интерфейсы и связывания (binding) которого могут определяться, описываться и отыскиваться документами XML. Web-служба напрямую взаимодействует с другими приложениями по межсетевым протоколам с помощью сообщений, реализованных с использованием приложений языка XML.

6.2.1.2. Архитектура Web-служб

В архитектуре Web-служб определены следующие  составные части:

  •  базовая архитектура Web-служб (Basic Web Services Architecture);
  •  расширенная архитектура Web-служб (Extended Web Services Architecture).

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

Базовая архитектура включает следующие технологии Web-служб:

  •  обмен сообщениями,
  •  обеспечение удаленного вызова процедур,
  •  описание услуг Web-служб,
  •  регистрация (публикация) и поиск (обнаружение) описаний услуг.

Базовая архитектура Web-служб определяет взаимодействие между агентами программного обеспечения как обмена сообщениями между программами-агентами запроса услуг (requesters) и программами-агентами выполнения услуг (providers).  Каждый из агентов может быть одновременно и выполнять запрос и предоставлять услугу. Агенты выполнения услуг обеспечивают реализацию сервиса и публикацию его описания, в то время как агенты запроса услуг должны иметь способ поиска описания услуг.

Базовая архитектура Web-служб содержит следующие компоненты:

  •  провайдера сервиса;
  •  агентства регистрации и поиска сервиса;
  •  клиента, запрашивающего сервис.

Взаимодействие программ-агентов включает следующие операции:

  •  декларации (публикации);
  •  поиска;
  •  связывания (binding).

Эти компоненты и операции для Web-служб обеспечиваются модулями программного обеспечения и их описаниями.

Так, агент выполнения услуг содержит программные модули с сетевым доступом, реализующие сервис, он же формирует описание сервиса и его декларацию (публикацию), доступную агенту запроса услуг или агентству регистрации (service discovery agency).

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

На рис. 6.2.1 приведена схема взаимодействия агента выполнения услуг, регистрационного агентства и агента запроса услуг.

Рис. 6.2.1. Схема взаимодействия агента выполнения услуг,

регистрационного агентства и агента запроса услуг

Web-службы реализуются на основе следующих протоколов:

  •  протоколов обмена данными между узлами (например, HTTP или SMTP);
  •  простого протокола доступа к объектам – SOAP (Simple Object Access Protocol)  для формирования и транспортировки сообщений между узлами;
  •  языка определения Web-служб – WSDL (Web Services Definition Language) описания интерфейса взаимодействия компонент распределенной системы.

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

Консорциум W3C не занимается выработкой рекомендаций (стандартов) взаимодействия, связанных с регистрационными агентствами. Однако в настоящее время существует ряд реализаций  регистрационных служб, основными из которых являются:

  •  универсальная система описания, обнаружения и интеграции – UDDI (Universal Description, Discovery and Integration);
  •  набор спецификаций ebXML.

Система UDDI разработана консорциумом OASIS (Organization for the Advancement of Structured Information Standards – организация развития структурированных информационных стандартов), которая объединяет более 600 организаций – разработчиков и пользователей информационных услуг. Эта система представляет собой средство регистрации компьютерных или коммерческих услуг в формате XML и имеет следующую классификацию:

  •  Желтые Страницы, в которых регистрируются под различными категориями деловые предложения и услуги;
  •  Белые Страницы, которые содержат контактную информацию;
  •  Зеленые Страницы, содержащие в основном технические детали для обращения к сервису.

Система UDDI предоставляет свои услуги также и для Web-служб, и к ней можно обращаться, используя  сообщения, сформированные в соответствии с протоколом SOAP.

Спецификации ebXML, в разработке которых также принимал участие консорциум OASIS, в основном предназначены для электронного бизнеса. В них описаны средства регистрации, поиска и анализа сервисных услуг в форматах профиля протокола сотрудничества – CPP (Collaboration-Protocol Profile) и соглашения протокола сотрудничества CPA (Collaboration-Protocol Agreement) также в формате XML. Но, в отличие от UDDI, где информация строго структурирована и формализована, т.е. содержит только метаданные о сервисе, ebXML допускает включение в регистрацию кроме метаданных и дополнительную информацию произвольной структуры.

Наиболее распространенным средством реализации UDDI и ebXML является разработанный фирмой Sun интерфейс прикладных программ (APIApplication Program Interface) на языке Java для реестров XMLJAXR (Java API for XML Registries).

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

  •  асинхронные сообщения;
  •  передача данных в режиме дополнений (attachment) в сообщениях SOAP;
  •  идентификация и конфиденциальность сообщений.

6.2.2. Протокол SOAP

Предшественником протокола SOAP был протокол XML-RPC (XML-Remote Procedure Call – удаленный вызов процедур на основе XML). Как видно из названия этого протокола, он предназначался только для вызова удаленных процедур, причем сообщения для вызова этих процедур, а также ответы на вызовы представлялись в формате документов XML с заданным в протоколе набором элементов.

Затем на основе протокола XML-RPC в 1998 г. сотрудниками фирмы UserLand и корпорации Microsoft был разработан протокол простой протокол доступа к объектамSOAP, определяющий общую структуру сообщения в формате XML для  обмена в распределенных телекоммуникационных системах (а не только для вызова удаленных процедур).

Позднее разработка протокола SOAP была передана в консорциум W3 и новые спецификации этого протокола были разработаны в W3.

Следующая версия протокола   SOAPSOAP 1.1 была выпущена в мае 2000 г. Последняя в настоящее время версия SOAP 1.2 (Second Edition – вторая редакция) была утверждена в апреле 2007 г.

6.2.2.1. Модель обработки сообщения SOAP

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

Сообщение SOAP генерируется в узле, называемом начальным отправителем сообщения SOAP (initial SOAP sender). Адресатом этого сообщения является конечный получатель сообщения SOAP (ultimate SOAP receiver).

По пути от начального отправителя к конечному получателю сообщение может проходить через несколько посредников SOAP (SOAP intermediaries). Совокупность этих узлов образует путь сообщения SOAP (SOAP message path). Посредники SOAP одновременно являются и получателями SOAP (SOAP receivers) и отправителями SOAP (SOAP senders), поскольку они и получают  сообщения SOAP из сети и отправляют его дальше (после возможной обработки сообщения) другому посреднику или конечному получателю сообщения SOAP.

Пример передачи сообщения SOAP от начального отправителя к конечному получателю приведен на рис. 6.2.2.

Рис. 6.2.2. Пример передачи сообщения SOAP

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

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

  •  роль с именем next и URI 

http://www.w3.org/2003/05/soap-envelope/role/next 

описывает как должен действовать любой посредник и конечный получатель сообщения SOAP;

  •  роль с именем none и URI 

http://www.w3.org/2003/05/soap-envelope/role/none 

описывает как не должен действовать любой узел SOAP;

  •  роль с именем ultimateReceiver и URI

http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver 

описывает как должен действовать конечный получатель сообщения SOAP.

6.2.2.2. Структура сообщения SOAP

6.2.2.2.1. Конверт SOAP

Сообщение SOAP является документом XML. Однако, согласно спецификации, сообщение не должно содержать  объявления типа документа и инструкций по обработке.

Фиксированный набор элементов, описывающих сообщение SOAP, определен в пространстве имен env, а описание схемы XML для сообщения находится по  адресу http://www.w3.org/2002/06/soap-envelope.

Сообщение  SOAP или его фрагменты могут иметь также элементы и атрибуты, определенные (с помощью атрибута xmlns) в других пространствах имен.

Корневым элементом сообщения SOAP является элемент env:Envelope (конверт).

Дочерними элементами env:Envelope являются необязательный элемент env:Header, содержащий заголовок сообщения и обязательный элемент env:Body, в котором задается содержимое сообщения.

Общая структура сообщения SOAP имеет следующий вид:

<?xml version="1.0" ?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

<env:Header>

<!-- Содержимое заголовка -->

</env:Header>

<env:Body>

<!-- Содержимое сообщения -->

</env:Body>

</env:Envelope>

Для сообщения SOAP определен также глобальный необязательный атрибут env:encodingStyle со значением типа xs:anyURI. Этот атрибут задает гиперссылку на набор правил сериализации сообщения SOAP для кодировки содержимого сообщения. Этот набор правил используется для десериализации (декодировки) фрагментов сообщения в узле конечного получателя сообщения. Стандартные правила сериализации сообщения SOAP заданы в

http://www.w3.org/2003/05/soap-encoding,

однако можно использовать и свои правила сериализации.

Атрибут env:encodingStyle можно использовать в следующих элементах:

  •  элементе env:Header и/или в его потомках;
  •  дочерних элементах элемента env:Body и/или в их потомках (за исключением элемента env:Fault);
  •  дочерних элементах элемента env:Detail и/или в их потомках.

Дочерние элементы элемента env:Header называются блоками заголовка SOAP.

Блоки заголовка SOAP, помимо атрибута env:encodingStyle, могут иметь также необязательные атрибуты env:role,  env:mustUnderstand и env:relay.

Атрибут env:role со значением типа xs:anyURI задает роль, выполняемую узлом SOAP, которому предназначен данный блок заголовка. Если этот атрибут не задан, по умолчанию для узла предполагается роль конечного получателя сообщения SOAP.  

Атрибут env:mustUnderstand со значением типа xs:boolean указывает, должна ли выполняться обработка блока заголовка SOAP (значение "true") или нет (значение "false"). Если атрибут не задан, предполагается значение "false".

Атрибут env:relay со значением типа xs:boolean указывает, должно ли выполняться перенаправление блока заголовка в получателе SOAP, если он не обрабатывается (значение "true") или нет (значение "false"). Если атрибут не задан, предполагается значение "false".

Пример заголовка сообщения SOAP:

 <env:Header>

   <gr:group xmlns:gr="http://dep.staff.edu/groups"

   env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

   env:mustUnderstand="true">

<gr:name>ТД-01</gr:name>

     <gr:year>1</gr:year>

<gr:chair>Кафедра ТС</sd:chair>

   </gr:group>

   <em:exam xmlns:em="http://dep.staff.edu/sessions"

   env:role="http://www.w3.org/2003/05/soap-envelope/role/next"

   env:mustUnderstand="true">

<em:name>Информатика</em:name>

<em:semester-index>2</em:semester-index>

   </m:exam>

 </env:Header>

В заголовке содержатся два блока, причем каждый из них определен в своем пространстве имен.  Первый блок (элемент group в пространстве имен gr) содержит сведения о студенческой группе: наименование (элемент name), курс (элемент year) и кафедра (элемент chair). Второй блок (элемент exam в пространстве имен em) содержит сведения об экзамене: наименование предмета (элемент name) и номер семестра (элемент semester-index).

Блоки заголовков должны быть обработаны в следующем узле-посреднике SOAP, как это определено атрибутами env:role в этих блоках. Кроме того, в соответствии со значением атрибута env:mustUnderstand должна выполняться обработка блоков заголовков в узлах SOAP.

Элемент env:Body может содержать любые дочерние элементы и потомки этих элементов, в которых, наряду с другими элементами, можно использовать атрибут  env:encodingStyle.  Единственным дочерним элементом env:Body, который  определен в спецификации SOAP, является элемент env:Fault.

Пример тела сообщения SOAP:

  <env:body xmlns:sd="http://dep.staff.edu/students">

     <sd:student>

  <sd:name>Иван</sd:name>

 <sd:surname>Иванович</sd:surname>

 <sd:last-name>Иванов</sd:last-name>

      </sd:student>

 <sd:student>

  <sd:name>Петр</sd:name>

 <sd:surname>Петрович</sd:surname>

 <sd:last-name>Петров</sd:last-name>

      </sd:student>

</env:Body>

Содержимое тела сообщения (в пространстве имен sd) содержит сведения о двух студентах студенте: имя (элемент name), отчество (элемент surname) и фамилию (элемент lastname). Тело сообщения вместе с заголовком, приведенном в предыдущем примере,  можно рассматривать как сообщение SOAP – запрос на получение оценок двух студентов из заданной в заголовке группы по заданным в заголовке наименовании дисциплины и номеру семестра.

6.2.2.2.2. Сообщение об ошибке

Элемент env:Fault используется в том случае, если в сообщении SOAP необходимо передать сведения об ошибке. Как уже указывалось, в этом случае элемент env:Fault должен быть единственным дочерним элементом элемента env:Body.

Для элемента env:Fault определены следующие дочерние элементы: env:Code, env:Reason, env:Node, env:Role, и env:Detail.

6.2.2.2.2.1. Элемент env:Code

Обязательный элемент env:Code, задающий значение кода ошибки, содержит два дочерних элемента:

  •  обязательный элемент env:Value, содержащий код ошибки;
  •  необязательный элемент env:Subcode, уточняющий код ошибки.

В качестве значения элемента env:Value используется один из следующих кодов ошибок верхнего уровня, определенных в спецификации SOAP:

  •  env:VersionMismatch – пространство имен, локальное имя или полное имя элемента не соответствует элементу, определенному в спецификации SOAP 1.2;
  •  env:MustUnderstand – блок заголовка, в котором задан атрибут env:mustUnderstand со значением "true", не соответствует своей схеме XML;
  •  env:DataEncodingUnknown – в блоке заголовка или теле сообщения  обнаружены данные, которые можно трактовать как записанные с использованием неизвестной кодировки;
  •  env:Sender – сообщение либо неправильно сформировано, либо оно не содержит данных, необходимых для его обработки;
  •  env:Receiver – посредник или конечный получатель не  может обработать правильно сформированное из-за внутренних причин.

Если в узле SOAP генерируется ошибка с кодом env:VersionMismatch, в ответное сообщение должен быть включен блок заголовка с элементом env:Upgrade. Элемент должен содержать один или более дочерних элементов env:SupportedEnvelope с атрибутами qname, задающими  полные имена конвертов SOAP.  Элементы env:SupportedEnvelope располагаются в элементе  env:Upgrade в порядке их предпочтительности (сначала более предпочтительные имена, затем менее предпочтительные).

Пример блока заголовка env:Upgrade:

 <env:Upgrade>

       <env:SupportedEnvelope qname="ns1:Envelope"

      xmlns:ns1="http://www.w3.org/2003/05/soap-envelope"/>

    <env:SupportedEnvelope qname="ns2:Envelope"

    xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/"/>

 </env:Upgrade>

Узел SOAP, сгенерировавший это блок заголовка, поддерживает как элемент Envelope SOAP 1.2 в пространстве имен ns1, так и элемент Envelope SOAP 1.1 в пространстве имен ns2. Более предпочтительным является использование элемента Envelope SOAP 1.2.

 

Если в узле SOAP генерируется ошибка с кодом env:MustUnderstand, в ответное сообщение должны быть включены блоки заголовков с элементом env:NotUnderstood., которые должны содержать атрибуты qname, задающие  полные имена блоков заголовков исходного сообщения, для которых задан атрибут env:mustUnderstand со значением "true" и которые не соответствует своей схеме XML.  

Пример блоков заголовка env:NotUnderstood:

Для приведенного выше примера заголовка сообщения SOAP, в случае, если при обработке этих блоков возникли ошибки, в узле-обработчике ошибки будет сгенерирован следующий заголовок:

<env:Header>

<env:NotUnderstood qname="gr:group"

  xmlns:gr="http://dep.staff.edu/groups"/>

<env:NotUnderstood qname="em:exam"

   xmlns:em="http://dep.staff.edu/sessions"/>

</env:Header>

6.2.2.2.2.2. Элемент env:Reason

Обязательный элемент env:Reason содержит текстовое пояснение ошибки. Дочерними элементами для env:Reason являются один или больше элементов env:Text, содержимым которых является текст пояснения ошибки.  

В каждом элементе env:Text для определения языка, на котором приведено пояснение, должен быть задан атрибут xml:lang, причем значение этого атрибута должно быть различным в разных элементах env:Text.

6.2.2.2.2.3. Элементы env:Node и env:Role

Для получения сведений об узле на пути сообщения SOAP, в котором произошла ошибка, используются необязательные элементы env:Node и env:Role. Значениями этих элементов являются данные типа xs:anyURI.

Элемент  env:Node содержит URI узла, а элемент env:Role содержит ссылку на URI с описанием одной из ролей узла.  

6.2.2.2.2.4. Элемент env:Detail

Необязательный элемент env:Detail содержит в своих дочерних элементах дополнительную или уточняющую информацию об ошибке. Дочерние элементы env:Detail называются компонентами детализации (detail entries).

Каждый компонент детализации может иметь полное имя, определенное в некотором пространстве имен, а также ноль и более атрибутов, в том числе и атрибут env:encodingStyle, задающий вид кодировки  информации об ошибке. Компонент может иметь также текстовое содержимое и/или дочерние элементы, содержащие дополнительные пояснения к ошибке.

6.2.2.2.2.5. Пример сообщения об ошибке

В приведенном ниже сообщении выводятся сведения об ошибке, которое произошла из-за того, что в приведенных выше примерах запроса о сдаче студентами Ивановым и Петровым экзамена по информатике для Петрова не задан элемент name.

<?xml version='1.0' ?>

<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope"

xmlns:me="http://ITC.staff.students.edu/message-errors"              xmlns:xml="http://www.w3.org/XML/1998/namespace">

 <env:Body>

    <env:Fault>

      <env:Code>

         <env:Value>env:Sender</env:Value>

         <env:Subcode>

           <env:Value>

Ошибка в запросе

</env:Value>

         </env:Subcode>

      </env:Code>

      <env:Reason>

        <env:Text xml:lang="ru">

Неверная структура сообщения

</env:Text>

<env:Text xml:lang="en">

Wrong message structure

</env:Text>

      </env:Reason>

  <env:Node>

http://ITC.staff.students.edu

</env:Node>

<env:Role>

http://www.w3.org/2003/05/soap-envelope/role/next

</env:Role>

      <env:Detail>

        <me:FaultDetails>

<me:errorCode>18</e:errorCode>

           <me:message>

     Отсутствует элемент name

</me:message>        

        </me:FaultDetails>

      </env:Detail>

    </env:Fault>

 </env:Body>

</env:Envelope>

6.2.2.3. Типы данных SOAP

В сообщениях SOAP передаются данные самых разных типов: числа, даты, строки символов, массивы, структуры. Определение типов этих данных выполняется, как обычно, в схемах XML.

Типы, определенные в схеме, заносятся в пространство имен, идентификатор которого задается в атрибуте env:encodingStyle. Этот атрибут можно использовать в любом элементе сообщения SOAP, за исключением элемента env:Envelope. Для пространства имен

http://www.w3.org/2003/05/soap-encoding,

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

Для определения типа данных элемента используется атрибут env:nodeType, который может иметь одно из следующих значений: simple (простой тип), array (массив) или struct (структура).

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

6.2.2.3.1. Простые типы данных и ссылки

Для определения типа данного в спецификации SOAP определен атрибут enc:itemType, значением которого является один из типов данных схемы XML.

Примеры задания типов данных:

1. <age env:nodeType="simple" enc:itemType="xs:int">19</age>

Для элемента age (возраст) определен тип данных – целое число (xs:int).

2. <birthDate env:nodeType="simple"

enc:itemType="xs:date">2002-12-30</birthDate> 

Для элемента (дата рождения) определен тип данных – дата (xs:date).

В сообщении SOAP можно делать ссылки на другие элементы. Для этого используются атрибуты id и ref.

Атрибут id, также как и в HTML, используется для идентификации элемента. На элемент, заданный с атрибутом id, можно сослаться в атрибуте  ref другого элемента, т.е. атрибут действует аналогично атрибуту href в HTML.

Пример использования атрибутов id и ref:

<bd:book-description

xmlns:bd="http://library.org/book-descriptions">

<bd:book>

 <bd:title>Собака Баскервилей</title>

 <bd:author id="Doyle">Дойл Артур Конан</author>

</bd:book>

<bd:book>

 <bd:title>Рассказы о Шерлоке Холмсе</title>

 <bd:author ref="Doyle"/>

</bd:book>

</bd:book-description> 

В этом примере элемент bd:author во втором элементе bd:book ссылается на элемент bd:author в первом элементе bd:book.

6.2.2.3.2. Массивы

Для элементов типа массив наряду с атрибутами env:nodeType и enc:itemType должен быть задан атрибут enc:arraySize.

В этом атрибуте задается размер массива (для одномерных массивов) или размеры массива, отделенные друг от друга пробельными символами (для многомерных массивов). Значением размера может быть либо положительное целое число, либо символ "*". Во втором случае размер массива не определен и задается непосредственно при заполнении массива элементами. Если массив многомерный, значение "*" может иметь только первый индекс. Если для массива не задан атрибут enc:arraySize, предполагается, что массив является одномерным и имеет неопределенное число элементов.

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

Элементы массива могут иметь как одинаковый, так и разный тип. В элементе, определяющем массив, в атрибуте  enc:itemType в первом случае  задается тип элементов массива, во втором случае – значение  "xs:anySimpleType".  

Примеры задания массива:

1. <student-last-name env:nodeType="array"

enc:itemType="xs:string" enc:arraySize="3">

  <item>Иванов</item>

  <item>Петров</item>

<item>Сидоров</item>

</student-last-name>

В этом примере задан массив данных для студента из трех элементов. Элементы массива имеют строковый тип (xs:string).

2. <student-data env:nodeType="array" id="IvanovII"

enc:itemType="xs:anySimpleType" enc:arraySize="*">

  <name enc:itemType="xs:string">

Иванов Иван Иванович

</name>

  <group-index enc:itemType="xs:string">

ТД-01

</group-index>

<birthDate enc:itemType="xs:date">

1991-01-12

</birthDate>

</student-data> 

В этом примере задан массив сведений о студенте. Первый элемент – фамилия, имя отчество имеет строковый тип (xs:string), второй – индекс также имеет строкой тип и третий – дата рождения имеет тип даты (xs:date).

6.2.2.3.3. Структуры

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

Пример задания структуры:

<student env:nodeType="struct">

<student-data ref="IvanovII">

<enter-year enc:itemType="xs:gYear">2007</enter-year>

<current-data env:nodeType="struct">

 <year enc:itemType="xs:positiveInteger">2</year>

  <mean-mark enc:itemType="xs:decimal">

4.3

</mean-mark>

</current-data>

</student>

В этом примере задана структура сведений о студенте student, состоящая из трех полей. Первое поле student-data задано как ссылка на массив сведений о студенте, описанный в предыдущем примере. Во втором поле enter-year задан год поступления студента в вуз. Третье поле current-data является структурой, полями которой, в свою очередь, являются курс обучения year и средняя оценка mean-mark.

6.2.2.4. Представление удаленного вызова процедур в SOAP

Одной из целей создания протокола SOAP было создание средств, облегчающих вызов удаленных процедур – RPC (Remote Procedure Call) для наиболее распространенных языков программирования. Для этого в спецификации SOAP 1.2 определены унифицированное представление запросов и ответов RPC. Это представление не зависит от компьютерной платформы и не привязано к каким-либо конкретным языкам программирования.

Для вызова удаленной процедуры необходимы следующие данные:

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

6.2.2.4.1. Вызов процедуры

Для вызова удаленной процедуры в теле сообщения SOAP (элемент env:Body)  задается структура, имя которой совпадает с именем вызываемой процедуры или метода. Имена полей совпадают с именами аргументов, порядок следования полей в структуре совпадает с порядком следования аргументов в процедуре или методе, а значения аргументов задаются в текстовом содержимом полей. В полях структуры перечисляются аргументы процедуры или метода. Аргументы процедуры или метода могут быть как простыми переменными, так и массивами или структурами.

Примеры вызова удаленной процедуры:

1. Удаленный метод 

public int getAge(StudentName studentName,

String groupIndex)

определяет возраст студента с заданным фамилией, именем и отчеством (ФИО) studentName (объект класса StudentName) и из заданной группы groupIndex.

Класс StudentName объявлен следующим образом:

class StudentName {

String name;   // Имя студента

String surname;  // Отчество студента

String lastName;  // Фамилия студента

}

Для студента Иванова Ивана Ивановича из группы "ТД-01" сообщение SOAP для вызова удаленного метода getAge() будет иметь следующий вид:

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

 <env:Body>

<sd:getAge xmlns:sd="http://dep.staff.edu/students"

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

<sd:StudentName>

<sd:name>Иван</sd:name>

<sd:surname>Иванович</sd:surname>

<sd:lastName>Иванов</sd:lastName>

 </sd:StudentName>

<sd:groupIndex>ТД-01</sd:groupIndex>

    </sd:getAge>

 </env:Body>

</env:Envelope>

2. Удаленный метод 

public float getMeanValue(int [] values)

определяет среднее значение элементов массива целых чисел values.

Сообщение SOAP для вызова этого удаленного метода будет иметь следующий вид:

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

 <env:Body>

<st:getMeanValue xmlns:st=" http://math.edu/stat"

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

  <values env:nodeType="array"

  enc:itemType="xs:int" enc:arraySize="*">

   <item>3</item>

   <item>20</item>

 <item>42</item>

 <item>14</item>

  </values>

    </st:getMeanValue>

 </env:Body>

</env:Envelope>

6.2.2.4.2. Возврат результатов выполнения процедуры

Для возврата результатов выполнения процедуры в сообщении SOAP задается элемент с произвольным именем (однако принято для имени этого элемента использовать имя вызываемой процедуры или метода, к которому добавлено окончание Response).

Имена дочерних элементов заданного элемента совпадают с именами выходных параметров, а содержимым являются значения этих параметров.

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

Для определения возвращаемого значения сначала задается имя элемента, в содержимом которого будет передаваться возвращаемое значение. Имя этого элемента определяется в содержимом элемента result, который определен в пространстве имен (обычно с именем rpc) с идентификатором

http://www.w3. org/2002/06/soap-rpc.

Примеры возврата результатов выполнения удаленной процедуры:

1. Для удаленного метода getAge() сообщение SOAP (без использования элемента result) будет иметь следующий вид:

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

 <env:Body>

<sd:getAgeResponse xmlns:sd="http://dep.staff.edu/students "

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

<sd:studentAge>17</sd:studentAge>

</sd:getAgeResponse>

 </env:Body>

</env:Envelope>

2. Для удаленного метода getMeanValue() сообщение SOAP (с использованием элемента result) будет иметь следующий вид:

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

 <env:Body>

<st:getMeanValueResponse xmlns:st="http://math.edu/stat"

xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

  <rpc:result>st:meanValue</rpc:result>

  <st:meanValue>19.75</st:meanValue>

    </st:getMeanValueResponse>

 </env:Body>

</env:Envelope>

6.2.2.4.3. Ошибки при вызове процедур

В представлении удаленного вызова процедур в SOAP введены дополнительные уточняющие коды (subcodes) ошибок.

Сообщения об ошибках, возникающих при вызове удаленных процедур, формируются по следующим правилам:

  •  если узел SOAP, на котором размещена процедура, не может ее выполнить из-за каких-либо временных условий, например, нехватки памяти, в элементе env:Code должна быть сгенерирована ошибка со значением env:Receiver в элементе env:Value;
  •  если аргументы процедуры закодированы с помощью метода, неизвестного в узле SOAP, на котором размещена процедура, в элементе env:Code должна быть сгенерирована ошибка со значением env:DataEncodingUnknown в элементе env:Value;
  •  если запрашиваемая процедура отсутствует в узле SOAP, в элементе env:Code может быть сгенерирована ошибка со значением env:Sender в элементе env:Value,  а для содержимого элемента env:Value в элементе env:Subcode задается значение rpc:ProcedureNotPresent;
  •  если узел SOAP, на котором размещена процедура, не может проанализировать переданные аргументы, а также в случае, если число и/или типы аргументов не соответствуют аргументам процедуры, в элементе env:Code должна быть сгенерирована ошибка со значением env:Sender в элементе env:Value,  а для содержимого элемента env:Value в элементе env:Subcode задается значение rpc:BadArguments;
  •  остальные ошибки генерируются по правилам, описанным в п. 6.2.2.2.2.1.

Значения, задаваемые в элементах env:Reason и env:Detail, зависят от реализации обработки вызова процедуры.

Пример сообщения об ошибке при вызове процедуры:

В приведенном ниже сообщении выводятся сведения об ошибке, которое произошла из-за того, что в приведенных выше примерах запроса о сдаче студентами Ивановым и Петровым экзамена по информатике для Петрова не задан элемент name.

Если в предыдущем примере определения возраста  студента Иванова Ивана Ивановича в сообщении SOAP для вызова удаленного метода getAge()отсутствует элемент

<sd:groupIndex>ТД-01</sd:groupIndex>,

т.е. не задан аргумент  groupIndex, то сообщение об ошибке будет иметь следующий вид:

<?xml version="1.0"?>

<env:Envelope 

xmlns:env="http://www.w3.org/2003/05/soap-envelope"

xmlns:me="http://ITC.staff.students.edu/message-errors"              xmlns:xml="http://www.w3.org/XML/1998/namespace">

 <env:Body>

    <env:Fault xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

      <env:Code>

         <env:Value>env:Sender</env:Value>

         <env:Subcode>

           <env:Value>

rpc:BadArguments

</env:Value>

         </env:Subcode>

      </env:Code>

      <env:Reason>

        <env:Text xml:lang="ru">

Не задан аргумент groupIndex

</env:Text>

      </env:Reason>

    </env:Fault>

 </env:Body>

</env:Envelope>

6.2.2.5. Связывание с протоколами обмена

Пересылка сообщения между узлами SOAP может быть выполнена с использованием одного из протоколов прикладного уровня Internet, например, HTTP или SMTP. Спецификация, описывающая передачу сообщения SOAP от одного узла к другому с использованием конкретного протокола, называется связыванием (binding).

В дополнение с конкретной реализацией передачи сообщения SOAP, протокол связывания обеспечивает механизмы поддержки возможностей (features), необходимых для приложения SOAP.

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

Примерами возможностей являются возможность кодирования данных или возможность использования надежного канала при передаче.

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

6.2.2.5.1. Пересылка сообщения по протоколу HTTP

Протокол HTTP является в настоящее время самым распространенным протоколом обмена данными в сети Internet. Клиент  HTTP посылает запрос серверу HTTP, задавая URI сервера, имя запрашиваемого файла и версию протокола. В ответ на запрос клиент получает ответ HTTP, в котором содержится запрашиваемый файл, либо сообщение об ошибке. Такой режим запрос-ответ может быть использован для посылки сообщения-запроса SOAP с возможным получением сообщения-ответа SOAP, а URI сервера в запросе можно трактовать как конечный получатель сообщения SOAP (возможно,  через узлы-посредники SOAP).

При связывании сообщения SOAP с запросом HTTP можно указать один из двух методов передачи параметров в запросе: POST или GET.  

6.2.2.5.1.1. Использование метода POST

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

Для сообщений SOAP в поле заголовка Content-Type должен быть записан специально созданный для MIME-типа application подтип soap+xml.

Если запрос воспринят и обработан конечным получателем сообщения SOAP, то в первой строке ответа код обработки должен иметь значение "200 OK", в поле заголовка Content-Type указывается MIME-тип application/soap+xml, а тело ответа содержит сообщение SOAP.

Если при обработке запроса были выявлены ошибки, код обработки в первой строке ответа должен иметь значение "500 Internal Server Error", а в теле ответа выводится сообщение SOAP об ошибке.

Пример использования метода POST:

Запрос HTTP для сообщения SOAP вызова удаленного метода getAge() в предыдущем примере будет иметь следующий вид:

POST /students HTTP/1.1

Host: dep.staff.edu

Content-Type: application/soap+xml; charset="windows-1251"

Content-Length: длина-тела-сообщения

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

 <env:Body>

<sd:getAge xmlns:sd="http://dep.staff.edu/students"

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

<sd:StudentName>

<sd:name>Иван</sd:name>

<sd:surname>Иванович</sd:surname>

<sd:lastName>Иванов</sd:lastName>

 </sd:StudentName>

<sd:groupIndex>ТД-01</sd:groupIndex>

    </sd:getAge>

 </env:Body>

</env:Envelope>

Для правильного вызова метода getAge()ответ будет иметь следующий вид:

HTTP/1.1 200 OK

Content-Type: application/soap+xml; charset="windows-1251"

Content-Length: длина-тела-сообщения

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

 <env:Body>

<sd:getAgeResponse xmlns:sd="http://dep.staff.edu/students "

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

<sd:studentAge>17</sd:studentAge>

</sd:getAgeResponse>

 </env:Body>

</env:Envelope>

Если в сообщении SOAP для вызова метода getAge()содержалась ошибка (не задан аргумент groupIndex), ответ будет иметь следующий вид:

HTTP/1.1 500 Internal Server Error

Content-Type: application/soap+xml; charset="windows-1251"

Content-Length: длина-тела-сообщения

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope"

xmlns:me="http://ITC.staff.students.edu/message-errors"              xmlns:xml="http://www.w3.org/XML/1998/namespace">

 <env:Body>

    <env:Fault xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

      <env:Code>

         <env:Value>env:Sender</env:Value>

         <env:Subcode>

           <env:Value>

rpc:BadArguments

</env:Value>

         </env:Subcode>

      </env:Code>

      <env:Reason>

        <env:Text xml:lang="ru">

Не задан аргумент groupIndex

</env:Text>

      </env:Reason>

    </env:Fault>

 </env:Body>

</env:Envelope>

6.2.2.5.1.2. Использование метода GET

При формировании запроса по методу GET можно запросить только параметры для формирования ответного сообщения SOAP. Запроса по методу GET можно использовать также для доступа к Web-службам, задавая в параметрах запроса имя Web-службы и ее параметры. В запросе в поле Accept необходимо в MIME-типах принимаемых данных указать тип application/soap+xml.

Ответ на запрос формируется с использованием метода POST.

Пример использования метода GET:

Запрос HTTP для сообщения SOAP вызова удаленного метода getAge() в предыдущем примере будет иметь следующий вид:

GET /students?name=Иван&surname=Иванович&lastName=Иванов& groupIndex=ТД-01 HTTP/1.1

Host: dep.staff.edu

Accept: text/xml; application/soap+xml 

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

Если в запросе пропущен параметр groupIndex:

GET /students?name=Иван&surname=Иванович&lastName=Иванов HTTP/1.1

Host: dep.staff.edu

Accept: text/xml; application/soap+xml,

ответ HTTP будет тот же, что и для неправильного запроса в предыдущем примере.

6.2.2.5.1.3. Прикрепления в запросах и ответах HTTP

Компоненты распределенного приложения часто должны обмениваться не только текстовыми сообщениями SOAP, но и документами других форматов (например, изображениями, мультимедийными данными или документами Word). Метод POST протокола HTTP может передавать такие данные с использованием MIME-типа multipart.

Тип multipart объединяет несколько фрагментов разных MIME-типов в теле запроса или ответа.  В зависимости от степени связанности фрагментов в типе multipart различают несколько подтипов: alternative, parallel и related. В  технологии Web-служб наиболее часто используется подтип related, определенный для тесно связанных фрагментов.

Запрос или ответ, состоящий из нескольких фрагментов, начинается с поля заголовка Content-Type, в котором определен тип и подтип  заголовка (multipart/related) и, кроме того, задан обязательный параметр boundary, значением которого является  разделитель – любой набор символов, не совпадающий с начальными символами ни одной строке сообщения, например:

Content-Type: multipart/related; boundary=fragment-boundary.

После заголовка Content-Type вставляется пустая строка, а затем  на отдельной строке записывается разделитель, причем перед разделителем без пробелов записываются символы "--". После этого задается первая часть сообщения со своими полями заголовков, за которыми следует пустая строка и тело первого фрагмента. Аналогичным образом, после пустой строки и разделителя с символами "--" записывается второй фрагмент и т.д.

В конце тела запроса или ответа опять ставится разделитель, у которого символы "--" ставятся не только впереди, но и сзади.

Все поля заголовков в отдельных фрагментах необязательны, т.е. каждая часть может начинаться с пустой строки. Существенным является только  поле Content-Type.  Если это поле не задано, предполагает, что фрагмент содержит текст в кодировке ASCII, т.е. поле заголовка по умолчанию имеет следующий вид:

Content-Type: text/plain; charset="US-ASCII".

Поле Content-Type начального фрагмента должно содержать обязательный параметр type, задающий тип содержимого начального фрагмента тела запроса или ответа. На начальный фрагмент можно явно указать с  помощью необязательного параметра start поля Content-Type, который задается как уникальный адрес электронной почты, заключенный в угловые скобки. Если параметр start отсутствует, то начальным считается первый фрагмент сообщения. Необязательный параметр start-info поля Content-Type содержит дополнительные сведения о начальном фрагменте тела запроса или ответа. Эти сведения (например, аргументы вызова) обычно используются программой, которая будет обрабатывать начальный фрагмент.

В заголовке каждого фрагмента задается  поле Content-ID, значением которого, так же, как и параметра start,    является  уникальный адрес электронной почты, заключенный в угловые скобки, например:

<student12345@ourmail.edu>.

Кроме этого, в заголовке каждого фрагмента может быть задано поле Content-Disposition. Значение этого поля определяет расположение фрагмента: для встроенного фрагмента задается значение   inline, а для фрагмента, находящегося во внешнем файле, задается значение  attachment. Во втором случае в поле задается дополнительный параметр  filename, значением которого является имя файла, содержащего данный фрагмент сообщения, например:

Content-Disposition: attachment; filename=myImage.gif.

В заголовках фрагментов может быть также задано поле Content-Transfer-Encoding, определяющее кодировку передаваемых данных, например 8bit или base64.

Значением необязательного поля Content-Location, которое можно поместить в заголовок фрагмента сообщения является URI,  идентифицирующий этот фрагмент сообщения так же, как и почтовый адрес в поле заголовка Content-ID. Поле Content-Location можно использовать вместе или вместо поля Content-ID.

Для включения сообщения SOAP в тело запроса или ответа MIME-типа multipart/related определены следующие правила:

  •  сообщение SOAP помещается в начальный фрагмент  тела запроса или ответа;
  •  MIME-тип сообщения SOAP устанавливается равным application/soap+xml;
  •  заголовок начального фрагмента содержит поле Content-ID,  а параметре start поля Content-Type заголовка задается ссылка на значение поля Content-ID начального фрагмента части. Остальные фрагменты также могут содержать поле Content-ID и/или поле Content-Location.
  •  ссылки на другие фрагменты тела запроса или ответа выполняются в сообщении SOAP с помощью атрибута href, причем для адреса электронной почты в Content-ID ссылка выполняется с использованием схемы cid (для ссылки на URI в схему cid использовать не надо).

Пример сообщения SOAP с прикреплениями:

POST /services/ImageServlet HTTP/1.1

Host: dep.staff.edu

Content-Type: multipart/related;

boundary=fragment-boundary;

start="<client123.xml@ourmail.edu>";

startinfo="application/soap+xml"

Content-Length: длина-тела-сообщения

--fragment-boundary

Content-Type: application/soap+xml; charset="windows-1251"

type="application/soap+xml"

Content-Transfer-Encoding: 8bit

Content-ID: "<client123.xml@ourmail.edu>"

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Body>

 <ic:imageCollection

xmlns:ic="http://dep.staff.edu/images">

<ic:map href="cid:image01.gif@ourmail.edu"/>

<ic:map href="images/image04"/>

</ic:imageCollection>

</env:Body>

</env:Envelope >

--fragment-boundary

Content-Type: image/gif

Content-Transfer-Encoding: base64

Content-ID: <image01.gif@ourmail.ed>

R01GODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5NSBJRVRGLiBVbmFldGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRl…

--fragment-boundary

Content-Type: image/png

Content-Transfer-Encoding: binary

Content-Location: images/image04

Content-Disposition: attachment;

filename=http://dep.staff.edu/images/image04.png

--fragment-boundary--

6.2.2.5.2. Пересылка сообщений по протоколу SMTP

Разработчики приложений SOAP могут использовать для передачи протокол электронной почты SMTP. В этом случае сообщение SOAP задается как тело обычного письма электронной почты (e-mail). Так же, как в теле запроса и ответа протокола HTTP, в электронных письмах можно использовать прикрепления.

Пример письма e-mail, содержащего сообщение SOAP:

Электронное письмо для сообщения SOAP вызова удаленного метода getAge() в предыдущем примере будет иметь следующий вид:

From: petrov@ourmail.edu

То: studentApp@ourmail.edu

Subject: Запрос возраста

Date: Fri, 25 Jan 2008 14:08:00 GMT

Message-Id: <EE492E16A090090276D208424960C0C@ourmail.edu>

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

 <env:Body>

<sd:getAge xmlns:sd="http://dep.staff.edu/students"

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

<sd:StudentName>

<sd:name>Иван</sd:name>

<sd:surname>Иванович</sd:surname>

<sd:lastName>Иванов</sd:lastName>

 </sd:StudentName>

<sd:groupIndex>ТД-01</sd:groupIndex>

    </sd:getAge>

 </env:Body>

</env:Envelope>

Ответ на вызов также оформляется как письмо электронной почты:

From: studentApp@ourmail.edu

То: petrov @ourmail.edu

Subject: Ответ на запрос возраста

Date: Fri, 25 Jan 2008 14:10:08 GMT

Message-Id: <200109251753NAA10655@ourmail.edu>

<?xml version="1.0"?>

<env:Envelope

xmlns:env="http://www.w3.org/2002/06/soap-envelope">

 <env:Body>

<sd:getAgeResponse xmlns:sd="http://dep.staff.edu/students "

   env:encodingStyle="http://www.w3.org/2002/06/soap-encoding">

<sd:studentAge>17</sd:studentAge>

</sd:getAgeResponse>

 </env:Body>

</env:Envelope>

Файл: file:///web/1/5fan/public_html/www/files/13/5fan_ru_69049_247b0fb8e60ae232810623ffaa9f4800.doc   Создан: 2008-04-20T07:19:00Z Модифицирован: 2008-04-20T07:19:00Z     Автор:


Посредник

SOAP

Начальный отправитель сообщения SOAP

онечный получатель сообщения SOAP

Узел

SOAP

Путь сообщения SOAP

Посредник

SOAP

Регистрационное агентство

Описание услуг

Описание услуг

Агент выполнения услуг

Агент запроса услуг

Поиск

Публикация

Взаимодействие

Узел

SOAP


 

А также другие работы, которые могут Вас заинтересовать

20359. СУММИРОВАНИЕ МОЩНОСТЕЙ СИГНАЛОВ СВЧ ГЕНЕРАТОРОВ 95.5 KB
  СУММИРОВАНИЕ МОЩНОСТЕЙ СИГНАЛОВ СВЧ ГЕНЕРАТОРОВ 18. Способы суммирования мощностей сигналов 18. Суммирование мощностей сигналов с помощью многополюсной схемы 18. Суммирование мощностей сигналов с помощью ФАР 18.
20360. АМПЛИТУДНАЯ МОДУЛЯЦИЯ 94.5 KB
  Виды модуляции 19. Виды модуляции Модуляцией называется процесс управления одним или несколькими параметрами колебаний высокой частоты в соответствии с законом передаваемого сообщения. Классифицировать методы модуляции можно по трем признакам в зависимости: – от управляемого параметра высокочастотного сигнала: амплитудная AM частотная ЧМ и фазовая ФМ; – числа ступеней модуляции: одно двух трехступенчатая; – вида передаваемого сообщения – аналогового цифрового или импульсного непрерывная со скачкообразным изменением...
20361. Однополосная АМПЛИТУДНАЯ МОДУЛЯЦИЯ 54 KB
  Нелинейные искажения сигнала при амплитудной модуляции. Структура ОБП сигнала 20. Усиление ОБП сигнала в двухканалыюм усилителе 20. Формирование ОБП сигнала 20.
20362. ЧАСТОТНАЯ И ФАЗОВАЯ МОДУЛЯЦИЯ 111 KB
  Спектр сигнала при частотной и фазовой модуляции. Основные определения Поскольку мгновенная частота t с фазой t сигнала связана соотношением: 21. При частотной модуляции ЧМ мгновенная частота сигнала изменяется по закону модулирующего сигнала при фазовой ФМ фаза.7 следует что при частоте модулирующего сигнала =const отличить ЧМ от ФМ не представляется возможным.
20363. ЧАСТОТНАЯ И ФАЗОВАЯ МОДУЛЯЦИЯ дискретных сообщений 63.5 KB
  Частотная и фазовая модуляция дискретных сообщений При передаче дискретной в том числе цифровой кодированной информации комбинации двоичных сигналов состоящей из логических 1 и 0 модуляцию называют манипуляцией сигнала а устройство реализующее данный процесс как модулятором так и манипулятором. Три названных способа манипуляции ВЧ сигнала имеют разный уровень помехоустойчивости определяемой как вероятность ошибки принятого символа на выходе приемника от соотношения мощностей полезного сигнала и белого шума на входе демодулятора.1...
20364. ИМПУЛЬСНАЯ МОДУЛЯЦИЯ 116.5 KB
  Излучаемый РПДУ сигнал модулированный последовательностью прямоугольных импульсов показан на рис. Рис. При периодической последовательности прямоугольных импульсов рис.l где Е амплитуда импульса рис.
20365. ОБЩИЕ ПРИНЦИПЫ ГЕНЕРИРОВАНИЯ И УСИЛЕНИЯ ВЧ И СВЧ КОЛЕБАНИЙ 209 KB
  ОБЩИЕ ПРИНЦИПЫ ГЕНЕРИРОВАНИЯ И УСИЛЕНИЯ ВЧ И СВЧ КОЛЕБАНИЙ Классификация и физический механизм работы ВЧ и СВЧ генераторов Генератор на электровакуумном приборе Генератор на биполярном транзисторе Генератор на полевом транзисторе Генератор на диоде Клистронный генератор Генератор на лампе бегущей волны Время взаимодействия носителей заряда с электромагнитным полем Принципы синхронизма и фазировки носителей заряда с электромагнитным полем Мощность взаимодействия носителей заряда с электромагнитным полем 3. В основе работы всех типов...
20366. ЭЛЕКТРИЧЕСКИЕ ЦЕПИ ВЧ ГВВ 136 KB
  ЭЛЕКТРИЧЕСКИЕ ЦЕПИ ВЧ ГВВ 10. Согласующие цепи в узкополосных ВЧ транзисторных генераторах 10. Согласующие цепи в широкополосных ВЧ генераторах 10. Обобщенная схема ГВВ Назначение входной цепи состоит в согласовании входного сопротивления транзистора Zвх с источником возбуждения.
20367. ЭЛЕКТРИЧЕСКИЕ ЦЕПИ широкополосных генераторов 63 KB
  Согласующие электрические цепи в широкополосных ВЧ генераторах 11. Согласующие электрические цепи в широкополосных ВЧ генераторах Предельная возможность согласования генератора с нагрузкой в полосе частот. На одной частоте можно произвести оптимальное согласование генератора с нагрузкой при любых параметрах последней выполнив условие 5. при создании широкополосного генератора.