Відкрита архітектура грід-сервісів

Все ж, для реалізації концепції «усе як ресурс», яка може бути моделлю для грід-сервісної інфраструктури, можливостей вищеназваних стандартів може виявитись недостатньо. Група дослідників, що представляла Global (Open) Grid Fourm, послідовно впроваджувала власну концепцію сервісно-орієнтовної архітектури Грід, яка, пройшовши розвиток від загального опису архітектури OGSA [9] до стандарту WSRF, згодом була реалізована в кількох масштабних грід-інфраструктурах. Сформувати рекомендації щодо реалізації грід-сервісів просто неможливо, не взявши до уваги цей цінний досвід.

Головні засади OGSA

Виходячи з того, що у Грід, як і у подібних внутрішніх IT-структурах підприємств, процес обчислень активно залучає операції зі створення та управління динамічниими групами ресурсів та сервісів. Ці групи ресурсів можуть бути різними за масштабом, тривалістю життя, постачальниками, можуть бути як однорідними, так і гетерогенними, можуть поєднуватись у різні способи. Ці особливості слугували основою для розробки відкритої архітектури грід-сервісів (OGSA).

Семантика грід-сервісу за OGSA

Як вже зазначалося, здатність до віртуалізації та поєднання різних сервісів прямо залежить від стандартних визначень інтерфейсів. Паралельно існує потребу у стандартній семантиці взаємодії сервісів, наприклад – у єдиній домовленості при оповіщенні про помилки.

З цією метою OGSA дає своє вузьке визначення грід-сервісу як веб-сервісу, що має набір добре визначених інтерфейсів та дотримується спеціальних домовленостей. Інтерфейси мають охоплювати виявлення, динамічне створення, управління тривалістю існування, оповіщення, управління сервісом, домовленості ж стосуються адресації (іменування) та розширюваності. Ці моменти складають основу концепції OGSA-сервісів.

Інтерфейси та домовленості, яким слідує сервіс, стосуються, зокрема, поведінки при управлінні тимчасовими екземплярами сервісів. Грід-середовище та ВО передбачають, що часто є необхідність у динамічному створенні нових екземплярів сервісів, які б могли управляти асоційованими з ними даними про стан. Коли ж дані про стан стають непотрібними – їх слід знищити. Прикладами таких тимчасових сутностей із власним станом є: дані сесії відеоконференції, запити до БД, операція з обробки даних, виділення мережевого каналу, сесія передачі даних, резервування обчислювальних потужностей тощо. Тимчасовість суттєво впливає на управління, іменування, пошук та використання сервісів.

Сервісна модель

Як вже зазначалося, головний лейтмотив OGSA – це «все має бути представлене як сервіс» (сервіс – сутність з мережевими можливостями, що надає функціональність через обмін повідомленнями). Обчислювальні ресурси, сховища, мережі, програми, бази даних – все це сервіси у OGSA. Прийняття єдиної загальної сервісно-орієнтованої моделі означає, що всі ці компоненти середовища віртуалізуються. Конкретніше кажучи, OGSA все представляє як грід-сервіс, називаючи ним веб-сервіс, який дотримується ряду домовленностей та підтримує стандартні інтерфейси. Базовий набір інтерфейсів, який реалізують усі OGSA-сервіси, дозволяє побудову сервісів вищого рівня на його основі.

Сервіси у OGSA характеризуються тими можливостями, які вони надають. OGSA-сервіс реалізує один або більше інтерфейсів, при чому кожен інтерфейс визначає набір операцій, що проводяться шляхом обміну визначеною послідовністю повідомлень. Ці інтерфейси відповідають portType у WSDL. Набір portTypes, які підтримуються конкретним сервісом (та деяка додаткова інформація по версіям), вказаний у елементі serviceType сервісу (розширення WSDL, введене в OGSA).

Грід-сервіси можуть підтримувати власний внутрішній стан (дані стану) протягом свого існування. Наявність стану відрізняє один екземпляр сервісу від іншого, що має той самий інтерфейс.

Прив’язка інтерфейса до протоколу може визначати семантику доставки, що стосується, приміром, надійності. Як вже було вказано, у динамічному грід-середовищі складно гарантувати, що повідомлення дійшло до адресата. З іншого боку, важливо, щоб адресат зі станом отримав не більше одного примірника повідомлення (або жодного). В такому випадку бажано було б використовувати протокол, який би реалізовував це правило. Іншим побажанням для протоколу є підтримка взаємної аутентифікації.

Сервіси OGSA можуть створюватись та знищуватись динамічно. Знищуватись явно за вказівкою, або ж неявно через системний збій. Для управління життєвим циклом сервісу OGSA визначає відповідні інтерфейси.

Оскільки OGSA-сервіси динамічні та підтримують стан, потрібен спосіб, щоб відрізняти один динамічно створений екземпляр сервісу від іншого. Тому кожний екземпляр грід-сервісу отримує унікальний ідентифікатор – Grid Service Handle (GSH), який відрізняє його від усіх інших існуючих на даний момент, в минулому чи майбутньому екземплярів. В разі, коли сервіс перезапускається зі збереженням стану, він, звичайно, може використовувати той самий GSH.

Грід-сервіси можуть оновлюватись впродовж свого існування, наприклад, буде додана підтримка нових протоколів. Тому GSH не несе жодної інформації щодо протоколів чи стану. Натомість така інформація, необхідна для взаємодії з окремим динамічним екземпляром, інкапсулюється у посилання Grid Service Reference (GSR). На відміну від GSH, який є незмінним, GSR для екзпмпляру сервісу може змінюватись впродовж його життя. GSR може мати явний термін придатності, або ж може стати неактуальним в будь-який час протягом періоду існування екземпляру, тому OGSA впроваджує механізм отримання оновленого GSR.

Результат від використання GSR, період існування якого закінчився, є невизначеним. Також слід мати на увазі, що навіть утримання дійсного GSR не гарантує доступу до екземпляру сервісу: доступ може бути обмежено локальними політиками. На додачу, екземпляр може аварійно завершитись, що, звісно, завадить його використанню через GSR.

Реалізація концепції грід-сервісів: від OGSI до WSRF

Еволюція підходів до реалізації грід-сервісів

Специфікація відкритої інфраструктури веб-сервісів версії 1.0, видана у липні 2003, визначає набір домовленостей та розширень щодо використання мови опису веб-сервісів та XML-схем для реалізації веб-сервісів із підтримкою стану. Вона впроваджує ідею веб-серівісів з підтримкою стану та визначає підходи для створення, іменування та управління життєвим циклом екземплярів сервісів, для визначення та доступу до даних стану, для асинхронного оповіщення про зміну стану, для представлення та керування наборами екземплярів сервісів, і для стандартної обробки помилок виклику сервісів. У січні 2004 була запропонована платформа ресурсів веб-сервісів як рефакторинг та еволюція OGSI, що спирається на використання нових стандартів веб-сервісів, зокрема WS-Addressing, та на досвід від впровадження свого попередника. WSRF зберігає практично усі функціональні можливості OGSI, змінюючи синтаксис (напр., використовуючи WS-Addressing) та впроваджуючи нову термінологію. Додатково, WSRF розбиває функціональність OGSI на 5 різних специфікацій, що можуть поєднуватись. Розглянемо більш детально взаємозв’язки між WSRF та OGSI.

Ядром OGSI був грід-сервіс як веб-сервіс, що дотримується низки угод для таких цілей, як управління життєвим циклом, доступ до стану та оповіщення про його зміни. OGSI-грід-сервіси надавали можливість контрольованого управління розподіленим та часто – довгоживучим станом, що часто вимагається у розподілених середовищах. OGSI також вводить поняття стандартної фабрики та реєстрації інтерфейсів для створення та пошуку грід-сервісів, а також базовий тип помилки.

Згодом архітектура веб-сервісів еволюціонувала: як приклад – впровадження WSDL 2.0 та вихід специфікації WS-Addressing. Ці розробки змусили переглянути те, як функціональні можливості, закладені у OGSI, використовують функціональність інших специфікацій (зокрема WS-Addressing). Це був слушний час для узгодження функціоналу OGSI із архітектурою веб-сервісів (WS-Arch). Також OGSI 1.0 поєднував в одній специфікації функції, корисні самі по собі, такі як оповіщення. Тому вважалося доцільним розділити OGSI для створення платформи відносно незалежних стандартів.

Як результат такої спроби – набір специфікацій (таблиця 2.6), загальновідомий як платформа ресурсів веб-сервісів [13], в той час, за питання оповіщень (підписка, доставка) відповідає група специфікацій WS-Notification. Разом, ці специфікації зберігають усі суттєві функціональні можливості, присутні у OGSI, впроваджуючи лише зміни у синтаксисі та поняттях. Розбиття OGSI на окремі специфікації дозволяє їх подальше гнучке поєднання. Все це, як вважається, пропонує розробникам більш легкий та послідовний шлях до використання функціональності, закладеній ще у OGSI.

Важливо показати, як саме нові специфікації WSRF та WS-Notification походять від OGSI. Для цього розглянемо, як кожна з конструкцій OGSI реалізована у новіших специфікаціях та вкажемо області, де ці специфікації пропонують відмінні чи вдосконалені можливості.

Таблиця 2.6 – Специфікації WSRF

OGSI

Доповнимо та уточнимо викладене вище про OGSI. Специфікація визначає:

- набір розширень до WSDL, багато з яких вже стали відображені у WSDL 2.0;

- конструкції WSDL для представлення, опитування, оновлення даних сервісу (метадані та стан);

- конструкції Grid Service Handle та Grid Service Reference для адресації грід-сервісів;

- визначення загальної інформації про помилки від операцій із залученням XML-схеми та пов’язаної семантики WSDL. Просто визначається базовий формат повідомлень про помилки, без змін до моделі повідомлень про помилки WSDL;

- набір операцій по створенню та знищенню грід-сервісів, який надано як для явного знищення сервісів, так і для неявного збору сміття від сервісів, у яких збіг термін існування;

- набір операцій по створенню та використанню за посиланням груп гетерогенних веб-сервісів;

- механізми опитування асинхронних оповіщень про зміни у значеннях елементів даних сервісів.

Існує як мінімум 6 (!) різних реалізацій специфікації OGSI, тому було набуто деякий досвід практичного використання OGSI. На додачу, були спроби створити специфікації “верхнього рівня” по відношенню до конструкцій OGSI.

Зміни у стандартах веб-сервісів та критика OGSI

З тих пір, як ще на початку 2002 р. Розпочалась розробка OGSI, світ веб-сервісів істотно змінився. Зокрема, виникли нові специфікації та шаблони використання, які спрощували реалізацію ідей, закладених у OGSI.

WS-Addressing пропонує нейтральний до транспорту (протоколу доставлення повідомлень) механізм адресації веб-сервісів. Специфікація визначає XML-елементи для ідентифікації кінцевих точок (endpoints) веб-сервісу і їх включення до повідомлень. Ця специфікація дозволяє підтримку передачі повідомлень у мережах, що включають вузли обробки, такі як менеджери кінцевих точок, файрволи, шлюзи, незалежно від транспорту. Інформація, яка закладена у посиланні на кінцеву точку, не лише надає адресу самого веб-сервісу, але й може слугувати для ідентифікації конуретних його ресурсів з підтримкою стану через використання відповідних властивостей посилання на кінцеву точку.

WS-MetaDataExchange пропонує ряд механізмів для отримання інформації про опублікований сервіс, такої як WSDL-опис, XML-схема та ін.

Тому, оскільки вищеназвані стандарти надають деякі можливості, також визначені у OGSI, більш корисним було б використати їх напряму, аніж підтримувати специфікацію, яка дублює ці стандарти. Розробка WSRF також була відповіддю на критику OGSI з боку спільноти користуачів технології веб-сервісів:

1. Специфікація перевантажена. У OGSI не було чіткого розмежування функцій для підтримки послідовного, поступового прийняття. Наприклад, оповіщення є саме по собі корисною функцією, яка не залежить від особливостей роботи із даними сервісу. Сімейства специфікацій WSRF та WS-Notification врахували ці зауваження.

2. Проблеми при роботі із існуючими веб-сервісами та інструментарієм. OGSI “агресивно” використовує XML-схеми, наприклад, повсемісним використанням атрибутів xsd:any чи документно-орієнтованими WSDL-операціями. Це спричиняло проблеми, наприклад, із викорстанням JAX-RPC. WSRF натомість використовує стандартні механізми XML-схем, звичні розробникам та такі, що підтримуються наявним інструментарієм. Замість того, щоб розширювати визначення portType з WSDL 1.1, визначаються ”легальні” для WSDL 1.1 шляхи для анотування елемента portType для асоціацій WSDL-операцій із ресурсною моделлю.

3. Занадто сильна об’єктна орієнтація. В рамках OGSI моделлю ресурсу з підтримкою стану є веб-сервіс, який інкапсулює стан ресурсу та життєвий цикл сервісу, таким чином поєднуючи в собі сам сервіс та стан. Як зазначалося у попередніх розділах, це суперечить ідеології SOA та веб-сервісів, яка орієнтується на відсутність стану чи окремих екземплярів у веб-сервісів. Не всі реалізації веб-сервісів підтримують динамічне створення та знищення сервісу. У специфікації WSRF акцент зміщений на відокремлення веб-сервісу від керованих ним сутностей, які підтримують стан. WSRF вказує спосіб поєднання веб-сервісу та stateful-ресурсу, називаючи це “WS-Resource” та застосовуючи WS-Addressing для адресації таких поєднань.

4. Впровадження WSDL 2.0. Автори OGSI використовували конструкції із запропонованого тоді чорнового варіанту специфікації WSDL 2.0. Затримка із публікацією цієї специфікації створювала проблеми із сумісністю існуючого інструментарію та OGSI. Враховуючи це, слід орієнтуватися на сумісність із вже існуючими та популярними стандартами, як WSDL 1.1. для запобігання залучення нових інструментів.

Перехід до WSRF

Перехід до WSRF включав такі кроки:

1. введення концепції ресурсу веб-сервісу (WS-Resource);

2. чіткіше розмежування функцій та вивчення інших специфікацій по веб-сервісам;

3. широший погляд на механізм оповіщень, який є загальною функціональною можливістю для веб-сервісів, на якій можна збудувати оповіщення про зміну стану.

Конструкція WS-Resource WSRF головним чином пов’язаний із створенням, адресацією, перевіркою, управлінням життєвим циклом ресурсів, що мають стан. WSRF надає засоби подання стану як stateful-ресурсу та закріплює зв’язки між веб-сервісами та ресурсами. Поєднання ресурсу зі станом та веб-сервісу названо WS-Resource – ресурс веб-сервісу. Платформа описує визначення таких ресурсів та описує те, як зробити властивості ресурсу доступними через інтерфейс веб-сервісу, а також як управляти життєвим циклом ресурсу.

Як видно з короткого порівняння (таблиця 2.8), як OGSI, так і WSRF пов’язані з тим, як управляти ресурсами зі станом через інтерфейс веб-сервісів. Навіть зважаючи на те, що ці два підходи моделюють ресурси зі станом по різному – відповідно, як OGSI-грід-сервіс та як ресурс веб-сервісу WS-Resource – вони надають принципово ідентичну функціональність та використовують семантично подібні WSDL-описи інтерфейсу. Як OGSI-сервіс, так і WS-Resource можуть бути створені, адресовані, перевірені, знищені у подібний спосіб.

WSRF має дві головні переваги над OGSI. По-перше, WSRF був краще узгоджений як із існуючими XML-стандартами, так із новими, такими як WS-Addressing. Таким чином, новий підхід легше реалізувати за допомогою перевіреного існуючого та більш нового інструментарію розробки, та легше використати з існуючими веб-сервісами. Друга перевага – концептуальна. Термінологія та конструкції OGSI помилково переконали частину веб-сервіс-спільноти у тому, що веб-сервіси мають перетворитися на громіздкі структури. WSRF показав, що мета полягала лише в маніпулюванні ресурсами через інтерфейс веб-сервісів. Ніщо не заважало в рамках обох підходів реалізувати сервіс без стану, що просто транслює операції до внутрішніх ресурсів. WSRF робить цей факт більш ясним, розмежовуючи обробники повідомлень та ресурси зі станом.

WSRF також зважив і на інші висновки, набуті після публікації специфікації OGSI. Практика показала, що інтерфейс OGSI Factory (фабрика) не настільки корисний, й існували відмінні методи, що досягали тої ж мети. Тому WSRF просто визначає більш загальний шаблон WS-Resource Factory (фабрики ресурсів).

Інтерфейс оповіщень OGSI не підтримував багатьох функцій, потрібних у загальній системі обробки оповіщень та таких, що підтримуються існуючим програмним забезпеченням, орієнтованим на передачу повідомлень. Цю прогалину має заповнити сімейство специфікацій WS-Notification.

OGSI використовує Grid Service Reference (GSR) для адресації сервісу, а також вводить конструкцію Grid Service Handle (GSH) та механізм HandleResolver як один із способів контролю відповідностей між абстрактними, довготривалими іменами та конкретними, імовірно, тимчасовими адресами. Комбінація цих трьох конструкцій дає кілька окремих функцій у взаємозалежному наборі механізмів. WSRF визначає незалежні механізми для цих функцій. Специфікація WS-RenewableReferences визначає можливість стабільності кінцевих посилань шляхом додавання спеціальних політик.

Великий об’єм та обсяг специфікації OGSI зробили її важкою для читання та розуміння, та для визначення того, які фрагменти є суттєвими для тої чи іншої задачі. Тому WSRF розбиває функціонал OGSI на окремі специфікації, що дозволяє також їх гнучке поєднання. Вже згадувалось про те, що використання XML-стандартів у OGSI погано сумісне із існуючим інструментарієм. Тому було прийнято рішення про більш консервативний підхід до використання XML-схеми, наприклад, за рахунок використання кількох операцій замість єдиної, але розширюваної операції у OGSI.

Рисунок 2.6 – Порядок роботи із веб-сервісом, OGSI-сервісом та WSRF-сервісом

Розширення GWSDL до portType з WSDL 1.1 в рамках OGSI було більше зайвим “синтаксичним цукром” для розширення інтерфейсу. На додачу, GWSDL йде навіть далі із проголошенням даних сервісу як частини визначення інтерфейсу. На жаль, GWSDL був найбільшою перешкодою використання OGSI. Тому WSRF просто визначає свої повідомлення за допомогою конструкцій WSDL 1.1, та вимагає від розробників складних інтерфейсів просто копіювати та вставляти компоненти таких інтерфейсів до повноцінного переходу на WSDL 2.0.