Импорт формата полезной нагрузки в случае использования описаний сообщений document/literal

При использовании в Web-сервисе стиля document/literal схемы форматов обмена данными часто опираются на существующий стандарт документа. Это может вызвать проблемы с синхронизацией WSDL-файлов со стандартными схемами. В этой статье показано, как использовать XInclude, чтобы включить в WSDL-файл фрагменты внешней схемы.

Для того, чтобы формализовать XML-документ, который передается в Web-сервисе, в разделе types WSDL-файла можно разместить фрагмент XML-схемы. В большинстве случаев под этим понимается содержание тела сообщения SOAP (SOAP body). При использовании в Web-сервисе стиля RPC это обычно специализированный XML-формат, который преобразует конструкции XML-схемы W3C (W3C XML Schema, WXS) в формат SOAP. Такой подход характерен для Web-сервиса и не очень полезен вне его. Это разделение на XML-документ, который вероятно используется на уровне приложения в любой конечной точке (endpoint), и переданным формат часто является основной причиной критики использования в Web-сервисе стиля RPC и основанием для отстаивания стиля document/literal. Если читатель не знаком со стилем document/literal, необходимые сведения можно почерпнуть, обратившись к материалам, приведенным в разделе .

В случае использования стиля document/literal XML-формат, который весьма удобен для обработки на любой стороне, просто помещается в конверт и передается в низменном виде. Это означает, что подробности схемы, которые располагаются в разделе types WDDL, часто являются частью более широко используемой схемы. Этой схемой может быть даже известная схема, как, например, XHTML, Docbook или один из многочисленных XML-форматов для обмена бизнес-данными - UBL или OAGIS. Это означает, что включение этой схемы в WSDL-документы может привести к проблемам с синхронизацией или совместимостью. Что случится, если схема изменилась, а WSDL -нет? В этом случае могут возникнуть как ошибки, которые сложно определить, так и серьезные проблемы.

Инъекция включением

Конструкция XInclude, определенная консорциумом W3C, задает модель обработки и синтаксис для превращения ссылки на внешний документ в фактический XML в этом документе (или его части). Данный процесс называется включением (inclusion), он похож на инструкцию #include в C или C++. С технической точки зрения включение XML осуществляется объединением ряда информационных наборов XML в один составной Infoset. Если файл схемы хранится по какому-либо адресу, его можно включить в WSDL-файл. Предположим, что следующий документ должен быть отправлен в Web-сервисе, в котором используется стиль literal:

Листинг 1. Пример документа, отправляемого в Web-сервисе, в котором используется стиль literal

<?xml version="1.0" encoding="iso-8859-1"?> <labels> <label> <quote> Midwinter Spring is its own season </quote> <name>Thomas Eliot</name> <address> <street>3 Prufrock Lane</street> <city>Stamford</city> <state>CT</state> </address> </label> <label> <name>Ezra Pound</name> <address> <street>45 Usura Place</street> <city>Hailey</city> <state>ID</state> </address> </label> </labels>

Данный формат формализуется в XML-схеме W3C следующим образом:

Листинг 2. XML-схема W3C для документа, отправляемого в стиле literal

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" > <xs:element name="labels"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" maxOccurs="unbounded" ref="label"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="label"> <xs:complexType> <xs:sequence> <xs:element minOccurs="0" ref="quote"/> <xs:element ref="name"/> <xs:element ref="address"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="quote"> <xs:complexType mixed="true"> <xs:sequence> <xs:element ref="emph"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="emph" type="xs:string"/> <xs:element name="name" type="xs:string"/> <xs:element name="address"> <xs:complexType> <xs:sequence> <xs:element ref="street"/> <xs:element ref="city"/> <xs:element ref="state"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="street" type="xs:string"/> <xs:element name="city" type="xs:string"/> <xs:element name="state" type="xs:string"/> </xs:schema>

Приведенный ниже пример (Листинг 3) - это раздел types из WSDL-файла, который включает необходимую часть определения схемы.

Листинг 3. Часть WSDL-файла, в котором для присоединения схемы используется XInclude

Лучше меньше, да лучше

Листинг 3 - это включение отнюдь не всего файла. В данном примере для WSDL требуются определения элемента из файла схемы, и поэтому для извлечения этого подмножества из всей схемы в Листинге 3 используется XPointer. В XPointer определено несколько схем для таких извлечений. Схема xmlns(...) определяет отображение пространств имен, а схема xpointer(...) задает выражения, которые определяют, какое подмножество документа будет использоваться. XPointer опирается на XPath, и выражение /xs:schema/* означает тоже самое, что и в XPath - то есть выбираются только потомки элемента xs:schema.

Важное замечание. Данный синтаксис XPointer соответствует требованиям Рабочей версии спецификации XPointer от 10 ноября 2003г., однако, он отличается от прежнего способа выражения XPointer в XInclude. Автор выяснил, что инструментальные средства пока еще не поддерживают последний вариант, и поэтому читателю, возможно, какое-то время придется пользоваться более ранней редакцией. Листинг 4 - эквивалент Листинга 3, записанный в соответствии с прежним синтаксисом XPointer.

Листинг 4. Вариант Листинга 3, в котором используются более ранний синтаксис XPointer

Примечание. Часть, начинающаяся с "xmlns(", обычно располагается сразу после знака "решетка", а не со следующей строки, однако, для удобства восприятия отформатированного текста после этого знака был добавлен символ разрыва строки.

Ресурсы

Исчерпывающие сведения об использовании в Web-сервисах стиля document/literal можно получить, прочитав статью Джеймса Маккарфи (James McCarthy) "Преимущества использования стиля document в Web-сервисах" (, developerWorks, июнь 2002 г.) и статью Расселла Бутека (Russell Butek) "Какой стиль WSDL следует использовать" (, developerWorks, октябрь 2003г.).

В статье Билала Сиддикуи (Bilal Siddiqui) "Развертывание Web-сервисов с WSDL" (, developerWorks, ноябрь 2001г.) рассматривается ранняя версия WSDL.

Текущая версия спецификации "Язык описания Web сервисов, версия 1.2" (). Познакомится с будущей версией можно, прочитав "WSDL, версия 2.0, Часть 0. Основные понятия" ().

Учебное пособие Юча Огбуджи (Uche Ogbuji) "Разработка на Python/XML с помощью 4Suite, часть 4: композиция и обновления" () посвящено XInclude и XPointer - в нем рассказывается о более раннем синтаксисе XInclude (октябрь 2002г.).

Отличное введение в XInclude (более ранний синтаксис) - статья Эллиотта Расти Хэрольда (Elliotte Rusty Harold) "Использование XInclude" ().

Учебные пособия на ресурсе ZVON - и . Они также посвящены более ранней версии XInclude.

Наиболее подробная информации содержится в спецификациях "Включения XML (XInclude), версия 1.0" () и "Структура XPointer" (), опубликованных на сайте консорциума W3C.

Множество других статей, рубрик, учебных пособий и заметок в разделах и рубрики developerWorks.

На странице приведена информация о том, как стать сертифицированным разработчиком XML.

и поддерживается многими инструментальными средствами

XInclude - прост и поддерживается многими инструментальными средствами XML. Это удобный инструмент для многих ситуаций, который может помочь улучшить сопровождение WSDL-документов в стиле document/literal.

Binding

Элемент binding определяет базовый транспорт и формат передачи для сообщений. Каждый элемент binding в документе WSDL указывает на элемент interface. Все элементы operation, определенные в элементе interface, должны быть связаны с этим binding. Элемент endpoint в компоненте service указывает элемент binding. И элементы endpoint, и элементы binding созданы для обеспечения гибкости и прозрачности местоположения. Многочисленные элементы endpoint с различным сетевым адресом могут использовать одну и ту же протокол, определенный в binding. В спецификации "WSDL 2.0, Связывания" определяются расширения элемента binding для таких протоколов и форматов сообщений, как SOAP, HTTP и MIME. На рисунке 7 приведена схема элемента binding.

Рис. 7. Схема элемента binding

Как известно, одним из направлений

Автор: Арулази Десиасилан (Arulazi Dhesiaseelan)
Перевод:

Как известно, одним из направлений деятельности международного консорциума W3C является программа по разработке и продвижению технологий Web-сервисов (), в рамках которой рабочая группа занимается определением языка описания Web-сервисов и возможных способов взаимодействия с сервисами. 26 марта 2004г. рабочая группа обнародовала черновой вариант спецификации WSDL 2.0. Это событие можно расценить как переломный момент в истории развития языка WSDL. В этой статье рассказывается о изменениях, которые были внесены в спецификацию WSDL 1.1, и о том, что было улучшено в новой версии языка WSDL.

Definitions

Элемент definitions является корневым элементов любого документа WSDL. Он используется в качестве контейнера, в котором содержится вся необходимая информация о данной услуге и ее атрибутах. На рисунке 2 приведена схема элемента definitions. Атрибут targetNamespace этого элемента является обязательным атрибутом типа anyURI. Это пространство имен может напрямую или косвенно определять семантику WSDL. Кроме того у элемента definitions могут быть другие необязательные атрибуты, соответствующие различным пространствам имен, которые могут использоваться в документе WSDL.

Рис. 2. Схема элемента definitions

Import

По своему назначению элемент import очень похож на элемент include, с тем исключением, что импортированный документ WSDL может относиться к другому целевому пространству имен. Атрибут namespace этого элемента является обязательным, а атрибут location - необязательным. На рисунке 4 приведена схема элемента import.

Рис. 4. Схема элемента import

Include

Элемент include предназначен для разделения описаний Web-сервиса на модули - различные компоненты описаний сервисов из одного и того же пространства имен могут находиться в другом документе WSDL, которой можно использовать в описаниях Web-сервисов. Атрибут location является обязательным, он задает нахождение этих документов WSDL. Фактическое значение пространства имен добавляемого документа WSDL должно соответствовать целевому пространству имен элемента definitions в документе WSDL, в который добавляется первый документ. На рисунке 3 приведена схема элемента include.

Рис. 3. Схема элемента include

Interface

Элемент interface содержит поименованный набор абстрактных операций и сообщений. При необходимости он может расширять один или несколько других элементов interface. Элементы interface в других компонентах, как, например, binding, указываются по QName. Элемент interface содержит элемент operation, атрибуты name и pattern которого является обязательными, а style - необязательным. На рисунке 5 приведена схема элемента interface. Элементы feature определяют функциональные возможности, связанные с обменом сообщениями между общающимися сторонами, что включает сведения о надежности, безопасности, зависимостях и маршрутизации. Элемент property используется для управления поведением элемента feature. Ряд возможных и допустимых значений этого элемента задается указаниями на описание схемы. Эти значения могут использоваться в нескольких элементах feature.

Рис. 6. Схема элемента interface

Компоненты WSDL

Язык WSDL содержит ряд компонентов и их ассоциированных свойств, предназначенных для описания Web-сервисов. В следующих разделах статьи кратко рассматривается каждый из этих компонентов. Листинг 1. Скелет WSDL 2.0

сервиса можно разделить на две

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

В конкретной части описания элементы binding задают транспорт и формат доставки для интерфейсов (элементов interface). Элемент сервиса (элемента service) endpoint связывает сетевой адрес в соответствие со связыванием (элементом binding). Наконец, элемент service группирует конечные точки (элементы endpoint), которые реализуют общий интерфейс (элемент interface). На рисунке 1 изображена концептуальная модель компонентов WSDL.

Рис. 1. Концептуальная модель WSDL

В связи со значительностью изменений,

В связи со значительностью изменений, внесенные в версию языка 1.1, WSDL 1.1 был переименован в WSDL 2.0. Ниже перечислены основные изменения: В язык WSDL добавлена дополнительная семантика, что явилось одной из причин, почему атрибут targetNamespace элемента definitions стал обязательным. Удалены конструкции сообщений. Теперь они задаются в элементе types при помощи системы типов XML-схемы. Отсутствует поддержка перегрузки операторов. Элемент portType переименован как interface. Поддержка наследования элемента interface достигается благодаря использованию атрибута extends в элементе interface. Элемент port переименован в endpoint.

В соответствии поставленными задачами, рабочая

В соответствии поставленными задачами, рабочая группа опубликовала на сайте W3C рабочие варианты следующих основных спецификаций языка WSDL: ("Язык описания Web-сервисов (язык WSDL), версия 2.0, часть 1: Базовый язык"); ("Язык описания Web-сервисов (язык WSDL), версия 2.0, часть 2: Шаблоны сообщений"); ("Язык описания Web-сервисов (язык WSDL), версия 1.2, часть 3: Связывания")

Кроме того рабочая группа выпустила документы, в которых описываются требования, предъявляемые к описанию Web-сервисов, и сценарии использования языка WSDL: (Требования, предъявляемые к описанию Web-сервисов); (Сценарии использования языка описаний Web-сервисов).

W3C XML-схему языка WSDL 2.0 можно найти на сайте консорциума: .

В приведенных выше документов содержится информация о ходе работ над этими спецификациями.

Ресурсы

(страница рабочей группы, занимающейся разработкой языка WSDL); ("Язык описания Web-сервисов (язык WSDL), версия 2.0: Основные понятия); ("Язык описания Web-сервисов (язык WSDL), версия 2.0, часть 1: Базовый язык"); (W3C XML-схема языка WSDL 2.0); (Документация на W3C XML-схему языка WSDL 2.0, созданная с помощью программного средства XMLSpy). Оригинальный текст статьи можно посмотреть здесь:

document.write('

');

Новости мира IT:

02.08 - 02.08 - 02.08 - 02.08 - 02.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 31.07 - 31.07 - 31.07 - 31.07 - 31.07 -

Архив новостей

Последние комментарии:

(66)

2 Август, 17:53

(19)

2 Август, 17:51

(34)

2 Август, 15:40

(42)

2 Август, 15:35

(1)

2 Август, 14:54

(3)

2 Август, 14:34

(3)

2 Август, 14:15

(2)

2 Август, 13:34

(7)

2 Август, 13:04

(3)

2 Август, 12:28

BrainBoard.ru

Море работы для программистов, сисадминов, вебмастеров.

Иди и выбирай!

google.load('search', '1', {language : 'ru'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('018117224161927867877:xbac02ystjy'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true);

IT-консалтинг

Software Engineering

Программирование

СУБД

Безопасность

Internet

Сети

Операционные системы

Hardware

PR-акции, размещение рекламы — ,
тел. +7 495 6608306, ICQ 232284597

Пресс-релизы —

This Web server launched on February 24, 1997

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

Если Вы нуждаетесь в , то Вам в этом поможет наш СЦ «Техинком»!

Service

Элемент service описывает набор элементов endpoint, которые указывают на одиночный сетевой адрес для элемента binding. Вся другая информация о протоколе сдержится в элементе binding. К элементу service можно обратиться по Qname. У этого элемента есть обязательные атрибуты name и interface. На рисунке 8 приведена схема элемента service.

Рис. 8. Схема элемента service

Шаблоны обмена сообщениями WSDL

Шаблоны обмена сообщениями определяют последовательность и число сообщений в одной операции (элементе operation). В спецификации Web Services Description Language (WSDL) Version 2.0 Part 2: Message Patterns ("Язык описания Web-сервисов (язык WSDL), версия 2.0, часть 2: Шаблоны сообщений") описывается несколько типов шаблонов сообщений. Шаблоны обмена сообщениями используют правила генерации неисправностей, предназначенные для оповещения о возникновении неисправностей. Обмен сообщениями может быть прерван, если генерация неисправностей происходит независимо от набора стандартных правил. Следующий набор стандартных правил кратко описывает поведение при возникновении ошибок. ошибка замещает сообщение (Fault Replaces Messages); сообщение вызывает ошибку (Message Triggers Fault); ошибок нет (No Faults).

На рисунке 9 показаны эти различные шаблоны обмена сообщениями со схемами обработки ошибок.

Рис. 9. Шаблоны обмена сообщениями WSDL

Описание сервиса, предназначенного для передачи информации о котировках акций, на WSDL 1.1 и WSDL 2.0

В этом разделе кратко рассмотрен простой сервис, предназначенный для передачи информации о котировках акций. В представлены типы XML-схемы, которые используются в описании этого сервиса. Листинги и - описание интерфейса сервиса на WSDL 1.1 и WSDL 2.0, соответственно, листинги и - описание реализации сервиса на WSDL 1.1 и WSDL 2.0.

Types

Элемент types определяет типы данных, которые используются при обмене сообщениями. Язык WSDL использует W3C XML-схему в качестве предпочтительного языка схемы. WSDL может использовать и другие системы, например, DTD и RELAX NG. Чтобы воспользоваться схемами, их необходимо импортировать или внедрять в элементе types документа WSDL. Для импортирования используется конструкция xs:import, а для внедрения - xs:schema. Импортированные или внедренные компоненты схемы в документе WSDL указываются по QName. На рисунке 5 приведена схема элемента types.

Рис. 5. Схема элемента types

В этой статье были рассмотрены

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

Описание вложений

Как указано в уставе Рабочей группы Basic Profile, добавление в разрабатываемый стандарт положения о поддержке вложений предусматривает обратную совместимость. Это означает, что все артефакты Basic Profile 1.0 (DESCRIPTION, MESSAGE, INSTANCE и т.д.) будут также совместимы и с Basic Profile 1.1. Для этого в Basic Profile 1.0 были удалены и изменены требования, согласно которым соединение (binding) ограничивается только SOAP HTTP, то есть теперь стало допустимым соединение SOAP HTTP, либо соединение MIME.

Хотя SwA довольно надежная спецификация, Раздел 5 "MIME Binding" Примечания WSDL 1.1 не совсем точно определен, что ведет к проблемам с совместимостью. Basic Profile 1.1 связывает этот раздел с SwA. Соединения MIME трактуются как нечто отличное от SwA. В Basic Profile 1.1 также исправлены двусмысленности соединений MIME, а также ошибки ("баги") в схеме соединений MIME.

Приведенный ниже фрагмент кода WSDL 1.1 демонстрирует, что можно делать с помощью Basic Profile 1.1 для стиля rpc/literal (заметим, что префиксы пространства имен привязаны к тем же самым универсальным идентификаторам ресурса, как и в Разделе 1.2 :

<wsdl:message name="msg-in"> <wsdl:part name="photo-reference" type="xsd:anyURI"/> <wsdl:part name="photo-attachment" type="xsd:base64Binary"/> </wsdl:message>

<wsdl:message name="msg-out"> <wsdl:part name="result" type="xsd:string"/> </wsdl:message>

<wsdl:portType name="my-portType"> <wsdl:operation name="my-operation"> <wsdl:input message="tns:msg-in"/> <wsdl:output message="tns:msg-out"/> </wsdl:operation> </wsdl:portType>

<wsdl:binding name="my-binding" type="tns:my-portType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="my-operation"> <soap:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soap:body parts="photo-reference" use="literal" namespace="http://example.com/some-namespace"/> </mime:part> <mime:part> <mime:content part="photo-attachment" type="application/octetstream"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> <soap:body use="literal" namespace="http://example.com/some-namespace"/> </wsdl:output> </wsdl:operation> </wsdl:binding>

В этом фрагменте часть (part) photo-reference входного сообщения привязана к телу SOAP (SOAP Body), а часть (part) photo-attachment - к отдельной части (part) MIME. Ниже приведен пример входного сообщения для соединения my-binding:
MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=boundary; type=text/xml; start="<my-root-part@example.com>" Content-Description: This is an optional message description.
--boundary Content-Type: text/xml; charset="UTF-8" Content-Transfer-Encoding: 8bit Content-ID: <my-root-part@example.com>
<?xml version='1.0' ?> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body xmlns:types="http://example.com/some-namespace"> <types:my-operation> <photo-reference>cid:my-cool-photo@example.com</photo-reference> </types:my-operation> </env:Body> </env:Envelope>
--boundary Content-Type: application/octet-stream Content-Transfer-Encoding: binary Content-ID: <my-cool-photo@example.com>
...binary photograph... --boundary--
Заметим, что входное сообщение привязано к соединению MIME, а выходное - к соединению SOAP HTTP по Basic Profile 1.0. Basic Profile 1.1 допускает подобное смешение. На самом деле Basic Profile 1.1 "идет дальше" - если используемое соединение MIME, а тело SOAP (SOAP Body) - единственная перечисленная часть MIME, отправитель может отправить это сообщение, применяя соединение SOAP HTTP (если нет вложений) или соединение MIME.
Ниже приведен эквивалентный пример с такими же входным и выходным сообщениями. В этом фрагменте используется стиль document/literal вместо rpc/literal (заметим, что префикс types пространства имен привязан к URI (Uniform Resource Identifier, Универсальный идентификатор ресурса) для пространства имен http://example.com/some-namespace):
<wsdl:types> <schema targetNamespace="http://example.com/some-namespace" xmlns="http://www.w3.org/2000/10/XMLSchema" elementFormDefault="unqualified"> <element name="my-operation"> <complexType> <sequence> <element name="photo-reference" type="xsd:anyURI"/> </sequence> </complexType> </element> <element name="my-operationResponse"> <complexType> <sequence> <element name="result" type="xsd:string"/> <sequence> </complexType> </element> </schema> </wsdl:types>

<wsdl:message name="msg-in-doc"> <wsdl:part name="photo-reference-wrapper" element="types:my-operation"/> <wsdl:part name="photo-attachment" type="xsd:base64Binary"/> </wsdl:message> <wsdl:message name="msg-out-doc"> <wsdl:part name="result-wrapper" element="types:my-operationResponse"/> </wsdl:message>
<wsdl:portType name="my-portType-doc"> <wsdl:operation name="my-operation-doc"> <wsdl:input message="tns:msg-in-doc"/> <wsdl:output message="tns:msg-out-doc"/> </wsdl:operation> </wsdl:portType>
<wsdl:binding name="my-binding-doc" type="tns:my-portType-doc"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="my-operation-doc"> <soap:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soap:body parts="photo-reference-wrapper" use="literal"/> </mime:part> <mime:part> <mime:content part="photo-attachment" type="application/octetstream"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding>

Аниш Кармаркар

Дата: 16-09-2003
Автор: Аниш Кармаркар (Anish Karmarkar)
Перевод: Intersoft Lab

Ресурсы

Спецификация организации WS-I "BasicProfile Version 1.0a", Кит Бэллинджер (Keith Ballinger), Дэвид Энебуске (David Ehnebuske), Мартин Гуджин (Martin Gudgin), Марк Ноттингем (Mark Nottingham), Прасад Йендлури (Prasad Yendluri), от 8 августа 2003г.

"Устав Рабочей группы Web Services Basic Profile" организации WS-I, Том Гловер (Tom Glover), Кристофер Фэррис (Christopher Ferris), Кристофер Курт (Christopher Kurt), Кит Бэллинджер (Keith Ballinger), от 21 января 2003г.

Запрос на комментарии комитета по инженерным вопросам Internet (IETF) "Универсальные локаторы ресурса Контент-ID и Сообщение-ID" ("Content-ID and Message-ID Uniform Resource Locators"), Э. Левинсон (E. Levinson), март 1997г.

Спецификация компании Sun "Среда ативизации JavaBeans, версия 1.0а" ("JavaBeans Activation Framework Specification Version 1.0a"), Барт Кэлдер (Bart Calder), Билл Шэннон (Bill Shannon), от 27 мая 1999г.

Запрос на комментарии комитета по инженерным вопросам Internet (IETF) "MIME инкапсуляция обобщенных документов, таких как HTML (MHTML)" ("MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)"), Дж. Пэлм (J. Palme), А. Хопменн (A. Hopmann), Н. Шелнесс (N. Shelness), март 1999г.

Рабочая версия спецификации консорциума W3C "Механизм оптимизации передачи SOAP-сообщений" ("SOAP Message Transmission Optimization Mechanism"), Ноа Мендельсон (Noah Mendelsohn), Марк Ноттингем (Mark Nottingham), Херве Руеллан (Herve Ruellan), от 21 июля 2003г.

Черновой проект "Рекомендуемое приложение Infoset к SOAP-приложениям с вложениями" ("Proposed Infoset Addendum to SOAP Messages with Attachments"), Адам Босуорф (Adam Bosworth), Дон Бокс (Don Box), Мартин Гуджин (Martin Gudgin), Марк Джоунз (Mark Jones), Франц-Джозеф Фриц (Franz-Josef Fritz), Эми Леуис (Amy Lewis), Жан-Жак Моро (Jean-Jacques Moreau), Марк Ноттингем (Mark Nottingham), Дэвид Орчард (David Orchard), Херве Руеллан (HervГ© Ruellan), Джеффри Шлиммер (Jeffrey Schlimmer), Фолькер Вайхерс (Volker Wiechers), документ в стадии оформления.

Спецификация комитета UDDI организации OASIS "Справочник структуры данных для UDDI версия 2.03" ("UDDI Version 2.03 Data Structure Reference"), Клос фон Риген (Claus von Riegen) (редактор), от 19 июля 2002г.

Web-сайт Организации по развитию возможности взаимодействия Web-сервисов ().

Примечание консорциума W3C "Язык описания Web-сервисов 1.1" ("", Эрик Кристенсен (Erik Christensen), Франциско Курбера (Francisco Curbera), Грег Мередит (Greg Meredith), Саньива Веераварана (Sanjiva Weerawarana), от 15 марта 2001г.

Web-страница Рабочей группы консорциума W3C XML Protocol.

Оригинальный текст статьи можно посмотреть здесь:
A Preview of WS-I Basic Profile 1.1

document.write('');

Новости мира IT:

02.08 - 02.08 - 02.08 - 02.08 - 02.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 01.08 - 31.07 - 31.07 - 31.07 - 31.07 - 31.07 -

Архив новостей

Последние комментарии:

(66)

2 Август, 17:53

(19)

2 Август, 17:51

(34)

2 Август, 15:40

(42)

2 Август, 15:35

(1)

2 Август, 14:54

(3)

2 Август, 14:34

(3)

2 Август, 14:15

(2)

2 Август, 13:34

(7)

2 Август, 13:04

(3)

2 Август, 12:28

BrainBoard.ru

Море работы для программистов, сисадминов, вебмастеров.

Иди и выбирай!

Loading

google.load('search', '1', {language : 'ru'}); google.setOnLoadCallback(function() { var customSearchControl = new google.search.CustomSearchControl('018117224161927867877:xbac02ystjy'); customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET); customSearchControl.draw('cse'); }, true);

IT-консалтинг

Software Engineering

Программирование

СУБД

Безопасность

Internet

Сети

Операционные системы

Hardware

PR-акции, размещение рекламы — ,
тел. +7 495 6608306, ICQ 232284597

Пресс-релизы —

Указание вложений

Рассмотренные примеры позволяют Web-сервису описывать вложения, но это описание ничего не говорит о том, как указывать вложения из конверта SOAP (SOAP Envelope), а это самый обычный случай использования. Рассмотрим ситуацию, когда бинарные данные слишком велики, чтобы их встраивать в конверт SOAP. SwA позволяет передавать данные в качестве вложения, но их необходимо указывать из конверта SOAP. Благодаря такому подходу для более высоких уровней приложения неважно, встроены данные или отправлены как вложение. (Например, на Java для этого можно было бы воспользоваться javax.activation.DataHandler).

Basic Profile 1.1 решает проблему описания отношения указатель-указание, определяя тип swaRef во (временном) пространстве имен http://ws-i.org/profiles/basic/1.1/xsd (этот тип образован путем ограничения типа xsd:anyURI):

<xsd:schema targetNamespace="http://ws-i.org/profiles/basic/1.1/xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xsd:simpleType name="swaRef"> <xsd:restriction base="xs:anyURI" /> </xsd:simpleType> </xsd:schema>

Basic Profile 1.1 требует, чтобы значение этого типа было разрешено в пакете MIME, то есть URI, который является значением этого типа в реальном документе, должен разыменовывать часть MIME в том же самом пакете MIME.

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

В рассмотренном выше примере со стилем rpc/literal тип части photo-reference входного сообщения может быть изменен на swaRef. Аналогично, для примера с document/literal тип элемента photo-reference в разделе wsdl:types также может быть изменен на swaRef. Из-за того, что элемент photo-reference в конверте SOAP (SOAP Envelope) указывает на часть MIME в том же самом пакете MIME, можно снова говорить о факте доступности в этом описании WSDL. Пример rpc/literal может быть модифицирован для использования этого нового типа следующим образом (заметим, что префикс bp11 пространства имен привязан к URI для пространства имен http://ws-i.org/profiles/basic/1.1/xsd):

<wsdl:message name="msg-in"> <wsdl:part name="photo-reference" type="bp11:swaRef"/> <wsdl:part name="photo-attachment" type="xsd:base64Binary"/> </wsdl:message>

<wsdl:message name="msg-out"> <wsdl:part name="result" type="xsd:string"/> </wsdl:message>

<wsdl:portType name="my-portType"> <wsdl:operation name="my-operation"> <wsdl:input message="tns:msg-in"/> <wsdl:output message="tns:msg-out"/> </wsdl:operation> </wsdl:portType>

<wsdl:binding name="my-binding" type="tns:my-portType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="my-operation"> <soap:operation soapAction="http://example.com/soapaction"/> <wsdl:input> <mime:multipartRelated> <mime:part> <soap:body parts="photo-reference" use="literal" namespace="http://example.com/some-namespace"/> </mime:part> <mime:part> <mime:content part="photo-attachment" type="application/octetstream"/> </mime:part> </mime:multipartRelated> </wsdl:input> <wsdl:output> <soap:body use="literal" namespace="http://example.com/some-namespace"/> </wsdl:output> </wsdl:operation> </wsdl:binding>

Теперь процессор WSDL, обрабатывающий этот фрагмент кода WSDL, знает, что URI в теле SOAP (SOAP Body) является указанием на часть MIME в том же самом пакете MIME, и может генерировать соответствующие интерфейсы прикладного программирования для доступа к бинарным данным, которые отправляются как отдельная часть MIME. Ранее, когда тип swaRef еще не использовался, процессор WSDL не знал, разрешится ли значение URI в сообщении SOAP локально и разрешится ли вообще.

Включения, SwA и совместимость

По мере того, как Web-сервисы получает все большие применение в "серьезных" приложениях, важным становится наличие стандарта, который описывал бы совместимые вложения и согласовывался бы с спецификациями SOAP 1.1 и WSDL 1.1. Существует несколько причин, по которым требуется применять вложения при передаче больших объемов данных: как бинарных, так и других документов XML. К достоинствам использования вложений можно отнести небольшой размер сообщений, менее строгие требования к памяти, уменьшение времени обработки (отсутствует необходимость преобразовывать бинарные данные в base-64) и, самое главное, перемещение данных потоком (streaming). Вложения позволяют приложениям использовать соответствующие API (интерфейсы прикладного программирования) для обработки данных в потоковом режиме. Это существенно повышает производительность при пересылке в SOAP-конверте объектов BLOB и CLOB из базы данных приложения. Преимущества вложений подробно описаны в следующих документах: SwA, "SOAP 1.2 Возможность вложений" (SOAP 1.2 Attachment Feature), "XML, SOAP и бинарные данные" (XML, SOAP and Binary Data), "Рекомендуемое приложение Infoset к SOAP-приложениям с вложениями" (Proposed Infoset Addendum to SOAP Messages with Attachments) и "Механизм оптимизации передачи SOAP-сообщений" (SOAP Message Transmission Optimization Mechanism). Рабочая группа XMLP (XML Protocol) также занимается разработкой технологии вложений для SOAP 1.2.

Basic Profile 1.0 способствует поддержанию принципа совместимости на базовом уровне - SOAP 1.1, WSDL 1.1, UDDIv2 (см. "Спецификация интерфейса прикладного программирования для UDDI, версия 2.04" (UDDI Version 2.04 API Specification) и "Справочник структуры данных для UDDI версия 2.03" (UDDI Version 2.03 Data Structure Reference)) и т.д. Однако, единственное, что не было учтено в Basic Profile 1.0, это поддержка вложений. А ведь использование вложений влияет на совместимость Web-сервисов с точки зрения пакетирования (packaging), форматирования (formatting) и сериализации (serialization).

Наиболее широко применяемая и признанная технология включений - это MIME ( Multipurpose Internet Mail Extensions, Многоцелевые расширения электронной почты в сети Internet). SwA

комбинирует MHTML и CID для указания частей MIME в SOAP. В Basic Profile 1.1 в качестве технологии вложений была выбрана SwA, а для описания SwA - Раздел 5 "MIME Binding" WSDL 1.1. В Basic Profile 1.1, как и в предыдущей версии этого стандарта, уточняется, корректируется и выделяется ряд соответствующих спецификаций с целью повышения совместимости и устранения двусмысленности. То есть рассматривается проблема, с которой сталкивались разработчики и пользователи Web-сервисов при манипулировании большими объемами бинарных данных и их передаче в конвертах SOAP 1.1.

Направленность Basic Profile 1.1 совпадает с позицией, избранной Рабочей группой XMLP в отношении вложений для SOAP 1.2, как записано в Рабочей версии спецификации "Механизм оптимизации передачи SOAP-сообщений" (). Оба документа используют MIME и опираются на SwA. MTOM даже "идет дальше": он включает вложения как часть Infoset (поскольку SOAP 1.2 строится на Infoset), то есть модель обработки SOAP 1.2 также становится применимой к вложениям. Передаваемые сообщения в обоих случаях будут очень похожи. MTOM - это эволюционный подход в технологии вложений, подобный переходу от SOAP 1.1 к SOAP 1.2.

го августа 2003 г. представители

12- го августа 2003 г. представители организации WS-I (Web Services Interoperability Organization, Организация по развитию возможности взаимодействия Web-сервисов) объявили о выходе окончательной версии спецификации Basic Profile 1.0 - набора рекомендаций о том, как использовать стандарты Web-сервисов, чтобы улучшить совместимость. Для разработчиков, пользователей и поставщиков Web-сервисов и инструментов Web-сервисов это большой шаг вперед в достижении совместимости в стремительно развивающемся мире Web-сервисов. Однако, чем еще занималась эта организация?
Члены консорциума WS-I признают, что Basic Profile 1.0 - это только начало, предстоит долгий путь, пока Web-сервисы и их совместимость получат повсеместное распространение. В целях ускорения процесса признания Web-сервисов и продвижения принципа совместимости перед Рабочей группой Basic Profile, которая разработала одноименный документ, была поставлена задача по написанию следующей версии спецификации, в которой будет определено, как присоединять вложения (attachment). Так, в уставе
группы записано:
"Рабочей группе поручено разрешить вопрос о включении поддержки вложений в будущую редакцию Basic Profile, которая по причине минимального количества изменений будет именоваться Basic Profile 1.1. Она должна опираться на Basic Profile 1.0, а также:
Примечание W3C "SOAP-сообщения с вложениями" (SOAP Messages with Attachments) от 11 декабря 2000г."

Итак, спецификация Basic Profile 1.1, как следует из ее названия, это следующая версия Basic Profile 1.0. Ее основу составляет Basic Profile 1.0, в нее также добавляется поддержка Примечания "SOAP-сообщения с вложениями" (SOAP Messages with Attachments (SwA)) и Раздела 5 "Соединение MIME " (MIME Binding) из Примечания WSDL 1.1 (Web Services Description Language, Язык описания Web-сервисов). В рамках работы над этим документом Рабочие группы WS-I занимаются разработкой примеров приложений и инструментов тестирования для данной спецификации. Благодаря этому, на момент публикации окончательного варианта стандарта он получит необходимую апробацию и будет "отлажен". Как и нынешняя версия Basic Profile, эта редакция спецификации будет выпущена вместе с примерами приложений и инструментами тестирования.
Эта статья опирается на последний вариант Рабочей версии Basic Profile 1.1, написанием которой Рабочая группа занимается с января 2003г. В ходе работы над этим проектом члены группы выявили более 70 технических вопросов, которые требуют разрешения. "За бортом" осталось очень незначительное число вопросов. Повторимся, что в этой статье рассматривается Рабочая версия - в процессе разработки стандарта в некоторые ее разделы могут (и, наверняка, будут) внесены некоторые изменения.

одна из функциональностей, которая столь

Совместимые вложения - одна из функциональностей, которая столь необходима разработчикам и пользователям Web-сервисов. Рабочая группа Basic Profile решила эту проблему, включив SwA в Basic Profile 1.1, устранив двусмысленность и заполнив пробел в существующих спецификациях. Более того, Basic Profile 1.1 также позволяет средствам связывания языков генерировать соответствующие интерфейсы прикладного программирования, чтобы полностью реализовать возможности вложений.