Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Web-сервисы и спецификация SOAP

Дон Маквитти

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

Принципы работы Web-сервисов

Процесс развертывания Web-сервисов далеко не так прост, как его расписывает реклама большинства производителей, и пути, ведущие к их продуктивному применению, зачастую тернистые. Вот лишь основные этапы, которые вам предстоит осуществить в обязательном порядке: написать программный код Web-сервиса, воспользовавшись своим любимым средством разработки приложений; имея исходный код, сгенерировать оболочку (wrapper) для Web-сервиса (здесь вам поможет ПО .Net фирмы Microsoft, если, конечно, вы им воспользуетесь ); на базе оболочки Web-сервиса сгенерировать пакет развертывания и определение WSDL (Web Services Definition Language) для сервера; воспользовавшись серверным файлом WSDL, сгенерировать клиентский пакет-"заглушку" (stub); и наконец, развернуть и протестировать Web-сервис.

Конечно, чтобы протестировать Web-сервис, вам придется написать его клиентскую часть, используя клиентский файл-"заглушку" для генерации класса интерфейса. Как видите, работы невпроворот. К счастью, Web-серверное ПО Apache/Tomcat и Microsoft IIS .Net позволяют автоматизировать большую часть процесса развертывания Web-сервиса.

Используя спецификацию WSDL, ваше приложение может "говорить" на системно-независимом языке, и это будет звучать примерно так: "Если вы хотите пообщаться со мной, то можете сделать это следующим образом". С одной строны, системная независимость приложений проистекает из использование формата XML при создании WSDL-определений, а с другой - спецификация SOAP (Simple Object Access Protocol) позволяет взаимодействовать вашему и клиентским приложениям. Вы должны только предоставить входные данные, заботы же о том, как доставить их приложению для обработки и вернуть ее результаты вам протокол SOAP полностью берет на себя.

Чаще всего для обмена данными на уровне протокола SOAP используется протокол HTTP, определяемый для большинства Web-сервисов в качестве "транспортного механизма". Вместе с тем язык определений WSDL позволяет устанавливать любой из имеющихся транспортных механизмов, обеспечивающих вызов ваших приложений и возвращение ответов от них. Например, один ваш клиент Web-сервисов выдает запрос: "Рассчитайте баланс за текущий год" и отсылает его по протоколу HTTP. Расчет годового баланса - это не какая-нибудь тривиальная задача, поэтому, запустив браузер, вы, вряд ли сядете перед экраном монитора и станете терпеливо ждать окончания ее выполнения. Используя язык WSDL, приложение может "ответить" вам следующее: "Если мы рассчитываем баланс, то в качестве транспортного механизма будем использовать протокол SMTP; когда расчет завершится, мы отправим уведомляющее электронное сообщение боссу".

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

Для создания файла WSDL можно использовать одно из многочисленных бесплатных приложений. Наиболее популярными из них являются Java2wsdl (http://www.apache.org) - для Web-сервисов Java и WSDL.exe - для Web-сервисов .Net. Эти инструментальные средства позволяют генерировать файлы WSDL для уже написанных приложений. Воспользовавшись готовым файлом WSDL, можно сгенерировать серверные и клиентские "заглушки" и использовать их в рамках проектов для развертывания и доступа к своим Web-сервисам.

Компоненты архитектуры Web-сервисов

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

Спецификация вызова

Коммуникации с Web-сервером предполагают следующую минимальную последовательность действий (ради простоты примем, что передача данных в обоих направлениях осуществляется по протоколу HTTP):

1. Клиент посылает HTTP-запрос post, содержащий имя Web-сервиса и его параметры. По ходу дела отметим, что и HTTP-спецификация get также доступна клиенту.

2. Сервер отправляет HTTP-ответ, содержащий результат обработки запроса.

Спецификация интерфейса: WSDL

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

Как же можно получить WSDL-файл нужного вам Web-сервиса? Да очень просто: большинство из них реагирует на запрос следующего вида: http://www.mywebservice.com/someServiceURL/wsdl?

Допустим, поставщик рассказал вам о своем Web-сервисе под названием "Wonderful". Чтобы получить его WSDL-файл, обратитесь к Web-серверу поставщика по предоставленной URL-ссылке, добавив к ней окончание "/wsdl?" В ответ на это вы получите документ XML в формате, речь о котором пойдет дальше.

Структура файла WSDL

Разобраться в структуре файла WSDL совсем не сложно, нужно только рассматривать каждый ее уровень по отдельности. Ниже приведено описание структуры WSDL-файла абстрактного формата и рассказано о том, как следует определять интерфейс, предоставляемый Web-сервисом.

Уровень 1 включает всего два главных элемента: поддерживаемую версию языка XML и оператор определения верхнего уровня.

XML Version (версия языка XML) - это версия спецификации XML консорциума W3C, с которой данный документ согласуется.

Definitions (определения) - это элемент, в котором вы определяете ваш сервис и поддерживаемые им типы данных. В него включаются все элементы Уровня 2.

Уровень 2 содержит определение сервиса (The Service Definition).

Types (Типы). С помощью этого элемента вы определяете сложные типы данных, используемые в остальных элементах файла WSDL. Например, если выходными данными определяемого в этом файле Web-сервиса являются дата, время суток и некоторая величина, например, курс акций, то вам нужно будет определять тэги и типы данных XML для этих полей.

Message Name (имя сообщения). Этот элемент помогает вам определить те сообщения, которые умеет обрабатывать ваша программа. Здесь происходит отображение внешних имен сообщений в их внутренние имена.

Port Type (тип порта) - это общедоступная точка входа для вызывающих приложений, где определяются поддерживаемые операции и сообщения, используемые каждой из этих операций.

Binding Name (привязка имени). Этот элемент привязывает операцию к транспортному механизму. В этом разделе вы можете указать, например, что "запросы поступают в виде HTTP-сообщений post по такой-то URL-ссылке, а ответы возвращаются посредством сообщений SMTP".

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

Уровень 3 детализирует элементы Уровня 2. На этом уровне вы, к примеру, можете указать, что "транспортным механизмом для такого-то элемента Binding Name Уровня 2 является протокол HTTP". Каждому элементу Уровня 2 соответствует свой собственный элемент Уровня 3, но в этой статье элементы этого уровня мы анализировать не будем.

Таким образом, файл WSDL предоставляет клиенту следующую важную информацию о Web-сервисе: какие сообщения он распознает; какие транспортные механизмы использует для их передачи; по какому адресу можно разыскать данный сервис. В следующем примере представлен упрощенный вариант документа WSDL 1.1 Specification Document комитета SOAP; его можно найти в сети Интернет по адресу http://www.w3.org/TR/wsdl#_wsdl.

Просматривая этот документ, можно прежде всего определить, где размещается данный сервис. Об этом сообщается в поле "soap: Address location" раздела определений сервиса файла WSDL:

<soap: address location="http://example.com/stockquote">

Чтобы выяснить, какие сообщения данный Web-сервис распознает, нужно найти определение сообщения GetLastTradePriceInput, использующего в качестве входных данных код эмитента ценных бумаг. Обратите ваше внимание на то, что раздел Message Name определен при этом как элемент Уровня 2. В данном примере имеется всего один элемент Уровня 3 - part name (имя компонента).

<message name="GetLastTradePriceInput">

<part name="Ticker Symbol" element="String"></message>

И наконец, узнать о том, какую информацию мы получили от Web-сервиса в качестве ответа и в каком формате, можно из определения сообщения с именем GetLastTradePriceOutput:

<message name="GetLastTradePriceOutput">

<part name="price" element="float"></message>

Рассмотрев данный элемент определения сервиса, мы сделаем вывод, что в ответном сообщении информация о курсе акций будет иметь вид числа с плавающей запятой.

Спецификация запросов/ответов

Как уже говорилось ранее, протокол SOAP используется и для отправки сообщений в адрес Web-сервиса и для получения ответов от него. Чтобы обеспечить требуемый уровень системной независимости Web-сервисов, протокол SOAP использует язык разметки документов XML, который позволяет выражать URL-ссылки и параметры в форме, гарантирующей их отображение в системозависимые переменные как вызывающим приложением, так и самим сервисом.

Заголовок сообщения SOAP, привязанного к протоколу HTTP, выглядит точно так же, как и заголовок любого HTTP-сообщения post, содержимое которого представлено в формате text/XML. Тело сообщения post имеет конверт SOAP (SOAP Envelope), в который "вкладывается" запрос к сервису. Последний содержит факультативный заголовок, любые подлежащие использованию пространства имен и сам вызов с параметрами - и все это выражено обычным текстом на языке XML. Сообщение с ответом сервера имеет точно такую же форму, только содержимым его являются результаты работы сервиса, полученные на основе предоставленных вами параметров (см. "Пример клиентского HTTP-сообщения SOAP".

Обратите внимание на то, как структурирован наш пример. За стандартными заголовками HTTP следуют сведения о версии конверта (SOAP Envelope version), типе кодирования (SOAP Encoding Style), и наконец, само тело сообщения (SOAP body), являющееся непосредственным объектом нашего интереса. Наш Web-сервис имеет точку входа, определяемую адресом http://www.Someplace.org/GetSomeValues. В качестве входных данных (мы послали строковую величину "test input", воспользовавшись тэгом XML paramOne)эта точка принимает единственную строковую переменную.

Обработав запрос, сервер посылает ответ (см. "Пример сообщения с ответом сервера"). Еще раз обратите внимание на стандартный заголовок HTTP. Максимальная длина содержимого сообщения, определяемая элементом заголовка Content-Length (если таковой имеется), должна в точности соответствовать аналогичному параметру спецификации SOAP. Хотя это требование полностью согласуется со стандартом HTTP 1.1, на некоторых серверах HTTP 1.0 оно может приводить к проблемам. Стандартный HTTP-заголовок информирует нас о том, что контент сообщения имеет текстовый тип (Content-type: text/XML). Заголовок SOAP предоставляет информацию о стиле кодирования, тело же SOAP (SOAP Body) - это та часть сообщения сервера, которая несет "полезную нагрузку". Здесь getSomeValueResponse является подпрограммой, результат выполнения которой выводится в переменную ResponseText посредством тэга Result.

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

Объединение компонентов

У вас имеется работающее приложение и WSDL-файл , описывающий его интерфейс. Что нужно сделать еще? Сначала вы должны развернуть приложение и опубликовать свой WSDL-файл. Если вы работаете в среде, полностью основанной на ПО .Net, то это максимально упрощает вам задачу (конечно, предполагается, что вы принимаете все установки по умолчанию). Хотя инсталляция, основанная на серверах Tomcat/Apache, потребует от вас выполняется больших объем работы, на данной стадии развития стандарта на Web-сервисы, на наш взгляд чем такой работы больше - тем лучше.

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





  
1 '2003
СОДЕРЖАНИЕ

бизнес

• С чего начинается адаптивное управление?

• Ошибки, которые вы уже не сделаете, прочитав эту статью

• "Интерпроком ЛАН" - "неправильный" дистрибутор

инфраструктура

• Тестируем средства создания и распространения образов дисков

информационные системы

• Опыт внедрения ERP-системы в крупном медицинском учреждении. Часть I

• Опыт внедрения ERP-системы в крупном медицинском учреждении. Часть II

• ПО мониторинга работы операторов в call-центрах

• Web-сервисы и спецификация SOAP

кабельные системы

• Проектирование и построение защищенных беспроводных ЛВС

• Интероперабельность компонентов категории 6

• Скалыватели оптоволокна

сети связи

• Quo vadis, VoIP?

• Сеть MPLS на Урале

защита данных

• Решения HIP предотвратят вторжения на хосты

новые продукты

• Новая версия NIC Express; Alcatel 5020 Softswitch; SI2000 COCOS — контакт-центр Iskratel и «Искрауралтел»; OptiSwitch-F — фиксированная конфигурация, SFP-трансиверы


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх