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

В идеале SOA должна быть многоуровневой средой. Объединенные в бизнес-приложения сервисы, которые реализуют бизнес-логику, образуют ее верхний уровень. Лежащие в их основе ИТ-среды также могут быть организованы по принципам сервис-ориентированной архитектуры и предоставлять в качестве сервисов свои ресурсы. Системы управления такими инфраструктурными сервисами, в свою очередь, используют механизмы Web-сервисов для мониторинга и контроля над распределенными гетерогенными средами. Отсюда — еще одно направление в современной программной индустрии: управление с помощью Web-сервисов.

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

SOA под контролем

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

Роль системы управления в данном случае традиционна: обеспечить постоянный мониторинг и контроль над работающими в SOA приложениями с тем, чтобы потенциальные проблемы выявлялись и корректировались прежде, чем они нанесут существенный урон процессам бизнеса. Нетрадиционными являются лишь объекты управления — интерфейсы и транзакции взаимодействия Web-сервисов.

Существует набор управляющих функций, общих для любых сред развертывания Web-сервисов. Для SOA производственного уровня реализация этих функций должна быть задачей соответствующей инфраструктуры, дабы не заставлять разработчиков приложений заботиться о проблемах мониторинга и безопасности при создании каждого нового сервиса. Эту задачу решает программное обеспечение управления Web-сервисами. На нем специализируются и нишевые производители, наподобие Blue Titan Software или Infravio, и ведущие игроки рынка системного управления, в том числе IBM, HP, BMC и CA. По оценкам компании ZapThink, объем рынка управления Web-сервисами и SOA в будущем году превысит 9 млрд долл. Как отмечают аналитики, о приближении данного рынка к состоянию зрелости свидетельствует тот факт, что большинство представленных на нем продуктов уже обеспечивают стандартный набор функций, решающих общие задачи управления средой взаимодействия сервисов.

Управление Web-сервисами включает в себя большинство классических функций системного управления: мониторинг, генерацию сообщений для системного администратора, управление соглашениями об уровне обслуживания (SLA, Service Level Agreement) и качеством сервиса, обработку исключительных ситуаций, анализ корневых причин сбоев. Однако, в отличие от обычного системного управления, отвечающего за нормальное функционирование компонентов ИТ-инфраструктуры и приложений, решения для управления Web-сервисами контролируют коммуникации между приложениями и обеспечивают необходимые взаимосвязи при выполнении сложных бизнес-процессов.

Продукты системного управления могут определить, что послано сообщение определенного типа, но «не видят» его содержание. Системы управления Web-сервисами, основанные на таких базовых стандартах, как XML, SOAP и WSDL, способны диагностировать не только типы, но и семантику запросов. Например, средства мониторинга приложений, построенных с помощью Web-сервисов, отслеживают текущее состояние сервисов, перехватывая запросы и ответы от них без вмешательства в код приложения.

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

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

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

Безопасность — важнейшая характеристика SOA корпоративного уровня. Как правило, она обеспечивается путем кооперации возможностей системы управления Web-сервисами и инфраструктурной платформы их развертывания. Во многих продуктах для управления Web-сервисами защита является одной из базовых функций. В среде SOA безопасность подразумевает поддержку таких средств:

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

WSDM

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

Основные усилия поставщиков и организаций по стандартизации сосредоточены на двух стандартах управления — WSDM и WS-Management.

Спецификация распределенного управления Web-сервисами Web Services Distributed Management (WSDM) сначала разрабатывалась компаниями CA, IBM и Talking Blocks. Затем последняя была поглощена HP, помимо которой к группе разработчиков WSDM присоединилась компания BMC Software. С февраля 2003 года работа над стандартом проходит под эгидой консорциума OASIS (Organization for the Achievement of Srtuctured Information Standards), который официально одобрил WSDM в марте 2005 году.

В принципе, WSDM представляет собой не одну, а две спецификации — Management Using Web Services (MUWS) и Management of Web Services (MOWS). MUWS определяет представление интерфейсов управления произвольными ИТ-ресурсами в виде Web-сервисов. Эта спецификация задает базу для использования технологии Web-сервисов при создании управляющих приложений и описывает единые механизмы управления ресурсами для таких приложений. MOWS, основываясь на стандарте MUWS, определяет, как управлять Web-сервисами. Эта спецификация задает механизмы и методологии, с помощью которых обеспечивается интеграция управления приложениями на базе Web-сервисов. MUWS позволяет реализовать общую среду управления разнородными ресурсами, объединив различные управляющие продукты. В свою очередь, MOWS, опираясь на первую спецификацию стандарта WSDM, обеспечивает управляемость интегрированной среды композитных бизнес-приложений и, в конечном счете, управляемость SOA, которая объединяет внутренние корпоративные сервисы и прикладные компоненты партнеров.

WSDM MUWS

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

Существуют стандартные модели. Например, разрабатываемая организацией Distributed Management Task Force (DMTF) модель CIM (Common Information Model) определяет, какая управляющая информация необходима для систем, сетей и приложений. WSDM MUWS дополняет модель управления, задавая механизм ее выражения с помощью схем XML и доступа к модели посредством Web-сервисов. Основанная на MUWS спецификация MOWS обеспечивает информационную модель управления для Web-сервисов, определяя возможности управляемости и атрибуты объектов, которые заданы как Web-сервисы.

Стандарт WSDM не связан с какой-либо конкретной инструментальной технологией управления и предполагает, что интерфейс доступа к управляемому ресурсу полностью независим от технологии (JMX, WMI, Java и др.). Это значительно увеличивает гибкость управления при работе в распределенной неоднородной среде. Надо сказать, уже существуют специальные коннекторы для связи интерфейсов WSDM с инструментальными средствами управления, например Apache Muse и Web Services Connector for Java Management Extensions (JMX) Agents (рис. 1).

Возможности управления в распределенной среде, совместимость различных систем управления и независимость от платформ реализации управляемых ресурсов, которые обеспечивает WSDM, достигаются благодаря тому, что эта спецификация опирается на базовые стандарты Web-сервисов (XML, WSDL, SOAP и WS-Addressing), а также ряд специальных стандартов, развиваемых OASIS (рис. 2).

Рис. 2. Технологический стек WSDM

Спецификация WSDM MUWS задает базовый набор интерфейсов, или возможностей управляемости (manageability capabilitity), которыми может быть описан управляемый ресурс. Она определяет и стандартный формат управляющих событий, благодаря чему обеспечивается корреляция событий в разных системах управления.

Возможности управляемости можно рассматривать как некий «контракт». В нем определяется, что управляемый ресурс может предложить системе управления для своего мониторинга и контроля. MUWS описывает концептуальные, общие для всех моделей управления возможности, позволяя комбинировать их в зависимости от принятой модели и типа ресурса, а при необходимости — расширять их спектр в конкретной системе управления.

MUWS включает в себя следующие возможности управляемости:

  • характеристики управляемости (manageability characteristics) описывают возможности, которые поддерживаются для данного ресурса;
  • идентификация (identity) задает уникальный идентификатор ресурса;
  • описание (description) формулирует версии ресурса;
  • свойства корреляции (correlatable property) — набор свойств ресурса, которые показывают, что два управляемых ресурса с разной идентификацией на самом деле являются одним и тем же ресурсом;
  • метрики (metrics) определяют, как собираются данные о производительности и другая статистика по ресурсу в заданные интервалы времени. MUWS предоставляет специальные атрибуты для управления процессом сбора метрик;
  • конфигурация (configuration) определяет, как осуществлять мониторинг и конфигурировать ресурс;
  • состояние (state) определяет модель состояния ресурса, которая позволяет отслеживать переход из одного состояния в другое и контролировать поведение ресурса;
  • оперативный статус (operational status) определяет три простейших статуса ресурса (доступный, недоступный и неизвестный);
  • объявление (advertisement) определяет стандартное уведомление, которое должно быть послано системе управления при создании ресурса;
  • зависимости (relationship) описывают зависимости между ресурсами (например, дисковый накопитель присоединен к серверу).

Таким образом, задаваемые в MUWS интерфейсы ресурса позволяют управляющей системе идентифицировать ресурс, выявлять его уникальность, определять зависимости между ресурсами, получать сообщения при появлении новых ресурсов, собирать статистику о производительности и получать информацию о рабочем состоянии ресурса. Для реализации этих функций MUWS использует средства двух других групп спецификаций Web-сервисов — WS-Resource Framework (WS-RF) и WS-Notification (WS-N).

WS-RF описывает механизмы доступа к ресурсам с сохранением состояния, представленным в виде Web-сервисов. WS-RF использует спецификацию WS-Addressing, которая позволяет задать для таких ресурсов «конечные точки» (endpoint) Web-сервисов. Одно из общих требований системы управления — получить информацию о свойствах данного управляемого ресурса или разместить ресурс, соответствующий определенным критериям. В WS-RF определяется спецификация WS-ResourceProperties, описывающая способ представления, объявления и доступа к свойствам ресурса, таким как число и размер блоков дискового накопителя.

Семейство спецификаций WS-N задает модель уведомлений о событиях для Web-сервисов. Частью этой модели является стандарт WS-BaseNotification, определяющий набор сообщений для реализации модели взаимодействия сервисов на основе событий, то есть по принципу «публикация-подписка». Спецификация WS-Topics, также входящая в WS-N, используется для представления и задания характеристик элементов, которые могут содержаться в уведомлениях о событиях.

Стандартный XML-формат событий WSDM Event Format определяет базовые данные по управляющим событиям разных типов, обеспечивает согласованную обработку, корреляцию и интерпретацию событий управляющими системами в среде Web-сервисов. Этот формат включает в себя три категории данных об управляющих событиях: источник сообщения, причина события и данные о ситуации. В каждой категории описывается набор стандартных свойств, характерных для большинства управляющих событий, который может быть при необходимости расширен. Например, данные о ситуации позволяют описать специфический тип ситуации, в которой произошло событие, ее статус, время и сообщение о событии. Таким образом механизм уведомлений MUWS в совокупности со стандартным описанием формата сообщений обеспечивает согласованный способ передачи управляющей системе сообщений о событиях, отслеживание изменений в статусе ресурса и внештатные ситуации.

WSDM MOWS

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

Ценность стандарта WSDM MOWS состоит в том, что он, опираясь на механизмы управления MUWS и стандарты Web-сервисов, позволяет скомбинировать в одном Web-сервисе его функциональные характеристики и свойства управляемости. Это открывает широкие возможности для реальной адаптивности ИТ-инфраструктуры, предназначенной для поддержки бизнес-процессов. В такой среде несложно перейти от использования сервиса как задачи в рамках бизнес-процесса к управлению этим сервисом, если при выполнении задачи произошел сбой. Можно автоматически в режиме реального времени предпринять корректирующие действия или перенаправить запросы другому Web-сервису.

Рассмотрим простой пример — Web-сервис печати (рис. 3). Ресурс, сетевой принтер, представлен как Web-сервис, функциональный интерфейс которого обеспечивает единственную возможность — печать. Интерфейс управления этим ресурсом как устройством печати включает в себя два свойства (счетчик напечатанных страниц и доступную емкость картриджа) и операцию активации печати. Наконец, возможности управления принтером как Web-сервисом печати включают в себя метрику числа запросов и операции контроля над оперативным статусом принтера (старт/стоп).

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

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

Стандарт WSDM уже поддерживается продуктами ведущих производителей средств системного управления. Компания HP после приобретения Talking Blocks пополнила свое семейство OpenView системой SOA Manager и обеспечила поддержку подключаемых модулей OpenView Smart Plug-in на базе технологий WSDM. В свою очередь CA, один из основных разработчиков WSDM, уже не первый год продвигает систему управления Web-сервисами с идентичным стандарту названием Web Services Distributed Management. В конце 2005 года IBM представила пакет средств разработки инструментов управления на базе WSDM. Компания использует формат уведомлений о событиях WSDM в ряде продуктов управляющего семейства Tivoli. Поддержку спецификаций WSDM реализовали в своих решениях также Cisco Systems, Fujitsu, AmberPoint, Hitachi, Tibco Software и SOA Software.

WS-Management

В октябре 2004 года корпорация Microsoft совместно с Sun Microsystems, Dell, Intel и AMD опубликовала спецификацию WS-Management. Основным инициатором разработки была именно Microsoft, несколькими месяцами ранее продемонстрировавшая эту технологию под названием WMX (Web services Management Extensions). В августе 2005 года спецификация WS-Management была представлена на рассмотрение DMTF.

Как и WSDM MUWS, WS-Management определяет, как использовать Web-сервисы в качестве средства удаленного управления компьютерными ресурсами. В качестве базы обмена данными с управляемыми устройствами WS-Management использует спецификации обеспечения транзакций, безопасности и надежности коммуникаций в среде Web-сервисов (WS-Policy, WS-Trust, WS-SecureConversation, WS-Federation).

Спецификации WS-Management и WSDM MUWS имеют ряд общих черт. Обе подразумевают, что управляемый ресурс представлен как XML-документ, доступный с помощью механизмов протокола SOAP. Обе поддерживают индивидуальную адресацию каждого ресурса с помощью WS-Addressing, допуская возможность XML-представления группы ресурсов как единого компонента управляемой системы. Основное различие между спецификациями состоит в масштабах сред и уровне сложности компьютерных ресурсов, которыми нужно управлять.

При разработке WS-Management стояла задача оптимизации управления небольшими системами — сетевыми и карманными устройствами, персональными компьютерами, серверами начального и среднего уровня (в том числе на базе «лезвийной» архитектуры), сервисами операционных систем. Аналитики ZapThink, например, прогнозировали, что WS-Management может стать достойной альтернативой устаревающему протоколу SNMP при управлении удаленными устройствами, сняв целый ряд его недостатков, таких как отсутствие механизмов защиты. Правда, поддержка безопасных надежных коммуникаций управления имеет и отрицательные стороны. WS-Management создает дополнительный XML-трафик, который и так значителен, а в текущем году, по оценкам ZapThink, составит не менее четверти общего объема передачи данных в корпоративных информационных средах.

Однако WS-Management не замахивается на управление высокобюджетными распределенными центрами данных со сложным разнородным оборудованием и критически важными приложениями. Эта задача под силу стандарту WSDM, что, кстати, символизирует буква D (distributed) в его названии. С точки зрения деталей спецификаций такое различие реализуется, в том числе путем адресации управляемых ресурсов. Как уже отмечалось, обе спецификации используют протокол WS-Addressing, а именно механизм присваивания каждому ресурсу идентификатора EPR (WS-Addressing Endpoint Reference). Однако если WS-Management определяет структуру EPR, то WSDM не накладывает на нее ограничений, допуская управление оборудованием и системами произвольных типов и уровней сложности. Такой подход обеспечивает и выполнение принципа слабой связанности сервиса управления ресурсом с потребителем этого сервиса — управляющей системой, которая может не интересоваться деталями адресации управляемого ресурса.

WS-Management позволяет идентифицировать управляемый ресурс как Web-сервис и взаимодействовать с ним как с Web-сервисом. Возможности доступа к свойствам управляемых ресурсов, сбора метрик, управления их состоянием и статусом, определения зависимостей между ресурсами эта спецификация, в отличие от WSDM MUWS, не поддерживает. WSDM задействует все соответствующие опции интерфейсов управления для описания разных по степени сложности ресурсов. Комбинации этих сведений позволяют представлять разные модели управления, хотя, как уже отмечалось, WSDM сама не задает определенной модели. WS-Management вообще не имеет инструментов описания многообразной управляющей информации о ресурсе, что, с одной стороны, подчеркивает ограниченность возможностей данного стандарта при сложном управлении, а с другой, — упрощает его интеграцию с существующими моделями, например с CIM.

Разработчики спецификации WS-Management уже реализовали ее в своих продуктах или планируют это сделать. Так, Microsoft обеспечила поддержку WS-Management в новой версии Windows Server 2003 R2. Корпорация Sun реализовала WS-Management на Java и включает данную спецификацию в Solaris 10, N1 Grid и Sun Management Center для организации совместимости с управляющими решениями Microsoft. Компания Intel намерена использовать WS-Management в технологии управления на уровне процессорной платформы Active Management Technology (AMT). Одновременно основные представители групп разработчиков конкурирующих стандартов управления на базе Web-сервисов инициировали процесс их унификации, справедливо полагая, что от этого ситуация с управлением неоднородными информационными средами только выиграет.

В марте HP, IBM, Intel и Microsoft опубликовали описание планируемых обновлений и новых спецификаций из серии WS-*. Они позволят объединить функциональность многочисленных спецификаций задания ресурсов, поддержки коммуникаций между Web-сервисами на основе событий и реализации платформы Web-сервисов для построения систем управления. Последнее подразумевает конвергенцию стандартов WSDM MUWS и WS-management. На воплощение этих планов, то есть создание и публикацию первых версий унифицированных спецификаций, а также их доработку и представление в органы по стандартизации отведены полтора-два года.

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

Как закалялся WSDM

ИТ-менеджерам необходимо знать, кто, когда и откуда обращается к сервисам, насколько их операционные характеристики соответствуют целевым и т.д. Для интеграции всевозможных Web-сервисных контейнеров и промежуточного программного обеспечения со средствами мониторинга и управления и задуман стандарт WSDM, разработкой которого занимается одноименный комитет под эгидой OASIS. Первое виртуальное заседание экспертов состоялось 2 апреля 2003 года, а финальная версия спецификации должна была появиться к январю 2004-го.

Однако спецификация, в значительной степени подготовленная, так и не была представлена общественности. В соответствии с духом WS-* авторы предпочитали не изобретать велосипед, а воспользоваться другими стандартами, дополняющими WSDM. Но те стандарты, на которых был основан WSDM, никак не могли получить официального статуса. В итоге сложилась парадоксальная ситуация: фактически завершенный стандарт WSDM 1.0 ссылается на целый ряд никем не утвержденных спецификаций.

Среди них — и спецификация WS-Addressing, имевшая в 2004 году статус начального драфта соответствующей рабочей группы W3C. Последняя констатировала, что официальная версия этого стандарта может существенно отличаться от варианта, по сути, уже заложенного в WSDM. Более того, спецификация WS-Notification, также используемая в WSDM наряду с несколькими другими рабочими драфтами, ссылается на еще более раннюю версию WS-Addressing. В конце концов эти противоречия удалось частично преодолеть. Стандарт был принят OASIS в марте 2005 года в виде двух спецификаций — MUWS 1.0 (о предоставлении Web-сервисных интерфейсов управления произвольными ИТ-ресурсами) и дополняющей ее MOWS 1.0 (об использовании модели и интерфейсов MUWS применительно к самим Web-сервисам).

Нелегкий путь WSDM только начался. Без маломальской инструментальной поддержки обеспечение управляемости Web-сервисов представляется весьма трудоемким, требующим высокой квалификации разработчика. Однако поставщики серверов приложений восприняли WSDM без энтузиазма. Они предоставляют функции управления сервисами через собственные административные консоли, а также более традиционные машинные интерфейсы на базе JMX и SNMP. Несмотря на поддержку WSDM основными платформами управления CA, HP и IBM, для управления сервисами до сих пор используются методики, отработанные на других видах программного обеспечения.

Важно и то, что Web-сервисы, в силу своей открытости, представляют особый интерес для администраторов. Пока WSDM проходил процедуры согласования и утверждения, успел расцвести целый рынок средств Web Services Management (WSM), отличных от традиционных инструментов системного управления. Эти средства (как в программном, так и в программно-аппаратном исполнении) технологически представляют собой сетевой промежуточный слой, передающий сообщения между сервисами и их потребителями. Вместо прямого обращения к сервисам системы-потребители обращаются к их WSM-проекциям. Уже потом слой WSM, эмулируя клиента, обращается к самому сервису с запросом и возвращает ответ (при его наличии). Естественно, одновременно осуществляются мониторинг проходящих сообщений и сбор необходимых администраторам метрик о сервисах.

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

К преимуществам «посреднического» подхода WSM можно отнести практически полную прозрачность и совместимость с любыми приложениями, в том числе «не подозревающими», что за ними «наблюдают». Это означает, что элементарной поддержкой управления сервисы можно снабдить постфактум, что бывает весьма кстати. Заодно есть возможность использования некоторых функций, традиционно относящихся к интеграционным брокерам. Так, WSM зачастую обеспечивает преобразование если не самих запросов, то, по крайней мере, некоторых аспектов протокола взаимодействия сервиса и клиента (например, преобразование SOAP 1.1 в SOAP 1.2, добавление заголовков WS-Security и т.п.).

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

Осознавая все эти проблемы, разработчики систем WSM перешли к технологии легковесных «агентов», встраиваемых в сервер приложений и осуществляющих сбор операционных показателей непосредственно в контейнерах Web-сервисов. Таким образом, сетевые маршруты запросов больше не пришлось искажать, что привело к уменьшению трафика и позволило использовать уже существующие аппаратные ресурсы без существенных «накладных» издержек. Собираемые агентами сведения пересылаются в систему, осуществляющую их хранение и анализ. В качестве «витрины» операционных данных выступают как собственные пользовательские порталы WSM, так и реестры UDDI, в которых информация может быть опубликована для последующей визуализации или машинной обработки (например, для балансировки нагрузки либо перераспределения вычислительных ресурсов). Реестр UDDI (если он корректно используется) также служит оптимальным первичным источником данных о доступных сервисах, поскольку обеспечивает организацию замкнутого процесса управления SOA.

Агенты WSM дублируют значительную часть функциональности WSDM, который и задумывался во избежание необходимости создания таких агентов каждым из поставщиков с целью поддержки всех мыслимых контейнеров Web-сервисов. Остается надеяться, что ситуация изменится с выходом WSDM 1.1, период публичного ознакомления с которым завершился в мае 2006-го. В отличие от предшествующей версии, новые спецификации MUWS 1.1 и MOWS 1.1 ссылаются на завершенные официальные стандарты OASIS и W3C. Последний из них, злополучный WS-Addressing, которого с нетерпением ждали в технических комитетах OASIS и W3C, получил наивысший статус Рекомендации W3C только 9 мая 2006 года. Поддержка WSDM платформами исполнения сервисов и соответствующими инструментальными средствами позволит заменить агенты WSM-систем на стандартные интерфейсы и снизить зависимость от конкретных систем управления.

Даниил Фейгин (feygin@unitspace.com), член консорциума OASIS, технический директор компании UnitSpace (Москва).