Приклади реалізації грід-сервісних архітектур

Головними «експлуатантами» специфікацій WSRF є розробники ПЗПШ (програмного забезпечення проміжного шару) Globus Toolkit 4 та UNICORE 6. В обох із них базові грід-сервіси успішно реалізовані з урахуванням засад OGSA таWSRF, однак сама архітектура істотно відрізняється, що піддає сумніву можливість вирішення проблеми функціональної сумісності між ПЗПШ лише за рахунок використання спільних стандартів. На даний момент вже випущена нова версія GT – п’ята, в якій тимчасово призупинено використання WSRF-грід-сервісів. Підтримка усіх особливостей специфікацій WSRF виявилася заскладною для розробників в умовах динамічних змін в технології веб-сервісів. Що ставить під питання доцільність використання специфікацій WSRF, особливо при розробці прикладних грід-сервісів. В роботі [25] обидва ці ПЗПШ досить несподівано порівнюються (протиставляються) із семантичними підходами (WSMO, OWL-S) з точки зору пошуку сервісів, що є натяком на потенційну несумісність грід-сервісів WSRF та існуючих технологій семантичних веб-сервісів.

Щоб додатково дослідити ступінь реальної придатності WSRF для побудови прикладних грід-сервісів, звернемося до існуючого досвіду. Існує чимало спроб використати готовий інструментарій GT чи UNICORE для створення прикладних сервісів (різного ступеня успішності). Зважаючи на потенційні проблеми із семантичним розширенням, додатково звернемо увагу на інший аспект – можливість використання інструментарію з виконання бізнес-процесів (BPEL для веб-сервісів) разом із WSRF-грід-сервісами.

В деяких роботах пропонується архітектура грід-сервісів для біоінформатики. Основними компонентами такої системи є OGSA-DAI для об’єднання гетерогенних ресурсів даних, програма GYM з обробки білкових структур, WSRF-сервіси доступу до них та BPEL-процесор для виконання робочих потоків. Вказано шляхи адаптації BPEL до WSRF-сервісів.

Рисунок 2.7 – Запропонована архітектура, що поєднує BPEL та WSRF

Роботи підтверджують потенційну можливість використання BPEL та WSRF на прикладі системи, що використовує графічну нотацію CRESS, середовище ActiveBPEL та грід-сервіси GT4.

Наведемо приклад архітектури (ГІС-системи) для виконання бізнес-процесів в середовищі, де співіснують традиційні веб-сервіси та WSRF-сервіси. Пропонується використовувати єдиний модуль управління робочими потоками, доступ з якого до сервісів різного типу забезпечується через проміжні адаптери та проксі-об’єкти.

У літературі пропонується розширити стандарт BPEL новим видом діяльності gridInvoke задля уможливлення створення потоків WSRF-сервісів. Рішення перевіряється за допомогою інструментарію ActiveBPEL та модулю з візуального створення потоків для середовища проектування Eclipse.

В деяких роботах досліджується можливість використання WS-BPEL-потоків та WSRF-сервісів ПЗПШ UNICORE для виконання потоків наукових задач. Вкзазано специфіку наукових потоків порівняно з традиційними бізнес-процесами: більшу прив’язку до конкретного користувача, залучення передач даних, що ініціюються третьою стороною (third-party transfers), швидка мінливість потоків із накопиченням досвіду. Запропоноване рішення полягає у розробці процесора потоків BIS-Grid, адаптованого під специфіку підсистеми запуску задач даного ПЗПШ.

Рисунок 2.8 – Пропозиція щодо розширення стандарту BPEL задля запуску WSRF-сервісів

Нарешті, розглянемо платформау CINWEGS (Collaborative Integrated Web and Grid Services) для узгодженої роботи веб- та грід-сервісів. Серед обраних технічних рішень для реалізації платформи – бібліотека та середовище виконання веб-сервісів Apache Axis, WSRF-сервіси GT4, реєстр Apache jUDDI, процесор робочих потоків ActiveBPEL.

На основі розглянутого вище можна зробити наступні висновки. За формальними ознаками, WSRF є розширенням стандартних веб-сервісів рядом специфікацій, які покликані надати можливість моделювати тимчасові ресурси із власним станом. Практика показала, що при інтеграції WSRF-рішень з існуючими напрацюваннями (stateless веб-сервісами, засобами оркестровки, семантичної розмітки) виникають проблеми, усунення яких вимагає внесення нових уточнень в існуючі стандарти та/або створення проміжних програмних адаптерів. Так, для реалізації концепції WS-ресурсу залучений шаблон фабрики, який є чужим для звичайних веб-сервісів, а також специфічне використання WS-Addressing (рисунок 2.8). Це при тому, що WSRF було спробою виправити ситуацію з OGSA / OGSI, де було впроваджено надзвичайно багато власних рішень, які не могли прижитися у Веб – реєстри, фабрики, GSH/GSR тощо. І хоча декларується, що WSRF є реалізацією OGSA, між ними багато відмінностей.

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