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

Автор выражает глубокую благодарность Марку Портайеру (Mark Portier) и Кэролайн Гринмен (Caroline Greenman) за их конструктивные замечания.

Недопустимость генерации WSDL

Ответим на вопрос: предназначен ли WSDL 1.1 для восприятия человеком. Типичный совет - генерировать WSDL, а не писать вручную. Автор по этому вопросу придерживается следующего мнения. Возможно, это и верно, если таким образом разрабатывается простой, демонстрационный сервис, но данный подход обречен на провал, когда он применяется к крупным системам. Даже программист, работающий самостоятельно, быстро утратит общее представление о проблеме; ситуация усложняется если разработку совместно ведут различные, территориально разнесенные группы специалистов. Большие распределенные системы требуют проектирования; ожидание того, что после объединения они будут совместно работать, приведет к катастрофе.

Если распределенные компоненты могут разрабатываться на различных языках программирования, то для того, чтобы указать, как должны быть задействованы сервисы, необходим Язык описания интерфейсов (Interface Definition Language, IDL), нейтральный по отношению к языку программирования. У CORBA (Общая архитектура посредника запросов к объектам, Common Object Request Broker Architecture), как и у DCOM (Распределенная модель компонентных объектов, Distributed Component Object Model), такой язык есть. IDL - это контракт между инициатором на обслуживание и поставщиком, но он только собирает синтаксис. Семантика остается неосвещенной: IDL оставляет открытым вопрос о том, что делает сервис.

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

Непрозрачность сети

Сеть не является прозрачной - вызов локального сервиса и его удаленный вызов существенно отличаются друг от друга. В качестве "памятки разработчику" можно порекомендовать тезисы Питера Дойча (Peter Deutsh) "Восемь заблуждений о распределенной обработке данных" ().

Неверная семантика различна для сетевого окружения и локальной реализации: при неудачном вызове не всегда известно, исполнился сервис или нет.

WSDL 1.1 описывает следующие виды вызовов: односторонний (one-way), запрос-ответ (request-response), ответ на требование (solicit-response) и уведомление (notification). Однако, связывания WSDL поддерживают только односторонний вызов и вызов вида запрос-ответ. Также следует понимать, что реально, а что - нет. Другими словами, сегодня невозможно реализовать ситуацию, когда клиент ожидает с сервера асинхронное получение практического, "промышленного качества" и согласованного со стандартами результата. Это следует расценивать как досадное обстоятельство, поскольку это именно тот механизм, который является наиболее гибким в ситуации частичного сбоя.

WSDL позволяет перемешивать и согласовывать виды вызова и транспорт (transport). На этом этапе важно прибегнуть к здравому смыслу. Первое требование - а это не всегда очевидно - необходимо четко представить, как стек протоколов предлагаемого Web-сервиса будет себя вести. В качестве примера рассмотрим, что случится если асинхронно вызвать Web-сервис поверх механизма синхронного транспорта. Предположим, что SOAP-сообщение пересылается в одну сторону по HTTP: бизнес логика на клиенте формирует SOAP сообщение, чтобы вызвать удаленный сервис. В результате запрос HTTP посылается на сервер. Когда сервер получает запрос, он должен немедленно возвратить ответ HTTP, не обслуживая этот запрос. Бизнес логика на сервере должна отрабатывать после того, как этот ответ был возвращен. Этот ответ не должен содержать SOAP-сообщение. Ответ HTTP с кодом состояния 200 или 202 не означает, что сервис успешно отработал.
Код сбоя, с другой стороны, должен гарантировать, что вызов сервиса не исполнился. Слой SOAP на клиенте не формирует новых сообщений до тех пор, пока он не получит ответ, или пока не истечет время ожидания.

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

Используя HTTP в в качестве транспортного протокола, клиент может быть уверен, что его запрос был доставлен. Стоит заметить, однако, что если клиент не получил ответ, это не значит, что сервер не получил и не обработал корректно этот запрос. Например, сеть может "упасть" во время отправки ответа. Другими словами, реализовать вызов просто, правильно завершенный вызов - нет.

Определение ограниченных интерфейсов

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

Типичная ошибка, совершаемая при реализации серверных систем, - установление соединения с базой данных при каждом запросе к этой базе. Автор совершил такую ошибку - выяснилось, что установление соединения с базой данных занимает больше времени, чем все остальное, вместе взятое. Чтобы минимизировать это падение производительности, можно прибегнуть к одному из двух приемов: воспользоваться пулом соединений (connection pool) или хранимой процедурой.

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

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

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

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

Отличие Web-сервисов от распределенных объектов

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

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

Проектирование интерфейсов

Прежде чем приступить к написанию WSDL, необходимо оговорить с заказчиками то, что Web-сервис должен делать. Следует записать случаи использования, четко определив, как этот сервис взаимодействует со своей средой. Предположим, что программа-агент (actor) с какой-либо целью вызывает Web-сервис. В этом случае, нужно создать не только сценарий "солнечного дня", который реализует поставленную задачу, но сценарий "дождливого дня", когда результат отрицательный. Какие гарантии может предложить система, что цель успешно достигнута? А когда нет? Где находится граница ответственности клиентской части и сервера?

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

Например, рассмотрим Web-сервис, который в качестве параметров принимает список установленных программ и величину свободного места на диске. Затем этот сервис должен вернуть список приложений, подлежащих обновлению. В случае если места достаточно, проблем не возникает. Однако, как быть, если его недостаточно? Как выбрать продукты, для которых необходимо установить новые версии? Предполагается ли, что клиент сам удаляет старые редакции программ, чтобы освободить место для новых? Это непростые вопросы, для решения которых потребуется разрабатывать сложные алгоритмы, при реализация которых не исключены ошибки. Разумеется, ни одну систему не следует определять подобным образом. Сервер должен предоставлять список приложений, зависимости между ними и требования, которые они предъявляют к ресурсам. Решение же о том, какой пакет установить, является задачей клиента. Поэтому поручив серверу это задание, клиент ничего не выиграет, он только повысит затраты на разработку серверной части.

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

Следующий шаг - проанализировать, как можно реализовать случаи использования. Будет ли единственный интерфейс (portType в WSDL версии 1.1), обеспечивающий всю функциональность? Или несколько интерфейсов? Каждый интерфейс может быть предложен в нескольких конечных точках, но, как правило, он должен быть неделимым. То есть конечная точка должна предоставлять либо всю функциональность, либо ничего. Аналогично, интерфейс должен быть семантически последовательным. Сказанное носит рекомендательный характер и опирается на здравый смысл, хотя ничто в спецификации WSDL не препятствует иной интерпретации.

Требуются ли какие-нибудь поддерживающие интерфейсы? Как и когда они должны вызываться? Какова природа этой зависимости? Пока нет стандартов, а только рекомендации о том, как обращаться с "хореографией сервисов" (service choreographies), как разрешать сервисам выполнять гиперссылки к другим сервисам. Другими словами, это неисследованная проблемная область.

Возвращает ли разрабатываемый сервис результат клиенту? Должен ли клиент располагать информацией о том, что сервис успешно отработал? Должен ли клиент вызывать сервис синхронно? Или асинхронно? Или же сервис будет поддерживать оба типа вызова?

Проектирование Web-сервисов

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

Тезис о том, что Web-сервисы являются "дружественными по отношению к брандмауэру" ("firewall friendly"), обманчив. Действительно, обычные брандмауэры оберегают корпоративные ценности от "злоумышленников", которые используют слабые места в прикладном программном обеспечении, появившиеся в результате открытия портов, на которых исполняются защищённые сервисы. С другой стороны, Web-сервисы через этих порты "выставляют" прикладное программное обеспечение. Другими словами, они ослабляют безопасность, предоставляя посторонним лицам доступ к приложениям - именно то, чему сетевой брандмауэр должен был бы воспрепятствовать. Поэтому необходимо новое поколение брандмауэров. На рынке уже появилось несколько новых игроков, предлагающих такие продукты. Поставщики обычных брандмауэров также начинают обращать внимание на эту проблему. Но это только начало, и такая технология должна еще оправдать себя.

Даже если предполагается применять Web-сервисы, необходимо помнить, что необязательно использовать SOAP. Например, автор статьи видел формы, передаваемые как аргумент запроса на удаленный вызов процедуры SOAP (SOAP-RPC). Ему также попадались формы, которые возвращались как часть ответа удаленного вызова процедуры SOAP. Он так и не смог найти дополнительную пользу от применения SOAP. Разве не был бы проще обыкновенный XML или HTML через HTTP?

Разделение проектирования и реализации

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

Разнесение бизнес логики и политики

Не следует реализовывать аутентификацию и авторизацию в бизнес логике. Безопасность транспортного уровня может быть как удовлетворительной, так и нет. В разделе приведены ссылки на статьи, в которых рассматривается этот вопрос. Даже если безопасность транспортного уровня и не урезается, все равно пока нет стандартов - они только разрабатываются, и из них стоит отметить создаваемые Техническим комитетом OASIS "Защищенность Web-сервисов" (). Предлагаемые подходы действительно способствуют разделению бизнес логики и политики (policy): заголовки SOAP вставляются в сервис, чтобы обеспечить характеристики безовасности, а информативная часть сообщения сохраняется для бизнес логики.

Но как же без ложки дегтя - предлагаемый стандарт применим только к Web-сервисам, использующим SOAP. Еще одна неприятность - отсутствие стандартизированного способа указать Качество защиты (Quality of Protection, QoP) сервиса в документе WSDL. Microsoft, BEA, SAP и IBM опубликовали спецификацию для "Приложений политики Web-сервисов" (), в которой рассматривается этот вопрос. Насколько известно автору, этот документ еще не был передан ни в один орган стандартизации.

Ресурсы

"Мыльная опера" на тему защищенность Web-сервисов будет продолжаться еще долго. Ниже приведено "содержание первых серий":

В цикле статей "Защищенность Web-сервисов" () Билала Сиддикуи (Bilal Siddiqui) описывается "дырка", которую создали основанные на SOAP Web-сервисы;

В своей статье "Web-сервисам необходим брандмауэр" () Керри Чемпион (Kerry Champion) выступает за использование брандмауэров XML;

В статье "Брандмауэры XML" () Престона Гралла (Preston Gralla) содержится упоминание о некоторых текущих коммерческих реализациях;

Спецификация "Ценные качества Web-сервисов" () разрешает все известные проблемы защищенности.

В статье "IDL, которого нет" () Мартина Гуджина (Martin Gudgin) и Тимоти Иуолда (Timothy Ewald) приводится более глубокий анализ WSDL с позиций IDL.

В белой бумаге "Кто пишет контракты Ваших Web-сервисов" () корпорации Karniak рассказывается о том, как точное описание упрощает процесс разработки Web-сервиса.

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

Автор: Джоан Питерз (Johan Peeters)

Перевод:

Недавно автору статьи довелось использовать язык WSDL (Web Services Description Language, Язык описания Web-сервисов) для нескольких существующих Web-сервисов - на одном клиенте работал сервер и клиентская реализация. У этого клиента и специалистов по обслуживание сервера уже сложились тесные рабочие отношения, но наступил момент, когда возникла необходимость в еще одной клиентской реализации, которую должна была выполнить группа разработчиков, находящихся в противоположенной точке земного шара. В связи с этим потребовалась четкая спецификация, описывающая такие сервисы, а именно для этого и предназначен WSDL. Поэтому автор вознамерился основательно изучить то, что ранее не было достаточно освещено. В результате, он приобрел ценный опыт - ему удалось вспомнить старую и добрую практику проектирования программного обеспечения и обнаружить ряд проблем, характерных для Web-сервисов, WSDL и XML Schema.

В самом начале, на этапе проектирования, было допущено несколько ошибок, которые изначально трудно заметить. Вероятно, эти недочеты не были бы допущены, если бы проектировщики дали формальное определение для своих сервисов на WSDL. Так что, вот основная мысль этих двух статей: пишите WSDL заранее, не генерируйте его потом, как это часто советуют поставщики.

При всем внимании, которым были одарены Web-сервисы, часто сложно отделить желаемое от действительного. В предлагаемом цикле статей акцент будет сделан на реальном, а не на потенциальном. В них читатель не найдет краткого обзора WSDL, кроме того предполагается, что он знаком с W3C XML Schema. В первой статье рассказывается, чем могут быть полезны при проектировании Web-сервисов практика проектирования программного обеспечения и опыт в области распределенной обработки данных. В ней рассматриваются некоторые решения, которые должен принимать проектировщик Web-сервисов, приводятся необходимые советы и рекомендации. В остальных статьях будет описан процесс проектирования: во второй статье будут перечислены некоторые "темные стороны" спецификации WSDL 1.1. В нее не войдут определения типов данных - темы третьей статьи, в которой будет представлена W3C XML Schema с позиции того, кто использует ее для определения данных, передаваемых через интерфейсы Web-сервисов.

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

Как уже отмечалось, 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, который не допускает совместного использования пространств имен.

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

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

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

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

Инструменты

Перед тем, как вдаваться в подробности, давайте рассмотрим инструмены, которые могут помочь. Во-первых, при написании 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-сервис, который приведет в бешенство системных администраторов: он запускает двоичный код (binary), по запросу вызывающей программой. Читатель, возможно, будет разочарован, не обнаружив примеров использования пространств имен и разделения на модули - этот пример не рассматривает эти особенности. Он иллюстрирует обработку ошибок - при проектировании была предусмотрена возможность появления двух ошибок: первая - если недостаточно памяти, в этом случае возвращается область выделенной динамической памяти и количество используемой памяти; вторая - если программа попытается разыменовывать нулевой указатель, в этой случае возвращается запись стека.

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

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

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

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

Описания 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 не разрешает импортирующей и импортируемой схеме совместно использовать пространство имен. По оценке автора, это очень удобное правило, поскольку сложно рассуждать о пространстве имен, если нет уверенности, что определение полное.

Ресурсы

Ценную информацию о 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

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.

Корпоративные сайты и порталы

Андрей Беляев,

Подготовлено: по материалам зарубежных сайтов
Перевод:
Авторские права:

Кристиан Веже,

Михаил Евдокимов, КомпьютерПресс 6'2001

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

Андрей Щербина, Открытые системы, #04/2003

П. В. Федосеев

Статья посвящена Microsoft Commerce Server, продукту, предназначенному для быстрого создания комплексных программных решений для электронной коммерции. Commerce Server содержит комплекс средств для построения business-to-customer (B2C) и business-to-business (B2B) систем.

, Открытые системы, #06/2003

, Открытые системы

Алексей Рындин (Главный инженер проектов), http://www.jetinfo.ru/

Web-сервисы

Александр Симаков, alexander-simakov.blogspot.com

, ведущий консультант-разработчик IBS Borlas
Источник:

An Oracle White Paper, перевод

Oracle Magazine/RE

Джером Джозефрай (Jerome Josephraj)
Перевод:

Мнение аналитиков IDC

по материалам зарубежных сайтов ,

, старший редактор издательства Oracle Publishing.
Перевод Oracle Magazine RE

, главный менеджер по продукту Oracle Application Server Containers for J2EE.
Перевод Oracle Magazine RE

Олег Ремизов,

Евгений Веселов, Михаил Голованов,

Дэвид Орчард,

, перевод:

, ,ФГУП Воткинский завод,

, Ижевский Государственный Технический Университет

Джоан Питерз (перевод )

Билал Сиддикуи (перевод )

Подготовлено по материалам зарубежных сайтов

Дэн Эверет (перевод )

Шейн Куркуру (Shane Curcuru) (Перевод: )