© Майк Лехманн
Статья была опубликована на сайте www.citforum.ru
Если вы полагаете, что термин Web services определяется не строго, поищите четкое определение термину управление Web-сервисами (Web services management). Некоторые думают, что он просто означает конфигурирование, мониторинг, аудит и журнализацию Web-сервисов (Web service configuration, monitoring, auditing, and logging). Другие определяют его более абстрактно, используя такие термины, как визуализация, уведомление, взаимодействие с протоколами и предоставление сервисов (service virtualization, notifications, protocol mediation, and provisioning).
Давайте разберемся с этой проблемой, которая часто возникает, как только вы переходите от работы с полудюжиной Web-сервисов к полновесным бизнес-сценариям, в рамках которых десятки Web-сервисов связываются в бизнес-процесс или сложное приложение.
На самом нижнем уровне Web-сервис – это просто еще одна программа, выполняющаяся в недрах вашей вычислительной инфраструктуры. С точки зрения управления, существует некоторое множество основных (ключевых) функций, которые применяются для управления Web-сервисами. В их числе - развертывание, конфигурирование и обеспечение безопасности (deployment, configuration, and security support), они комбинируюттся с некоторыми основными возможностями мониторинга и диагностики.
Эти ключевые функции реализованы в Oracle Application Server Control, консоли управления сервера приложений Oracle Application Server 10g, как показано на рисунке. Используя эту консоль, с которой можно работать через Web-браузер, вы можете легко управлять любым Web-сервисом в среде Java (J2EE Web service).
По мере перехода отрасли на платформу J2EE 1.4, эта консоль будет развиваться, чтобы обеспечить разработчиков средствами конфигурирования и мониторинга всех новых артефактов стандарта JAX-RPC, включая конфигурирование согласно спецификации JSR 109 (JSR 109 configuration), хендлеры JAX-RPC и затем обеспечение надежности, транзакций и безопасности Web-сервисов (Web services reliability, transactions, and security). Эта интегрированная консоль управления имеет особое значение в стандартизации JAX-RPC как части J2EE—инфраструктуры управления, которую ваш J2EE-сервер предлагает, чтобы в равной степени использоваться как с Web-сервисами, так и с классическими J2EE-компонентами.
В версии Oracle Application Server Containers for J2EE 10g (OC4J) Developer Preview 10.0.3, когда я создавал примеры JAX-RPC (см. врезку "Следующие шаги"), инфраструктура управления, лежащая в основе Application Server Control, была расширена для включения Java Management Extensions (JMX). В данном случае эти ранее реализованные возможности по-прежнему доступны, но новая консоль управления будет предоставлять возможности конфигурирования и мониторинга Web-сервисами через стандартные модули (beans - "бобы") JMX MBeans. Чтобы взглянуть на эти "бобы" (Web service Mbeans) через JMX-браузер прямо, перейдите на страницу http://127.0.0.1:8888/adminoc4j вашей OC4J 10.0.3 Developer Preview и запросите Web service MBeans.
Хотя управление Web-сервисом, как компонентом, необходимо предлолагает начало деятельности Web-сервиса, необходимо подчеркнуть тот ключевой аспект, который отличает большинство Web-сервисов от протоколов передачи двоичных данных в моделях программирования таких, как CORBA и DCOM: Web-сервисы – это технология работы с сообщениями, в которой и передача сообщений основана на XML (Simple Object Access Protocol [SOAP]), и они сами описываются на XML (Web Services Description Language [WSDL]).
В моей предыдущей статье я объяснил, как написать хендлер JAX-RPC для аудита и журнализации контента на основе SOAP. Сила такого подхода заключается в возможности манипулировать, перехватить и запросить "сырое" XML-сообщение по дороге к его пункту назначения.
С этим подходом связано несколько проблем, несмотря на очевидную привлекательность полного доступа к передаваемому сообщению. Например, для относительно типичной утилиты журнализации или аудита, этот подход не является слишком уж простым и декларативным — хендлер должен быть написан вручную (custom-written) и сконфигурирован для каждого Web-сервиса. Хотя хендлеры делают возможными сложные вещи, они не позволяют легко делать вещи простые.
Если вы отступите дальше и представите работу с Web-сервисами в разнородной среде, а это, скорей всего, наиболее типичное использование Web-сервисов, поскольку они по сути – технология интеграции, то применение хендлеров становится еще более проблематичным, так как они привязаны к JAX-RPC и не работают, если конечная точка (endpoint) вашего Web-сервиса реализована на C, Visual BASIC или Perl.
Таблица 1: Пример того, как может измениться входное сообщение
Тело оригинального входящего SOAP-сообщения
| ... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> </ns0:getEmpSalaryElement> </env:Body> ... |
SOAP-сообщение с новым параметром
| ... <env:Body> <ns0:getEmpSalaryElement> <String_1>7369</String_1> <salary_type>Commission</salary_type> </ns0:getEmpSalaryElement> </env:Body> ... |
Более общий подход заключается в том, что ввести "посредника" между потребителем сервиса и и его провайдером. Перехват сообщения на уровне трафика для его обработки - не новая идея. Она уже используется в Web-мире на уровне как оборудования, так и софтвера для балансирования загрузки, ускорения, маршрутизации и кеширования (load balancing, acceleration, routing, and caching).
Как только вы поймете, что вы можете не только инспектировать и манипулировать контентом SOAP-сообщения, но и применяя WSDL, получить полное представление о формате этого сообщения, его операторов и конечных точек, возможности этого подхода становятся весьма интересными.
Например, рассмотрим простой случай использования сервиса с таблицей Employee salary из моей предыдущей статьи. Этот сервис на основе номера служащего (employee number) возвращает соответствующую информацию о зарплате. Представьте, что после нескольких месяцев применения, этот сервис начинает использоваться несколькими крупными подразделениями в компании, и многие люди просят, чтобы сервис предоставлял и информацию о комиссионных. Разработчики решают просить пользователей этого сервиса изменить входящее сообщение, которое ранее содержало только номер служащего, чтобы оно включало дополнительный параметр, <salary_type> (тип зарплаты), отмечая что именно: зарплата (salary), комиссионные или они оба должны быть возвращены. Таблица 1 показывает разницу между двумя этими форматами.
В идеальном мире, и провайдер, и пользователи этого Web-сервиса должны изменить свои среды одновременно, чтобы поддержать новый параметр, и вычислительная система должна быть модернизирована. В мире Web-сервисов, в котором у провайдеров и потребителей часто различные приоритеты, несвязанные расписания модернизаций и нередко трудно изменяемые инфраструктуры, такая (одновременная) реализация этих модернизаций часто затруднительна.
Решение? Есть немало возможностей на уровне управления, с которыми можно "понять" передаваемое сообщение. Одна из них заключается в том, чтобы "ловить" передаваемые сообщения со старой подписью и маршрутизировать их к старой реализации (old implementation) — простое решение на основе версий. Другой подход заключается в том, чтобы преобразовать сообщения старого формата (old-style messages) без параметра <salary_type> в новый формат с включением значения по умолчанию для этого параметра. Такой тип абстракции реализации называется виртуализацией сервиса (service virtualization).
Результат этого подхода – провайдер сервиса может выполнять модернизацию по расписанию, независимому от потребителей сервиса. Еще лучше то, что процесс управления происходит на "лету" независимо от реализации, можно проводить модернизацию, даже если ваша внутренняя (back-end) среда состоит из разнородных реализаций Web-сервисов. Соответственно, потребители сервисов могут выбирать модернизацию или воспользоваться преимуществом новых функций по своему собственному расписанию.
Для такой инфраструктуры можно указать немало случаев применения. Что, если ваши клиенты требуют использования SOAP-сообщений, но вы не можете модернизировать вашу внутреннюю инфраструктуру для обработки двоичных данных? Вы можете использовать это подход для "посредничества" между протоколом входящего SOAP и двоичным протоколом в вашей внутренней инфраструктуре. Либо вы могли бы маршрутизировать сообщение к другим машинам на основе таких факторов, как тип клиента, посылающего сообщение, или необходимость учитывать расписания модернизаций этих машин.
И этот продуманный процесс, и появляющиеся прототипы реализаций вызвали ажиотаж в управлении Web-сервисами. Эта область является естественным дополнением для других появляющихся стандартов для Web-сервисов в областях надежности, безопасности, транзакций, grid-вычислений и даже управления бизнес-процессами. Но важно не забывать, что она не волшебная; эта область просто пользуется преимуществами и новациями характеристик присущих Web-сервисами.
Уже реализуется скоординированное движение к обеспечению управлению Web-сервисами как ресурсом. Стандарт, к которому стремятся большинство поставщиков, - это Web Services for Distributed Management (WSDM), разрабатываемый OASIS, который сделает для Web-сервисов то, что Java Management Extensions (JMX) сделали для приложений среды J2EE: предоставить независимый от поставщиков и реализаций способ для трактовки разнородных Web-сервисов как управляемых ресурсов (manageable resources). Во что это стандарт практически должен воплотиться – это набор Web-сервисов и операций, которые должна будет обеспечивать каждая реализация Web-сервиса — операции для конфигурирования, мониторинга и других задач управления. Если этот набор будет реализован согласно данному стандарту, любой Web-сервис будет управляем любой инфраструктурой управления, совместимой с WSDM.
Технический комитет OASIS по WSDM начал свою работу над таким стандартом в феврале 2003 года продолжает работать над версией 1.0 стандарта, которая должна завершиться в середине 2004 года.
И будьте уверены, в каждой большой версии Oracle Application Server управлению Web-сервисами будет уделяться все нарастающее внимание.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
