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

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

Часть II Введение

В предыдущей статье ("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.

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