Что такое WSDL файл?
Язык описания web-сервисов WSDL
Язык описания веб-сервисов WSDL (Web Services Description Language) основан на языке XML. В июне 2007 года была утверждена WSDL 2.0 в качестве стандарта W3C (World Wide Web Consortium), но несмотря на это версия WSDL 1.1 остается широко используемой формой описания Web-сервисов SOAP. WSDL 1.1 имеет определенные недостатки, включающие чрезмерно сложную структуру. Это серьезно затрудняет его чтение для начинающих.
На рисунке, позаимствованному из Wikipedia, представлены структуры WSDL для версий 1.1 и 2.0.
WSDL 1.1
В WSDL документах версии 1.1 используется корневая секция с названием , включающая один «пассивный» дочерний элемент (ссылка на отдельные документы WSDL 1.1) и пять «активных» дочерних элементов, составляющие описание сервиса :
| Тег/секция | Назначение | Примечание |
|---|---|---|
| wsdl:import | Секция отдельного документа WSDL 1.1 | Отдельный документ WSDL 1.1 с описаниями, включаемый в текущий документ |
| wsdl:types | Секция определения типов данных | Определение вида отправляемых и получаемых сервисом XML-сообщений |
| wsdl:message | Секция элементов данных | Описание используемых Web-сервисом сообщений |
| wsdl:portType | Секция абстрактных операций | Список операций, которые могут быть выполнены с сообщениями |
| wsdl:binding | Секция связывания сервисов | Описание способов доставки сообщений |
| wsdl:service | Секция определения сервиса | Описание сервиса в целом, как правило, включая один или несколько элементов с информацией доступа для элементов |
Первым дочерним элементом секции для документирования может быть использован не представленный в таблице элемент . Данный тег может быть также использован также для документирования любого из элементов описания сервиса.
Для полного описания сервиса требуется один элемент каждого из представленных в таблице типов, за исключением . Но не обязательно, чтобы все они находились в одном и том же документе. Элемент позволяет собирать полное описание WSDL из нескольких документов. Три элемента описания ( , и ) формируют полное описание интерфейса сервиса. Элементы и ориентированы на реализацию элементов сервиса.
Пример WSDL 1.1
На странице описания клиентов SOAP были использованы действующие WEB-сервисы получения значений кодов ZIP города Нью-Йорк и информации сервиса BELAVIA. В качестве примера описания WSDL рассмотрим WEB сервис BELAVIA. Следующий листинг представляет структуру сервиса wsdl :
Структура WSDL сервиса BELAVIA
Описания сервиса WSDL представлено одним документом и не включает секцию . В корневой секции определяются именованные пространства, используемые при описании элементов документа.
Секция включает используемые для сообщений определения XML в виде одного или нескольких элементов . WSDL допускает альтернативы XML-схеме для этих определений, но большинство стеков поддерживает только XML-схемы. При необходимости элементы могут включать или для вставки внешних по отношению к WSDL других схем. В листинге приведен усеченный перечень элементов секции .
Компонентам документа WSDL присваиваются отдельные имена с использованием атрибута name. При использовании в корневом элементе документа атрибута targetNamespace, имена этих компонентов определены в этом пространстве имен. Это означает, что при определении имени достаточно присвоить простую, или «локальную», часть имени, но ссылки на этот компонент должны уточнять имя с помощью префикса пространства имен или с помощью пространства имен по умолчанию.
Представленные элементами сообщения расположены в ядре описаний сервисов WSDL. Элементы являются описаниями XML-данных, передаваемых между клиентом и поставщиком услуг. Каждый элемент содержит, как правило, один дочерний элемент , для которого требуется собственный уникальный в пределах атрибут name и один из атрибутов element или type, ссылающийся на определение схемы XML-данных.
Элементы определяют абстрактный интерфейс сервиса в части сообщений, передаваемых сервису и принимаемых от него, и содержат любое количество дочерних элементов . Дочерний элемент имеет собственный атрибут name и включает один или несколько дочерних элементов с описанием сообщения. В зависимости от способа использования могут быть включены следующие типы дочерних элементов :
- — входные данные, отправляемые клиентом поставщику услуг;
- — возвращаемые клиенту поставщиком услуг данные;
- — возвращаемые клиенту поставщиком услуг данные при возникновении ошибки.
WSDL 1.1 определяет две модели взаимодействия клиента и поставщика услуг, представленных различными последовательностями дочерних элементов и : операций типа запрос-ответ, где за следует , и односторонние операции, содержащие только . В случае операций типа запрос-ответ за элементами и может следовать любое количество элементов .
Каждый элемент , или включает ссылку на описание сообщения в виде обязательного атрибута message. В данной ссылке уточняется пространство имен добавлением префикса.
Если рассмотреть элемент с точки зрения Java как определение интерфейса, то элементы будут эквивалентны методам, включающим в качестве параметров элементы ; элементы будут определять результаты выполнения методов, а соответствовать исключениям. Этот подход используется при генерировании кода Java из WSDL.
Дочерние элементы содержат информацию о способе реализации. Элементы из пространства имен WSDL соответствуют элементам и должны использовать то же значение name – а не ссылки с уточнением пространства имен, как в случае . Та же связь по имени относится и к дочерним элементам / / элементов . Несмотря на повторное использование одних и тех же имен элементов, содержание этих элементов существенно отличается для дочерних элементов относительно элементов .
Расширения, определяемые WSDL, вступают в игру в . Дочерний элемент используется в определении сервиса SOAP и включает обязательный атрибут transport для определения вида транспорта, используемого привязкой. Необязательный атрибут style позволяет выбирать способ rpc или document для представления XML-данных. Наиболее распространенное значение document соответствует сообщениям с использованием элементов определения схемы, а не типа.
Элемент включает дочерние элементы внутри которого
- тег используется для значения SOAPAction с целью идентификации запросов,
- дочерние элементы / / содержат теги , указывающих, что данные сообщения передаются в теле сообщения SOAP.
Последним компонентом описания сервиса WSDL является элемент который состоит из группы элементов . Каждый элемент связывает адрес доступа с . Адрес доступа определяется атрибутом тега .
WSDL 2.0
Описание документа WSDL 2.0 на странице не приводится, но желающие могут ознакомится с англо-язычной версией здесь.
Веб-сервисы в теории и на практике для начинающих
Что такое веб-сервисы?
Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.
Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.
С другой стороны, если гипотетически разделить Интернет на несколько слоев, мы сможем выделить, как минимум, два концептуальных типа приложений — вычислительные узлы, которые реализуют нетривиальные функции и прикладные веб-ресурсы. При этом вторые, зачастую заинтересованы в услугах первых.
Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.
Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.
По сути, веб-сервисы — это реализация абсолютно четких интерфейсов обмена данными между различными приложениями, которые написаны не только на разных языках, но и распределены на разных узлах сети.
Именно с появлением веб-сервисов развилась идея SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture).
Протоколы веб-сервисов
На сегодняшний день наибольшее распространение получили следующие протоколы реализации веб-сервисов:
- SOAP (Simple Object Access Protocol) — по сути это тройка стандартов SOAP/WSDL/UDDI
- REST (Representational State Transfer)
- XML-RPC (XML Remote Procedure Call)
На самом деле, SOAP произошел от XML-RPC и является следующей ступенью его развития. В то время как REST — это концепция, в основе которой лежит скорее архитектурный стиль, нежели новая технология, основанный на теории манипуляции объектами CRUD (Create Read Update Delete) в контексте концепций WWW.
Безусловно, существуют и иные протоколы, но, поскольку они не получили широкого распространения, мы остановимся в этом кратком обзоре на двух основных — SOAP и REST. XML-RPC ввиду того, что является несколько «устаревшим», мы рассматривать подробно не будем.
Нас в первую очередь интересуют вопросы создания новых веб-служб, а не реализация клиентов к существующим (как правило поставщики веб-сервисов поставляют пакеты с функциями API и документацией, посему вопрос построения клиентов к существующим веб-службам менее интересен с точки зрения автора).
SOAP против REST
Проблемы данного противостояния хорошо описаны в статье Леонида Черняка, найденой на портале www.citforum.ru.
По мнению же автора, кратко можно выделить следующее:
SOAP более применим в сложных архитектурах, где взаимодействие с объектами выходит за рамки теории CRUD, а вот в тех приложениях, которые не покидают рамки данной теории, вполне применимым может оказаться именно REST ввиду своей простоты и прозрачности. Действительно, если любым объектам вашего сервиса не нужны более сложные взаимоотношения, кроме: «Создать», «Прочитать», «Изменить», «Удалить» (как правило — в 99% случаев этого достаточно), возможно, именно REST станет правильным выбором. Кроме того, REST по сравнению с SOAP, может оказаться и более производительным, так как не требует затрат на разбор сложных XML команд на сервере (выполняются обычные HTTP запросы — PUT, GET, POST, DELETE). Хотя SOAP, в свою очередь, более надежен и безопасен.
В любом случае вам решать, что больше подойдет вашему приложению. Вполне вероятно, вы даже захотите реализовать оба протокола, чтобы оставить выбор за пользователями службы и — это ваше право.
Практическое применение веб-сервисов
Поскольку речь идет о практическом применении, нам нужно выбрать платформу для построения веб-службы и поставить задачу. Так как автору ближе всего PHP 5, мы и выберем его в качестве технологии для построения службы, а в качестве задачи примем следующие требования.
Допустим, нам необходимо создать службу, предоставляющую доступ к информации о курсах валют, которая собирается нашим приложением, и накапливается в базе данных. Далее посредством веб-сервиса, данная информация передается сторонним приложениям для отображения в удобном для них виде.
Как видим задача довольно проста и, с точки зрения самой службы, ограничивается лишь чтением информации, но в практических целях нам этого будет достаточно.
Этап первый — реализация приложения сбора информации о курсах валют.
Информацию о курсах валют мы будем собирать со страниц сайта НБУ (Национального Банка ) ежедневно и складывать в базу данных под управлением СУБД MySQL.
Создадим структуру данных.
Таблица валют (currency):
Таблица номиналов обмена (exchange):
Для работы с базой данных воспользуемся ORM слоем на базе пакета PHP Doctrine. Реализуем граббер:
класс Grubber (models/Grabber.php):
и сам граббер (grabber.php):
Теперь заставим наш граббер отрабатывать раз в сутки в 10:00 утра, путем добавления команды запуска граббера в таблицы cron:
Все — у нас есть достаточно полезный сервис.
Теперь реализуем веб-сервис, который позволит другим приложениям извлекать данные из нашей базы.
Реализация SOAP сервиса
Для реализации веб-сервиса на базе SOAP протокола, мы воспользуемся встроенным пакетом в PHP для работы с SOAP.
Поскольку наш веб-сервис будет публичным, хорошим вариантом будет создание WSDL файла, который описывает структуру нашего веб-сервиса.
WSDL (Web Service Definition Language) — представляет из себя XML файл определенного формата. Подробное описание синтаксиса можно найти здесь.
На практике будет удобно воспользоваться функцией автоматической генерации файла, которую предоставляет IDE Zend Studio for Eclipse. Данная функция позволяет генерировать WSDL файл из классов PHP. Поэтому, прежде всего, мы должны написать класс, реализующий функциональность нашего сервиса.
класс CurrencyExchange (models/CurrencyExchange.php):
Отметим, что для автоматической генерации WSDL, нам необходимо написать комментарии в стиле javadoc, потому что именно в них мы прописываем информацию о типах принимаемых аргументов и возвращаемых значений. Неплохо также описывать в нескольких словах работу методов — ведь WSDL послужит описанием API для сторонних разработчиков, которые будут использовать ваш веб-сервис.
Не пишите в докблоках param void или return void — для WSDL это не критично, но вот при реализации REST доступа к тому-же классу у вас возникнут проблемы.
Теперь в Zend Studio входим в меню File->Export. выбираем PHP->WSDL, добавляем наш класс, прописываем URI-адрес нашего сервиса и создаем WSDL-файл. Результат должен быть примерно таким: http://mikhailstadnik.com/ctws/currency.wsdl
Если вы будете добавлять новую функциональность в ваш веб-сервис, вам нужно будет пересоздавать WSDL-файл. Но здесь не так все гладко. Следует учитывать, что SOAP-клиент, который уже запрашивал ваш WSDL файл, кеширует его на своей стороне. Поэтому, если вы замените старое содержимое новым в WSDL файле, некторые клиенты его не прочтут. А значит, при добавлении новой функциональности, дописывайте версию в имя вашего файла. И не забудбте обеспечить обратную совместимость для старых клиентов, особенно если вы не являетесь их поставщиком.
С другой стороны, WSDL довольно жестко задает структуру веб-сервиса, а это значит, что, если существует необходимость ограничить функциональность клиента по сравнению с сервером, вы можете не включать определенные методы ваших классов в WSDL. Таким образом они не смогут быть вызваны, несмотря на то, что существуют.
Реализация же самого сервера не предстваляет теперь никакой сложности:
Вы можете попробовать веб-сервис в работе по адресу: http://mikhailstadnik.com/ctws/
Там же доступен тестовый клиент: http://mikhailstadnik.com/ctws/client.php
Код простейшего клиента может быть таким:
Реализация REST сервиса
REST — это не стандарт и не спецификация, а архитектурный стиль, выстроенный на существующих, хорошо известных и контролируемых консорциумом W3C стандартах, таких, как HTTP, URI (Uniform Resource Identifier), XML и RDF (Resource Description Format). В REST-сервисах акцент сделан на доступ к ресурсам, а не на исполнение удаленных сервисов; в этом их кардинальное отличие от SOAP-сервисов.
И все же удаленный вызов процедур применим и в REST. Он использует методы PUT, GET, POST, DELETE HTTP протокола для манипуляции объектами. Кардинальное отличие его от SOAP в том, что REST остается HTTP-запросом.
Поскольку в PHP пока еще нет реалзации REST, мы воспользуемся Zend Framwork, в который включена реализация как REST клиента, так и REST севера.
Воспользуемся уже готовым классом CurrencyExchange. Напишем сам сервер:
Как видите все очень сходно и просто.
Однако, следует оговорить, что наш REST-сервис менее защищен, чем SOAP-сервис, так как любой добавленый метод в класс CurrencyExchange при его вызове отработает (сам класс определяет сруктуру сервиса).
Проверим работу нашего сервиса. Для этого достаточно передать параметры вызова метода в сроке GET-запроса:
При желании или необходимости вы можете самомтоятельно задавать структуру ваших XML ответов для сервиса REST. В этом случае, также будет необходимо позаботиться и о создании определения типа вашего XML документа (DTD — Document Type Definition). Это будет минимальным описанием API вашего сервиса.
Простейший тестовый клиент к REST сервису может быть в нашем случае таким:
В принципе, Zend_Rest на сегодняшний день нельзя назвать наиболее точной реализацией принципов REST. Утрируя, можно говорить о том, что эта реализация свелась к удаленному вызову процедур (RPC), хотя философия REST гораздо шире.
Вы можете скачать пример в исходных кодах c PHP Doctrine и Zend Framework (4,42 Мб).
Заключение
Мы выполнили задачу минимум и показали, что такое веб-сервисы, для чего они нужны и как их реализовывать. Естественно, приведенный пример, возможно, несколько оторван от жизни, но он был выбран лишь в качестве инструмента для объяснения предмета и сущности веб-сервисов.
Кроме того мы увидели, что реализация веб-сервиса — задача довольно простая при использовании современного инструментария, который позволяет сконцентрироваться, в первую очередь, на разработке функциональности самого сервиса, не заботясь о низкоуровневой реализации протоколов.
Автор надеется, что данный материал будет действительно полезен тем, кто становится на тропу разработки веб-служб.
WSDL — Краткое руководство
WSDL расшифровывается как язык описания веб-сервисов. Это стандартный формат для описания веб-службы. WSDL был разработан совместно Microsoft и IBM.
Особенности WSDL
WSDL — это основанный на XML протокол для обмена информацией в децентрализованных и распределенных средах.
Определения WSDL описывают, как получить доступ к веб-службе и какие операции она будет выполнять.
WSDL — это язык для описания взаимодействия с сервисами на основе XML.
WSDL является неотъемлемой частью универсального описания, обнаружения и интеграции (UDDI), всемирного реестра предприятий на основе XML.
WSDL — это язык, который использует UDDI.
WSDL произносится как «wiz-тупой» и произносится как «WSD-L».
WSDL — это основанный на XML протокол для обмена информацией в децентрализованных и распределенных средах.
Определения WSDL описывают, как получить доступ к веб-службе и какие операции она будет выполнять.
WSDL — это язык для описания взаимодействия с сервисами на основе XML.
WSDL является неотъемлемой частью универсального описания, обнаружения и интеграции (UDDI), всемирного реестра предприятий на основе XML.
WSDL — это язык, который использует UDDI.
WSDL произносится как «wiz-тупой» и произносится как «WSD-L».
Использование WSDL
WSDL часто используется в сочетании с SOAP и XML-схемой для предоставления веб-сервисов через Интернет. Клиентская программа, подключающаяся к веб-службе, может прочитать WSDL, чтобы определить, какие функции доступны на сервере. Все используемые специальные типы данных встраиваются в файл WSDL в форме XML-схемы. Затем клиент может использовать SOAP для фактического вызова одной из функций, перечисленных в WSDL.
История WSDL
WSDL 1.1 был представлен Ariba, IBM и Microsoft в виде заметки W3C для описания сервисов для W3C XML Activity по XML-протоколам в марте 2001 года.
WSDL 1.1 не был одобрен Консорциумом World Wide Web (W3C), однако он только что выпустил проект для версии 2.0, который будет рекомендацией (официальным стандартом), и, таким образом, одобрен W3C.
WSDL — Элементы
WSDL разбивает веб-службы на три определенных идентифицируемых элемента, которые могут быть объединены или использованы повторно после определения.
Три основных элемента WSDL, которые могут быть определены отдельно:
- Типы
- операции
- переплет
Документ WSDL имеет различные элементы, но они содержатся в этих трех основных элементах, которые можно разрабатывать как отдельные документы, а затем их можно объединять или повторно использовать для формирования полных файлов WSDL.
Элементы WSDL
Документ WSDL содержит следующие элементы:
Определение — это корневой элемент всех документов WSDL. Он определяет имя веб-службы, объявляет несколько пространств имен, используемых в оставшейся части документа, и содержит все элементы службы, описанные здесь.
Типы данных — типы данных, которые будут использоваться в сообщениях, представлены в форме схем XML.
Сообщение — это абстрактное определение данных в форме сообщения, представленного либо в виде всего документа, либо в качестве аргументов, которые должны быть сопоставлены с вызовом метода.
Операция — это абстрактное определение операции для сообщения, например, присвоение имени методу, очереди сообщений или бизнес-процессу, которое примет и обработает сообщение.
Тип порта — это абстрактный набор операций, сопоставленный с одной или несколькими конечными точками, определяющий набор операций для привязки; коллекция операций, как она абстрактна, может быть сопоставлена с несколькими транспортными средствами через различные привязки.
Связывание — это конкретный протокол и форматы данных для операций и сообщений, определенных для определенного типа порта.
Порт — это сочетание привязки и сетевого адреса, обеспечивающее целевой адрес службы связи.
Сервис — это набор связанных конечных точек, охватывающий определения сервиса в файле; службы сопоставляют привязку с портом и включают любые определения расширяемости.
Определение — это корневой элемент всех документов WSDL. Он определяет имя веб-службы, объявляет несколько пространств имен, используемых в оставшейся части документа, и содержит все элементы службы, описанные здесь.
Типы данных — типы данных, которые будут использоваться в сообщениях, представлены в форме схем XML.
Сообщение — это абстрактное определение данных в форме сообщения, представленного либо в виде всего документа, либо в качестве аргументов, которые должны быть сопоставлены с вызовом метода.
Операция — это абстрактное определение операции для сообщения, например, присвоение имени методу, очереди сообщений или бизнес-процессу, которое примет и обработает сообщение.
Тип порта — это абстрактный набор операций, сопоставленный с одной или несколькими конечными точками, определяющий набор операций для привязки; коллекция операций, как она абстрактна, может быть сопоставлена с несколькими транспортными средствами через различные привязки.
Связывание — это конкретный протокол и форматы данных для операций и сообщений, определенных для определенного типа порта.
Порт — это сочетание привязки и сетевого адреса, обеспечивающее целевой адрес службы связи.
Сервис — это набор связанных конечных точек, охватывающий определения сервиса в файле; службы сопоставляют привязку с портом и включают любые определения расширяемости.
В дополнение к этим основным элементам спецификация WSDL также определяет следующие служебные элементы:
Документация — Этот элемент используется для предоставления удобочитаемой документации и может быть включен в любой другой элемент WSDL.
Импорт — этот элемент используется для импорта других документов WSDL или схем XML.
Документация — Этот элемент используется для предоставления удобочитаемой документации и может быть включен в любой другой элемент WSDL.
Импорт — этот элемент используется для импорта других документов WSDL или схем XML.
ПРИМЕЧАНИЕ. — Части WSDL обычно генерируются автоматически с использованием инструментов, поддерживающих веб-службы.
Структура документа WSDL
Основная структура документа WSDL выглядит следующим образом —
Документ WSDL также может содержать другие элементы, такие как элементы расширения и элемент службы, которые позволяют группировать определения нескольких веб-служб в одном документе WSDL.
Продолжите анализировать пример документа WSDL.
WSDL — Пример
Ниже приведен файл WSDL, предоставленный для демонстрации простой программы WSDL.
Предположим, что сервис предоставляет единственную общедоступную функцию, называемую sayHello . Эта функция ожидает один строковый параметр и возвращает приветствие одной строки. Например, если вы передаете параметр world, то сервисная функция sayHello возвращает приветствие «Hello, world!».
пример
Содержимое файла HelloService.wsdl —
Пример анализа
Определения — HelloService
Тип — Использование встроенных типов данных, и они определены в XMLSchema.
sayHelloRequest — параметр firstName
sayHelloresponse — приветствие, возвращаемое значение
Тип порта — операция sayHello, состоящая из запроса и службы ответа.
Привязка — Направление использования транспортного протокола HTTP SOAP.
Сервис — Сервис доступен по адресу http://www.examples.com/SayHello/
Порт — связывает привязку с URI http://www.examples.com/SayHello/, где можно получить доступ к работающей службе.
Определения — HelloService
Тип — Использование встроенных типов данных, и они определены в XMLSchema.
sayHelloRequest — параметр firstName
sayHelloresponse — приветствие, возвращаемое значение
Тип порта — операция sayHello, состоящая из запроса и службы ответа.
Привязка — Направление использования транспортного протокола HTTP SOAP.
Сервис — Сервис доступен по адресу http://www.examples.com/SayHello/
Порт — связывает привязку с URI http://www.examples.com/SayHello/, где можно получить доступ к работающей службе.
WSDL — элемент
Элемент должен быть корневым элементом всех документов WSDL. Он определяет название веб-службы.
Вот фрагмент кода из последней главы, в котором используется элемент определения .
Из приведенного выше примера можно сделать вывод, что определения —
является контейнером всех других элементов.
указывает, что этот документ называется HelloService .
указывает атрибут targetNamespace . TargetNamespace — это соглашение XML-схемы, которое позволяет документу WSDL ссылаться на себя. В этом примере мы указали targetNamespace http://www.examples.com/wsdl/HelloService.wsdl
определяет пространство имен по умолчанию: xmlns = http: //schemas.xmlsoap.org/wsdl/. Поэтому все элементы без префикса пространства имен, такие как message или portType , считаются частью пространства имен WSDL по умолчанию.
определяет многочисленные пространства имен, которые используются в оставшейся части документа.
является контейнером всех других элементов.
указывает, что этот документ называется HelloService .
указывает атрибут targetNamespace . TargetNamespace — это соглашение XML-схемы, которое позволяет документу WSDL ссылаться на себя. В этом примере мы указали targetNamespace http://www.examples.com/wsdl/HelloService.wsdl
определяет пространство имен по умолчанию: xmlns = http: //schemas.xmlsoap.org/wsdl/. Поэтому все элементы без префикса пространства имен, такие как message или portType , считаются частью пространства имен WSDL по умолчанию.
определяет многочисленные пространства имен, которые используются в оставшейся части документа.
ПРИМЕЧАНИЕ. — Спецификация пространства имен не требует, чтобы документ присутствовал в данном месте. Важным моментом является то, что вы указываете уникальное значение, отличное от всех других определенных пространств имен.
WSDL — элемент
Веб-сервис должен определить свои входы и выходы и то, как они отображаются в сервисы и выходят из них. Элемент WSDL заботится об определении типов данных, используемых веб-службой. Типы — это документы XML или части документа.
Элемент types описывает все типы данных, используемые между клиентом и сервером.
WSDL не привязан исключительно к конкретной системе ввода.
WSDL использует спецификацию XML-схемы W3C в качестве выбора по умолчанию для определения типов данных.
Если служба использует только простые встроенные типы XML-схемы, такие как строки и целые числа, то элемент types не требуется.
WSDL позволяет определять типы в отдельных элементах, чтобы их можно было повторно использовать в нескольких веб-службах.
Элемент types описывает все типы данных, используемые между клиентом и сервером.
WSDL не привязан исключительно к конкретной системе ввода.
Что такое WSDL файл?
WSDL (WEB Services Description Language) — язык описания веб-сервисов. Предназначен для точного описания веб-сервиса и его программных интерфейсов. В описании можно найти такую информацию, как адрес сервера, протокол, номер используемого порта, формат запроса и многое другое.
Содержание
Задачи
Стандартизированное описание упрощает понимание и применение. Допустим, что вы нашли сервис, который решает необходимые вам задачи, и хотите его использовать в своих решениях. Самый простой способ получить информацию о чужой разработке и ее возможностях — взглянуть на 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), как разрешать сервисам выполнять гиперссылки к другим сервисам. Другими словами, это неисследованная проблемная область.
Что такое WSDL файл?
WSDL (англ. Web Services Description Language ) — язык описания веб-сервисов и доступа к ним, основанный на языке XML.
Последняя официальная спецификация на момент написания статьи версия 2.0 (WSDL Version 2.0 от 26 июня 2007 года), которая имеет статус рекомендации, и версия 1.1 (WSDL Version 1.1 от 15 марта 2001 года), которая имеет статус заметки (note).
Содержание
Структура
Каждый документ WSDL можно разбить на следующие логические части:
- определение типов данных (types) — определение вида отправляемых и получаемых сервисом XML сообщений
- элементы данных (message) — сообщения, используемые web-сервисом
- абстрактные операции (portType) — список операций, которые могут быть выполнены с сообщениями
- связывание сервисов (binding) — способ, которым сообщение будет доставлено
Пример WSDL
См. также
- SOAP
- WDDX
Ссылки
- WSDL: взгляд изнутри: часть I, часть II
 |
Microsoft Visual Studio
Stylus Studio
Проблемы с открытием и работой с файлами WSDL, скорее всего, связаны с отсутствием надлежащего программного обеспечения, совместимого с файлами WSDL на вашем компьютере. Наиболее очевидным решением является загрузка и установка Microsoft Visual Studio или одной из перечисленных программ: oXygen XML Editor, Stylus Studio. В верхней части страницы находится список всех программ, сгруппированных по поддерживаемым операционным системам. Самый безопасный способ загрузки Microsoft Visual Studio установлен — для этого зайдите на сайт разработчика (Microsoft Corporation) и загрузите программное обеспечение, используя предоставленные ссылки.
Вы по-прежнему не можете получить доступ к файлам WSDL, хотя Microsoft Visual Studio установлен в вашей системе? Убедитесь, что программное обеспечение обновлено. Иногда разработчики программного обеспечения вводят новые форматы вместо уже поддерживаемых вместе с новыми версиями своих приложений. Причиной того, что Microsoft Visual Studio не может обрабатывать файлы с WSDL, может быть то, что программное обеспечение устарело. Последняя версия Microsoft Visual Studio должна поддерживать все форматы файлов, которые совместимы со старыми версиями программного обеспечения.
