Iphone
shpora.me - незаменимый помощник для студентов и школьников, который позволяет быстро создавать и получать доступ к шпаргалкам или другим заметкам с любых устройств. В любое время. Абсолютно бесплатно. Зарегистрироватся | Войти

* данный блок не отображается зарегистрированым пользователям и на мобильных устройствах

1 модуль. Паралельні -mike

Лекція 1 Базові складові Grid і ресурси

 

1.1 Напрями розвитку технології Grid

 

До теперішнього часу вже реалізовані і реалізуються безліч проектів по створенню Grid-систем. Більша частина цих проектів має експериментальний характер. Виходячи з результатів аналізу проектів можна зробити висновок про три напрями розвитку технології Grid:

·     обчислювальний Grid;

·     Grid для інтенсивної обробки даних;

·     семантичний Grid для операцій з даними з різних баз даних.

Метою першого напряму є досягнення максимальної швидкості обчислень за рахунок глобального розподілу цих обчислень між комп'ютерами. Проект DEISA (www.desia.org) може служити прикладом цього напряму, в якому робиться спроба об'єднання суперкомп'ютернихцентрів.

Метою другого напряму є обробка величезних об'ємів даних відносно нескладними програмами за принципом «одне завдання – один процесор». Доставка даних для обробки і пересилка результатів в цьому випадку є достатньо складним завданням. Для цього напряму інфраструктура Grid є об'єднанням кластерів. Один з проектів, метою якого і є створення виробничої Grid-системи для обробки наукових даних, є проект EGEE (Enabling Grids for E-SCIENCE), який виконується під егідою Європейського Союзу (www.eu-egee.org). Учасниками цього проекту є більше 90 наукових і освітніх установ зі всього світу, включаючи Україну.

Побудова інфраструктури Grid в рамках проекту EGEE орієнтована, в першу чергу, на застосування в різних галузях наукової діяльності, у тому числі і для обробки даних у фізиці високих енергій учасниками експериментів, що проводяться на базі створеного в Європейському центрі ядерних досліджень (CERN, www.cern.ch) прискорювача LHC.

Проект EGEE тісно зв'язаний на даній фазі розвитку з проектом LCG (LHC Computing Grid), який, по суті, і є його технологічною базою.

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

·     координація використання ресурсів за відсутності централізованого управління цими ресурсами;

·     використання стандартних, відкритих, універсальних протоколів і інтерфейсів;

·     забезпечення високоякісного обслуговування користувачів.

 

1.2 Концепція побудови GRID

 

Прогрес в області розробки нових обчислювальних пристроїв і мережевих технологій вражає. Тільки за останніх 15 років тактова частота персональних машин зросла з 10 Мгц до 5ГГц (500 разів), а пропускна спроможність мереж з 10 Мбіт/с до 100 Гбіт/с (10000 разів).

Але не за горами деякі принципові обмеження, наприклад, постійна часу поляризації діелектрика рівна 10 – 13сек, що встановлює верхню межу на тактову частоту будь – яких операцій на рівні ~1013 Гц. (Тгц).

Важко собі уявити, що людство змириться з обмеженнями обчислювальних можливостей. Одним з шляхів вирішення проблеми – паралельне виконання великого числа операцій і розподілена структура обчислювальної системи. Такі технології вже використовуються, наприклад, при побудові Ethernet – интерфейса для швидкості 10 Гбіт/сек (Fast Ethernet).

Зв'язок між продуктивністю обчислювача і потрібною пропускною спроможністю каналів обміну встановлює емпіричний закон Amdahl, який стверджує, що кожному мільйону операцій в секунду процесора повинна відповідати пропускна спроможність вводу/виводу, рівна мегабіту в секунду.

У якійсь мірі техніка WWDM (Wide Wavelength Division Multiplexing) може бути віднесена до методики розпаралелювання операцій.

Технологія GRID повністю укладається в ці рамки. Вона дозволила істотно понизити вартість виконання обчислювальних операцій.

GRID дозволяє виявити і використовувати вільні обчислювальні ресурси. Ця система для передачі програм і даних використовує стандартні канали і протоколи (Ethernet, SDH, АТМ, TCP/IP, MPLS і так далі). Переваги GRID особливо значущі для завдань, де допускається розпаралелюваннярозрахунків. Поки не склалося точне визначення того, що слід вважати за GRID. До цього класу відносять і системи із спеціалізованими шинами або мережевими сегментами (область супер – ЕОМ) і системи об'єднані через Інтернет (слабо зв'язані GRID). Технологія GRID, вирішуючи свої проблеми, сама стає рушійною силою при розробці нових мережевих технологій (напр. GRIDFTP і ін.).

Широке впровадження в телекомунікації оптоволокна відкриває додаткові можливості, у тому числі і для систем GRID. Оскільки для отримання необхідної смуги пропускної спроможності достатньо 2нм у вікні прозорості волокна, відкриваються можливості мультиплексування десятків потоків в межах одного волокна.

При сучасних швидкостях обміну (більше 1 Гбіт/с) транспортний протокол ТСР (L4) почав обмежувати ефективність обміну. Проблеми виникають при великій смузі пропускання B і RTT.

Останніми роками у зв'язку з мультимедіа розроблені методи і протоколи гарантії якості обслуговування QOS. Це, перш за все, RSVP – TE (IntServ) і MPLS – TE (DiffServ). Для динамічного формування пріоритетних потоків привабливіший MPLS – TE (розділення потоків по DSCP) особливо у разі єдиного сервіс – провайдера. Але при з'єднаннях точка – точка це не істотно.

Техніка гарантії QOS дозволяє розділити інформаційні потоки по пріоритетах, а це у свою чергу дозволяє оптимізувати обчислювальний процес в розподіленому середовищі. Однією з проблем в цьому випадку виявляється відсутність сумісної техніки гарантії QOS в LAN і WAN.

Для забезпечення QOS може використовуватися протокол IEEE 802.17 (RPR – ResilientPacket Ring).

Поява протоколу (GMPLS) відкриває додаткові можливості в сфері передачі програм і даних. Оскільки протокол GMPLS практично працює на рівні L1, значення RTT виявляється мінімізованим.

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

Тут з'єднання відбувається по схемі Е2Е і з цієї причини не виникає необхідності вбуферизації (звідси слідує мінімізація RTT).

Первинна роль архітектури GRID полягає у використанні незадіяних ресурсів.

SOA (Service Oriented Architecture – архітектура, орієнтована на сервіс) – хоча GRID може працювати без архітектури, орієнтованої на сервіс, бізнес і керівники IT служб, повинні зрозуміти, що побудова SOA, украй необхідна і бажана. Веб – сервіси на основі SOA дозволяють виключитиміжпрограмні і інформаційні обміни – що сприяє раціоналізації операцій, збільшенню продуктивності, більшої гнучкості і низької вартості обчислень.

Business Process Flow (управління бізнес – процесами) – як тільки з'являється архітектура, орієнтована на сервіс, підприємство може починати вести бізнес-процеси прозорим способом, використовуючи існуючі інформаційні системи.

GRID є технологією забезпечення гнучкого, безпечного і скоординованого загального доступу до ресурсів. При цьому слово «ресурс» розуміється в дуже широкому сенсі, тобто ресурсом може бути апаратура (жорсткі диски, процесори), а також системне і прикладне ПО (бібліотеки, додатки).

У термінології GRID сукупність людей і організацій, що вирішують спільно те або інше загальне завдання і що надають один одному свої ресурси, називається віртуальною організацією. Наприклад, віртуальною організацією може бути сукупність всіх людей, що беруть участь в якій-небудь науковій колаборації. Віртуальні організації можуть розрізнятися за складом, масштабом, часом існування, родом діяльності, цілями, відносинами між учасниками (довірені/не довірені особи) і так далі. Склад віртуальних організацій може динамічно мінятися.

 

1.3 Стандартизація Grid

 

У останні декілька років технологія Grid еволюціонувала від ретельно конфігурованоїінфраструктури, яка підтримувала виконання обмеженого числа додатків категорії Grant Challengeна високопродуктивній апаратурі, до динамічного середовища, розвиток якого направляє міжнародне співтовариство. У міру становлення технології Grid реальністю до процесу її розвитку все більш залучається індустрія. Участь комерційних організацій прискорює розробку надійного програмного забезпечення, що підтримує середовища Grid за межами академічних лабораторій. У свою чергу, це впливає як на архітектуру Grid, так і на пов'язані з нею  протоколи і стандарти. Пристосування до архітектури Grid технології Web-сервисів принесло істотну користь та привело до появи дещо фрагментованого середовища розробки. Розробники програмного забезпечення і Grid-сервісів добиваються відповідності угодам і стандартам, широко поширеним в їх співтоваристві. Проте по різних політичних і технічних причинах є декілька точок зору, що змагаються, щодо того, як слід реалізовувати архітектуру, і на які стандарти потрібно спиратися. Це суперництво гальмує розробників програмного забезпечення Grid, оскільки вони не упевнені, що майбутні стандарти включатимуть ті, що використовуються сьогодні. Основною організацією по стандартизації Grid єGlobal Grid Forum (GGF www.ggf.org). Крім того, роботи по стандартизації ведуться в Organizationfor the Advancement of Structured Information Standards (OASIS www.oasis.org), World WideConsortium (W3C www.w3c.org), Distributed Management Task Force (DMTF www.dmtf.prg), WebServices Interoperability Organization (WS-I www.ws-i.org), Internet2 (www.internet2.edu) і LibertyAlliance (www.projectliberty.org). Найбільш важливим стандартом, покликаним визначити загальну, стандартну і відкриту архітектуру Grid, є стандарт Open Grid Services Architecture (OGSA), що розвивається GGF. У березні 2004 р. була випущена перша версія стандарту (OGSA 1.0), а в червні 2005 р. вийшла друга версія стандарту. OGSA є сервіс-орієнтованою архітектурою, в якій специфікується набір розподілених обчислювальних патернів, що реалізовуються з використанням Web-сервісів. Стандарт призначається для визначення всіх основних сервісів, які можуть використовуватися в додатках e-business або e-science, включаючи управління роботами і ресурсами, комунікації і безпеку. Робота по специфікації інтерфейсів сервісів, семантики, протоколів і інших технічних деталей надана різним робочим групам усередині GGF і іншим організаціям по стандартизації Grid. Перша конкретизація OGSA була здійснена в документі OpenGrid Services Infrastructure (OGSI), випущеному в липні 2003 р. Цей документ базувався на понятті Grid-сервіса, розширенні Web-сервиса, в якому забезпечувався стандартний набір механізмів для управління станом. У OGSI 1.0 визначається набір принципів і розширень для використання WSDL і XML Schema при організації Web-сервісів з підтримкою стану. Критики OGSI відзначали ряд проблем в цьому стандарті: дуже великий об'єм; потреба в розширенні стандартного WSDL; дуже сильна об'єктна орієнтованість. Це привело до виникнення руху за визначення альтернативноїінфрастуктури Grid, заснованої на чистих специфікаціях Web-сервісів. 20 січня 2004 р. HP, IBM,Fujitsu і Globus Alliance оголосили про випуск WS-Resource Framework (WSRFwww.globus.org/wsrf). Цей документ складається з набору специфікацій для виразу зв'язку між ресурсами, що володіють станами, і Web-сервісами. У специфікаціях визначаються конкретні формати повідомлень і зв'язані визначення на XML. Остаточні результати були передані двом новим технічним комітетам OASIS: WS-Resource Framework (WSRF) TC і WS-Notification (WSN) TC. WSRF TC відповідає за стандартизацію специфікацій WS-Resource Lifetime (визначаються способи управління життєвим циклом ресурсу і специфікуються Web-сервіси для ліквідації ресурсу); WS-Resource Properties (визначаються способи запиту і модифікації ресурсів, що описуються XML-документами Resource Property); WS-ServiceGroup (визначаються способи представлення і управління колекціями Web-сервісів і/або WS-ресурсами); WS-BaseFaults (визначається базовий XML-тип, використовуваний при обміні повідомленнями в Web-сервісах для інформування про збої). WSN TC займається стандартизацією трьох специфікацій, що відносяться до інтерфейсів Web-сервісів: WS-BaseNotification (асинхронне сповіщення, що включає інтерфейси виробника і споживача); WS-BrokeredNotificatiion (асинхронне сповіщення); WS-Topics (організація і категоризація тем для підписки). Деякі організації, що ведуть або планують Grid-проекты, користуються альтернативними специфікаціями, що включають Basic Profile (BP1.0) від WS-I, WebServices Grid Application Framework (WS-GAF, North-East Regional e-Science Centrewww.neresc.ac.uk/ws-gaf) і WS-I+ (Open Middleware Infrastructure Institute www.omii.ac.uk). Специфікація BP1.0 була опублікована в квітні 2004 р. і містила керівництво по використанню SOAP. WSDL і UDDI. У WS-GAF пропонується підхід, відмінний від OGSI, до розширення функціональності Web-сервісів для задоволення потреб Grid-додатків. У WS-I+ указуються існуючі стандарти, які є потенційно сумісними із стандартами Grid, що розвиваються. Фактичним стандартом безпеки в Grid є Grid Security Infrastructure (GSI http://forge.gridforum.org/projects/gsi-wg). У двох нових проектах досліджуються альтернативні рішення, які можуть вплинути на стандарти GSI. У проектах GridShib (http://grid.ncsa.uiuc.edu/GridShib) і ESP-GRID (http://e-science.ox.ac.uk/oesc/projects) створені нові механізми і стратегії розподіленої аутентифікації, що дозволяють віртуальним організаціям в Grid інтегруватися з традиційною інфраструктурою корпоративної безпеки.

 

1.4 Архітектура Grid

 

Open Grid Services Architecture (OGSA) направлена на стандартизацію адресації (для сумісності), за допомогою визначення основи структури додатку GRID. По суті стандарт OGSA визначає сервіси GRID, їх можливості і те, на яких технологіях вони засновані. Проте, OGSA не розрізняє особливостей технічної сторони специфікації; метою є визначення – що є системою GRID. OGSA називають архітектурою, оскільки вона направлена на побудову і установку інтерфейсів, з яких можуть бути побудовані, системи, засновані на відкритих стандартах WSDL.

Таблиця 1. Пропонований OGSA інтерфейс служб GRID

Тип порту

Операція

Опис

GridService

FindServiceData

Запит різної інформації про сервіси GRID, включаючи основну діагностичну інформацію, інформацію про інтерфейси і про особливості сервісів. Підтримка різних мов запитів

SetTermination Time

Установка часу знищення сервісу GRID

Destroy

Видалення служби

Notification – Source

SubscribeTo –NotificationTopic

Підписка на повідомлення про події, що відносяться до сервісів, і заснована на типі повідомлення

Notification – Sink

Deliver Notification

Виконання і асинхронна вставка повідомлення

Registry

RegisterServiceUnregisterService

Реєстрація додатків GRID. Анулювання реєстрації додатків GRID

Factory

CreateService

Створення нового сервісу GRID

Handle Map

FindByHandle

Повернення посилання про службу GRID, що асоціюються з їх дескрипторами

 

 

Є два основні критерії, що виділяють GRID – системи серед інших систем, що забезпечують доступ до ресурсів, що розділяються:

·     GRID – система координує розрізнені ресурси. Ресурси не мають загального центру управління, а GRID – система займається координацією їх використання, наприклад, балансуванням навантаження. Тому проста система управління ресурсами кластера не є системою GRID, оскільки здійснює централізоване управління всіма вузлами даного кластера, маючи до них повний доступ. GRID – системи мають лише обмежений доступ до ресурсів, залежний від політики того адміністративного домену (організації-власника), в якому цей ресурс знаходиться.

·     GRID – система будується на базі стандартних і відкритих протоколів, сервісів і інтерфейсів. Не маючи стандартних протоколів, неможливо легко і швидко підключати нові ресурси в GRID – систему, розробляти новий вигляд сервісів і так далі.

Додамо ще декілька властивостей, якими зазвичай володіють GRID – системи:

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

·     масштабованість: працездатність GRID – системи при значному збільшенні або зменшенні її складу;

·     гнучка і могутня підсистема безпеки: стійкість до атак зловмисників, забезпечення конфіденційності;

·     можливість контролю над ресурсами: застосування локальних і глобальних політик і квот;

·     гарантії якості обслуговування;

·     можливість одночасної, скоординованої роботи з декількома ресурсами.

Хоча сама технологія GRID не прив'язана до певних ресурсів, найчастіше реалізації GRID – систем забезпечують роботу з наступними типами ресурсів:

·     обчислювальні ресурси – окремі комп'ютери, кластери;

·     ресурси зберігання даних – диски і дискові масиви, стрічки, системи масового зберігання даних;

·     мережеві ресурси;

·     програмне забезпечення – яке-небудь спеціалізоване ПО.

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

Не слід змішувати технологію GRID з технологією паралельних обчислень. В рамках конкретної GRID – системи, звичайно, можливо організувати паралельні обчислення з використанням існуючих технологій (PVM, MPI), оскільки GRID – систему можна розглядати як якийсь мета-комп´ютер, що має безліч обчислювальних вузлів. Проте технологія GRID не є технологією паралельних обчислень, в її завдання входить лише координація використання ресурсів.

Архітектура GRID визначає системні компоненти, цілі і функції цих компонент і відображає способи взаємодії компонент один з одним. Архітектура GRID є архітектурою взаємодіючих протоколів, сервісів і інтерфейсів, що визначають базові механізми, за допомогою яких користувачі встановлюють з'єднання з GRID – системою, спільно використовують обчислювальні ресурси для вирішення різного роду завдань. Архітектура протоколів GRID розділена на рівні (Рисунку 1.1), компоненти кожного з них можуть використовувати можливості компонент будь-якого з розташованих нижче рівнів. В цілому ця архітектура задає вимоги для основних компонент технології (протоколів, сервісів, прикладних інтерфейсів і засобів розробки ПО), не надаючи строгий набір специфікацій, залишаючи можливість їх розвитку в рамках прийнятої концепції.

 

Підпис: Рівні протоколів ГрідПідпис: Рівні протоколів Інтернет

Рисунок 1.1 – Рівні архітектури протоколів Grid і їх відповідність рівням архітектури протоколів Інтернет

 

Інфраструктура GRID заснована на наданні ресурсів в загальне користування, з одного боку, і на використанні публічно доступних ресурсів, з іншого. У цьому плані ключове поняття інфраструктури GRID – віртуальна організація, в якій кооперуються як споживачі, так і власники ресурсів. Мотиви кооперації можуть бути різними. У існуючих GRID – системах віртуальна організація є об'єднанням (колаборацію) фахівців з деякої прикладної області, які об'єднуються для досягнення загальної мети.

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

Ефективний розподіл ресурсів і їх координація є основними завданнями системи GRID, і для їх вирішення використовується планувальник (брокер ресурсів). Користуючись інформацією про стан GRID – системи, планувальник визначає найбільш відповідні ресурси для кожного конкретного завдання і резервує їх для її виконання. Під час виконання завдання може запитати у планувальника додаткові ресурси або звільнити надмірні. Після завершення завдання всі відведені для неї обчислювальні ресурси звільняються, а ресурси пам'яті можуть бути використані для зберігання результатів роботи.

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

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

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

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

У розподіленому середовищі, яким є GRID – система, життєво важливою властивістю є відсутність так званої єдиної точки збоїв. Це означає, що відмова будь-якого ресурсу не повинна приводити до збою в роботі всієї системи. Саме тому планувальник, система моніторингу і інші сервіси GRID – системи розподілені і продубльовані. Не дивлячись на всю складність, архітектура GRID розроблялася з метою забезпечити максимальну якість сервісу для користувачів. У GRID – системах використовуються сучасні технології передачі даних, забезпечення безпеки івідмовостійкої.

 

1.4.1 Базовий рівень

 

Рисунок 1.2 – Ресурси GRID

 

Базовий рівень (Fabric Layer) архітектури GRID описує служби, що безпосередньо працюють з ресурсами. Ресурс є одним з основних понять архітектури GRID. Ресурси можуть бути вельми різноманітними, проте, як вже згадувалося раніше, можна виділити декілька основних типів (рисунок 1.2):

·     обчислювальні ресурси;

·     ресурси зберігання даних;

·     інформаційні ресурси, каталоги;

·     мережеві ресурси.

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

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

Інформаційні ресурси і каталоги є особливим видом ресурсів пам'яті. Вони служать для зберігання і надання метаданих і інформації про інші ресурси GRID – системи. Інформаційні ресурси дозволяють структуровано зберігати величезний об'єм інформації про поточний стан GRID – системи і ефективно виконувати завдання пошуку.

Мережевий ресурс є сполучною ланкою між розподіленими ресурсами GRID – системи. Основною характеристикою мережевого ресурсу є швидкість передачі даних. Географічно розподілені системи на основі даної технології здатні об'єднувати тисячі ресурсів різного типу, незалежно від їх географічного положення.

 

1.4.2 Рівень зв'язку

Рівень зв'язку (Connectivity Layer) визначає комунікаційні протоколи і протоколиаутентифікації.

Комунікаційні протоколи забезпечують обмін даними між компонентами базового рівня.

Протоколи аутентифікації, ґрунтуючись на комунікаційних протоколах, надають криптографічні механізми для ідентифікації і перевірки достовірності користувачів і ресурсів.

Протоколи рівня зв'язку повинні забезпечувати надійний транспорт і маршрутизацію повідомлень, а також привласнення імен об'єктам мережі. Не дивлячись на існуючі альтернативи, зараз протоколи рівня зв'язку в GRID – системах припускають використання тільки стека протоколів TCP/IP, зокрема: на мережевому рівні – IP і ICMP, транспортному рівні – TCP, UDP, на прикладному рівні – HTTP, FTP, DNS, RSVP. Враховуючи бурхливий розвиток мережевих технологій, в майбутньому рівень зв'язку, можливо, залежатиме і від інших протоколів.

Для забезпечення надійного транспорту повідомлень в GRID – системі повинні використовуватися рішення, що передбачають гнучкий підхід до безпеки комунікацій (можливість контролю над рівнем захисту, обмеження делегування має рацію, підтримка надійних транспортних протоколів). В даний час ці рішення ґрунтуються як на існуючих стандартах безпеки, спочатку розроблених для Інтернет (SSL, TLS), так і на нових розробках.

 

1.4.3 Ресурсний рівень

Ресурсний рівень (Resource Layer) побудований над протоколами комунікації іаутентифікації рівня зв'язку архітектури GRID. Ресурсний рівень реалізує протоколи, що забезпечують виконання наступних функцій:

·     узгодження політик безпеки використання ресурсу;

·     процедура ініціації ресурсу;

·     моніторинг стану ресурсу;

·     контроль над ресурсом;

·     облік використання ресурсу.

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

Розрізняють два основні класи протоколів ресурсного рівня:

·     інформаційні протоколи, які отримують інформацію про структуру і стан ресурсу, наприклад, про його конфігурацію, поточне завантаження, політику використання;

·     протоколи управління, які використовуються для узгодження доступу до ресурсів, що розділяються, визначаючи вимоги і допустимі дії по відношенню до ресурсу (наприклад, підтримка резервування, можливість створення процесів, доступ до даних). Протоколи управління повинні перевіряти відповідність запрошуваних дій політиці розділення ресурсу, включаючи облік і можливу оплату. Вони можуть підтримувати функції моніторингу статусу і управління операціями.

Список вимог до функціональності протоколів ресурсного рівня близький до списку для базового рівня архітектури GRID. Додалася лише вимога єдиної семантики для різних операцій з підтримкою системи оповіщення про помилки.

 

1.4.4 Колективний рівень

Колективний рівень (Collective Layer) відповідає за глобальну інтеграцію різних наборів ресурсів, на відміну від ресурсного рівня, сфокусованого на роботі з окремо узятими ресурсами. У колективному рівні розрізняють загальні і специфічні (для додатків) протоколи. До загальних протоколів відносяться, в першу чергу, протоколи виявлення і виділення ресурсів, системи моніторингу і авторизації співтовариств. Специфічні протоколи створюються для різних додатків GRID (наприклад, протокол архівації розподілених даних або протоколи управління завданнями збереження стану і тому подібне).

Компоненти колективного рівня пропонують величезну різноманітність методів сумісного використання ресурсів. Нижче приведені функції і сервіси, що реалізуються в протоколах даного рівня:

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

·     сервіси сумісного виділення, планування і розподілу ресурсів забезпечують виділенняоднго або більше ресурсів для певної мети, а також планування виконуваних на ресурсах завдань;

·     сервіси моніторингу і діагностики відстежують аварії, атаки і перевантаження;

·     сервіси дублювання (реплікації) даних координують використання ресурсів пам'яті в рамках віртуальних організацій, забезпечуючи підвищення швидкості доступу до даним відповідно до вибраних метрик, таких як час відповіді, надійність, вартість і т.п.;

·     сервіси управління робочим завантаженням застосовуються для опису і управління багатокроковими, асинхронними, багатокомпонентними завданнями;

·     служби авторизації співтовариств сприяють поліпшенню правил доступу до ресурсів, що розділяються, а також визначають можливості використання ресурсів співтовариства. Подібні служби дозволяють формувати політики доступу на основі інформації про ресурси, протоколи управління ресурсами і протоколи безпеки зв’язуючого рівня;

·     служби обліку і оплати забезпечують збір інформації про використання ресурсів для контролю звернень користувачів;

·     сервіси координації підтримують обмін інформацією в потенційно великому співтоваристві користувачів.

 

1.4.5 Прикладний рівень

Прикладний рівень (Application Layer) описує призначені для користувача застосування (додатки), що працюють в середовищі віртуальної організації. Додатки функціонують, використовуючи сервіси, визначені на рівнях, що пролягають нижче. На кожному з рівнів є певні протоколи, що забезпечують доступ до необхідних служб, а також прикладні програмні інтерфейси (Application Programming Interface – API), відповідні даним протоколам.

Для полегшення роботи з прикладними програмними інтерфейсами користувачам надаються набори інструментальних засобів для розробки програмного забезпечення (Software Development Kit– SDK). Набори інструментальних засобів високого рівня можуть забезпечувати функціональність з одночасним використанням декількох протоколів, а також комбінувати операції протоколів з додатковими викликами прикладних програмних інтерфейсів нижнього рівня.

Звернемо увагу, що додатки на практиці можуть викликатися через достатньо складні оболонки і бібліотеки. Ці оболонки самі можуть визначати протоколи, сервіси і прикладні програмні інтерфейси, проте подібні надбудови не відносяться до фундаментальних протоколів і сервісів, необхідних для побудови GRID – систем.

 

1.4.6 Стандарти, що використовуються для побудови архітектури GRID

Існує декілька стандартів, використовуваних для побудови архітектури GRID. Ці стандарти утворюють базові блоки, які дозволяють посилати запити додаткам і базам даних. Ці стандарти також дозволяють розвернути програмне забезпечення, що дозволяє спростити управління бізнес – процесом. До стандартів GRID і зв'язаних з ними стандартів слід віднести:

·     Комунікації «програма – програма» (SOAP, WSDL, і UDDI);.

·     Сумісне використання даних (мова XML).

·     Передача повідомлень(SOAP, WS – Addressing, MTOM (для додатків));

·     Надійна передача повідомлень (WS – Reliable Messaging);

·     Управління робочим процесом (WS – Management);

·     Управління транзакціями(WS – Coordination, WS – AtomicTransaction, WS – Business –Activity);

·     Розподіл ресурсів (WS – RF або система ресурсних Web – сервісів);

·     Забезпечення безпеки (WS – Security, WS – SecureConversation, WS – Trust, WS –Federation, Система безпечних зв'язків Kerberos для Web – сервісів;

·     Обробка метаданих(WSDL, UDDI, WS – Policy).

·     Orchestration (стандарти, використовувані для абстрагування бізнес – процесів від логіки додатків і джерел даних і для встановлення правив, які дозволяють бізнес – процесам взаємодіяти між собою);

·     Верхній рівень управління бізнес – процесом (інженерна мова бізнес – процесу для Webсервісів – BPEL4WS)

·     Події, що запускають бізнес – процес (WS – Notification).

Горизонтальна і вертикальна інфраструктура програмного забезпечення, яка необхідна для забезпечення безпеки, пошти, обміну повідомленнями, робочого потоку, колаборації, обмінів програма – програма, а також середовища сумісного використання даних може бути знайдена в інфраструктурних пропозиціях таких компаній як IBM (WebSphere), Microsoft (.NET), BEA (WebLogic) і Sun (ONE). Web – сервіси і XML реалізації містяться в пропозиціях інших постачальників.

1.4.6.1 Сервіс-орієнтована архітектура

Фундаментальною концепцією OGSA є те, що сервісна архітектура складається з компонентів служб GRID, які працюють як спеціальні Web – сервіси, що надають ряд інтерфейсів, що відповідають спеціальним вимогам. SOA визначає, як взаємодіють два обчислювальні об'єкти, для того, щоб один об'єкт дав можливість другому виконати визначену роботу на користь першого. Ця робота співвідноситься з сервісом, а дії сервісу визначаються мовою описів. Кожна взаємодія самостійна і практично не залежить від іншого. Бізнес додатки створюються для автоматизації різних бизнес – процесів, але часто без здійснення в них можливості адаптуватися до потреб, що змінюються; доопрацювання бізнес процесів в даному середовищі, достатньо трудомістке завдання. Все тому, що бізнес додатки традиційно створюються як одиничні, монолітні, такі, що включають всі інструменти. Тому будь – які зміни в них достатньо дорогі і займають багато часу. У середовищі SOA, додатки створюються у вигляді набору сервісів, кожен з яких має свої завдання і властивості. У міру зміни потреб, деякі сервіси можуть додаватися, деякі видалятися або доопрацьовуватися.

Web – сервіси володіють наступними характеристиками:

·     Це Інтернет додаток, що виконує спеціальні завдання і що підкоряється стандартним специфікаціям.

·     Сервіс є здійснимим, він описується на XML і доступі до нього може бути здійснений за допомогою XML – повідомлень.

·     Він може бути анонсований, виявлений і викликаний в розподіленому обчислювальному середовищі.

·     Він не залежить від платформи або мови.

Web – сервіс є системою ПЗ, URL якого ідентифікується, а інтерфейси і зв'язки визначені і описані за допомогою XML. Він може бути виявлений іншими системами ПЗ. Ці системи, у свою чергу, можуть взаємодіяти з Web – сервісом, використовуючи XML повідомлення, що передаються за допомогою Інтернет протоколів. Мова описів Web–сервісів (WSDL) фактично є, заснованим на XML, стандартом для опису Web–сервісів. Простий протокол доступу до об'єктів (SOAP) є, заснованим на XML, стандартним мережевим протоколом для обміну повідомленнями між Web – сервісами (описи W3C).

1.4.6.2 Мова описів Web – сервісів

WSDL документ (мова описів Web – сервісів) визначає Web – сервіс, використовуючи приведені нижче основні елементи:

 

Таблиця 1.2 – Деякі позначення елементів у мові описів Web – сервісів

Елемент

Визначає

<portType>

Постачальники повинні показувати, чи можливо ефективно управляти процесами GRID, включаючи модель на випадок збитків

<Message>

Повідомлення, використовувані в Web – сервісе. Абстрактне визначення передаваних даних

<Types>

Типи даних, використовувані в Web – сервісе. Надає інформацію про будь – які складні типи даних, вживаних в документах WSDL. У разі використання простих типів даних цей елемент не потрібний.

<Binding>

Протоколи з'єднання, використовувані в Web – сервісе. Описує, як викликається операція, за допомогою визначення протоколу і формату даних

<Port>

Визначає одиночну крайову крапку у вигляді адреси для з'єднання, тобто крайову точку з'єднання

<Service>

Визначає адреси портів з'єднання. Служба – сукупність мережевих крайових крапок або портів

 

 

WSDL документ містить описи елементів, що складаються з блоків types, message, portType,binding, і service elements, що описане в таблиці вище. Основна структура документа WSDL виглядає таким чином:

<definitions>

<types>

опис типів. . .

</types>

<message>

опис повідомлень . . .

</message>

<portType>

опис порту . . .

</portType>

<binding>

опис з'єднання . . .

</binding>

</definitions>

1.4.6.3 Web Services Inspection Language

Web Services Inspection Language (WSIL) – простий механізм виявлення Web – сервісів. WSIL – формат XML документа, створений для полегшення збору і виявлення Web – сервісів. Створений IBM і Microsoft і виданий в кінці 2001 року, WSIL є привабливим за рахунок своєї простоти, в порівнянні з UDDI, він простий і краще «піднімає» існуючі Web – сервіси. Модель WSILдецентрализована і «піднімає» існуючі Web – сервіси прямо на місці.

1.4.6.4 Universal Description, Discovery, and Integration

Universal Description, Discovery, and Integration (UDDI) – стандартний протокол опису Web – сервісів і протокол їх пошуку. Реєстр (UDDI) може містити метадані для будь – яких видів сервісів, разом з варіантами «якнайкращої практики», вже визначеними для сервісів, описаних за допомогою WSDL. За рахунок розбиття Web – сервісів на групи, що взаємодіють з категоріями і бізнес процесами, UDDI здатний ефективно шукати Web – сервіси. Специфікація UDDI визначає ієрархічну схему XML, що забезпечує модель для анонсування, перевірки і виклику інформації проWeb – сервіси. Вибір ліг на XML, оскільки його формат представлення даних не залежить від платформи і відображає ієрархічні взаємозв'язки. У UDDI використовуються технології, засновані на загальних інтернет протоколах TCP/IP, HTTP, XML і SOAP. Існує 2 види UDDI реєстрів: публічні реєстри UDDI – службовці точками збору різних бізнесів, для повідомлення про їх сервіси, приватні реєстри UDDI, які роблять те ж саме але для організацій.

UDDI регістр містить наступні структурні типи даних:

·     businessEntity. XML – элемент верхнього рівня в бізнес запису UDDI. businessEntityзбирає дані по запиту інформації об бізнес обслуговуванні, категорії продукту або виробництва, географічному положенні, а також контактну інформацію. Він підтримує пошук по організаціях, продуктах і географічному положенні.

·     businessService. Логічне продовження структури даних businessEntity і родоначальник структури bindingTemplate. businessService містить описову інформацію бізнес послуг з груп споріднених технічних послуг, включаючи ім'я групи, коротку інформацію про групу, опис технічної послуги, інформацію про категорію.

·     bindingTemplate. Логічне продовження структури businessService. bindingTemplateмістить дані, що відносяться до додатків, які необхідно запустити або пов'язати з Web – сервісом. Ця інформація містить URL Web – сервіса, посилання на специфікації інтерфейсу і ін.

·     tModel. Містить описи специфікації Web – сервісів або систематики, які формують основу для технічних ідентифікаторів. Роль tModel полягає в наданні технічних специфікацій Web– сервісів, що дозволяє полегшити пошук Web – сервісів, сумісних з певною технічною специфікацією. Користувачі Web – сервісів можуть легко визначити інші сумісні Web – сервіси,грунтуючись на описі специфікацій в структурі tModel. Наприклад, для того, щоб послати биснес – партнеру RFP, запрошуюча служба повинна знати не тільки URL/местоположение служби, але і в якому форматі повинен бути посланий RFP, які протоколи використовувати, врахувати вимоги безпеки, яку форму відгуку має на увазі відсилання RFP.

1.4.6.5 Протокол SOAP (Simple Object Access Protocol)

SOAP – простий, заснований на XML, протокол, для обміну інформацією в децентралізованому, розподіленому середовищі. SOAP підтримує різні стилі обміну інформацією, включаючи:

·     Обмін інформацією, що формується після видаленого виклику процедури. Цей тип обміну робить доступним процес запит – відповідь, в якому крайовий користувач отримує процедурне повідомлення і дає відповідь відповідним повідомленням.

·     Інформаційний обмін на основі механізму обміну повідомленнями. Цей тип обміну використовують організації і додатки, яким потрібно обмінюватися бізнес – документами, послане повідомлення не має на увазі негайний відгук на нього.

SOAP характеризується:

·     Протокольною незалежністю.

·     Мовною незалежністю.

·     Незалежністю від ОС і платформи.

·     Підтримкою SOAP XML – повідомлень взаємодіючих частин (використовуючи багатоскладну структуру MIME).

Повідомлення SOAP складається з (1) SOAP конверта, який містить дві структури даних, (2) SOAP – заголовка і тіла SOAP і (3) інформації про імена, службовців для їх опису. Заголовок є необов'язковою частиною, він передає інформацію про запит, визначений в тілі SOAP. Наприклад, він може містити інформацію по безпеці, ділову інформацію або профіль користувача. Тіло містить запит Web – сервісу або відповідь на нього.

Специфікація описує структуру і тип даних при обміні повідомленнями, використовуючи XML – схему. Спосіб, в якому SOAP використовується для посилки запитів і отримання відповідей від Web – сервіса:

·     Клієнт SOAP використовує документ XML, який узгоджується із специфікацією SOAP і містить запит про послугу.

·     Клієнт SOAP посилає документ серверу SOAP, а той обробляє його за допомогою HTTP, HTTPS.

·     Web – сервіс отримує повідомлення SOAP, направляє його, у вигляді службового запиту, додатку, що надає запрошувану послугу.

·     Відгук від сервісу повертається SOAP серверу, використовуючи SOAP протокол, а це повідомлення повертається SOAP – клиенту, що послав запит.

 

Веб-технології відіграли суттєву роль у справі вільного доступу та спільного використання інтернет-ресурсів. Чергового прориву на цьому шляху, що приведе нас до Веб нового покоління, вже давно очікують від грід-технологій. Вони обіцяють забезпечити зв’язність ресурсів, їх функціональну сумісність на принципово новому рівні, незважаючи на географічні обмеження чи неоднорідність ресурсів. Грід робить можливим спільне використання, вибір, агрегування географічно розподілених, автономних ресурсів залежно від їх доступності, потужності, вартості, адміністративних політик, вимог користувачів до якості обслуговування та надійності тощо. Таким чином, Веб може розглядатися як “інформаційний грід”, а Грід – як “розширений веб”, що позначає те, що Грід йде далі суто інформаційного обміну, надаючи можливість спільного використання комп’ютерних ресурсів (ЦП, пам’ять, сховища, мережі, програми, високоточне обладнання тощо), а не лише інформації. Серед додаткових можливостей, які Грід може потенційно запропонувати порівняно з Веб, можна вказати хоча б такі: автоматичне динамічне оновлення та розширення, конфігурування, підбір ресурсів, автоматичне планування, інтелектуальний синтез знань, автоматичне рішення питань сумісності. Однак, претендуючи на місце у майбутньому Веб, Грід має бути узгоджений з веб-технологіями не лише з концептуального боку, а й з технічного.

Грід-сервіси та їх особливості

Розглядаючи грід-систему у статиці, можна представити Грід як множину компонентів – користувачів, апаратних ресурсів, програм, служб. Основу частину компонентів Грід складають грід-ресурси. Під ресурсом можна розуміти будь-який реальний чи уявний об’єкт, до якого потрібно надати доступ іншим сутностям типу користувачів чи програм. Виділяють дві основні категорії грід-ресурсів: фізичні (обчислювальні ресурси, сховища, мережі, периферія), та логічні (дані, знання, прикладні програми). Таке представлення Грід як взаємопов’язаної множини ресурсів відоме як “ресурсно-орієнтоване”. В той же час, ресурси та користувачі Грід перебувають у постійній взаємодії: вони взаємодіють між собою, надсилаючи чи отримуючи запити та відповіді на них, при цьому діючи як незалежні агенти. З такою динамічною поведінкою грід-систем добре узгоджується “сервісно-орієнтований” підхід, базовим поняттям якого є сервіс. Під сервісом можна розуміти деякий програмний модуль із визначеною функціональністю. Мережеве поєднання сервісів, подібне до нейронних структур людського організму, де виходи одного сервісу можуть бути входами для іншого, дозволяє будувати системи зі складною поведінкою. Серед головних принципів сервісно-орієнтованої архітектури (SOA) виділяють наступні: максимальне повторне використання, модульність, здатність до поєднання, функціональна сумісність, відповідність стандартам, можливість ідентифікування, категоризації, моніторингу сервісів. Ці загальні принципи згодом конкретизувалися у наступний перелік:

1.  Стандартизований контракт. Інтерфейс взаємодії сервісів описується документально.

2.  Слабка зв’язність. Взаємозв’язки між сервісами мають бути такими, що мінімізують взаємозалежності.

3.  Абстрагування сервісів. Внутрішня логіка сервісу має бути прихована від зовнішнього світу, який обізнаний лише з його контрактом.

4.  Повторне використання. Логіка розбивається на сервіси з думкою про вигоду повторного використання.

5.  Автономність сервісів. Сервіси контролюють логіку, яку вони інкапсулюють.

6.  Відсутність внутрішнього стану. Задля мінімізації використання ресурсів та кращої масштабованості сервіси не повинні зберігати свій стан між викликами.

7.  Автоматизоване виявлення. Сервіси супроводжуються метаданими, що уможливлюють їх автоматизоване виявлення та ідентифікацію.

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

Зважаючи на ці особливості та відштовхуючись від сервісно-орієнтованого підходу, підходящою абстракцією для одиниці функціональності Грід є грід-сервіс: спеціалізована автономна служба, що є базовою складовою частиною середовища зі слабкими зв’язками між компонентами, яким є Грід. Наприклад, грід-сервіси, призначені для роботи з даними, взаємодіють з грід-ресурсами сховищ, грід-сервіси для рішення складних обчислювальних задач використовують обчислювальні грід-ресурси тощо. Надалі будемо спиратися на саме таке загальне трактування грід-сервісу як самостійної функціональної одиниці грід-системи, без огляду на технічні деталі його поведінки, реалізації, протоколів. Таке уточнення необхідне, оскільки існує і вузьке конкретне визначення грід-сервісу як веб-сервісу, що надає набір визначених інтерфейсів та слідує певним домовленостям, визначеним у “Відкритій архітектурі грід-сервісів” (OGSA). Для того, щоб розрізняти ці поняття, реалізацію грід-сервісів за OGSA будемо іменувати OGSA-сервісами. Виділяють також базові грід-сервіси, що надають базову функціональність грід-системи користувачам (запуск задач, передача даних, моніторинг та ін.), та прикладні, додаткові, спеціалізовані грід-сервіси, що надають додаткову функціональність (напр., вирішуючи вузькоспеціалізовані обчислювальні задачі таких прикладних областей, як астрономія, біомедицина, фізика тощо) та можуть використовувати у своїй роботі базові грід-сервіси (в т.ч. агрегуючи їх для створення складних середовищ вирішення задач, грід-порталів). Щоправда, реалії Грід вносять деякі уточнення у принципи побудови сервісів. Серед загальних особливостей та вимог саме до грід-сервісів порівняно з принципами SOA варто виділити такі :

1.  Тривалий час існування та складний життевий цикл. Грід-сервіси, зазвичай, мають складнішу логіку, ніж просто “запит-відповідь”. Тому грід-сервіси можуть існувати довше, аніж від моменту надходження запиту до сервісу до надсилання сервісом відповіді.

2.  Підтримка внутрішнього стану. Грід-сервіси можуть слугувати для доступу до реальних об’єктів грід, таких як задачі, файли, апаратні ресурси, програми тощо. В цьому випадку, грід-сервіс має змінювати стан об’єктів, за які він відповідає, у відповідь на вхідні запити. Якщо ж кожному з таких об’єктів поставити у відповідність свій екземпляр грід-сервісу, то цей екземпляр має змінювати свій стан та зберігати його протягом всього часу існування зв’язаного з ним об’єкту. Цей пункт явно суперечить пункту 6 викладених вище принципів SOA.

3.  Оповіщення. Грід-сервіси мають підтримувати механізм оповіщень, за допомогою яких вони асинхронно, тобто, без потреби у вхідному запиті, надсилають своїм клієнтам повідомлення про зміни у стані.

4.  Узгодженість із інфраструктурою безпеки Грід (GSI).

Життєвий цикл грід-сервісів

Вищевикладені пункти потребують деяких уточнень. Наведемо кілька прикладів. Так, якщо сервіс слугує для надання синхронних відповідей на запити типу “надати перелік доступних грід-вузлів”, то йому не потрібно підтримувати механізм оповіщень, існувати постійно між вхідними запитами, підтримувати свій внутрішній стан. Все, що має виконувати такий сервіс – зчитати збережений на поточний момент перелік грід-вузлів з бази даних і передати цю інформацію клієнту. Однак, якщо сервіс слугує для управління конкретною грід-задачею (сама задача представлена як окремий сервіс), то цей сервіс зобов’язаний існувати так довго, як існує сама задача у грід, і кожний новий вхідний запит має змінювати або опитувати поточний внутрішній стан сервісу. Таким чином, грід-сервіси як складова грід-системи не мають певних обов’язкових обмежень на модель поведінки чи особливості життєвого циклу. Ці обмеження вводяться на етапі конкретизації грід-системи у певну архітектурну модель. Так, архітектура OGSA, що успішно реалізована в таких пакетах програмного забезпечення проміжного шару Грід, як Globus Tooklit 4 [10] чи UNICORE [11], зобов’язує грід-сервіс дотримуватись вимог 1-4. Будь-яке інше конкретне архітектурне рішення може відходити від цих вимог, і, можливо, лишатись при цьому життєздатним. Дане дослідження розглядатиме шляхи узгодження грід-сервісів та веб-сервісів з урахуванням можливості забезпечення вимог 1-4, при цьому не орієнтуючись виключно на архітектуру OGSA та сумісність з нею.

Веб-сервіси: перевірене рішення для SOA

На сьогодні найбільш популярною технологією, яка реалізує принципи SOA є веб-сервіси. Часто ці терміни навіть помилково сприймають як синоніми. Веб-сервіси визнані надійним рішенням з обміну повідомленнями між сутностями незалежно від їх географічної рознесеності чи технологічної (апаратної, програмної) гетерогенності. Веб-сервіси як платформа для організації міжпрограмної взаємодії добре себе зарекомендувала при побудові інтернет-сервісів B2B, e-Science, e-Government. Їх застосування сприяє впровадженню міжмашинної взаємодії, зменшуючи обсяги ручної, неавтоматизованої роботи користувачів. Будучи добре стандартизованими, веб-сервіси спрощують задачу забезпечення функціональної сумісності та інтеграції компонентів від різних постачальників. Цю задачу значно полегшує і той факт, що веб-сервіси є незалежними від мови програмування чи операційної системи. Стек технологій веб-сервісів, таких як XML, WSDL, SOAP та UDDI, дозволяє на практиці реалізувати принципи SOA на рівні “будь-що є сервісом”. Очевидним є бажання перевірити, чи так само добре підходить технологія веб-сервісів для використання її у архітектурі Грід.

 

Таблиця 2.1 – Спільні та відмінні риси грід- та веб-сервісів

 

Веб-сервіси

Грід-сервіси

Спільні принципи

Модульність, слабка зв’язність, прагнення до повторного використання, абстрагування, здатність до поєднання, моніторинг, категоризація

 

Життєвий цикл

Від запита до відповіді, збереження даних у БДМ

Існування між запитами, впродовж часу існування грід-ресурсу

Внутрішній стан

Відсутність спеціальної підтримки як ідеологічно, так і в стандартах

Має підтримуватись через особливості грід-ресусрів

Оповіщення

Прийнято додаткові стандарти WS-Notification

Мають підтримуватись через специфіку роботи Грід.

Безпека

Стандарти WS-Security

Підтримка GSIМ

Стандартизація

Визначені, зрілі стандарти

Наявність різних реалізацій проміжного програмного забезпечення грід не сприяє стандартизації

 

 

Грід-сервіси та веб-сервіси: можливість інтеграції

До цього моменту було показано, веб-сервіси та грід-сервіси ідеологічно мають і багато спільного, і декотрі відмінності. Уточнимо їх (таблиці 2.1). Ці відмінності традиційно виділяються теоретиками Грід (в основному, учасниками Global/Open Grid Forum) як важливі передумови для введення доповнень у стандарти веб-сервісів. Чи є ці зміни необхідними та принципово неминучими, буде детальніше розглянуто в наступних розділах, а зараз спробуємо лише окреслити можливі шляхи інтеграції грід- та веб-сервісів. Виходячи з того, що грід-сервіси не завжди можуть бути повноцінно реалізовані як веб-сервіси, оскільки веб-сервіси не у всьому сумісні з архітектурою грід [9], то мова може йти про компромісне змішане “Грід-Веб-рішення”. Вже згадані OGSA-сервіси були першою спробою поєднати грід- та веб-сервіси на рівні, близькому до стандартів. OGSA не лише визначила семантику грід-сервісу, а й вказала стандартні механізми створення, іменування, виявлення грід-сервісів, що могли б існувати тривалий час та підтримували внутрішній стан. Як результат, була розроблена специфікація OGSI (Open Grid Services Infrastructure) [12], яка, реалізуючи принципи OGSA, визначала грід-сервіс як веб-сервіс, що відповідає певним домовленостям по інтерфейсам та поведінці. Було визначено, як саме клієнт має взаємодіяти з грід-сервісом стосовно питань управління життєвим циклом, отримання оповіщень, обробки помилок. Ці визначені специфікацією домовленості надавали можливість надійного, безпечного, відмовостійкого управління станом, що звичайно вимагається у розподілених системах типу Грід. З певних причин, які будуть детальніше розкриті згодом, ця специфікація не набула популярності у веб-спільноти. На зміну їй було розроблено сімейство стандартів WSRF (Web Service Resource Framework), вже таки затверджене OASIS. WSRF зосереджується на створенні, адресації, управлінню життевим циклом ресурсів, що мають внутрішній стан. Була проведена межа між веб-сервісом та ресурсом, та вказані шляхи, за допомогою яких клієнт міг звертатися до конкретного ресурсу. У деяких роботах робиться спроба виділити два ортогональні методи інтеграції веб- та грід-сервісів: грід-орієнтовані веб-сервіси та веб-орієнтовані грід-сервіси. Перший підхід полягає у тому, що веб-сервіси набувають деякої грід-специфічної функціональності, тобто “наслідуюються” від грід-сервісів, якщо користуватися об’єктно-орієнтованою термінологією. Другий підхід полягає у тому, що грід-сервіси використовують веб-сервіси як комунікатори, як “базовий клас” для наслідування, таким чином грід-сервіси можуть розглядатися і як стандартні веб-сервіси.

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

 

 

Таблиця 2.2 – Можливі шляхи узгодження грід та веб-сервісів

Наслідки для...

Адаптація Грід під стандарти веб-сервісів

Адаптація Веб під вимоги грід-сервісів

Грід

архітектура грід-сервісів віддаляється від концепції “ресурс-як-сервіс”

можливо реалізувати складну поведінку грід-сервісів, відповідну до життєвого циклу грід-ресурсів

Веб

грід-сервіси автоматично сумісні з існуючими веб-сервісами, адаптувати численний WS-інструментарій не потрібно

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

 

 

Як видно, кожен з підходів має свої недоліки: потрібно або переглядати архітектуру грід так, щоб вона була придатна до реалізації на “чистих” веб-сервісах, що не зовсім коректно з ідеологічного боку, або ж треба вносити доповнення до веб-сервісів та ризикувати не дочекатися їх затвердження (у випадку з OGSI) чи прийняття та просування веб-спільнотою. Тепер розглянемо детальніше інтеграційні можливості кожного з цих підходів. Для дослідження першого підходу слід розглянути особливості базових складових технологій веб-сервісів: SOAP, WSDL, UDDI, стандарти WS-*. Другий підхід краще дослідити на прикладах еволюції специфікацій OGSA-OGSI-WSRF.

Веб-сервіси як спосіб реалізації грід-сервісів

Базові елементи технології веб-сервісів

Архітектура веб-сервісів базується на трьох основних елементах:

-      SOAP (Simple Object Access Protocol, простий протокол доступу до об’єктів) як протокол обміну XML-повідомленнями,

-      WSDL (Web Service Description Language, мова опису веб-сервісів) як стандартна мова опису контрактів сервісів,

-      UDDI (Universal Description Discovery & Integration, універсальний опис, виявлення, інтеграція) як стандартний механізм для пошуку сервісів.

Переваги веб-сервісів, що зробили їх популярними, наступні: незалежність від мови програмування та платформи, та використання мови XML, для якої існує чимало засобів обробки на багатьох мовах. Уточнимо, яким чином відбувається взаємодія клієнта з веб-сервісом. Головні актори у взаємодії:

-      програмний клієнт (не сам користувач, а програма, в т.ч. – інший веб-сервіс, тобто веб-сервіси слугують для взаємодії між машинами, а не людьми);

-      реєстр сервісів (UDDI-сховище описів веб-сервісів, в якому публікуються контракти та інші метадані веб-сервісів для їх подальшого пошуку та використання клієнтами);

-      сам веб-сервіс (програма, що здатна обмінюватись повідомленнями по протоколу SOAP відповідно до WSDL-контракту, постачальник веб-сервісу відповідальний за публікацію його опису у UDDI та забезпечення його доступності).

Наступна схема (рисунок 2.1) ілюструє порядок взаємодії з веб-сервісом. 
Постачальник веб-сервісу може не публікувати його метадані у реєстрі, не створювати WSDL-опису. Таке спрощене рішення залишиться дієвим у невеликих закритих системах, однак таке рішення значно втратить у інтероперабельності та масштабованості. Якщо дотримуватись повного циклу зі створення веб-сервісу, то слід опублікувати його опис, бажано – у стандартному сховищі.

Опис : D:\WORK\Dropbox\Акредитація\ris-2-1.JPG

Рисунок 2.1 – Взаємодія з веб-сервісом: обробка повідомлень

 

Після цього будь-який клієнт може дізнатись про існування веб-сервісу та порядок взаємодії з ним, опитавши реєстр. Стандартний UDDI-сервіс реєстру покликаний допомогти в автоматизації процесу пошуку сервісів. Однак допустимим є публікація контракту веб-сервісу і у інші способи – головне, щоб цільові клієнти могли ознайомитись із цим контрактом стосовно інтерфейсу взаємодії із сервісом. Отримавши з реєстру (чи будь-де інде) WSDL-опис веб-сервісу, клієнт може з нього дізнатись, де і як звернутися до сервісу. WSDL є мовою опису інтерфейсів для веб-сервісів. За цим етапом вже слідує безпосередньо етап взаємодії. Клієнт надсилає веб-сервісу дані, загорнуті у SOAP-повідомлення. Зазвичай передача йде по протоколу HTTP. Веб-сервіс розгорнутий на веб-сервері, зі встановленим SOAP-процесором, який дозволяє “розпакувати” дані з XML-повідомлення. Після виконання корисних дій, веб-сервіс повертає клієнту відповідь, загортаючи її назад у HTTP-SOAP-повідомлення. Слід відзначити, втім, що SOAP може використовуватись з будь-яким протоколом прикладного рівня: SMTP, FTP, HTTP та інш. Проте, найчастіше SOAP використовується разом з HTTP. Перш ніж перейти до розгляду окремих компонентів технології веб-сервісів, зробимо кілька коментарів у бік грід-сервісів. Очевидно, що на окремих вузлах грід, де будуть базуватися грід-сервіси, слід встановити контейнер: зв’язку “веб-сервер програм (Application Server) + SOAP-процесор (SOAP engine)” (детальніше про SOAP – див. далі). Допустимі два шляхи: намагатися не залежати від конкретної реалізації контейнера, використовуючи готові відкриті продукти, чи розробити власне спеціалізоване рішення. Спеціалізоване рішення потребуватиме постійної підтримки вузького кола розробників, що може бути занадто обтяжливо, як показав приклад пакету проміжного програмного забезпечення Globus Toolkit 4. Розробники GT4 створили власний контейнер “Java WS Core” на базі Axis 1.x як середовище функціонування WSRF-сервісів (рисунок 2.2). Втім, після досвіду 5 років використання та підтримки було прийнято рішення про припинення розвитку WS-core, оскільки за цей час технології еволюціонували, бібліотеки Axis 1.x та PureTLS застаріли. Це поставило під питання майбутнє WSRF-архітектури базових сервісів Грід, від якої (можливо, тимчасово) відійшли її ж творці у наступній 5-ій версії GT. Цей приклад доводить, що при виборі технічних засобів слід враховувати, наскільки широке коло їх користувачів, стабільність розвитку, підтримку, перспективи, мінливість тих чи інших стандартів, на яких вони базуються.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-2.JPG

Рисунок 2.2 – SOAP-контейнер GT4

 

Протокол SOAP (Simple Object Access Protocol)

SOAP – це протокол обміну XML-повідомленнями. Відгук від сервісу повертається SOAP серверу, використовуючи SOAP протокол, а це повідомлення повертається SOAP - клиенту, що послав запит.

SOAP – простий, заснований на XML, протокол, для обміну інформацією в децентралізованому, розподіленому середовищі. SOAP підтримує різні стилі обміну інформацією, включаючи:

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

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

SOAP характеризується:

-      Протокольною незалежністю.

-      Мовною незалежністю.

-      Незалежністю від ОС і платформи.

-      Підтримкою SOAP XML - повідомлень взаємодіючих частин (використовуючи багатоскладну структуру MIME).

Повідомлення SOAP складається з (1) SOAP конверта, який містить дві структури даних, (2) SOAP - заголовка і тіла SOAP і (3) інформації про імена, службовців для їх опису. Заголовок є необов'язковою частиною, він передає інформацію про запит, визначений в тілі SOAP. Наприклад, він може містити інформацію по безпеці, ділову інформацію або профіль користувача. Тіло містить запит Web - сервісу або відповідь на нього.

Специфікація описує структуру і тип даних при обміні повідомленнями, використовуючи XML – схему. Спосіб, в якому SOAP використовується для посилки запитів і отримання відповідей від Web - сервіса:

-      Клієнт SOAP використовує документ XML, який узгоджується із специфікацією SOAP і містить запит про послугу.

-      Клієнт SOAP посилає документ серверу SOAP, а той обробляє його за допомогою HTTP, HTTPS.

-      Web - сервіс отримує повідомлення SOAP, направляє його, у вигляді службового запиту, додатку, що надає запрошувану послугу.

Встановлюючи правила на структуру повідомлень, придатні і для односторонньої комунікації, SOAP особливо корисний при клієнт-серверній взаємодії у RPC-стилі (запит-відповідь). Одною з вагомих переваг протоколу SOAP над, скажімо, CORBA, є те, що постачальник сервісу не зобов’язаний надавати скомпільовані клієнтські “заглушки” для усіх типів клієнтів (SOAP взагалі не прив’язаний до платформи чи мови програмування). По-друге, протокол SOAP є більш дружнім до файрволів. Однак ці переваги досягаються за рахунок меншої продуктивності, спричиненої витратами на обробку XML-повідомлень.

SOAP-повідомлення є синтаксично коректними (англ. well formed) XML-документами. Структурними елементами є пролог (необов’язковий елемент) з XML-декларацією та SOAP-конверт (пакунок, envelope) – кореневий елемент, який містить елементи заголовку (необов’язковий) та тіла повідомлення:

-      XML Declaration (optional).

-      SOAP Envelope (the root element.

-      SOAP Header (optional.

-      SOAP Body.

Характерними є дві речі: відносно велика частка службових символів (корисна інформація, фактично, полягає у назві методу, типу параметру та його значенні – див. Приклад), та використання просторів імен (namespaces). Використання просторів імен, визначених у XML-схемах, дає, між іншим, можливість застосовувати верифікацію повідомлень на відповідність XML-схемам. Це, звичайно, знизить швидкість обробки. Тобто, протокол SOAP, з одного боку, – простий та незалежний від ОС чи мови програмування, що є перевагою у випадку грід-середовищ. Він добре підходить під модель “запит-відповідь”, допускає механізми автоматизованої перевіки повідомлень на їх відповідність встановленим зразкам, в наявності є автоматизовані засоби для розробників програмного забезпечення (в т.ч. грід-сервісів).

 

Лістинг 2.1 – Простий приклад повідомлення-запиту для методу “піднести ціле число у квадрат” матиме вигляд.

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-1.JPG

Однак, для викорстання у Грід може знадобитися додатковий захист – шифрування самого вмісту XML-повідомлень. Слід також відзначити чималі накладні витрати на пакування-розпакування повідомлень, істотно вищі ніж у інших протоколів типу CORBA. Це слід враховувати при розробці грід-сервісів, які інтенсивно обмінюються значними об’ємами даних.

WSDL-опис

Згідно підходу SOA інтерфейси сервісів мають бути чітко описані та опубліковані. Ця вимога набуває значення, коли в складній архітектурі мають поєднуватись сервіси різних розробників. WSDL-документ – це контракт веб-сервісів, мова WSDL – це мова опису інтерфейсів веб-сервісів. WSDL-опис є також XML-документом, що зручно з точки зору наявних засобів розбору для різних мов програмування. Існує дві специфікації WSDL – перевірена часом і досі популярна 1.1, та офіційно рекомендована W3C у 2007 р. нова версія 2.0. Розглянемо деякі особливості мови WSDL на прикладі версії 2.0, маючи на увазі деякі відмінності між версіями, показані на рисунку 2.3. Опис веб-сервісу можна розділити на дві частини. У абстрактній частині опису веб-сервіс описується за допомогою системи типів (зазвичай з використанням XML-схеми), поняттями повідомлень, які сервіс приймає та відправляє. Шаблони обміну повідомленнями визначають послідовність та кількість повідомлень. Елемент operation зв’язує шаблони обміну повідомленнями з одним або кількома повідомленнями. Елемент interface групує операції (елементи operation) незалежно від протоколу передачі даних. У конкретній частині опису елементи binding задають транспорт та формат доставки для інтерфейсів (елементів interface). Елемент servcie endpoint пов’язує мережеву адресу із елементом binding. Нарешті, елемент service групує елементи endpoint, що реалізують загальний інтерфейс.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-5.JPG

Рисунок 2.3 – Відмінності у термінології WSDL 1.1 та 2.0

 

Лістинг 1.2 – Задання параметрів

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-2.JPG

Ще раз підкреслимо значимість WSDL-контракту для побудови архітектури на веб-сервісах (і грід-сервісах): опис інтерфейсу сприяє автоматизації при взаємодії з веб-сервісом не лише людини, розробника програмного забезпечення, а й інших сервісів, дозволяє автоматично компонувати сервіси згідно їх інтерфейсів у складні маршрути. Наявність механізмів доставки повідомлень про помилки також є дуже важливою, хоча усі сценарії, закладені у шаблони обміну повідомленнями є синхронними. Асинхронні ж оповіщення не входять до стандарту WSDL 2.0. Також WSDL 2.0 все ще бракує семантики, що може бути виправлене за рахунок додаткових анотацій.

UDDI

UDDI (Universal Description, Discovery and Integration) надає відносно незалежний механізм для публікації та пошуку описів сервісів. Він підтримує різні типи описів сервісів, включаючи WSDL-документи, стандартні Java-інтерфейси чи інші XML-документи. У специфікації визначається API реєстру, причому інтерфейс призначений виконувати дві важливі задачі: реєструвати бізнес та його сервіси, і шукати зареєстровані сервіси та прив’язуватись до них. Тобто вузол UDDI-реєстру слугує як провайдер сервісу (публікуючи сервіси), як реєстр сервісів (надаючи можливість проглядати каталог веб-сервісів), та запитувач сервісів (шукаючи запитаний сервіс та прив’язуючи клієнта до нього). І реєстрація, і опитування здійснюються через визначені UDDI-команди, які передаються через SOAP. UDDI насправді представляє собою веб-сервіси, що дозволяють клієнтам реєструвати інтерфейс на вузлі, проглядати, перевіряти, прив’язуватись до зареєстрованих сервісів. Для доступу до цих сервісів UDDI клієнт надсилає SOAP-повідомлення у термінах UDDI-схеми. На рис. показана базова архітектура UDDI-реєстру стосовно запитів. SOAP-запит надсилається до серверу та десеріалізується SOAP-процесором на UDDI-вузлі. Далі виконуються UDDI-запити до реєстру, що перетворюються на запити до бази даних. Відповідь зворотнім порядком через SOAP-процесор для серіалізації та веб-сервер доставляється клієнту (рисунку 2.4).

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-8.JPG

Рисунок 2.4 – Спрощена схема архітектури UDDI-реєстру

 

Тобто використання UDDI передбачає обмін SOAP-повідомленнями. Можливе створення власних приватних реєстрів для корпоративного інтранету або B2B-мережі. Публічні реєстри різного часу створювались на ibm.com, microsoft.com, sap.com, uddi.org, xmethods.com. Згодом, компанії зосередились на приватних реєстрах, використовуючи UDDI як стандартний механізм реєстрації та пошуку корпоративних сервісів у внутрішній мережі або для представлення своїх сервісів бізнес-партнерам. Реєстри UDDI зберігають інформацію про організації, їх сервіси, і про те, як до цих сервісів отримати доступ. Розроблена модель даних та API які дозволяють публікацію такої інформації та її опитування. Така система часто порівнюється із електронною телефонною книжкою, у якій інформація різних типів проіндексована та представлена відповідним чином. Конкретніше говорять, що UDDI підтримує три типи даних реєстру: «білі сторінки» (довідник бізнес-учасників за іменем), «жовті сторінки» (бізнес за категорією) та «зелені сторінки» (бізнес за сервісами):

-      Білі сторінки – функції UDDI як білих сторінок дозволяють шукати бізнес по імені або якомусь іншому унікальному ідентифікатору типу DUNS чи Thomas Register. Ця інформація доступна через елемент businessEntity.

-      Жовті сторінки – бізнес по категоріям. UDDI також підтримує категоризацію по галузях промисловості, продукції, місцезнаходженню. Ця інформація також пов’язана з елементом businessEntity.

-      Зелені сторінки – умовно позначають можливість UDDI реєструвати бізнес та проглядати зареєстровані записи по типам сервісів та можливостям, які вони надають. Ці можливості надаються елементами businessService та bindingTemplate.

Тобто загалом, UDDI дозволяє реєстрацію та пошук за такими критеріями: назва, ідентифікатор, промисловість, продукція (послуги), місцезнаходження, тип сервісу, бізнес-процес. Розглянемо дещо детальніше структури даних реєстру (рисунок 2.5). Уся інформація в реєстрі зберігається у вигляді взаємопов’язаних екземплярів кількох типів структур даних:

-      businessEntity (інформація про організацію-постачальник сервісу)

-      businessService (опис функціональності сервісу)

-      bindingTemplate (технічні тедалі сервісу)

-      tModel (атрибути чи метадані про сервіс, такі як таксономії, транспорт, цифрові підписи тощо)

-      publisherAssertions (відношення між сутностями в реєстрі)

-      subscription (запит на внесення змін до списку сутностей)

Кожна структура даних в реєстрі має унікальний ключ – UUID (Universally Unique ID). Що важливо, реєстр дозволяє побудову різних таксономій для створення семантичної структури інформації, яка зберігається в реєстрі.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-9.JPG

Рисунок 2.5 – Структури даних реєстру та приклад їх заповнення

 

UDDI надає можливість реєструвати чи отримувати на запит WSDL-документ певного сервісу. Оскільки як UDDI, так і WSDL описують деталі сервісу (у власний спосіб), між ними є певний зв’язок. Використання гнучкості моделі даних UDDI та взаємовідповідностей між UDDI та WSDL дозволяє:

-              автоматичну реєстрацію сервісів із їх WSDL-описами у реєстрі та

-              автоматичне створення гнучких запитів до UDDI на основі знань з WSDL-опису. Таблиця відповідності елементів WSDL та UDDI наведена нижче.

 

Таблиця 2.3 – Відповідність елементів WSDL та UDDI (варіант)

WSDL

UDDI

інтерфейси (portType/interface

tModel

portType/interface

tModel

локальна назва portType

tModelName

місцезнаходження WSDL

overviewURL

прив`язка (binding)

tModel

Binding

tModel

binding Namespace

keyedReference у categoryBag

локальна назва binding

tModelName

portType на який посилається binding

keyedReference уcategoryBag

протокол

keyedReference у categoryBag

Транспорт

keyedReference у categoryBag

сервіс (service)

businessService

Service

businessService

service Namespace

keyedReference у categoryBag

локальна назва service

keyedReference у categoryBag

посилання (port/endpoint)

bindingTemplate

Port

bindingTemplate

port Namespace

keyedReference, що міститься в businessService

локальна назва port

InstanceParms у tModelInstanceInfo, що відносяться до tModel прив’язки

binding, вказаний у port

tModelInstanceInfo із tModelKey для tModel, що відноситься до binding

portType, вказаний у port

tModelInstanceInfo із tModelKey для tModel, що відноситься до portType

 

 

 

Таблиця 2.4 – Відповідність елементів BPEL та UDDI (варіант)

WSDL

UDDI

Process

tModel

process Namespace

keyedReference у categoryBag

локальна назва of process

tModelName

місцезнаходження BPEL-документа з описом процесу

overviewURL

WSDL portTypes

portType tModels

Port

bindingTemplate

 

 

Розглядаючи можливість композиції веб-сервісів та автоматичного виконання цілих маршрутів веб-сервісів, описаних мовою BPEL (детальніше – див. у наступних розділах), можливо використати наступні відповідності для відображення BPEL у UDDI (таблиця 2.4). Структури даних UDDI, зокрема, tModel, як вже зазначалося, можуть слугувати для додання семантики в реєстр. Так, можна створити (використати) онтологію веб-сервісів, та прив’язати її елементи до структур UDDI, причому за відсутності відповідників використовуються нові елементи tModel. Таким чином існує можливість створення модулів семантичного пошуку сервісів. У пропонується підхід, який полягає у розширенні структури даних UDDI businessService додатковим елементом serviceProfile, який вказуватиме на збережену DL-онтологію (KIF, DAML, OWL) сервісу. У деяких роботах пропонується подолати обмеженість синтаксичного пошуку UDDI за рахунок «обгортання» інтерфейсу UDDI у компонент-брокер, що підтримує семантичний пошук, та, паралельно із внутрішньою переадресацією запитів до UDDI, опитує базу онтологій.

WS-*

Стандарти На додачу до трьох основних елементів технології веб-сервісів (SOAP, WSDL, UDDI), було випущено ряд специфікацій, які стандартизують рішення в області адресації, безпеки, сумісності, оповіщень та ін. Розглянемо ті з них, які можуть бути особливо корисними при розробці грід-сервісів.

WS-Addressing

WS-Addressing встановлює стандартний механізм включення даних про маршрутизацію повідомлень у заголовки SOAP. Цей механізм доповнює транспорт мережевого рівня, який лише турбується про доставку повідомлення до диспетчера, який здатний прочитати метадані у SOAP-заголовку. WS-Addressing підтримує використання асинхронної взаємодії шляхом указання елемента SOAP-заголовку (wsa:ReplyTo), який містить кінцеве посилання (EPR) на одержувача відповіді. Це відокремлює час життя SOAP-транзакції «запит-відповідь» від тривалості життя HTTP-запиту/відповіді, дозволяючи (що важливо) довготривалі сеанси.

Кінцеві посилання.

Кінцеве посилання (англ. endpoint reference, EPR) – це XML-структура, що інкапсулює інформацію, корисну для адресації WS-повідомлення. Вона включає: адресу пункту призначення повідомлення та будь-які додаткові параметри (т.зв. параметри посилання), які необхідні для маршрутизації повідомлення до точки його призначення, а також – необов’язкові метадані (WSDL, WS-Policy) про сервіс. Параметри посилання:

-    URI точки призначення.

-    Source endpoint – EPR сервісу, що відправив це повідомлення (диспетчер).

-    Reply endpoint -- EPR, на яке слід надіслати відповідь.

-    Fault endpoint -- EPR, на яке слід надсилати повідомлення про помилки.

-    Action – значення, що може визначати семантику повідомлення (URI).

-    Унікальний ідентифікатор повідомлення (URI).

-    Відношення до попередніх повідомлень (пара URI).

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

WS-Security

WS-Security є гнучким та багатофункціональним доповненням до SOAP, яке впроваджує механізми безпеки. Протокол вказує, яким чином вимоги цілісності та конфіденційності можуть бути реалізовані для SOAP-повідомлень, а також дозволяє роботу з різними форматами, такими як SAMP, Kerberos, X.509. Основним акцентом є використання XML-підпису та XML-шифрування. WS-Security описує три головні механізми:

-    Як підписувати SOAP-повідомлення для гарантування цілісності та non-repudiation.

-    Як шифрувати повідомлення для гарантування конфіденційності.

-    Як додавати авторизацію (security-tokens).

Специфікація дозволяє використання широкий набір форматів цифрового підпису, алгоритмів шифрування, механізмів довіри, та security-tokens:

-    Сертифікати X.509.

-    Kerberos tickets.

-    Логін/пароль.

-    SAML-Assertion.

-    інші довільні засоби авторизації.

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

Приклади захисту SOAP-повідомлень.

1.  Transport Layer Security (без WS-Security) Типовий приклад – комунікація через HTTPS, WS-Security стає непотрібною, що сприятливо впливає на продуктивність обробки повідомлень

2.  Якщо ж довіряти проміжним ланкам не можна, повідомлення слід підписувати та, за потреби, шифрувати.

3.  Потрібно додатково гарантувати відповідальність (non-repudiation) – можливість довести, що саме заявленний користувач є автором повідомлення. Тут кращим рішенням можуть стати також цифрові підписи, механізм використання яких визначено у WS-Security.

При цьому слід враховувати, що накладні витрати на шифрування та підпис є достатньо суттєвими. Якщо продуктивність критична, слід намагатися використовувати лише один з видів захисту – шифрування або підпис. Накладні витрати пояснюються зростанням об’єму повідомлень та криптографічною обробкою. Так, було проведено кілька досліджень впливу захищеності повідомлень на швидкість їх обробки. За одним з них вимірювались 25 різних типів SOAP-повідомлень різного об’єму та складності, захищених WS-Security та WS-SecureConversation, на ЦП Pentium 4 2,8 ГГц. Воно виявило, що шифрування проходило швидше за підпис; одночасне шифрування та підпис у 2-7 разів повільніше, ніж лише підпис, та генерує значно більші документи; застосування операцій з безпеки до SOAP в десятки разів повільніше, ніж шифрування чи підпис простих даних. Важливість стандарту WS-Security для грід-сервісів полягає в тому, що він, підтримуючи X.509-сертифікати, дозволяє інтегруватися веб-сервісам у стандартну інфраструктуру безпеки грід (GSI) [20].

RESTful-веб-сервіси та Грід

Існують і альтернативні підходи до реалізації веб-сервісів. Одним з них є так званий REST-підхід, що базується на засадах архітектури Representational State Transfer [21]. За такого підходу спрощується реалізація клієнтів, оскільки такі веб-сервіси використовують сам лише протокол HTTP як основу для взаємодії, без додаткових протоколів-надбудов. REST-веб сервіси на даний момент не є стандартом, а лише підходом, набором поширених практик.

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

Запит складається із управляючої частини (команди), ідентифікатора ресурса (цілі запиту) та (необов’язкового) представлення ресурса. Відповідь містить метадані ресурса (в довільній формі) та (необов’язкове) представлення ресурса. Загально кажучи, RESTful-веб-сервіс є набором ресурсів, взаємодія з якими відбувається через HTTP-методи GET, PUT, POST та DELETE, та допустимих представлень ресурсів, узгоджених між споживачем сервісу та самим сервісом. При цьому важливим є відповідність логічної операції над ресурсом HTTP-методу. Звичайний варіант наведено в таблиці 2.5.

 

Таблиця 2.5 – Семантика HTTP-операцій в рамках REST-веб-сервісів

Операція

Операнд – колекція ресусрів

Операнд – ресурс

GET

Отримання списку всіх елементів колекції (та їх URI)

Отримання представлення ресурсу

PUT

Заміна колекції на нову

Оновлення ресурсу

POST

Створення нового ресурсу в колекції з автоматичним присвоєнням ідентифікатора

Ресурс розглядається як окрема колекція – див. POST для колекції

DELETE

Видалення усієї колекції

Видалення ресурсу

 

 

Наприклад, операція «GET http://example.com/grid-tasks/ HTTP/1.1» має наступну семантику: «отримати перелік усіх грід-задач на ресурсі example.com». А, наприклад, операція «POST http://example.com/grid-tasks HTTP/1.1» (далі в тілі повідомлення опис задачі в певному форматі) має такий смисл: «запустити нову грід-задачу на ресурсі example.com». Питання придатності REST-стилю для грід-сервісів набуває актуальності разом із ростом популярності самого REST-підходу). Підтримка REST-стилю була додана у WSDL 2.0.

Компонування веб-сервісів

Безперечно, особливий інтерес представляє можливість об’єднання веб-сервісів у складніші послідовності для автоматизованого, узгодженого виконання. При цьому взаємодія веб-сервісів може бути описана кількома способами, на різному рівні, наприклад, як виконувані бізнес-процеси, чи як абстрактні бізнес-процеси. Виконувані бізнес-процеси моделюють реальну поведінку учасників взаємодії. Абстрактні ж бізнес-процеси не мають бути виконані, вони лише частково конкретизовані, можуть приховувати деталі реалізації. Абстрактні процеси відіграють описову роль, роль шаблонів. Обидва ці названі підходи можуть бути виражені за допомогою мови WS-BPEL [23]. Також можна описати взаємодію сервісів як «оркестровку» (orchestration) чи як «хореографію» (choreography). Різниця полягає в тому, що при оркестровці присутній окремий процес, центральний диспетчер, який контролює взаємодію сервісів. При хореографії такого централізованого контролера немає, і кожен учасник взаємодії діє по своїм правилам. WS-BPEL є мовою оркестровки, а не хореографії, веб-сервісів, причому для опису повідомлень використовується специфікація WSDL 1.1 (це стосується навіть останньої версії стандарту WS-BPEL 2.0). Окрім надання можливості автоматизації отримання та відправки повідомлень, мова WS-BPEL також надає можливості з області структурного програмування: послідовності, розгалуження, умови, цикли. Обираючи ту чи іншу технологію для реалізації грід-сервісів, слід мати на увазі, що вже існує багатий інструментарій для BPEL-мов, в т.ч. WS-BPEL, який дозволяє організовувати складні сценарії узгодженого виконання веб-сервісів. Але цей інструментарій сумісний не з усіма стандартами і підходами (може не підтримувати WSDL 2.0, REST тощо).

Семантичні розширення веб-сервісів

Принципи, що лежать в основі веб-сервісів, на диво прості. І вони нічого не додають нового в світ розподілених обчислень і Інтернету:

-    особа, відповідальна за веб-сервіс, визначає формат запитів до свого веб-сервісу і його відповідей;

-    будь-який комп'ютер в мережі робить запит до веб-сервісу;

-    веб-сервіс обробляє запит, виконує яку-небудь дію, а потім відправляє назад відповідь.

Цією дією може бути, наприклад виведення, котирування акцій, виведення ціни на певний продукт, збереження запису в календарі зустрічей, переклад тексту з однієї мови на іншій, або перевірка номера кредитної картки. Веб-сервіси додали новий рівень функціональності, роблячи перший крок в напрямку прозорої інтеграції розподілених компонентів програмного забезпечення, використовуючи веб-стандарти. Проте поточні технології веб-сервісів, засновані на SOAP, WSDL та UDDI, оперують на синтаксичному рівні і вимагають участі людини у їх використанні. Для автоматизації процесів виявлення, компонування та виконання веб-сервісів необхідний їх семантичний опис. Опис веб-сервісів у машинно-зрозумілому форматі дозволяє отримувати більш складну функціональність на основі композиції сервісів, що надаються різними постачальниками. Крім того, це робить можливою інтероперабельність без попереднього узгодження між сторонами. Для забезпечення бази семантичних веб-сервісів, необхідна повна інфраструктура: починаючи від концептуальної моделі, продовжуючи формальною мовою, що надає формальний синтаксис і семантику для цієї моделі, і закінчуючи середовищем виконання, що «склеює» усі компоненти, які використовують цю мову. Серед ініціатив, які пропонують таку інфраструктуру, можна перерахувати декілька: Web-Service Modelling Ontology [5], OWL-S, Semantic Web-Service Framework та WSDL-S.

WSMO

Ініціатива Web-Service Modelling Ontology (WSMO) є одним із основних напрямків у Європі, що має на меті стандартизацію уніфікованої інфраструктури для семантичних веб-сервісів, що забезпечує підтримку концептуального моделювання та формального представлення служб разом із автоматизацією взаємодії з ними. WSMO надає онтологічну специфікацію основних елементів семантичних веб-сервісів. Фактично, семантичні веб-сервіси мають на меті перетворення перехід до нової генерації Веб, де Інтернет перетворений із репозиторію інформації, зрозумілого людині в загально-світову систему розподілених веб-обчислень. Для цього відповідна інфраструктура має інтегрувати базові принципи архітектури Веб, а також принципи розподілених сервіс-орієнтованих систем. Тому WSMO заснований на наступних принципах:

-      Веб-сумісність: WSMO наслідує концепцію Універсального ідентифікатора ресурсу (Universal Resource Identifier, URI) для унікального визначення об’єктів. Крім того, WSMO адаптує поняття просторів імен для цілісних інформаційних областей, підтримує XML та інші технологічні рекомендації W3C поруч із децентралізацією ресурсів.

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

-      Строге розділення: Розділення символізує ізоляцію ресурсів у WSMO, яка означає, що кожен ресурс визначений незалежно від інших, не покладаючись на можливі взаємодії та використання інших ресурсів. Це відповідає відкритій та розподіленій природі Веб.

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

-      Онтологічне розподілення ролей: Користувачі, або, більш загально, клієнти, існують у специфічних контекстах, які не будуть обов’язково такими, як у наявних веб-сервісів. Наприклад, користувач може хотіти замовити відпочинок відповідно до своїх уподобань щодо погоди, культури та піклування за дітьми в той час, як веб-сервіси типово дадуть можливість перевірити наявність місця в готелі та квитків на літак. Базова епістемологія WSMO розрізняє бажання клієнтів та наявні сервіси.

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

-      Семантика виконання: Для перевірки специфікації WSMO, формальна семантика виконання WSMX, як й інші WSMO-задіяні системи, забезпечують технічну реалізацію WSMO. Цей принцип слугує засобом точного визначення функціональності та поведінки систем, які є WSMO-сумісними.

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

Розглянемо концептуальну модель WSMO. Елементи онтології WSMO описані за допомогою мови мета-мета-моделей на основі Meta Object Facility (MOF). MOF визначає абстрактну мову та інфраструктуру для специфікації, конструювання та керування технологічно-нейтральними мета-моделями. Оскільки WSMO планувався як метамодель семантичних веб-сервісів, MOF був обраний як найбільш підходящий засіб для опису елементів WSMO. В термінах чотирьох шарів MOF (мета-мета-модель, мета-модель, шар моделі та інформаційний шар), мова визначення WSMO відповідає шару мета-мета-моделі, сама WSMO скаладає рівень мета-моделі, власне онтології, веб-сервіси, цілі та посередники складають рівень моделі і фактичні дані, які описані онтологією та передаються між веб-сервісами відповідають інформаційному шару. Найбільш часто використовувана мета-модельна конструкція MOF для визначення елементів WSMO – це Клас (і неявно класоузагальнююча конструкція sub-Class) разом із його Атрибутами, типами Атрибутів та специфікаторами кількості. Для того, щоб дозволити повні описання елементів, кожен із них описується не-функціональними властивостями. Вони базуються на наборі метаданих Dublin Core (DC) для загальних відомостей щодо елемента та інших сервісно-залежних властивостях, пов’язаних із QoS.

Онтології забезпечують формальну семантику для термінології, що використовується у всіх компонентах WSMO. Використовуючи MOF, онтологія може бути визначена наступним чином:

 

Лістинг 2.3 – Використання MOF

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-3.JPG

 

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

Веб-сервіси. WSMO надає засоби опису для сервісів, що запрошуються споживачами та надаються постачальниками, і є узгодженими між ними.

 

Лістинг 2.4 – Використання WSMO

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-4.JPG

 

В середині класу сервіса нефункціональні властивості та імпортовані онтології відвграють таку ж роль, як в класі онтологій, лише із додаванням властивості якості сервіса (quality of service). Додатковий тип посередника (WW Mediator) доданий для вирішення проблеми неспівпадінь віж веб-сервісами, пов’язаних із протоколом. Два останні атрибута визначають два ключові поняття WSMO для семантичного пису веб-сервісів: здатність (capability), яка є функціональним описом веб-сервіса, що визначає обмеження щодо вхідних та вихідних даних служби за допомогою понять передумов, припущень, постумов впливів; та інтерфейс (interface), що визначає як поводиться сервіс для досягнення його функціональності. Інтерфейс служби складається із опису клієнт-среверної взаємодії, що необхідна для споживання сервісу, та опису того, як досягається функціональність веб-сервіса через агрегування інших веб-сервісів.

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

 

Лістинг 2.5 – Окремі сутності найвищого рівня в WSMO

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-5.JPG

 

Запрошувана здатність у визначенні задачі представляє функціональність сервісів, яку б він хотів мати, а запрошуваний інтерфейс репрезентує інтерфейс сервіса, через який користувач хотів би із ним взаємодіяти.

Mediators. Поняття посередництва у WSMO адресує обробку неоднорідностей між елементами, що мають взаємодіяти, через вирішення розбіжностей між різними використаними термінологіями (рівень даних), комунікаційною поведінкою (рівень протоколів) та бізнес-процесами. WSMO-посередник з’єднує елементи WSMO, зберігаючи їх слабку зв’язаність, та забезпечує посередницькі засоби для вирішення неспівпадінь. Опис елемента WSMO-посередник включає елемент-джерело та елемент-ціль і сервіс обробки невідповідностей.

 

Лістинг 2.6 – Опис елемента WSMO-посередник

Опис : D:\WORK\Dropbox\Акредитація\f-2-2-6.JPG

 

WSMO визначає різні типи посередників для приєднання окремих елементів: OO Mediators приєднують та забезпечуєть взаємодію між гетерогенними онтологіями, GG Mediators поєднують задачі, WG Mediators з’єднують веб-сервіси із задачами, і WW Mediators забезпечують інтероперабельність між різними веб-сервісами.

OWL-S

OWL-S є веб-сервісною онтологією, заснованою на OWL; її задача – надати будівельні блоки для кодування семантично збагачених описань сервісів способом, що природньо грунтується на OWL. Часто на онтологію OWL-S ontology посилаються як на мову для опису веб-сервісів, таким чином відображуючи той факт, що вона надає словник, що разом із іншими аспектами OWL, може бути використаний для описання сервісів. 
Онтологія OWL-S основним чином складається із трьох взаємопов’язаних суб-онтологій, відомих як профіль, модель процесу та «заземлення». Профіль використовується для вираження того, що сервіс робить для оголошення, конструювання викликів до сервісу та порівняння сервісів; модель процесу описує як це працює для того, щоб дозволити виклик, виконання, композицію, моніторинг та відновлення; і «заземлення» встаовлює відповідність моделі процесу та детальної специфікації форматів повідомлень, протоколів тощо (зазвичай описується за допомогою WSDL).

Усі ці суб-онтології поєднані в поняття Сервіс, яке слугує організаційною точкою посилання для декларування веб-сервісів; завжди, служба оголошена, створюється екземпляр концепції Сервіс. Сервіс має властивості представляє, описаний та підтримує. Класи ServiceProfile (що ідентифікує суб-онтологію профілю), ServiceModel (суб-онтологія моделі процесу) та ServiceGrounding (суб-онтологія прив’язок) – це діапазони значень цих властивостей. Кожний екземпляр Service представляє опис ServiceProfile, описаний ServiceModel, та підтримує ServiceGrounding. ServiceProfile надає засоби опису сервісів, що запропоновані постачальниками та сервісів, що вимагаються споживачами. Не профіль визначає представлення сервісу, а, використовуючи наслідування OWL, спеціалізовані представлення для сервісів можуть бути використані як профілі. Проте, із практичних віркувань, OWL-S забезпечує одне можливе представлення через клас Profile. Сервіс, визначений через профіль OWL-S, моделюється функцією трьох базових типів інформації:

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

-      Функція, яку виконує сервіс: Перетворення, що виконується службою. Функціональний опис включає вхідні дані, що вимагає сервіс, та вихідні дані, які він генерує; передумови, очікувані сервісом, та наслідки, що витікають із його виконання.

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

Найбільш суттєвий тип інформації, представленої у профілі, що відіграватиме ключову роль впродовж виявлення сервісу, є специфікація функціональності, пропонованої сервісом. Профіль OWL-S наголошує два аспекти функціональності сервісу:

-      Трансформація інформації представлена входами та виходами сервісу.

-      Зміна стану внаслідок виконання сервісу представлена передумовами та наслідками сервісу.

Профіль OWL-S не надає схему для опису екземплярів входів/виходів/передумов/наслідків (ВВПН). Проте така схема існує у онтології процесу. Вважається, що ВВПН, опублікована профілем є підмножиною ВВПН процесу, тому очікується, що процесова частина опису містить ці екземпляри, а профіль може просто вказувати на них. Властивостями класу Profile, який онтологія профілю OWL-S визначає для вказування на ВВПН, є:

-      hasParameter: діапазон значень – екземпляри параметрів онтології процесу.

-      hasInput: діапазон значень – екземпляри входів онтології процесу.

-      hasOutput: діапазон значень – екземпляри виходів онтології процесу.

-      hasPrecondition: визначає одну із передумов сервіса та діапазоном значень має екземпляри передумов із онтології процесу.

-      hasResult: означає один із результатів сервісу, визначений класом Result онтології процесу; специфікує умови, за яких були згенеровані вихідні значення сервісу. Цей параметр також визначає, які доменні зміни відбуваються під час виконання сервісу.

Оскільки профіль OWL-S описує тільки загальне функціонування сервісу, необхідна детальна перспектива того, як взаємодіяти із сервісом. Ця взаємодія розглядається як процес, і OWL-S визначає субклас ServiceModel для можливості визначити процеси. З точки зору OWL-S, процес – це не обов’язково програма, а більше специфікація шляхів клієнтської взаємодії із сервісом. Процес може генерувати та повертати деяку нову інформацію на основі інформації, що йому надана, та загальному стані. Продукування інформації описується входами та виходами процесу. Також, процес може генерувати зміни загального стану. Ці переходи описується за допомогою передумов та впливів процесу. Будь-який процес може мати будь-яку кількість входів, що представляють інформацію, необхідну за деяких умов для початку процесу. Процеси можуть мати будь-яку кількість виходів, тобто інформації, яку процес надає запитуючій стороні. Входи та виходи представляються як субкласи загального класу Parameter (кожен параметр має тип, визначений за допомогою URI). Може існувати будь-яка кількість передумов, одночасне виконання яких має забезпечуватись для успішного запуску процесу. Процес може мати будь-яку кількість вихідних впливів. Виходи та впливи можуть залежати від загального стану у момент виконання процесу. Передумови та результуючі впливи зображуються логічними формулами. OWL-S трактує такі вирази як літерали: або текстові, або XML. Останнє використовується для мов, чиє стандартне кодування – це XML (SWRL, RDF тощо). Перше ж для мов на зразок KIF. Процеси поєднані із ВВПН, використовуючи наступні властивості:

-      hasParticipant має значення класу Participant.

-      hasInput має значення класу Input.

-      hasOutput має значення класу Output.

-      hasLocal має значення класу Local.

-      hasPrecondition має значення класу Condition.

-      hasResult має значення класу Result.

Процес включає як мінімум дві сторони. Одна – це клієнт, з точки зору якого описаний процес, інша – це сервіс, з яким має справу клієнт. Як клієнт, так і сервіс називаються учасниками; вони прямо пов’язані із процесом через властивість hasParticipant. Через властивості hasInput та hasOutput приєднуються входи та виходи процесу. Входи процесу можуть як напряму іти від користувача, так і з попередніх кроків того самого процесу. Наявність передумови визначає, що процес не може бути виконаний успішно, якщо вона не виконуються; передумови приєднані до процесу через властивість hasPrecondition. Можливі продукти роботи процесу – наслідки (або впливи) та виходи – приєднані до процесу не на пряму. А через властивість hasResult. Хоча властивості, описані попередньо, спільні для всіх процесів OWL-S, існують три їх типи:

-      Атомарні. Описують сервіси, що очікують одне (можливо, складене) повідомлення та повертають одне (можливо, складене) повідомлення у відповідь.

-      Композитні. Процеси, що містять певну інформацію стану; кожне повідомлення клієнта оновлює цей стан.

-      Прості. процеси, що використовуються як елементи абстракції, тобто простий процес може бути використаний для того, щоб дати уявлення про (спеціалізований спосіб використання) деякого атомарного процесу, або в якості спрощеної моделі деякого композитного процесу.

Атомарні процеси схожі на дії, які сервіс може виконати при його застосуванні у однокроковій взаємодії; композитні процеси відповідають діям, що потребують багатокрокових взаємодій; прості процеси надають механізм абстракції для уможливлювання декількох уявлень щодо одного і того ж процесу. Атомарні процеси можна викликати напряму, і вони не містять субпроцесів; їх виконання є однокроковим (з точки зору викликаючої сторони), тобто вони приймають повідомлення, роблять щось і повертають повідомлення-відповідь. Композитні процеси можна розібрати на інші (атомарні, композитні або прості) процеси; їх декомпозиція може бути визначена, використовуючи управляючі конструкції. OWL-S підтримує наступний набір управляючих конструкцій:

-      Sequence: набір процесів, що мають бути виконані послідовно.

-      Split: набір процесів, що мають бути виконані одночасно; конструкція виконана, коли усі їз її компонентів заплановані на виконання.

-      Split + Join: набір процесів для паралельного виконання із синхронізацією; завершується, коли усі процеси-учасники завершені.

-      Choice: Виконує одну із управляючих конструкцій із заданого набору; будь-яка із них може бути обрана для виконання.

-      Any-Order: Дозволяє процесам-компонентам виконання у будь-якому порядку, але послідовно.

-      If-Then-Else: Перевірити умову; якщо виконується, зробити Then; якщо не виконується – зробити Else.

-      Iterate: Виконати процес декілька разів. Конструкція не робить ніяких припущень щодо кількості ітерацій, моменту їх початку, завершення та поновлення.

-      Repeat-While та Repeat-Until: повторення, доки умова справджується/не справджується.

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

SWSF

Semantic Web Services Framework (SWSF) є одним із найновіших підходів до семантичних веб-сервісів, і пропонується та пропагандуєтьсяКомітетом мови семантичних веб-сервісів (Semantic Web Services Language Committee, SWSLC) з Semantic Web Services Initiative (SWSI). Інфраструктура складається із двох основних компонентів: онтології з відповідною концептуальною моделлю, що називається Semantic Web Services Ontology (SWSO) та мови, що використовується для визначення формальних характеристик понять веб-сервісів і описів, що називається Semantic Web Services Language (SWSL). SWSO представляє концептуальну модель для семантичного опису веб-сервісів та аксіоматизації, формального характеризування цієї моделі одним із двох варіантів SWSL: SWSL-FOL заснованій на логіці першого порядку (First-Order Logic, FOL) або SWSL-Rules, заснованій на логічному програмуванні. Результуючі онтології мають назви FLOWS (First-Order Logic Ontology for Web Services), що полягається на семантику логіки першого порядку, та ROWS (Rule Ontology for Web Services), що опирається на семантику логічного програмування.

Оскільки обидва представлення розділяють одну й ту саму концептуальну модель, зупинимось на FLOWS. Розробка онтології FLOWS відбувалась під впливом онтології OWL-S ontology вивчених під час її розробки уроків. Іншим фундаментальним аспектом у розробці FLOWS є забезпечення багатої поведінкової моделі процесу на основі Мови специфікації процесу (Process Specification Language, PSL). FLOWS можна розглядати як розширення/уточнення онтології OWL-S, сфокусоване на забепеченні інтероперабельності або семантики для існуючих стандартів у області веб-сервісів (наприклад, BPEL, WSDL, тощо). Хоча між онтологіями FLOWS та OWL-S є багато спільного, одна із важливих відмінностей у виразності базової мови. FLOWS заснований на FOL, чиї можливості багатші за OWL-S, заснованій на OWLDL. Засновуючись на логіці першого порядку, FLOWS використовує логічні предикати та терміни для моделювання загального стану.

Особливості обчислення ситуації, такі, як використання потоків, предикати, і умови, які змінюються з плином часу, були внесені для моделювання змін стану середовища. Інваріантні предикати та терміни у SWSO називаються відносинами. Онтологія FLOWS складається із трьох головних компонентів: дескрипторів сервісів, моделі процесу та прив’язок.

Дескриптори сервісів використовуються для надання базової описової інформації щодо сервісу. Модель процесу – для опису роботи процесу Прив’язки для зв’зування семантичних абстрактних описів сервісу з допомогою SWSO до детальної специфікації повідомлень, протоколів та іншого, що використовується у веб-сервісі.

WSDL-S

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

-      Заснованість на існуючих веб-стандартах. Стандарти представляють ключові положення для створення інтеграційних рішень і, як наслідок, WSDL-S просуває прямо сумісний механізм для додавання семантики у веб-сервіси.

-      Анотації мають бути агностичними стосовно мови представлення семантики. Різні провайдери веб-сервісів можуть використовувати різні способи представлення семантичних описів свої сервісів і, більше того, один виробник може використовувати декілька описів з метою виявлення його послуг різними семантичними рушіями. Таким чином WSDL-S не приписує, яка семантична мова має використовуватись і дозволяє поєднання із описами на різних мовах.

-      Підтримка анотацій типу даних у XML Schema: Так як XML Schema є важливим форматом визначення даних і бажаним є повторне використання інтерфейсів, описаних за допомогою XML, WSDL-S підтримує анотацію XML схем. Ці анотації використовуються для додавання семантики до входів та виходів анотованого веб-сервіса. Додатково, важливий аспект, який треба взяти до уваги, – це визначення відповідності складних типів XML Schema та онтологічних концепцій. Оскільки WSDL-S не визначає конкретної мови опису, техніка побудови цих відповідностей прямо залежить від обраного семантичного представлення.

WSDL-S пропонує п’ять елементів розширення для використання при анотації входів, виходів та роботи веб-сервісів:

-      modelReference: елемент, що визначає відношення один-до-одного між елементами схеми та поняттями онтології;

-      schemaMapping: атрибут, що може бути доданий до елементів XSD або складних типів, щоб асоціювати їх із онтологією (один-до-багатьох та багато-до-одного);

-      precondition: розширюючий елемент (дочірній до operation), що використовується для вказування комбінації складних виразів та умов в онтології, що мають виконуватись перед виконанням веб-сервісу;

-      effects: схожий до попереднього елемент за винятком, що умови в онтології мають виконуватись після виконання веб-сервісу.

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

Кожен із цих елементів може бути використаний для створення анотацій.

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

Все ж, для реалізації концепції «усе як ресурс», яка може бути моделлю для грід-сервісної інфраструктури, можливостей вищеназваних стандартів може виявитись недостатньо. Група дослідників, що представляла 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

Назва специфікації

Короткі відомості

WS-ResourceProperties

Описує те, як асоціюються ресурси зі станом та веб-сервіси для створення WS-ресурсів, та як доступні властивості ресурсу можуть бути отримані, змінені, видалено

WS-ResourceLifetime

Дозволяє запитувачу знищити ресурс негайно або заплановано

WS-RenewableReferences

Додає анотацію до WS-Addressing Endpoint Reference, яка потрібна для отримання нової кінцевої точки, коли поточна стає недійсною

WS-ServiceGroup

Для створення та використання груп неоднорідних сервісів через посилання

WS-BaseFault

Описує базовий тип помилки

WS-Notification (сімейство

Стандартні підходи до оповіщень, що використовують шаблон “публікація-підписка”.

 

 

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.

Опис : D:\WORK\Dropbox\Акредитація\ris-2-10.JPG

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

 

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

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

Головними «експлуатантами» специфікацій 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-сервісів.

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-11.JPG

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

 

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

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

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

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

 

Опис : D:\WORK\Dropbox\Акредитація\ris-2-12.JPG

Рисунок 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, які так і не набули поширення? З урахуванням розглянутих раніше деталей технології стандартних веб-сервісів можна, з певними уточненнями, стверджувати, що це реально (детальні уточнення див. у наступному розділі). Відштовхуючись від використання веб-сервісів як комунікаторів, як інтерфейсу зв’язку, не переобтяжуючи їх додатковими стандартами, можна побудувати, принаймні, прикладні грід-сервіси, які б спирались на існуюче ПЗПШ та не мали б стільки проблем із сумісністю з існуючим веб-інструментарієм.


Русский язык и культура речи

перейти к оглавлению

1. ЭЛЕМЕНТЫ И УРОВНИ ЯЗЫКА

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

Самая простая единица языка – это фонема, неделимая и сама по себе...

Идеология

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

Математические формулы. Шпаргалка для ЕГЭ с математики

Формулы сокращенного умножения

(а+b)2 = a2 + 2ab + b2

(а-b)2 = a2 – 2ab + b2

a2 – b2 = (a-b)(a+b)

a3 – b3 = (a-b)( a2 + ab + b2)

a3 + b3 = (a+b)( a2 – ab + b2)

(a + b)3 = a3 + 3a2b+ 3ab2+ b3

(a – b)3 = a3 – 3a2b+ 3ab2- b3

Свойства степеней

a0 = 1 (a≠0)

am/n = (a≥0, n ε N, m ε N)

a- r = 1/ a r (a>0, r ε Q)

m...

законы диалектики

Основные законы диалектики.

1)Закон единства и борьбы противоположностей.

Этот закон является «ядром» диалектики, т.к. определяет источник развития, отвечает на вопрос, почему оно происходит.

Содержание закона: источник движения и развития мира находится в нем самом, в порождаемых им противоречиях.

Противоречие – это взаимодействие противоположных сторон, свойств и тенденций в составе той или иной системы или между системами. Диалектическое противоречие есть только там, где...