Керуючи Web-сервісами (Managing Web Services)

Майк Лехманн

Використання переваг SOAP

Якщо ви вважаєте, що
термін 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-сервіс – це просто ще одна програма, що виконується в надрах
вашої обчислювальної інфраструктури. З точки зору управління,
існує деяка множина основних (ключових) функцій, які
застосовуються для керування Web-сервісами. У їх числі –
розгортання, конфігурування і забезпечення безпеки
(Deployment, configuration, and security support), вони
комбініруюттся з деякими основними можливостями моніторингу та
діагностики.

Ці ключові функції реалізовані в Oracle Application Server
Control, консолі управління сервера додатків Oracle Application
Server 10g, Як показано на малюнку 1. Використовуючи цю консоль, з якою можна
працювати через 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.

Особливості SOAP

Хоча управління 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-повідомлення


SOAP-повідомлення з новим параметром


<env:Body>
<ns0:getEmpSalaryElement>
<String_1>7369</String_1>
</ns0:getEmpSalaryElement>
</env:Body>

<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-сервісами буде приділятися все наростаюче
увагу.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*