Лекція 2 Зв'язок Grid та веб-технологій

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

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

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

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

До цього моменту було показано, веб-сервіси та грід-сервіси ідеологічно мають і багато спільного, і декотрі відмінності. Уточнимо їх (таблиці 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 – Можливі шляхи узгодження грід та веб-сервісів

Як видно, кожен з підходів має свої недоліки: потрібно або переглядати архітектуру грід так, щоб вона була придатна до реалізації на “чистих” веб-сервісах, що не зовсім коректно з ідеологічного боку, або ж треба вносити доповнення до веб-сервісів та ризикувати не дочекатися їх затвердження (у випадку з 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-опису. Таке спрощене рішення залишиться дієвим у невеликих закритих системах, однак таке рішення значно втратить у інтероперабельності та масштабованості. Якщо дотримуватись повного циклу зі створення веб-сервісу, то слід опублікувати його опис, бажано – у стандартному сховищі.

Рисунок 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. Цей приклад доводить, що при виборі технічних засобів слід враховувати, наскільки широке коло їх користувачів, стабільність розвитку, підтримку, перспективи, мінливість тих чи інших стандартів, на яких вони базуються.

Рисунок 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 – Простий приклад повідомлення-запиту для методу “піднести ціле число у квадрат” матиме вигляд.

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

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

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

Ще раз підкреслимо значимість 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).

Рисунок 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). Що важливо, реєстр дозволяє побудову різних таксономій для створення семантичної структури інформації, яка зберігається в реєстрі.

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

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

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

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

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

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

Розглядаючи можливість композиції веб-сервісів та автоматичного виконання цілих маршрутів веб-сервісів, описаних мовою 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 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

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

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

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

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

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

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

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

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

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

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: набір процесів для паралельного виконання із синхронізацією; завершується, коли усі процеси-учасники зав