Logo    
Продукты, технологии Проекты, внедрения Новости мира IT Форумы Курилка Новые публикации Учебный центр
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware HOWTO

22.10.2004

[an error occurred while processing this directive]
Google
WWW CITForum.ru

2003 г

WSDL: взгляд изнутри, часть II

Дата: 24-06-2003
Автор: Джоан Питерз (Johan Peeters)
Перевод: Intersoft Lab

В предыдущей статье ("WSDL: взгляд изнутри, часть I") автор привел общее описание процесса проектирования Web-сервисов. В ней отмечалось, что Язык описания Web-сервисов (Web Services Description Language, WSDL) только определяет синтаксис того, как Web-сервис может быть вызван; он не говорит ничего о его семантике. В этой статье этот вопрос получит дальнейшее рассмотрение.

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

Инструменты

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

Модульные описания Web-сервиса

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

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

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

Элемент portTypes - это набор семантически связанных операций, во многом подобный интерфейсу в языке программировании. Элемент binding не обязан охватывать все элементы operation данного portType. Например, определенные в одном portType элементы operation могут использовать различные транспортные протоколы. Поскольку service - это набор элементов port, а port ссылается на отдельный binding, можно определять сервисы, которые не предлагают все operation, определенные в portType. Однако, наличие таких сервисов является признаком плохо разделенных элементов portType.

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

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

Описания Web-сервиса, как только они согласованы, должны быть зафиксированы. WSDL 1.1 предусматривает необязательное использование целевого пространства имен. Однако, удобно назначать пространство имен для недвусмысленной идентификации сервисов и их версий - как принято делать в случае спецификаций стандартов. Сложность состоит в том, что WSDL 1.1 не очень четок относительно того, что подразумевается под целевым пространством имен. Другими словами, что точно вкладывается в это понятие? По мнению автора, под ним понималось те же правила, что и в W3C XML Schema.

Напомним кратко эти правила: то, что помещается в целевое пространство имен регулируется атрибутом form в элементах element и attribute. При отсутствии такого атрибута управление передается набору значений по умолчанию в атрибутах elementFormDefault и attributeFormDefault, находящихся в корневом элементе schema. При отсутствии явного задания значений по умолчанию в силу вступают неявные значения по умолчанию: к пространству имен относятся только элементы, определенные глобально.

В каком виде эти правила W3C XML Schema нашли свое отражение в WSDL 1.1? Во-первых, в WSDL не задействованы элементы element и attribute. Во-вторых, элементами верхнего уровня в WSDL являются messages, portTypes, bindings и services, являющиеся сущностями (entity), которые должны быть помещены в целевое пространство. Очевидно, в данном случае type не релевантны. В-третьих, несмотря на то, что теоретически атрибут form мог бы использоваться с любыми элементами, определенными в WSDL, это не является принятой практикой. В-четвертых, аналогично сказанному, атрибуты elementFormDefault и attributeFormDefault могли бы использоваться в элементе definitions, но автор с этим не сталкивался.

Таким образом, можно утверждать, что все message, portType, binding и service оказываются в целевом пространстве имен, а их потомки - нет.

Удобно ли это правило? А имеет ли это значение? Это имеет смысл, когда сообщения зашифрованы так, что - за исключением этого правила - пространство описания Web-сервиса могло бы "просочиться" в сообщение. Действительно, автор потратил достаточно времени, чтобы выяснить, что пространства имен, которые находились в зашифрованном SOAP-сообщениях, не были в пространстве имен WSDL из-за того, что, согласно принятой, но обескураживающей практике, то же самое пространство имен используется в качестве входного для шифрования SOAP. Непосредственным результатом указанного правила пространства имен является отсутствие элементов и атрибутов сообщения в пространстве имен описания Web-сервиса, если только они не помещены туда пространством имен шифрования SOAP.

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

Обработка ошибок

Возможно, единственно наиболее важное отличие между демо- и готовым сервисом заключается в качестве обработки ошибок. Тем не менее, в литературе этому вопросу удаляется мало внимания.

Определение отдельных сообщений с целью установления различных сбойных ситуаций может быть удобно - структура таких сообщений может меняться согласно возникшей сбойной ситуации. В Листинге определен Web-сервис, который приведет в бешенство системных администраторов: он запускает двоичный код (binary), по запросу вызывающей программой. Читатель, возможно, будет разочарован, не обнаружив примеров использования пространств имен и разделения на модули - этот пример не рассматривает эти особенности. Он иллюстрирует обработку ошибок - при проектировании была предусмотрена возможность появления двух ошибок: первая - если недостаточно памяти, в этом случае возвращается область выделенной динамической памяти и количество используемой памяти; вторая - если программа попытается разыменовывать нулевой указатель, в этой случае возвращается запись стека.

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

Замысел, однако, намного яснее в первом документе. Разработчики клиентской реализации, работая со вторым документом вероятно смогут предположить, что может быть возвращено и сообщение OutOfMemoryException. Но из спецификации неясно, имеет ли это значение. Также они не могут быть уверенными, что код клиентской реализации охватывает все сбойные ситуации, поскольку абстрактный класс tException может быть расширен типами, отличными от перечисленных во втором документе.

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

document/literal против rpc/encoded

Здравый смысл предписывает использовать текстовый формат передачи при вызове документа и кодированный при использовании RPC (Remote Procedure Call, Удаленный вызов процедуры). Однако, фундаментальных причин, почему необходимо следовать этому правилу, нет - это скорее исторически сложившиеся стечение обстоятельств, что инструменты, как правило, поддерживают эти комбинации.

Выбор осуществляется между сложностью модели программирования и сложностью маршалинга (marshalling) сообщений. RPC предлагает удобную модель программирования. Она не без изъянов, как отмечалось в предыдущей статье. Однако, также важно знать об обязательствах, которые форматы передачи, используемые с RPC, накладывают на маршалеров: различие между literal и encoded - это различие между составителем и читателем. Это означает, что у второго формата передачи может быть множество различных представлений для семантически эквивалентных сообщений.

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

Что можно ожидать

Как уже отмечалось, WSDL 1.1 не имеет статуса стандарта. И все же эта спецификация широко используется, часто не оправдывая надежд на возможность взаимодействия. Именно это и является причиной появления Организации по развитию возможности взаимодействия Web-сервисов (WS-I) - не получить право собственности на стандарт WSDL, а определить очертания, "состоящие из набора некоммерческих спецификаций Web-сервисов наряду с уточнениями и поправками к тем спецификациям, которые способствуют возможности взаимодействия".

Конечно, наличие еще одной организации стандартизации вызывает раздражение. Несмотря на заявленные цели, автор не может отделаться от ощущения, что деятельность организаций, схожих с WS-I, может привести к появлению взаимоисключающих стандартов. Тем не менее, он посоветовал бы ознакомиться с разделом 5 "Рабочего проекта принятия Basic Profile" (Basic Profile Approval Draft), в котором содержатся отличное разъяснение некоторых "дыр" WSDL 1.1. И все же автор не одобряет то, что организация уделяет максимум внимания SOAP.

В предыдущей статье также говорилось о Техническим комитете OASIS "Защищенность Web-сервисов" (OASIS WSS TC), который, кажется, становится лидером в области определения стандартов защищенности Web-сервисов. Это еще одна организация, которая решает часть поставленной выше задачи. Но смогут ли подойти друг к другу эти части, и кто собирается их объединять?

Право собственности на будущие версии WSDL, похоже, однозначно остается у консорциума W3C, где Рабочая группа по описанию Web-сервисов (Web Service Description Working Group) занята написанием WSDL 1.2. Согласно ее уставу, выход этой версии запланирован на май 2003 года. Эта срок, очевидно, будет сорван. Тем не менее, группа время от времени публикует рабочие проекты будущей редакции. Так, что же будет со "слабыми сторонами" WSDL , о которых шла речь выше?

Если судить по проекту, доступному на момент написания этой статьи, похоже, подтверждается интерпретация того, что происходит в целевом пространстве имен описания Web-сервисов. В нем говорится, что "информационная единица атрибута targetNamespace определяет присоединение пространства имен для компонентов верхнего уровня, определенных в этой информационной единице элемента definitions. Сообщения, типы порта, связывания и сервисы являются компонентами верхнего уровня". Будет ли WSDL 1.2 поддерживать реализацию нескольких интерфейсов является предметом жарких дебатов. В проекте WSDL 1.2 явно указано, что для используемых пространств имен с импортированными документами применяются те же правила как и в XML Schema. С другой стороны, альтернативный подход по разделению описаний на модули обеспечивается посредством элемента include, моделируемого по элементу include XML Schema, который не допускает совместного использования пространств имен.

Благодарности

XML Spy - зарегистрированная торговая марка компании Altova. Как обычно, особая благодарность Кэролайн Гринмен (Caroline Greenman) за критические замечания.

Ресурсы

Ценную информацию о WSDL можно почерпнуть из следующих материалов:

  • "Краткое (не совсем ) и неформальное (действительно) руководство по WSDL от Ярона" (Yaron's (not so) Quick and (really) Dirty Guide to WSDL);
  • "Толкование Языка описания Web-сервисов WSDL" (Web Services Description Language (WSDL) Explained);
  • "Обычные ошибки WSDL" (Common WSDL Errors).

Крепким духом и не только стоит прочитать "Примечание WSDL 1.1" консорциума W3C (WSDL 1.1). Обратите внимание на раздел 5 "Рабочего проекта принятия Basic Profile" (Basic Profile Approval Draft), поскольку в нем поясняются многие положения WSDL 1.1. Рабочая группа по описанию Web-сервисов (Web Service Description Working Group) занимается написанием спецификации WSDL 1.2. Время от времени группа публикует редакции рабочего проекта.

Оригинальный текст статьи можно посмотреть здесь:
WSDL Tales From The Trenches, Part 2

Ближайшие курсы Центра Информационных Технологий:

25-28 октября 2004, Москва
Введение в объектно-ориентированный анализ и проектирование и унифицированный процесс разработки программного обеспечения c использованием языка UML и CASE-средства IBM Rational Rose

1-4 ноября 2004, Москва
Современные технологии анализа и проектирования информационных систем

1-5 ноября 2004, Москва
Основы передачи данных

9-10 ноября 2004, Москва
Основы моделирования бизнес-процессов и спецификации требований к ПО

Подписка на новости библиотеки:

Новые поступления в on-line библиотеку:

19 октября

  • Функциональная безопасность программных средств
  • Технологические процессы и стандарты обеспечения функциональной безопасности в жизненном цикле программных средств
  • Так как же восстановить данные таблицы?
  • Использование CAST и табличных функций в PL/SQL

    14 октября

  • Разрезая биллионы
  • Платформа, которой не существует
  • Intel 9xx: время тестов
  • Сбалансированная система показателей: краткий обзор рынка программного обеспечения
  • Кросс-браузерность: теория и практика

    12 октября

  • В борьбе за каждый миллиметр
  • Хранилища данных и семантические разрывы
  • BI и ССП: связь между ними
  • Десять заповедей резервного копирования

    7 октября

  • XML-СУБД Sedna: технические особенности и варианты использования
  • Хранилище данных: вопросы и ответы
  • Порядок разработки ETL-процессов

    5 октября

  • Использование сокетов в Delphi
    Часть первая: стандартные сокеты
    Часть вторая: сокеты Windows
  • Задачи и аналитическая платформа для ВРМ
  • Методики, технологии и инструменты ВРМ
  • Выбор системы управления эффективностью бизнеса: решающие факторы

    30 сентября

  • MySQL: Руководство разработчика
  • MySQL: Руководство по ODBC и MyODBC

    28 сентября

  • СУБД ЛИНТЕР. Технический обзор
  • Новое в СУБД ЛИНТЕР 6.1
  • Использование ЛИНТЕР в качестве встроенной СУБД

    21 сентября

  • Материалы книги П.Б.Храмцова "Система доменных имен"
  • Храните свои терабайты в ящике
  • Тестирование контроллеров iSCSI
  • Девять ошибок, которые могут помешать работе SAN

    16 сентября

  • Курс лекций В.В.Воеводина "Параллельная обработка данных"
  • Заморочки от Oracle, или знать бы, где упасть
  • Реинжиниринг: многое в малом
  • CASE-технологии: что, когда, как?

    14 сентября

  • Сильнее угроза - крепче защита (обзор 16 инструментов)
  • GnuPG - OpenSource шифрование и цифровые подписи
  • Оптимизация не-HTML-сайтов для поисковых серверов
  • Новые графические супер-карты от ATI и NVidia
  • Новая жизнь Ethernet

    9 сентября

  • Экстремальное программирование и быстрая разработка ПО
  • 64 бита - "народные" и не очень
  • Рынок ЖК-дисплеев: компании меняют приоритеты
  • Футбольный стадион на рабочем столе

    7 сентября

  • Методология оценки безопасности информационных технологий по общим критериям
  • MySQL Administrator - рулить СУБД легко
  • Взгляд на Windows через лупу
  • Все яйца в одном лукошке
  • Жесткие диски: любимая емкость

    2 сентября

  • Обзор внешних жестких дисков
  • Техника безопасности в беспроводном мире
  • Добавляем в компьютер USB
  • OpenGL и Delphi на практике
  • OpenGL: раскрой глаза на трехмерную графику
  • Иллюзии и реалии безопасности (обзор журнала Computer)

    31 августа

  • Ipsysctl tutorial 1.0.4
  • От включения питания до приглашения Bash
  • OpenBSD - заметки конечного пользователя
  • Запуск Linux-приложений из FreeBSD

    24 августа

  • О системных таблицах InterBase
  • О blog-ах замолвим пару словечек
  • Что такое RSS?
  • Разгон... Sound Blaster'а

    19 августа

  • Введение в Delphi 8
  • Парное тестирование - возьмем от ХР лучшее
  • XML-RPC: вызов процедур посредством XML
  • Связь и интернет для всей планеты
  • Сети для ловли будущего
  • Три кита будущей беспроводной свободы

    17 августа

  • Стеганография. Особенности использования программ на основе метода наименьшего значащего бита
  • Ping своими руками
  • Спецификации XML 1.1 и "Пространства имен 1.1"
  • Что нового в WSDL 2.0

    11 августа

  • Информационная безопасность в современных системах управления базами данных
  • Методические рекомендации №1 "О порядке автоматизации отчетности по МСФО"
  • Черводинамика: причины и следствия
  • Оживляем веб-страничку
  • Тихий ПК: несколько простых способов избавиться от компьютерного шума

    10 августа

  • Полезные советы по Windows XP
  • Oracle и Perl - это очень просто

    9 августа

  • Проблемы при восстановлении и их решение
  • Восстановление сервера с помощью onbar и ISM
  • Настройка диспетчера хранения данных ISM

    5 августа
    Виктор Костромин. "Linux для пользователя"

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware HOWTO

    Реклама на IT-портале citforum.ru

    Нестандартные PR-акции - pr@citforum.ru
    Пресс-релизы и информация в каталог компаний - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав.