Часть 3

Этой статьей мы завершаем серию материалов, посвященных введению в технологию Web-служб (см. "КВ" №№43, 45 за 2002 г.). В предыдущих частях статьи мы ввели понятие распределенной системы, понимая под этим программную систему, компоненты которой функционируют на различных физических устройствах в Cети, и отметили, что огромное количество существующих программных систем являются распределенными. Мы указали на то, что одной из главных проблем таких систем является сложность интеграции неоднородных компонентов системы. Мы выяснили, что эту проблему можно успешно решить с помощью технологии Web-служб. Мы обсудили определение Web-службы, отметив, что некоторая программная система может считаться Web-службой, если удовлетворяет двум основным условиям. Во-первых, она должна предоставлять свое описание на некотором, основанном на XML языке, а во-вторых, она должна уметь общаться с другими программными системами с помощью XML-сообщений, передаваемых по какому-либо интернет-протоколу. Мы также обсудили очень популярную в настоящее время концепцию архитектуры, ориентированной на службы. В рамках данной концепции любой программный компонент рассматривается как служба, доступ к которой может быть динамически получен некоторой заинтересованной в этом стороной при посредничестве так называемого реестра служб. Данная модель заставляет рассматривать технологию Web-служб не только и не столько как очередное техническое нововведение, но и как новое решение для мира бизнеса.

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

Что делать?

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

1. Создание приложения, реализующего функциональность Web-службы. Как мы отмечали в предыдущей части статьи, в качестве такого приложения могут выступать класс Java или .Net, компонент EJB или COM, унаследованное приложение (legacy application), написанное, скажем, на COBOL или PL, хранимая процедура базы данных и т.д. Поскольку Web-службы часто используются для интеграции уже существующих систем, где приложения создавались еще до принятия решения обернуть их в Web-службы, этот шаг может не требовать каких-либо дополнительных усилий.
2. Создание описания интерфейса Web-службы. Когда мы определяли Web-службу, мы отметили, что ее интерфейс должен быть описан на некотором, основанном на XML языке, и в настоящее время чаще всего для описания интерфейса используется язык WSDL (Web Services Description Language). Описание интерфейса определяет набор операций, которые поддерживает данная Web-служба, а также количество и тип параметров этих операций. Ссылка на интерфейс Web-службы может публиковаться в реестрах служб, таких, как UDDI (см. предыдущую часть статьи). В некоторых случаях, однако, нет необходимости создавать в явном виде файл с описанием интерфейса, поэтому и этот шаг приходится выполнять не всегда.
3. Опубликование описания интерфейса в реестре служб. Этот шаг, опять-таки, является необязательным, он, как правило, необходим в том случае, если мы хотим, чтобы нашу службу могли найти во внешнем (public) реестре служб и, возможно, динамически вызвать.
4. Развертывание Web-службы (Web service deployment). Это важнейший и, часто, самый трудоемкий шаг при создании Web-службы. Можно говорить о двух логических компонентах, участвующих в вызове Web-службы - клиентском приложении, инициирующем вызов, и серверной части, принимающей запрос клиента и непосредственно осуществляющей вызов. На шаге развертывания мы должны предпринять действия, которые позволят осуществить вызов Web-службы на стороне сервера. Необходимые для развертывания действия зависят от реализации Web-службы, платформы, на которой она работает, протокола, по которому ее вызывают, а также конкретных продуктов, обеспечивающих транспорт и среду работы Web-службы. В данной статье мы будем рассматривать классический вариант вызова Web-службы с помощью протокола SOAP, а в качестве его реализации использовать популярный open-source продукт Apache Axis. Сама Web-служба, которую мы будем вызывать, реализована в виде Java-класса. Для такой Web-службы развертывание включает создание J2EE enterprise-приложения и установку его на сервере приложений, таком, как Apache Tomcat, IBM WebSphere Application Server, BEA WebLogic Server или др. При этом наше приложение должно содержать код реализации Web-службы, а также так называемый дескриптор развертывания SOAP, который позволяет связать адрес Web-службы с реализующим ее программным компонентом (в нашем случае - Java-классом).
5. Создание описания реализации Web-службы. На втором шаге мы обсуждали создание описания интерфейса Web-службы на языке WSDL. Теперь, когда мы развернули Web-службу на сервере, мы можем создать WSDL-документ, содержащий информацию о реализации службы. Этот документ должен содержать ссылку на интерфейс Web-службы, который он реализует, и также может публиковаться в реестрах служб, таких, как UDDI. Надо отметить, что одному и тому же интерфейсу могут соответствовать несколько различных реализаций (и, соответственно, их описаний).
6. Опубликование описания реализации в реестре служб. Этот шаг является необязательным. Как уже было сказано, он необходим в том случае, если мы хотим, чтобы нашу службу могли найти во внешнем реестре служб и, возможно, динамически вызвать.
7. Создание клиентского приложения для доступа к Web-службе. Как правило, на основе описания реализации Web-службы создается так называемый proxy-класс, который используется клиентским приложением и скрывает в себе все сложные подробности вызова Web-службы (например, использование API-реализации протокола SOAP).

Четыре пути

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

Сценарий разработки "снизу вверх" соответствует самому, пожалуй, распространенному случаю, когда приложение, реализующее функциональность Web-службы, уже существует. Как мы рассказывали в предыдущих частях статьи, в Web-службы часто "оборачивают" унаследованные приложения, предоставляя, таким образом, современный, универсальный интерфейс к коду, написанному, быть может, десятки лет назад на каком-нибудь мало используемом сегодня языке программирования. Используя готовую реализацию и современные средства разработки Web-служб (о которых мы расскажем ниже), легко автоматически сгенерировать описание Web-службы. Далее, опять-таки, используя автоматизированные средства разработки, необходимо развернуть службу на сервере приложений, а затем, при необходимости, опубликовать в реестре служб.

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

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

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

Инструменты

Из сказанного выше понятно, что процесс создания Web-служб вовсе не так "элементарен", как это часто пытаются представить в статьях, посвященных продвижению этой популярной технологии на рынок. Этот процесс требует создания достаточно большого количества различного рода программных артефактов (реализация службы, WSDL-файлы с описанием службы, дескрипторы развертывания и т.д.), что может быть весьма трудоемко и чревато ошибками, если делать все это вручную. К счастью, современные средства разработки (например, такие, как IBM WebSphere Studio Application Developer или Microsoft Visual Studio.NET) позволяют в значительной мере автоматизировать процесс создания и развертывания Web-служб.

Поскольку в настоящее время существует уже достаточно много средств для создания и развертывания Web-служб, а также серверов приложений, поддерживающих Web-службы, мы упомянем лишь инструменты, которые пользуются наибольшей популярностью среди разработчиков. В сложном деле определения популярности мы доверимся мнению читателей известного журнала "Web Services Journal" (www.sys-con.com/webservices), издаваемого компанией SYS-CON Media (она также издает такие журналы, как "Java Developer's Journal", ".NET Developer's Journal" и др.). Награды SYS-CON Media имеют достаточно высокий авторитет, иногда их называют "Оскарами" в отрасли программного обеспечения. Итак, в 2002 году выбор читателей журнала ("Readers' Choice Award") в номинации "Лучший сервер приложений для Web-служб" пал на сервер компании BEA Systems - BEA WebLogic Server 6.1. Продукт компании IBM - WebSphere Application Server - занял в этой номинации второе место. Другое решение IBM - WebSphere Studio Application Developer - было признано читателями лучшей интегрированной средой для разработки Web-служб. Первенствовала IBM и в номинации "Лучший сайт, посвященный технологии Web-служб". Победителем тут признан ресурс IBM developerWorks, предлагающий бесплатные статьи, учебные курсы и пособия для разработчиков, относящиеся, в том числе, и к технологии Web-служб (www-106.ibm.com/developerworks/webservices).

В целом же, наибольшее количество читательских наград получили IBM, BEA, Oracle, и Borland, что и неудивительно: именно эти компании (наряду с Microsoft) являются лидерами в области создания различного рода решений для Web-служб.

(Окончание следует)

Константин РАЗУМОВСКИЙ,
KRazumovsky@iba.by