WSDL

Задачи

Стандартизированное описание упрощает понимание и применение. Допустим, что вы нашли сервис, который решает необходимые вам задачи, и хотите его использовать в своих решениях. Самый простой способ получить информацию о чужой разработке и ее возможностях — взглянуть на WSDL-описание. Документы WSDL могут состоять из нескольких модулей или ссылаться на другие документы либо XML-схемы (XSD), которые описывают типы данных, используемые в веб-сервисе. Изначально было предложено несколько вариантов ведения описания, и два крупных игрока — Microsoft и IBM — познакомили со своим видением данной проблемы. Первая разработала и предложила язык SDL (Service Description Language), который был включен в состав первой версии SOAP Toolkit этой компании. IBM явила свое видение проблемы в Network NASSL (Accessible Service Specification Language), которая была реализована в SOAP4J в виде набора NASSL Toolkit. Идеи, предложенные в NASSL, вдохновили Microsoft на продолжение развития языка описания, в результате чего на свет появился SOAP Contract Language (SCL). Это решение оказалось очень эффективным, его доработали с учетом пожеланий сторонних производителей, и 15 марта 2001 года идеи превратились в спецификацию WSDL 1.1. Конечно же столько лет без изменений компьютерная область жить не может, поэтому 27 марта 2006 года появилась версия 2.0, а с 26 июня 2007 года она носит рекомендательный характер.

Справочник команд Unix/Linux

История

WSDL 1.0 (Сент. 2000) был разработан IBM, Microsoft и Ariba для описания веб-сервисов для SOAP toolkit.

WSDL 1.1, выпущен в марте 2001. Фактически это формализованный WSDL 1.0. Между этими версиями нет никаких принципиальных отличий.

WSDL 1.2 (Июнь 2003) по прежнему работает под W3C. WSDL 1.2 не поддерживается большинством вендоров SOAP.

WSDL 2.0 получил официальную поддержку W3C в июне 2007. WSDL 1.2 был переименован WSDL 2.0 поскольку имел большие отличия от предыдущей версии.

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

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

Другими словами, они ослабляют безопасность, предоставляя посторонним лицам доступ к приложениям - именно то, чему сетевой брандмауэр должен был бы воспрепятствовать. Поэтому необходимо новое поколение брандмауэров. На рынке уже появилось несколько новых игроков, предлагающих такие продукты. Поставщики обычных брандмауэров также начинают обращать внимание на эту проблему. Но это только начало, и такая технология должна еще оправдать себя. Даже если предполагается применять Web-сервисы, необходимо помнить, что необязательно использовать SOAP. Например, автор статьи видел формы, передаваемые как аргумент запроса на удаленный вызов процедуры SOAP (SOAP-RPC). Ему также попадались формы, которые возвращались как часть ответа удаленного вызова процедуры SOAP. Он так и не смог найти дополнительную пользу от применения SOAP. Если распределенные компоненты могут разрабатываться на различных языках программирования, то для того, чтобы указать, как должны быть задействованы сервисы, необходим Язык описания интерфейсов (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 силен в синтаксисе и слаб в семантике. Однако, не стоит им пренебрегать - в конечном счете важна именно семантика, синтаксис же используется просто, чтобы ее раскрывать.

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

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

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

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

См. также

SOA

Источник

WSDL: взгляд изнутри