Статья только в электронной версии журнала
ОБЗОРЫ
Web-сервисы обещают обеспечить открытость платформ, но прежде им требуется время для созревания
Влад Боркус, Елена Монахова
Web-сервисы (WS), про которые за последние два года не написал только ленивый, на самом деле являются продуктом эволюции очень старой идеи - инкапсуляции вычислительной логики в "черном ящике" с предоставлением четкого и понятного метода передачи ей входных параметров и получения назад итогов их обработки. Эта идея "сервисной ориентации" в 1960-е годы реализовывалась в форме библиотек подпрограмм, а впоследствии нашла развитие в виде моделей распределенных вычислений - с методами удаленного вызова процедур типа RPC или RMI, клиент-серверными и компонентными архитектурами наподобие COM или CORBA.
С возникновением протокола HTPP, стандарта де-факто обмена данными седьмого уровня модели OSI (т. е. уровня приложений) и языка XML, легко позволяющего создавать прикладные диалекты, появился простой и общепринятый подход для описания и удаленного вызова логики в "черных ящиках". В Web-сервисах важны именно эти два понятия, выделенные курсивом. Все остальные ключевые идеи - описания интерфейсов, содержащиеся в человекочитаемых текстовых файлах, репозитории информации о доступных методах и пр. - были и в других технологических решениях, скажем, в той же CORBA. Но в этих случаях отсутствовало согласие между производителями ПО. Теперь оно (правда, снова с оговорками) имеется.
Точно так же, как объектно-ориентированное программирование позволяло повторно использовать код и отделить реализацию функциональности от ее интерфейсов, теперь технология Web-сервисов позволяет скрыть от "потребителя" сервисов сведения о платформе, на которой они реализуются, о ее окружении, территориальном расположении и т. д. Подобная независимость означает возможность создавать высокоуровневые графические инструменты для работы с сервисами и в конечном итоге упростить создание корпоративных систем, сделав ее похожей скорее на сборку, чем на программирование.
Основные стандарты
Формально говоря, Web-сервис - это любой бизнес-процесс или единица логической функциональности, для описания которых и доступа к которым используется три стандарта: SOAP, WSDL и UDDI.
Рис. 1. Web-сервисная архитектура. Провайдер сервиса публикует его WSDL-описание в репозитории (1).
Клиент производит поиск в репозитории и запрашивает описание (2). Затем происходит вызов сервисов (3)
Simple Object Access Protocol (SOAP) представляет собой основанный на XML высокоуровневый протокол обмена сообщениями. Он определяет только структуру сообщений и несколько правил для их обработки и к тому же не зависит от типа используемого транспорта, а стало быть, может быть задействован в разных гетерогенных сетях. Однако обычно применяется транспортный протокол HTTP, поскольку в стандарте описано, как осуществлять привязку SOAP к HTTP.
Нынешним летом W3C одобрила версию 1.2 этого протокола. В ней устранены многие неоднозначности SOAP 1.1 и ошибки, а также добавлен ряд расширений. Например, описан новый способ обращения к SOAP-серверам при помощи команд HTTP GET; версия 1.1. допускала исключительно обмен SOAP-отформатированными запросами, что не всегда было допустимо.
Отличный обзор основных концепций SOAP и его привязки к Java можно найти в документации Sun Microsystems по продукту SunONE Message Queue (http://docs.sun.com/source/817-0355-10/SOAP.html).WebServicesDescriptionLanguage (WSDL) - стандарт описания информации, необходимой для вызова Web-сервиса - свойств его интерфейса, способа взаимодействия (например, сервис может быть ориентирован на прием и обработку входящих документов, а может быть просто обычной вычислительной функцией, возвращающей значение), места расположения. Очередная версия (она имеет номер 1.2) этого стандарта сейчас ратифицируется консорциумом W3C (www.w3c.org). В ее создании принимали участие такие тяжеловесы, как Hewlett-Packard (www.hp.com), Iona (www.iona.com), IBM (www.ibm.com), Nokia (www.nokia.com), SAP (www.sap.com), Sun Microsystems (www.sun.com), Tibco Software (www.tibco.com) и webMethods (www.webmethods.com).UniversalDescription , Discovery and Integration (UDDI) определяет правила регистрации WSDL-описаний Web-сервисов в каталогах, построенных по аналогии с каталогами "желтых страниц", а также получения записей из этих каталогов. Каталоги UDDI позволяют сделать доступ к Web-сервису независимым от места его расположения. Видимо, поэтому первые релизы данной спецификации ориентировались на использование Web-сервисов как механизмов межкорпоративного взаимодействия. Предполагалось вести огромные базы компаний, расположенных по всему миру, используя которые фирмы могли бы быстро находить себе партнеров и оформлять через Web запросы на их услуги.
Первые глобальные каталоги создали IBM, Microsoft и Hewlett-Packard. Однако выяснилось, что потенциально Web-сервисы гораздо более востребованы как внутрикорпоративная технология интеграции приложений, тем более ввиду того, что стандартов безопасности Web-сервисов пока нет (об этом ниже). Данный факт потребовал внесения существенных изменений в UDDI, и выпущена уже третья его версия. Фактически произошла прагматическая эволюция UDDI от "каталога электронного бизнеса" к компоненту "инфраструктуры Web-сервисов".
Рис. 2. Архитектура интеграции унаследованного ПО при помощи Web-сервисов
Задачей создания UDDI 1.0 (сентябрь 2000 г.) ставилось предложить основу для организации реестра основанных на Интернете бизнес-сервисов. Версия 2.0 (июнь 2001 г.) должна была обеспечить соответствие спецификации возникающим архитектурам Web-сервисов и предоставить более гибкие таксономии. Версия 3.0 уже предназначалась для широкой поддержки взаимодействия частных и общедоступных реестров. Это означает, что в UDDI 3 сделан акцент на средства описания взаимоотношений реестров, а не просто на правила доступа к одному открытому реестру. Хотя UDDI c самой первой редакции поддерживал концепции репликации и распределения запросов между серверами, его первая и вторая версии не давали возможностей для построения сложных связей между реестрами в рамках иерархической или сетевой (с делегированием функций) моделей.
Для решения этих задач в UDDI v3 включены: описания средств определения и создания регистрационного ключа записи в реестре (чтобы обеспечить ее уникальность при использовании сети реестров) и управления им; API публикации данных в каталоге и подписки на эти данные (последнее важно, когда один каталог черпает данные из другого); механизм использования цифровых подписей XML (XML digital signatures, XML-DSIG, спецификация, разрабатываемая W3C), которыми можно заверить и защитить записи в каталоге. Более подробный обзор возможностей UDDI v3 содержится в работе "The Evolution of UDDI" группы The Stencil Group (www.stencilgroup.com).
В настоящий момент проект UDDI.org поглощен организацией OASIS (Organization for the Advancement of Structured Information Standards, www.oasis-open.com). Версия UDDI v2 уже утверждена ею как отраслевой стандарт, а UDDI v3 и спецификации канонических схем (Schema Centric Canonicalization) утверждены как спецификации подкомитета OASIS UDDI Spec.
Заметим также, что репозитории сервисов нужны не всегда. Если область использования сервиса невелика (скажем, он потребляется внутри небольшой организации), то наиболее оптимальным подходом будет составление простого их перечня в HTML, доступного разработчику для инспекции через браузер. IBM предложила специальный язык разметки Web Services Inspection Language (WSIL), обеспечивающий структуру этих описаний.
Web-сервисы и задачи интеграции
Web-сервисы обладают рядом свойств, которые делают их крайне привлекательными для решения задач интеграции.
Во-первых, они обеспечивают отличное средство для оформления компонентов бизнес-логики в качестве интерфейсов, программно легко доступных и допускающих многократное применение в разных приложениях. Они также расширяют концепцию программных компонентов за границы предприятия. Легко представить такие сервисы, как авторизация банковских карт в Интернете, оформленными в виде Web-сервисов (подобные проекты, кстати, сейчас есть). Разработчики могут собирать приложения из Web-сервисов как обычную головоломку.
Во-вторых, Web-сервисы - это удобный механизм для взаимодействия приложений: ведь в идеале все их API определены и опубликованы в каталогах UDDI.
И наконец, они (по крайней мере теоретически) обеспечивают защиту инвестиций, так как приложения, "обернутые" в Web-сервисы, в целом легче заменить. Стоит, правда, заметить, что такое возможно, только если 100% функциональности всех приложений оформлено в виде Web-сервисов. В реальности, однако, этого в ближайшее время не произойдет. А значит, задачи типа переноса данных все равно будут представлять проблему. Более того, сейчас лишь немногие приложения автоматизации ориентированы на архитектуру Web-сервисов. Следовательно, для их подключения будут требоваться адаптеры и интеграционное ПО, открывающие хотя бы часть функций приложений в виде WS.
Есть и другие проблемы. Для успеха Web-сервисов важно, чтобы реализации WS-инфраструктуры, предлагаемые разными производителями, были совместимы. Но пока этого нет, и для такой несовместимости существуют три причины:
· неоднозначность в трактовке разными вендорами ПО текстов спецификаций уже согласованных стандартов;
· различия в спецификациях, которые уже приобрели широкое признание;
· недостаточное понимание пользователями взаимосвязи между спецификациями.
Для решения этих проблем в 2003 г. создана организация Web Services-Interoperability (www.ws-i.org), которая пытается выработать некий общий знаменатель для технологий WS. В августе нынешнего года она выпустила свой первый документ - WS-I Basic Profile 1.0a, определяющий требования к различным компонентам архитектуры WS, которые могут гарантировать их совместимость и прояснить "скользкие" моменты в использовании этих технологий. Данный документ базируется на спецификациях SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0 и XML Schema. Первое, что здесь бросается в глаза: используются не новейшие версии всех спецификаций.
Рис. 3. Будущий стек технологий Web-сервисной интеграции
Кроме того, на сегодня утверждены лишь упомянутые выше три базовых стандарта (именно стандарты, а не спецификации). Чтобы начать работать с Web-сервисами, их достаточно, однако для решения сложных бизнес-задач требуется наличие стандартов другого уровня. Так, для построения законченной корпоративной инфраструктуры необходимо ПО, обеспечивающее моделирование бизнес-процессов, мониторинг процессов, преобразование форматов и трансформацию самих данных, средства обеспечения безопасности, средства управления операциями, асинхронного обмена сообщениями и выполнения транзакций. Ниже мы рассмотрим эти задачи чуть подробнее.
Проблемные направления: для разработчика
Трансформация данных. При традиционном интеграционном подходе эту функцию обеспечивает брокер сообщений. Переход на Web-сервисную архитектуру не снимает задачу преобразования данных с повестки дня. Конечно, Web-сервис с легкостью может быть вызван любым приложением, но в ответ оно получит данные во внутреннем формате вызываемой платформы. И для их преобразования потребуется дополнительное ПО.
Средства для графического построения схем преобразования данных предоставляются большинством современных платформ интеграции, поддерживающих технологию WS, - Microsoft BizTalk Server, SunONE Integration Server, BEA Integration Platform, IBM MQ Message Broker, Oracle9i AQ и т. п. Правила конвертации сохраняются пока в разных форматах (например, в виде Java-кода в IBM InterChange Server), но в будущем неминуем сдвиг к обмену исключительно XML-форматированными документами, с преобразованием при помощи таблиц стилей XSLT (eXtensible Stylesheet Language Transformations), механизмов запросов к базам данных XQuery и путей XPath. Серверы SunONE Intergation Server и Microsoft BizTalk уже сегодня используют XML для внутреннего представления сообщений и XSLT для их конвертации.
Адаптеры. На сегодня большинство крупных производителей бизнес-ПО объявили о переходе к WS-архитектуре. В качестве примеров можно привести Baan, новая ERP-платформа Gemini которой будет иметь Web-сервисный API, и SAP AG, заявившую о переходе к архитектуре xApps на базе WS. Однако у абсолютно всех унаследованных приложений WS-интерфейса не будет. Не стоит ожидать, что адаптеры решат все проблемы: основная часть функционала старых программ будет навсегда скрыта от мира Web-сервисов.
Асинхронность. Современная архитектура WS не предполагает подобной возможности: Web-сервисы можно вызывать только синхронно. Что касается средств асинхронного взаимодействия, то наборы XML-стандартов RosettaNet и ebXML включают и спецификации на гарантированный обмен сообщениями, однако SOAP, лежащий в основе WS, не предусматривает ни гарантированной доставки, ни многоузловой маршрутизации. Недавно компании webMethods, Microsoft, IBM, Intel и другие предложили создать рабочую группу в W3C, которая займется решением этих проблем SOAP. В рамках организации OASIS уже действует комитет Web Services Reliable Messaging, призванный создать "общую и открытую модель" для гарантированной доставки сообщений Web-сервисам.
Пока же решения можно создавать только при помощи интеграционных шин. Например, российский продукт "Юпитер" компании ИВК предлагает прокси-компонент, позволяющий территориально удаленным приложениям вести сессии по протоколу HTTP (который SOAP использует в качестве транспорта) с гарантированной доставкой пакетов. Важно только правильно оформить вызов к Web-методу. Но для удобства работы с асинхронным обменом сообщениями требуется поддержка на уровне языка программирования и платформы исполнения, а эта поддержка не всегда имеется. Так, Java API for XML Messaging (JAXM) пока обеспечивает вызов Web-сервиса только синхронным способом.
Транзакционность. Web-сервисы не предусматривают возможности "отката" внесенных изменений, они по природе своей атомарны: сервис отработал, и состояние объекта, с которым он связан, изменилось. Нет также никаких стандартов, определяющих, как можно распространить контекст большой транзакции внутрь Web-сервиса.
Сейчас в мире делается ряд попыток создать необходимую базу спецификаций для координации транзакций. Первая такая попытка была предпринята в 2000 г., когда Oracle, IBM, Hewlett-Packard, Sun Microsystems и др. образовали организацию XAML. Она должна была разработать спецификацию одноименного языка (Transaction Authority Mark-up Language) для описания правил координации и исполнения транзакций, построенных на базе XML-ориентированных Web-сервисов. Однако Microsoft не поддержала этого начинания и оно закончилось ничем: несколько лет о проекте нет новостей, а теперь даже сайт xaml.org перестал функционировать, а аббревиатура XAML используется Microsoft для обозначения совсем другой технологии.
Примерно тогда же BEA предложила аналогичный протокол Business Transaction Protocol (BTP), который подала на утверждение в OASIS. Предполагалось сделать акцент на его совместимость с ebXML (www.ebxml.org) и RosettaNet (www.rosettanet.org). Им теперь занимается одноименный комитет этой организации, одобривший версию 1.0 в мае 2002 г. в статусе "спецификации комитета".
Нынешним летом был предложен еще ряд решений. Группа компаний, возглавляемая Sun Microsystems и Oracle, анонсировала проект Web Services Composite Application Framework (WS-CAF; http://developers.sun.com/techtopics/webservices/wscaf/) и сразу же передала его на попечительство соответствующего технического комитета в OASIS. Выдвинуто три спецификации, описывающие механизм координации транзакций в многошаговых бизнес-процессах: Web Service Context (WS-CTX), Web Service Coordination Framework (WS-CF) и Web Service Transaction Management (WS-TXM). Они определяют способ конфигурирования машин таким образом, чтобы Web-сервисные приложения (в том числе разных вендоров) могли обмениваться важной транзакционной информацией, в частности передавать контекст транзакции. Однако этот проект пока не поддерживают IBM и Microsoft, причем последняя уже отказалась в нем участвовать. Год назад Microsoft предложила свое решение проблемы WS-транзакций - WS-Transaction (WS-Tx). Она же предлагает в своей платформе .Net протокол многоузловой маршрутизации WS-Routing.
Динамическое согласование параметров запроса. Эта задача, возникающая при проектировании систем электронного бизнеса, также пока не решена с помощью стандартов WS. Попытки создать необходимую базу стандартов делаются в рамках консорциума ebXML, в котором для этого разрабатывается спецификация Collaboration-Protocol Profile and Agreement (CPP/CPA, текущая версия 2.0).
Workflow и управление бизнес-процессами. Современный уровень развития WS не обеспечивает стандартных механизмов описания на XML бизнес-процессов, состоящих из обращений к Web-сервисам и организации составных сервисов.
Пока на рынке есть лишь ряд технологий, эту задачу решающих. Например, XLANG, используемая в Microsoft BizTalk Server, ebXML Business Process Schema Specification (BPSS) и Web Services Business Process Execution Language (BPEL4WS), поддержка которой должна появиться в BizTalk Server2004. Корпорация IBM, со своей стороны, предложила спецификацию Web Services Flow Language (WSFL), которая позволяет описать сервис, состоящий из более мелких сервисов. Для описания бизнес-процессов иногда применяют и спецификацию RosettaNet PIP, хотя она не заточена под модель WS, да к тому же является "бумажной" (т. е. не машинно-обрабатываемой).
Сейчас BPEL4WS проходит утверждение в организации OASIS и в будущем, вероятно, станет основным стандартом на подобные вещи.
Проблемные направления: инфраструктурные
Безопасность. Наиболее "кричащий" пробел архитектуры WS: здесь требуются функции шифрования сообщений (а не пакетов, ведь сообщения проходят по многим узлам в Интернете), средства аутентификации и авторизации, в том числе однократной (single sign-on).
Даже в версии SOAP 1.2 проблеме безопасности уделено крайне скудное внимание. Она все еще отсылает по этим вопросам к наработкам рабочих групп W3C в области общих стандартов безопасности XML и к наработкам технического комитета Web Services Security (WS-Security, о нем см. ниже) организации OASIS. Поэтому пользователи SOAP должны пока опираться на отдельные аутентификационные технологии, а для защиты SOAP-сообщений применять технологии шифрования в виртуальных каналах точка - точка. В настоящее время таких технологий разработано множество: XML Key management specification (управление XML-ключами, XKMS), Security Assertion Markup Language (SAML), XML-DSIG, SOAP-SEC и пр.
Протокол авторизации XKMS был совместно разработан и предложен для утверждения W3C компаниями webMethods, Microsoft и Verisign в марте 2001-го.
SAML 1.0 поддерживается группой из 13 вендоров, включая Sun Microsystems, Baltimore Technologies, Entegrity Solutions, Novell, Netegrity, Oblix и RSA Security. Сейчас он развивается тем же комитетом OASIS Security Services.
Этот протокол предлагает стандартный способ обмена идентификационной информацией пользователя (протокол опирается на XML и SOAP), что дает ему возможность однократной аутентификации для доступа к ресурсам. SAML также обеспечивает удаленную авторизацию, т. е. один сайт может попросить у другого аутентифицировать пользователя и, быть может, переслать о нем какую-то дополнительную информацию. Один из трех описываемых SAML сценариев затрагивает аутентификацию Web-серверов.
И, наконец, IBM и Microsoft анонсировали уже упомянутый протокол WS-Security, работа над которым теперь идет в рамках все того же технического комитета OASIS. Этот стандарт дополняет SAML: если WS-Security определяет, как и в каком именно месте размещать идентификационные данные в конверте SOAP-сообщения, то SAML описывает требования к набору подобных сведений.
Среди поставщиков средств по управлению и безопасности, поддержавших WS-Security, можно упомянуть Computer Associates и саму IBM. Computer Associates предоставит расширенные функции по обеспечению безопасности WS, основанные на модели специализированных прокси-серверов.
Мониторинг и управление. Качество обслуживания также пока не затрагивается никакими стандартами WS. Это проблема сложная, касающаяся не только мониторинга состояния самого сервиса, но и инфраструктуры, на которой он базируется. И Computer Associates, и другие поставщики решений управления инфраструктурой уже сейчас выпускают продукты, позволяющие такое качество обслуживания комплексно обеспечить.
Среди потенциальных стандартов в этой области нужно назвать спецификацию Open Management Interface (OMI), созданную компаниями webMethods (она выпускает ПО интеграции) и Hewlett-Packard. Ее поддерживают и другие производители ПО управления - HP, IBM/Tivoli, CA, BMC Software.
OMI дает стандартный способ определения Web-сервисов как управляемых сетевых ресурсов, позволяет задавать их жизненный цикл (т. е. время доступности, активацию и дезактивацию сервиса, его внешние точки доступа и пр.), управлять правами доступа к сервису (в том числе задавать приоритеты в обслуживании одних пользователей перед другими), описывать правила балансировки нагрузки между дубликатами одного сервиса, мониторинга качества обслуживания (с генерацией сигналов тревог при нарушении) и управления версиями сервисов и вспомогательными ресурсами для них.
Выводы
Web-сервисы - интересная нарождающаяся технология, но ее использование пока сопряжено с трудностями. Вероятно, в течение ближайших трех лет "утрясутся" стандарты на решения основных проблем, сопряженных с WS, но пока уверенно их можно использовать лишь в экспериментах и для решения простых задач. В сложных же интеграционных проектах они не выдерживают конкуренции с традиционными платформами интеграции, которые, кстати, постепенно вбирают в себя и поддержку Web-сервисов.
Окончание. Начало см. в PC Week/RE, N 35/2003, с. 37.
