Веб-сервисы. Основы

Игорь Долотин | © UBS 2004

---

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

1. Немного истории

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

Как это обычно бывает, почти во всем “виноваты” деньги. Когда компьютерные сети вышли за рамки сугубо научных и военных учреждений (вспомним ARPAnet), они стали достоянием энтузиастов-частных лиц. Когда же частных лиц, пользующихся компьютерными сетями, стало достаточно много, сообразили, что компьютерные сети могут быть использованы для производства денег. Так компьютерные сети общего пользования, основная и самая распространенная из которых сегодня называется Интернет, стали бизнес-инструментом. Чтобы с помощью этого инструмента вести бизнес, он должен удовлетворять некоторому набору требований, главные из которых – безопасность и скорость передачи информации. Задачу выполнения этих требований стали решать на самом низком уровне – на уровне транспортных протоколов. Различные компании предложили различные реализации сетевых протоколов. Сетевые протоколы, как известно, задают правила формирования сетевых пакетов и обмена ими. Использующие эти правила (повторимся - различные для различных протоколов) сетевые приложения тем самым жестко привязываются к определенным протоколам. Между тем быстроразвивающиеся бизнес-отношения требовали, чтобы сетевые приложения, использующие различные протоколы, могли обмениваться между собой данными – таким образом, встала задача интеграции приложений.

Вот здесь-то и начались мытарства. На протяжении нескольких лет было создано несколько технологий взаимодействия распределенных приложений, так или иначе позволявших реализовать обмен данными между приложениями (среди получивших наибольшее развитие - Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) и Common Object Request Broker Architecture (CORBA)), однако каждая из них была довольно сложна в реализации, не обладала необходимой универсальностью (т. е. все же зависела от выбора, например, одной и той же операционной системы для всех участников обмена) и, что особенно плохо, эти технологии с большим трудом стыковались между собой. Т. е. произошло лишь укрупнение групп невзаимодействующих между собой приложений, что, разумеется, не могло устраивать ни бизнес, ни IT-специалистов.

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

• TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;
• HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;
• XML – универсальный язык для работы с любыми типами данных.

Мы умышленно подчеркиваем универсальность каждой из технологий, потому что эта универсальность – основа для понимания веб-сервисов. Они основаны только на общепринятых, открытых и формально независимых от вендоров технологиях. Только посредством этого достигается главное преимущество веб-сервисов как концепции построения распределенных ИС – их универсальность, т. е. возможность применения для любых операционных систем, языков программирования, серверов приложений и т. д. Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС. В этом и заключается основное принципиальное отличие веб-сервисов от предшественников. Уже сейчас ясно, что наиболее широкое применение веб-сервисы найдут в сфере интеграции корпоративных приложений (Enterprise Application Integration (EAI)). С помощью веб-сервисов можно несколько, порой сильно разнящихся между собой, бизнес-процессов выстроить в один-единственный цельный бизнес-процесс, достигнув при этом существенно более высоких показателей эффективности бизнеса – начиная от прямого увеличения выручки за счет улучшения продаж и обслуживания клиентов и кончая “банальным” сокращением накладных расходов при обмене данными.

2. Так ли все хорошо?

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

• Веб-сервисы позволяют компании интеграцию собственных бизнес-процессов с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости нежели с использованием иных интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития;
• Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают;
• Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в компании ИС, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них. Таким образом, обеспечивается сохранность уже сделанных инвестиций в IT-инфраструктуру и не идет увеличения требуемых, поскольку нет необходимости в радикальных изменениях;
• Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK).

Не менее подробно остановимся и на минусах веб-сервисов:

• Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом;
• Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов “на лету”, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries));
• Добавление к функциям сервера приложений функциональности провайдера веб-сервисов (в т. ч. SOAP-сервера) в силу новизны технологий может представлять определенную трудность;
• Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.

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

3. Определение веб-сервиса

Дадим формальное определение веб-сервиса:
Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи публичные интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.

Внимательно прочитав это крайне общее, но, тем не менее, очень точное по сути определение (именно в его общности и заключается, как ни парадоксально, его точность), можно увидеть, что единственное упоминание конкретной технологии сделано в отношении XML. Не говорится ни о применяемом сетевом протоколе, ни о языке программирования, ни о программной платформе. И хотя, как правило, для передачи сообщений в ИС на основе веб-сервисов в качестве транспортного протокола используется стандартный HTTP, его использование совершенно не обязательно, и можно использовать (посредством так называемых протокольных привязок (protocol bindings)), например, SMTP-протокол. На применение языков программирования также не накладывается никаких ограничений – уже разработаны веб-сервисы на Java, C++, C#, COBOL и других языках. С программными платформами, операционными системами и серверами приложений, дело обстоит еще проще (лучше) – возможны любые сочетания (например, можно найти и вызвать веб-сервис, развернутый на IBM WebSphere Application Server под управлением Linux, с рабочей станции Macintosh). Единственное условие – использование XML-сообщений (точнее SOAP-сообщений), поскольку реальной альтернативы XML как языку, позволяющему работать с различными типами данных, на сегодняшний день нет.

4. Service-Oriented Architecture (SOA, сервисно-ориентированная архитектура)

4.1 Большие предприятия - большие проблемы

В разделе 3 первой статьи цикла мы дали определение веб-сервиса как программной системы. Т.е., грубо говоря, согласно этому определению, веб-сервис в конечном счете - просто несколько особенно написанный фрагмент программного кода, выполняющегося на сервере. И это верно. Но данное определение - техническое. Попробуем взглянуть на веб-сервисы иначе, с точки зрения бизнес-анализа.

Концепция веб-сервисов родилась после нескольких не вполне удачных попыток многих групп аналитиков, архитекторов и разработчиков по всему миру создать среду и механизм взаимодействия того многообразия информационных систем, которые они же, эти группы аналитиков, архитекторов и разработчиков, и создали. Столь большое количество неглупых в общем-то людей редко тратят столько энергии, интеллекта и времени просто так - обычно, это означает, что предполагаемый результат их усилий очень востребован. Например, как ни странно, бизнесом. Современное коммерческое предприятие трудно представить без информационных систем различного назначения: бухгалтерских, финансово-аналитических, производственных, складских и т. д. Большое предприятие использует большие многофункциональные информационные системы (можно вспомнить аббревиатуры ERP, CRM, SCM и т. п.), часто несколько одновременно. А есть еще поставщики, клиенты, партнеры, у которых свои, не менее сложные и специфичные, информационные системы, и с ними информационным системам предприятия необходимо взаимодействовать. Как организовать это взаимодействие? Как ЭФФЕКТИВНО организовать это взаимодействие, чтобы создать производительные, надежные и безопасные автоматизированные (экстра)корпоративные (т. е. простирающиеся за пределы предприятия) цепочки именно тех бизнес-процессов, интеграция которых необходима предприятию для осуществления своих бизнес-функций? Именно в области интеграции (экстра)корпоративных приложений (англ. Enterprise Application Integration, EAI) лежит основная масса IT-проблем современных предприятий, именно на решение вопросов взаимодействия разнородных информационных систем готовы бросить свои основные ресурсы CEO и CIO, и именно здесь наиболее эффективным инструментом решения будут веб-сервисы.

4.2 Определение сервиса

Вернемся к эффективной организации взаимодействия информационных систем. Для начала неплохо бы знать какие бизнес-процессы необходимы предприятию для осуществления его бизнес-функций. С этой целью проводят декомпозицию функциональных блоков бизнес-процессов до получения цепочек бизнес-процессов, цепочек бизнес-процессов - до получения отдельных бизнес-процессов, а отдельных бизнес-процессов - до составляющих их функций. Бизнес-функция, дающая конкретный измеримый результат, является минимальной сущностью, имеющей ценность для бизнеса, неким квантом. Именно ее и можно отождествить с сервисом:

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

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

4.3 Определение сервисно-ориентированной архитектуры

Таким образом, с функциональной точки зрения бизнес-приложение распадается, в конечном итоге, на совокупность взаимодействующих между собой сервисов. Эту совокупность взаимодействующих сервисов можно отождествить с еще одним ключевым понятием - сервисно-ориентированной архитектурой:
Компонентная модель, состоящая из отдельных функциональных модулей приложений, называемых сервисами, имеющих определенные согласно некоторым общим правилам интерфейсы и механизм взаимодействия между собой, называется сервисно-ориентированной архитектурой (Service-Oriented Architecture, SOA).

Переходя в мир абстракций, можно дать следующее, более сильное, определение сервисно-ориентированной архитектуры:
Архитектура приложений, в рамках которой все функции приложения являются независимыми сервисами с четко определенными интерфейсами, которые можно вызывать в нужном порядке с целью формирования бизнес-процессов, называется сервисно-ориентированной архитектурой.
(Оговоримся, что на сегодняшний день устоявшегося, принятого IT-сообществом, определения SOA нет. Здесь мы приводим определение, которое, на наш взгляд, наиболее полно и точно отражает современное состояние этой концепции).

Поясним второе определение:
"все функции приложения" - как мы уже упомянули, любое приложение с функциональной точки зрения может быть представлено совокупностью функций; ресурс, реализующий функцию, есть сервис. Таким образом, приведенное определение требует для представления и реализации любого приложения в рамках SOA проведения его полной декомпозиции до уровня отдельных функций;
"являются независимыми сервисами" - в понятие независимости сервиса вкладывается следующий смысл: сервисы функционируют независимо от других информационных систем, являются функционально самостоятельными объектами. Они представляют собой "черные ящики" для любых внешних приложений: внешние приложения не знают, как сервис формирует из входных данных выходные. Все, что им известно - что необходимо подать на вход сервиса и что следует ожидать на его выходе;
"с четко определенными интерфейсами" - функция (или функции), которую реализует данный сервис, должна быть однозначно описана согласно определенным, принятым для всех сервисов, правилам. Должен быть описан набор и типы входных данных, а также набор и типы выходных данных;
"с ... интерфейсами, которые можно вызывать" - данное требование обусловлено необходимостью обеспечения взаимодействия между различными сервисами: для внешних по отношению к сервису информационных систем не должно иметь значения на каком языке программирования реализован сервис (точнее, здесь, веб-сервис), на какой программно-аппаратной платформе он функционирует, локально или удаленно он расположен. Внешняя информационная система должна иметь возможность взаимодействовать с сервисом (т.е. передать ему входные данные и получить выходные) вне зависимости от указанных его особенностей.

4.4 Требования к SOA

SOA, будучи практической (и практичной) концепцией, должна соответствовать определенным требованиям, предъявляемых к ней современным состоянием бизнес-отношений и информационных технологий, а также тенденциями их совместного развития:

• обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их совместное эффективное использование для повышения ROI от IT-вложений;
• обеспечивать реализацию различных типов интеграции:
  - пользовательская интеграция (user integration) - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;
  - интеграция приложений (application connectivity) - обеспечение взаимодействия приложений;
  - интеграция процессов (process integration) - интеграция бизнес-процессов;
  - информационная интеграция (information integration) - интеграция с целью обеспечения доступности информации и данных;
  - интеграция новых приложений (build to integrate) - интеграция новых приложений и сервисов в существующие информационные системы.
• обеспечивать поэтапность внедрения вновь созданных и миграции существующих информационных систем;
• иметь стандартизованную технологическую обеспеченность реализации и инструментарий разработки, совокупно предоставляющие наилучшие возможности повторного использования приложений, внедрения новых и миграции существующих информационных систем;
• позволять реализацию различных моделей построения информационных систем, в особенности таких как портальные решения, grid-системы и on-demand-системы.

Сегодняшний уровень развития SOA позволяет утверждать, что все указанные требования в той или иной мере выполняются.

4.5 SOA и веб-сервисы - в чем разница?

Необходимо отметить, что SOA - не есть синоним веб-сервисов, а веб-сервисы - не есть единственный способ реализации SOA. SOA не является технологией или набором технологий, это - концепция, абстрактное представление реализации информационных систем с помощью сервисов безотносительно конкретных технологий. Как нетрудно заметить, в SOA присутствуют элементы объектного подхода к построению информационных систем: декомпозиция (приложений на отдельные функции) и инкапсуляция (сервисы как "черные ящики"). Однако, подчеркнем, термин "объектно-ориентированный" по отношению к SOA не является корректным, т. к. в SOA отсутствуют все необходимые элементы объектно-ориентированной идеологии. Более правильно называть SOA концепцией, использующей объектный подход.

Веб-сервисы, в свою очередь, являются лишь технологиями, с помощью которых можно эффективно реализовать сервисно-ориентированную архитектуру. Существуют и другие технологии, с применением которых можно реализовать SOA - например, упомянутая выше CORBA.

4.6 Почему SOA?

Концепции SOA и веб-сервисов не новы; на протяжении последних десяти лет были и другие технологии построения распределенных информационных систем, например, CORBA и DCOM. Однако, со временем решения, построенный на их основе перестали удовлетворять основным требованиям, предъявляемым к бизнес-решениям: максимально низкая TCO, максимально высокий ROI, короткий цикл разработки и внедрения информационной системы, широкие возможности интеграции разнородных систем. Наряду с бизнес-причинами отмирания предыдущих технологий построения распределенных информационных систем была и не менее важная технологическая причина: эти технологии не достигли необходимого уровня зрелости. Они продвигались лишь отдельными вендорами, были обременены различными копирайтами, ограничивающими их распространение, не было разработано унифицированных нормативных и технических, принятых мировым IT-сообществом, документов, описывающих принципы применения этих технологий. Результат известен: ни одна из этих технологий не получила широкого практического применения и сегодня можно констатировать, что их развитие фактически остановилось.

Уроки были извлечены при создании методологической основы концепций веб-сервисов и SOA, и сегодня технологии веб-сервисов и SOA:

• являются open-source;
• основаны на общепринятых и общеупотребимых технологиях и стандартах: XML, HTTP, TCP/IP;
• позволяют достичь наилучших показателей TCO и ROI, нежели какие-либо иные существующие на сегодняшний день интеграционные технологии;
• находятся на уровне зрелости, необходимом и достаточном для успешного применения большим количеством ISV (англ. Independent Software Provider) по всему миру.

5. Стек технологий веб-сервисов

Итак, концепция сервисно-ориентированной архитектуры подразумевает реализацию бизнес-процессов предприятия в виде совокупности сервисов, взаимодействующих друг с другом либо с пользователями в определенной последовательности и в соответствии с определенными правилами. Отметим, что, вообще говоря, это весьма нетривиальная задача - определить эту "определенную последовательность" и "определенные правила" таким стандартным для индустрии (разработки бизнес-приложений) образом, чтобы покрыть весь спектр существующих сценариев взаимодействия бизнес-объектов, учитывая исторически сложившееся многообразие технической и технологической реализации этого взаимодействия и самих бизнес-объектов. Решить эту задачу в рамках какой-либо единой технологии пока не удалось. И хотя тенденция консолидации существующего множества технологий веб-сервисов в настоящее время налицо, для реализации сервисно-ориентированных архитектур с помощью веб-сервисов сейчас применяется совокупность технологий, образующих так называемый стек технологий веб-сервисов (см. Рис. 1).

Рис. 1: Стек технологий веб-сервисов

Стек технологий веб-сервисов принципиально разбивается на следующие две составляющие:

• технологии, обеспечивающие функциональность веб-сервисов (Functions);
• технологии, обеспечивающие качество сервиса веб-сервисов (Quality of service).

Эти составляющие в свою очередь образуются несколькими слоями (layers):

• технологии, обеспечивающие функциональность веб-сервисов:
  
  • транспортный слой (transport layer);
  • коммуникационный слой (service communication layer);
  • слой описаний сервисов (service description layer);
  • сервисный слой (service layer);
  • слой бизнес-процессов (business process layer);
  • слой реестров сервисов (service registry layer).
• технологии, обеспечивающие качество сервиса веб-сервисов:
  • слой политик (policy layer);
  • слой безопасности (security layer);
  • слой транзакций (transaction layer);
  • слой управления (management layer).

В целях понимания назначения слоев, дадим краткое описание каждого из них.

№	Наименование слоя	Назначение слоя	Технологии, реализующие слой
Функциональность (Functions)
1	Транспортный слой (Transport layer)	Описывает средства обмена данными между веб-сервисами	Стандартные: HTTP, JMS (для Java-приложений), SMTP Нарождающиеся: WS-ReliableMessaging, BEEP
2	Коммуникационный слой (Service communication layer)	Описывает средства формализации механизмов использования транспортных протоколов веб-сервисами. Используя метафоры, можно отождествить транспортный протокол с дорогой между веб-сервисами, а механизмы его использования, определяемые коммуникационным слоем, с грузовыми машинами, перевозящими по ней от сервиса к сервису сообщения	Стандартные: SOAP Нарождающиеся:REST
3	Слой описаний сервисов (Service description layer)	Описывает средства формализации интерфейсов веб-сервисов с целью обеспечения их функционирования независимо от программно-аппаратной платформы реализации или языка программирования. Различают два вида описаний сервиса: операционное (operational); полное (complete)	Стандартные: XML, WSDL Нарождающиеся: ebXML
4	Сервисный слой (Service layer)	Описывает программное обеспечение, вызываемое с помощью WSDL-описаний интерфейсов веб-сервисов. В частности, это сами веб-сервисы
5	Слой бизнес-процессов (Business process layer)	Описывает возможности организации веб-сервисов для реализации бизнес-процессов и потоков работ. При этом определяются правила, задающие последовательность взаимодействия веб-сервисов с целью удовлетворения бизнес-требованиям	Стандартные: в настоящее время нет Нарождающиеся: BPEL4WS
6	Слой реестров сервисов (Service registry layer)	Описывает возможности организации веб-сервисов в иерархические библиотеки, позволяющие публикацию, поиск и вызов веб-сервисов по их WSDL-описаниям интерфейсов	Стандартные: UDDI Нарождающиеся: WS-Inspection
Качество сервиса (Quality of service)
7	Слой политик (Policy layer)	Описывает правила и условия, согласно которым веб-сервисы могут быть использованы. Поскольку данные правила и условия относятся как к функциональному аспекту веб-сервисов, так и к аспекту обеспечения качества сервиса на Рис. 1, данный слой является общим для обоих аспектов	Стандартные: в настоящее время нет Нарождающиеся: WS-Policy, WS-PolicyAssertions и WS-PolicyAttachment
8	Слой безопасности (Security layer)	Описывает возможности обеспечения безопасности веб-сервисов и безопасности их функционирования (авторизация, аутентификация и разделение доступа)	Стандартные: WS-Security Нарождающиеся: WS-SecureConversation, WS-Federation, WS-Authorization, WS-Trust и WS-Privacy
9	Слой транзакций (Transaction layer)	Описывает свойство транзакционности распределенных систем на основе веб-сервисов для обеспечения надежности их функционирования	Стандартные: в настоящее время нет Нарождающиеся: WS-Transaction и WS-Coordination
10	Слой управления (Management layer)	Описывает возможности управления веб-сервисами и характеристиками их функционирования

Представленный выше стек технологий веб-сервисов вводит иерархию во множество технологий веб-сервисов в соответствии с их функциональным назначением. При этом в таблице указаны лишь наиболее широко применяемые и устоявшиеся технологии. Стандартными названы технологии, получившие официальный статус стандартов международных консорциумов по разработке IT-стандартов (W3C, OASIS либо WS-I). В действительности, спектр технологий, описывающих те или иные аспекты использования веб-сервисов либо сервисно-ориентированных архитектур, крайне широк, в частности, потому, что процесс разработки данных технологий является открытым - любая компания, некоммерческое объединение специалистов или даже один специалист может разработать и опубликовать спецификацию разработанной им технологии. В настоящее время это даже стало серьезной проблемой рынка веб-сервисов - количество спецификаций стало столь велико, что при фактической нерегламентированности глобального (в рамках всей индустрии) процесса их разработки, ввода в действие и использования, появляется опасность ввергнуть индустрию в хаос и технологическую разобщенность. А технологическая разобщенность - как раз то, от чего хотели уйти прежде всего, разрабатывая веб-сервисы и закладывая в качестве их концептуальной и технологической основы открытые и наиболее широко применяемые IT-технологии.

6. Принципы взаимодействия веб-сервисов в рамках сервисно-ориентированной архитектуры

В настоящее время технологический фундамент веб-сервисов образуется следующими технологиями:

• eXtensible Markup Language (XML);
• Simple Object Access Protocol (SOAP);
• Universal Description, Discovery and Integration (UDDI);
• Web Services Description Language (WSDL).

Данные технологии обеспечивают реализацию базовых свойств веб-сервиса, описанных в его определении (см. п. 4.2). Они же лежат в основе взаимодействия веб-сервисов в рамках сервисно-ориентированной архитектуры (см. Рис.2).

Рис. 2: Взаимодействие между компонентами сервисно-ориентированной архитектуры

Различают следующие три основных архитектурных компонента сервисно-ориентированной архитектуры:

• пользователь сервиса: приложение, программный модуль либо сервис, осуществляющий поиск и вызов необходимого сервиса из реестра сервисов по описанию сервиса, а также использующий сервис, предоставляемый провайдером сервиса, в соответствии с интерфейсом сервиса;
• провайдер сервиса: приложение, программный модуль либо сервис, осуществляющий реализацию сервиса в виде веб-сервиса, прием и исполнение запросов пользователей сервиса, а также публикацию сервиса в реестре сервисов;
• реестр сервисов: библиотека сервисов, предоставляющая пользователям сервиса средства поиска и вызова необходимого сервиса и принимающая запросы провайдеров сервисов на публикацию сервисов.

Каждый компонент может играть либо лишь одну роль (быть, например, только пользователем сервиса) либо одновременно сразу несколько ролей (например, быть провайдером одних сервисов и пользователем других).

Заметим, что в данном описании компонентов сервисно-ориентированной архитектуры и взаимодействия между ними следует различать термины "сервис" и "веб-сервис". Под сервисом понимается бизнес-функция (здесь уместно снова обратиться к п. 4.2), под веб-сервисом - программная реализация бизнес-функции (сервиса).

В ходе взаимодействия друг с другом компоненты сервисно-ориентированной архитектуры выполняют следующие основные операции:

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

Рассматривая взаимодействие компонентов сервисно-ориентированной архитектуры необходимо отметить наличие (и различие) следующих двух артефактов:

• описание сервиса: определяет формат запроса и отклика при взаимодействии пользователя сервиса и провайдера сервиса, а также требуемое качество сервиса;
• сервис: собственно сервис, который может быть вызван и использован пользователем сервиса в соответствии с опубликованным интерфейсом сервиса.

В заключение следует сказать, что с целью выработки и популяризации стандартов, описывающих взаимодействие веб-сервисов в рамках сервисно-ориентированной архитектуры, создано международное объединение около 150 ведущих компаний, называющееся WS-I (Web Services Interoperability Organization). Важным результатом работы данного объединения стало создание и утверждение в 2003 году так называемого WS-I Basic Profile 1.0 - пакета базовых спецификаций веб-сервисов, взаимоувязанных с целью обеспечения широких возможностей взаимодействия веб-сервисов. В настоящее время в данный профиль входят следующие спецификации технологий:

• SOAP 1.1;
• WSDL 1.1;
• UDDI 2.0;
• XML 1.0;
• XML Schema Part 1: Structures;
• XML Schema Part 2: Datatypes;
• RFC2246: The Transport Layer Security Protocol 1.0;
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile;
• RFC2616: HyperText Transfer Protocol 1.1;
• RFC2818: HTTP over TLS;
• RFC2965: HTTP State Management Mechanism;
• Secure Sockets Layer Protocol 3.0.

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

---

Комментарии к статье принимаются по адресу info@ubs.ru.