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

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

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

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

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

 Щоб почати обговорення пов'язаних з розподіленими СКБД проблем, передусім необхідно утямити, що ж таке розподілена база даних.

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

З цього витікає наступне визначення.

Розподілена СКБД – програмний комплекс, призначений для управління розподіленими базами даних і який дозволяє зробити розподіленість інформації прозорою для кінцевого користувача.

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

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

-    Набір логічно пов'язаних розподіоених даних.

-    Дані, що зберігаються, розбиті на деяку кількість фрагментів.

-    Між фрагментами може бути організована реплікація даних. Фрагменти і їх репліки розподілені по різних сайтах.

-    Сайти пов'язані між собою мережевими з'єднаннями.

-    Робота з даними на кожному сайті управляється СКБД.

-    СКБД на кожному сайті здатна підтримувати автономну роботу локальних застосувань.

-    СКБД кожного сайту підтримує хоч би одне глобальне застосування.

 Немає необхідності в тому, щоб на кожному з сайтів системи існувала своя власна локальна база даних, що і показане на прикладі топології СКРБД, представленої на рисунку 3.1.

 

image001

Рисунок 3.1 – Топологія   системи   управління розподіленою базою даних

 

Розглянемо приклад розподіленої обробки даних.

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

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

Дуже важливо розуміти відмінності, існуючі між розподіленими СКБД і розподіленою обробкою даних.

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

Крім того, слід чітко розуміти відмінності, існуючі між розподіленими і паралельними СКБД.

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

Переваги і недоліки, властиві розподіленим СКБД

Системи з розподіленими базами даних мають додаткові переваги  перед традиційними централізованими системами баз даних. На жаль, ця технологія не позбавлена і деяких недоліків. У цьому розділі ми обговоримо як переваги, так і недоліки, властиві системам з розподіленими базами даних.

Переваги:

  • Віддзеркалення структури організації.
  • Подільність і локальна автономність.
  • Підвищення доступності даних.

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

Підвищення надійності

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

Підвищення продуктивності

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

Економічні вигоди

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

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

Модульність системи

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

Недоліки:

Підвищення складності

Розподілені СКБД, здатні приховати від кінцевих користувачів розподілену природу використовуваних ними даних і забезпечити необхідний рівень продуктивності, надійності і доступності, безумовно є складнішими програмними комплексами, ніж централізовані СКБД. Той факт, що дані можуть піддаватися реплікації, також додає додатковий рівень складності в програмне забезпечення СКРБД. Якщо реплікація даних не буде підтримуватися на необхідному рівні, система матиме нижчий рівень доступності даних, надійності і продуктивності, ніж централізовані системи, а усі викладені вище переваги перетворяться на недоліки.

Збільшення вартості

Збільшення складності означає і збільшення витрат на придбання і супровід СКРБД (в порівнянні із звичайними централізованими СКБД).Разворачива-ние розподіленої СКБД зажадає додаткового устаткування, необхідного для установки мережевих з'єднань між сайтами. Слід чекати і зростання затрат на оплату каналів зв'язку, викликаних зростанням мережевого трафіку. Крім того, зростуть витрати на оплату праці персоналу, який буде потрібно для обслуговування локальних СКБД і мережевих з'єднань.

Проблеми захисту

У централізованих системах доступ до даних легко контролюється. Проте в розподілених системах потрібно буде організувати контроль доступу не лише до даних, реплікованих на декілька різних сайтів, але і захист мережевих з'єднань самих по собі. Раніше мережі розглядалися як абсолютно незахищені канали зв'язку. Хоча це частково справедливо і для теперішнього часу, проте відносно захисту мережевих з'єднань досягнутий дуже істотний прогрес.

Ускладнення контролю за цілісністю даних

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

Відсутність стандартів

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

Недолік досвіду

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

Ускладнення процедури розробки бази даних

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

Усі переваги і недоліки, властиві розподіленим СКБД, перераховані в таблиці 3.1.

 

Таблиця 3.1 – Переваги і недоліки розподілених СКБД

Переваги

Недоліки

Відображення структури організації

Підвищення складності

Розделяємість і локальна автономність

Збільшення вартості

Підвищення доступності даних

Проблеми захисту

Підвищення надійності

Ускладнення контролю за цілісністю даних

Підвищення продуктивності

Відсутність стандартів

Економічні вигоди

Недолік досвіду

Модульність системи

Ускладнення процедури розробки бази даних

 

 

3.2 Гомогенні і гетерогенні розподілені СКБД

 

Розподілені СКБД можна класифікувати як гомогенні і гетерогенні. У гомогенних системах усі сайти використовують один і той же тип СКБД. У гетерогенних системах на сайтах можуть функціонувати різні типи СКБД, що використовують різні моделі даних, тобто гетерогенна система може включати сайти з реляційними, сітковими, ієрархічними або об'єктно-орієнтованими СКБД.

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

Гетерогенні системи зазвичай виникають в тих випадках, коли незалежні сайти, що вже експлуатують свої власні системи з базами даних, інтегруються в новостворювану розподілену систему. У гетерогенних системах для організації взаємодії між різними типами СКБД потрібно буде організувати трансляцію передаваних повідомлень. Для забезпечення прозорості відносно типу використовуваної СКБД користувачі кожного з сайтів повинні мати можливість вводити запити, що цікавлять їх, на мові тієї СКБД, яка використовується на цьому сайті. Система повинна узяти на себе локалізацію необхідних даних і виконання трансляції передаваних повідомлень. У загальному випадку дані можуть бути потрібні з друго-го сайту, який характеризується такими особливостями, як:

-    інший тип використовуваного устаткування;

-    інший тип використовуваної СКБД;

-    інший тип використовуваного устаткування і СКБД.

Якщо використовується інший тип устаткування, проте на сайті встановлений той же самий тип СКБД, методи виконання трансляції цілком очевидні і включають заміну кодів і зміну довжини слова. Якщо типи використовуваних на сайтах СКБД різні, процедура трансляції ускладнюється тим, що необхідно відображувати структури даних однієї моделі у відповідні структури даних іншої моделі. Наприклад,відношення в реляційній моделі даних мають бути перетворені в записи і набори, типові для мережевої моделі даних. Крім того, потрібно буде транслювати текст запитів з однієї використовуваної мови на іншій (наприклад, запити SQL-оператор SELECT потрібно буде перетворити в запити з операторами FIND і GET мови маніпулювання даними сіткової СКБД). Якщо відрізняються і тип використовуваного устаткування, і тип програмного забезпечення, потрібно буде виконувати обидва види трансляції. Усе викладене вище назвичайно ускладнює обробку даних в гетерогенних СКБД.

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

Розробка розподілених реляційних баз даних

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

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

-              Розподіл. Кожен фрагмент зберігається на сайті, вибраному з врахуванням "оптимальної" схеми їх розміщення.

-              Реплікація. СКРБД може підтримувати актуальну копію деякого фрагмента на декількох різних сайтах.

Розподіл даних

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

Централізоване розміщення

Ця стратегія передбачає створення на одному з сайтів єдиної бази даних під управлінням СКБД, доступ до якої матимуть усі користувачі мережі (ця стратегія під назвою "розподілена обробка" вже розглядалася нами вище.) В цьому випадку локальність посилань мінімальна для усіх сайтів, за виключенням центрального, оскільки для отримання будь-якого доступу до даних потрібна установка мережевого з'єднання. Відповідно рівень витрат на передачу даних буде високий. Рівень надійності і доступності в системі низький, оскільки відмова на центральному сайті викличе параліч роботи усієї системи.

Роздільне (фрагментоване) розміщення

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

Розміщення з повною реплікацією

Ця стратегія передбачає розміщення повної копії усієї бази даних на кожному з сайтів системи.

Розміщення з вибірковою реплікацією

Ця стратегія є комбінацією методів фрагментації, реплікації і централізації.

 

3.3 Фрагментація. Призначення фрагментації

 

Коректність фрагментації

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

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

 

Таблиця 3.2 – Порівняльні характеристики різних стратегій розподілу даних

Розміщення даних

Локальність посилань

Надійність і доступність

Продуктивність

Вартістьпристроїв зберігання

Витрати на передачу даних

Централізоване

Найнижча

Найнижча

Незадовільна

Найнижча

Найвищі

Фрагментованое

Висока1

Низька для окремих елементів; висока для системи в цілому

Задовільна1

Найнижча

Низькі

Повна реплікація

Найвища

Найвища

Хороша для операцій читання

Найвища

Високі для  операцій обновлення,низькі для операцій читання

Вибіркова реплікація

Висока1

Низька дляокремих елементів, висока для системи

Задовільна 1

Середня

Низькі

 

  1 За умови якісного проектування.

 

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

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

У разі горизонтальної фрагментації елементом даних являється кортеж, а у разі вертикальної фрагментації – атрибут.

Типи фрагментації

Існують два основні типи фрагментації: горизонтальна і вертикальна. Горизонтальні фрагменти є підмножинами кортежів відношення, а вертикальні – підмножини атрибутів відношення, як показано на рисунку 3.2.

 

image002

Рисунок 3.2 – Різні   типи   фрагментації : а) горизонтальна; б) вертикальна

 

Крім того, існують ще два типи фрагментації: змішана (рисунок 1.13) і похідна (що є варіантом горизонтальної фрагментації).

 

image003

Рисунок 3.3 – Змішана фрагментація: а) горизонтально розділені вертикальні фрагменти; б) вертикально розділені горизонтальні фрагменти

 

 Відмова від фрагментації

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

Забезпечення прозорості в РСКБД

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

-              Прозорість розподіленості.

-              Прозорість транзакцій.

-              Прозорість виконання.

-              Прозорість використання СКБД.

Прозорість розподіленості

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

Прозорість транзакцій

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

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

Прозорість виконання

Прозорість виконання вимагає, щоб робота в середовищі СКРБД виконувалася точно так, як і в середовищі централізованої СКБД.

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

-              час доступу, що включає фізичний доступ до даних на диску;

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

-              час, необхідний для передачі даних по мережевих з'єднаннях.

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

Property (Еш, City)         10 000 записів, що зберігаються в Лондоні.

Renter(Їм, Max_Price)     100 000 записів, що зберігаються в Глазго.

Viewing(Ешг, Rno)         1 000 000 записів, що зберігаються в Лондоні.

Щоб отримати список об'єктів нерухомості в Абердине, які були оглянуті потенційними покупцями, згідними придбати об'єкти нерухомості  дорожче  200000,   можна  скористатися  наступним SQL -запитом:

SELECT p.pno FROM property p INNER JOIN

((renter r INNER JOIN viewing v ON r.rno = v.rno)

ON p.pno = v.pno

WHERE p.city = 'Aberdeen' AND r.max price > 200000;

Для простоти припустимо, що кожен кортеж у відношеннях має довжину, рівну 100 символам, що існує тільки 10 покупців, згідних придбати нерухомість за ціною більше 200000, і що в місті Абердин було проведено 100000 оглядів об'єктів нерухомості. Вважатимемо також, що час виконання обчислень несуттєвий в порівнянні з часом передачі даних, а швидкість передачі даних по каналах зв'язку складає 10000 символів в секунду, причому на кожне повідомлення, що відправляється між двома сайтами, припадає затримка доступу, рівна 1 секунді.

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

 Стратегія 1.

Переслати відношення Renter в Лондон і виконати там обробку запиту :

Час = 1+(100 000 * 100/10 000) = 16,7 хв.

Стратегія 2.

Переслати стосунки Property і Viewing в Глазго і виконати там обробку запиту :

Час = 2+[(1 000 000 + 10 000) * 100/10 000] = 28 год.

Стратегія 3.

З'єднати стосунки Property і Viewing в Лондоні, вибрати кор-тежи для об'єктів нерухомості, розташованих в Абердине, а потім для кожного з відібраних кортежів перевірити в Глазго, чи встановив цей клієнт значення стелі допустимої стои-мости нерухомості Max Price> 200 000 фунтів стерлінгів. Про-верка кожного кортежу припускає відправку двох повідомлень : запиту і відповіді.

Час = 100 000 * (1+100/10 000) + 100 000 * 1 = 2,3 дня.

Стратегія 4.

Вибрати   в   Глазго   кортежі   клієнтів,   що встановили   значення Max Price > 200 000 фунтів стерлінгів, після чого для кожного з j їх перевірити в Лондоні, чи оглядав цей клієнт об'єкти не-движимости в Абердине. І в цьому випадку кожна перевірка вклю-чает відправку двох повідомлень.

Час = 10*(1+100/10 000) + 10* 1 ≈20 с.                                       

Стратегія 5.

З'єднати стосунки Property і Viewing в Лондоні, вибрати сведе-ния про огляди об'єктів в Абердине, виконати проекцію ре-зультирующей таблиці по атрибутах Рпо і Rno, після чого пере-слать отриманий результат в Глазго для відбору кортежів по ус-ловию MaxPrice >  200 000 фунтів стерлінгів.  Для спрощення припустимо, що довжина кортежу після операції проекції також дорівнює 100 символам.

Час = 1 + (100 000 * 100/10 000) = 16,7 хв.

Стратегія 6.

Вибрати клієнтів зі значенням атрибуту Max_Price > 200 000 фун-тов стерлінгів в Глазго і переслати результуючу таблицю в Лондон для відбору відомостей про огляди об'єктів нерухомості в р. Абердин:

Час = 1 + (10 * 100/10 000) ≈1с.

 

 

Таблиця 3.3 – Порівняння результатів застосування різних стратегій для обробки одного і того ж розподіленого запиту

Стратегія

Час

1.

Переслати відношення Renter в Лондон і виконати там обробку запиту

16,7 хв.

2

Переслати стосунки Property і Viewing в Глазго і виконати там обробку запиту

28 ч.

3

З'єднати стосунки Property і Viewing в Лондоні, вибрати кортежі для об’єктів нерухомості в Абердині, а потім для кожного з відібраних кортежів провірити в Глазго, чи встановив цей клієнт максимальне значення допустимої вартості нерухомості Max Price > 200000

2,3 дні

4

Вибрати в місті Глазго кортежі клієнтів, що встановили значенняMax Price > 200000, після чого для кожного з них перевірити в Лондоні, чи оглядав цей клієнт об'єкти нерухомості в Абердині

20 с.

5

З'єднати стосунки Property і Viewing в Лондоні, вибрати відомості осмот-рах об'єктів в Абердине, виконати проекцію результуючої таблиці по атрибутах Рпо і Rno, після чого переслати отриманий результат в Глазго для відбору кортежів по умові Max Price > 200 000

16,7 хв.

6

Вибрати клієнтів зі значенням атрибуту Max Price > 200000 в Глазго і переслати результуючу таблицю в Лондон для відбору відомостей про огляди об'єктів нерухомості в Абердині

1с.

 

 

 Прозорість використання СКБД

Прозорість використання СКБД дозволяє приховати від користувача СКРБД той факт, що на різних сайтах можуть функціонувати різні локальні СКБД. Тому цей тип прозорості застосовний тільки у разі гетерогенних розподілених систем. Як правило, це один з найскладніших в реалізації типів прозорості.

Декілька слів на закінчення

На початку цього розділу, присвяченого обговоренню різних типів прозорості в середовищі розподілених СКБД, відзначалося, що досягнення повної прозорості не усіма розцінюється як бажана мета. Як ми вже бачили, концепція прозорості не може бути віднесена до типу "усе або нічого", оскільки може бути організована на декількох різних рівнях. Кожен з рівнів має на увазі наявність певного набору угод між сайтами, що входять в систему. Наприклад, при повній прозорості сайти повинні наслідувати загальну угоду з таких питань, як модель даних, інтерпретація схем, представлення даних і набір функціональності, що надається на кожному з сайтів. З іншого боку спектру знаходяться непрозорі системи, в яких єдиною угодою є формат обміну даними і набір функціональних можливостей, що надаються кожним сайтом в системі.

Дванадцять правив Дейта для РСКБД

Наостанок ми перерахуємо дванадцять правив (чи цілей), які були сформульовані Дейтом для типової СКРБД. Основою для побудови усіх цих правил є те, що розподілена СКБД повинна сприйматися кінцевим користувачем точно так, як і звична йому централізована СКБД. Дані правила схожі з дванадцятьма правилами Кодда для реляційних систем.

Правило 0. Основний принцип

З точки зору кінцевого користувача розподілена система повинна виглядати в точності так, як і звичайна, нерозподілена система.

Правило 1. Локальна автономність

Сайти в розподіленій системі мають бути автономними. У даному контексті автономність означає наступне:

-    локальні дані належать локальним власникам і супроводжуються локально;

-    усі локальні процеси залишаються чисто локальними;

-    усі процеси на заданому сайті контролюються тільки цим сайтом.

Правило 2. Відсутність опори на центральний сайт

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

Правило 3. Безперервне функціонування

В ідеалі, в системі ніколи не повинна виникати потреба в плановій зупинці її функціонування для виконання таких операцій, як:

-    додавання або видалення сайту з системи;

-    динамічне створення або видалення фрагментів з одного або декількох сайтів.

Правило 4. Незалежність від розташування.

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

Правило 5. Незалежність від фрагментації

Користувач повинен діставати доступ до даних незалежно від способу їх фрагментації.

Правило 6. Незалежність від реплікації

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

Правило 7. Обробка розподілених запитів

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

Правило 8. Обробка розподілених транзакцій

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

Правило 9. Незалежність від типу устаткування

СКРБД має бути здатна функціонувати на устаткуванні з різними обчислювальними платформами.

Правило 10. Незалежність від операційної системи

Прямим наслідком попереднього правила є вимога, згідно з яким СКРБД має бути здатна функціонувати під управлінням різних операційних систем.

Правило 11. Незалежність від мережевої архітектури

СКРБД має бути здатна функціонувати в мережах з різною архітектурою і типами носія.

Правило 12. Незалежність від типу СКБД

СКРБД має бути здатна функціонувати поверх різних локальних СКБД, можливо, з різним типом використовуваної моделі даних. Іншими словами, СКРБД повинна підтримувати гетерогенність.

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

 Резюме

-    Розподілена база даних є набором логічно пов'язаних між собою даних (і їх описів), що розділяються, які фізично розподілені в деякій комп'ютерній мережі. СКРБД є програмний комплексом, призначеним для прозорого управління розподіленої базою даних.

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

-    Переваги СКРБД полягають в тому, що вона дозволяє відбити структуру організації і підвищує можливості спільного використання видалених даних, підвищує надійність, доступність і продуктивність системи, дозволяє отримати економію коштів, а також організувати модульне збільшення розмірів системи.

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

-    Аналогічно тому, як централізована СКБД повинна надавати опреде-ленный набір стандартних функцій,  розподілена СКБД повинна надавати розширені можливості установки з'єднань, включати розширену службу системного каталогу, забезпечувати розподілену обробку запитів, підтримувати розширені засоби розпаралелювання операцій, а також мати власну службу відновлення.

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

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

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

-    З точки зору користувача, СКРБД повинна виглядати точно так, як і звичайна централізована СКБД, що досягається за рахунок забезпечення различ-ных типів прозорості. Завдяки прозорості розподілу користувачі не потребують яких-небудь відомостей про існуючу в системі фрагментації/реплікацію. Прозорість транзакцій забезпечує збереження узгодженості глобальної бази навіть за наявності паралельного доступу до неї з боку безлічі користувачів і наявності в системі різних відмов. Прозорість виконання дозволяє системі ефективно обробляти запити, що включають звернення до даних на декількох сайтах. Прозорість використання СКБД дозволяє системі функціонувати поверх установлен-ных на окремих сайтах локальних СКБД різного типу.

 Керування розподіленою паралельністю.

-    Цілі, що стояти при обробці розподілених транзакцій, не відрізняються від переслідуваних при обробці транзакцій у централізованих системах. Однак досягти цих цілей у випадку СКРБД складніше, оскільки потрібно забезпечити неподільність не тільки глобальної транзакції в цілому, але й всіх її субтранзакцій.

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

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

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

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

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

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

-    Модель X/Open DTP являє собою один з варіантів архітектури обробки  розподілених  транзакцій,   побудованої   на  застосуванні  протоколу OSI - TP і двофазного протоколу фіксації транзакцій. У цій моделі визначаються прикладні програмні інтерфейси й методи взаємодії між додатками, що запускають транзакції, менеджерами транзакцій, менеджерами ресурсів і менеджерами передачі даних.

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

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

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

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

-    Координатор транзакцій (ТС1) на вузлі S1, ділить транзакцію на декілька субтранзакцій, виходячи з інформації, що зберігається в глобальному каталозі системи.

-    Компонент передачі даних на вузлі – відправляє опис відповідних субтранзакцій на вузли S2 і S3.

-    Координатори транзакцій на вузлах S2 і S3 організовують виконання субтранзакцій, що поступили. Результати їх виконання передаються координаторові TC1 за допомогою компонентів передачі даних. Увесь описаний процес схематично представлений на рисунку 4.1.

 

image004

Рисунок 4.1 – Схема координації виконання розподілених транзакцій

 

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

 

4.2 Управління паралельним виконанням в розподіленому середовищі

 

У цьому розділі будуть представлені протоколи, які можуть використовуватися для організації управління паралельним виконанням в розподілених СКБД. Але спочатку слід ознайомитися з цілями, які стоять перед механізмом управління паралельним виконанням в розподіленому середовищі.

Цілі управління паралельним виконанням в розподіленому середовищі

Якщо припустити, що в системі не існує відмов, то призначення механізму управління паралельним виконанням полягатиме в забезпеченні узгодженості елементів даних і завершенні кожної елементарної операції в межах деякого встановленого проміжку часу. Крім того, прийнятний механізм управління паралельним виконанням в розподіленій СКБД повинен забезпечувати наступне:

-    стійкість до відмов на вузлі і в лініях зв'язку;

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

-    невисокий додатковий рівень споживання процесорного  часу і інших системних ресурсів;

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

-    відсутність додаткових обмежень на структуру елементарних операцій.

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

Проблема впордкування субтранзакцій в розподіленому середовищі

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

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

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

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

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

 

4.3 Протоколи блокування

 

Розглянемо наступні протоколи, засновані на двофазному блокуванні (2PL), які можуть застосовуватися для забезпечення впорядкування графіків в розподілених СКБД. До них відносяться централізований протокол двофазного блокування, двофазне блокування з первиннимикопіями, розподілений протокол двофазного блокування і блокування більшості копій.

Централізований протокол двофазного блокування

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

1.  Координатор транзакцій на вузлі S1 розділяє глобальну транзакцію на декілька субтранзакцій, використовуючи інформацію, що зберігається в глобальному системному каталозі. Координатор відповідає за дотримання узгодженості бази даних. Якщо транзакція передбачає оновлення копійованого елементу даних, координатор повинен забезпечити оновлення усіх існуючих копій цього елементу даних. Тому координатор повинен зажадати встановити виняткові блокування на усіх копіях оновлюваного елементу даних, а потім звільнити ці блокування. Для читання оновлюваного елементу даних координатор може вибрати будь-яку з існуючих копій. Зазвичай прочитується локальна копія, якщо така існує.

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

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

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

Перевага централізованого протоколу двофазного блокування полягає в тому, що його можна відносно просто реалізувати. Виявлення взаимоблокировок може виконуватися тими ж методами, що і в централізованих СКБД, оскільки уся інформація про блокування елементів знаходиться у розпорядженні єдиного диспетчера блокувань. Основний недолік цієї схеми пов'язаний з тим, що будь-яка централізація в розподіленій СКБД автоматично призводить до появи вузьких місць в системі і різко знижує рівень її надійності і стійкості. Оскільки усі запити на блокування елементів даних прямують на єдиний центральний вузол, його швидкодія обмежує можливості усієї системи. Крім того, відмова цього вузла викликає порушення роботи усієї розподіленої системи, тому вона стає менш надійною. Проте цій схемі властивий відносно невисокий рівень витрат на передачу даних. Наприклад, глобальна операція оновлення за участю агентів (субтранзакцій) на вузлах за наявності центрального диспетчера блокувань може потребувати відправки йому не менше 2n + 3 повідомлень, у тому числі:

-              один запит на блокування;

-              одне повідомлення про надання  блокування;

-              n сполучень з вимогою оновлення;

-              n підтверджень про виконане оновлення;

-              один запит на зняття блокування.

Двофазне блокування з первинними копіями

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

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

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

Розподілений протокол двофазного блокування

У цьому протоколі також робиться спроба подолати недоліки, властиві централізованому протоколу двофазного блокування, але вже за рахунок розміщення диспетчерів блокувань на кожному вузлі системи. В даному випадку кожен диспетчер блокувань відповідає за управління блокуванням даних, таких, що знаходяться на його вузлі. Якщо дані не піддаються реплікації, цей протокол функціонує аналогічно протоколу двофазного блокування з первинними копіями. Інакше розподілений протокол двофазного блокування використовує особливий протокол управління реплікацією, що дістав назву "Читання однієї копії і оновлення усіх копій" (Read - One - Write - All - ROWA). В цьому випадку для операцій читання може використовуватися будь-яка копія копійованого елементу, але перш ніж можна буде відновити значення елементу, мають бути встановлені виняткові блокування на усіх копіях. У такій схемі управління блокуваннями здійснюється децентралізованим способом, що дозволить позбавитися від недоліків, властивих централізованому управлінню. Проте цьому підходу властиві свої недоліки, пов'язані з істотним ускладненням методів виявлення взаємоблокувань (через наявності багатьох диспетчерів блокувань) і зростанням витрат на передачу даних (в порівнянні з протоколом двофазного блокування з первинними копіями), які викликані необхідністю блокувати усі копії кожного оновлюваного елементу. У цьому протоколі виконання глобальної операції оновлення, що має агентів на n вузлах, зажадає передачі не менше 5n повідомлень, у тому числі:

-    n сполучень із запитами на блокування;

-    n сполучень з наданням блокування;

-    п сполучень з вимогою оновлення елементу;

-    n сполучень з підтвердженням виконаного оновлення;

-    n сполучень із запитами на зняття блокування.

Це кількість повідомлень може бути скорочена до 4n, якщо не передавати запити на зняття блокування, яке в цьому випадку виконуватиметься при обробці операції остаточної фіксації розподіленої транзакції.

Блокування більшості копій

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

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

 

4.4 Протоколи з часовими відмітками

 

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

Загальним підходом в розподілених СКБД є конкатенація локальної часової відмітки з унікальним ідентифікатором вузла у форматі <локалъная_відмітка, ідентифікатор_вузла>. Значення ідентифікатора вузла має менший ваговий коефіцієнт, що гарантує впорядкування подій відповідно до моменту їх виникнення і лише потім відповідно до місця їх появи. Щоб запобігти виробленню більш завантаженими вузлами великих значень часових відміток в порівнянні з недовантаженими вузлами, необхідно використовувати певний механізм синхронізації значень часових відміток між вузлами. Кожен вузол поміщає свою поточну часову відмітку в повідомлення, що передаються на інші вузли. При отриманні повідомлення вузол-одержувач порівнює поточне значення його часової відмітки з отриманим і, якщо його поточна часова відмітка виявляється менше, міняє її значення на деяке інше, що перевищує те значення часової відмітки, яке було отримано ним в повідомленні. Наприклад, якщо вузол 1 з поточною часовою відміткою <10, 1> передає повідомлення на вузол 2 з поточною часовою відміткою <15,2>, то вузол 2 не змінює свою часову відмітку. І навпаки, якщо поточна часова відмітка на вузлі 2 рівна <5, 2>, то вузол 2 повинен змінити свою часову відмітку на <11, 2>.

 

4.5 Технології ActiveX та CORBA для побудови розподілених систем

 

ActiveX/DCOM – це корпоративна технологія з фірмовим знаком Microsoft. Головне її призначення – полегшення написання мережевих розподілених об'єктно-орієнтованих застосувань. По суті, ActiveX – це ні що інше, як звичайний набір бібліотек, що значно полегшують процес кодування. Іноді запитують, в чому різниця між OLE і його складеними механізмами (OLE Automation, OLE Documents, OLE Controls) і елементами ActiveX? Відповідь дуже проста. OLE-механізми засновані на компонентній об'єктній моделі (COM, Component Object Model), яка дозволяє створювати об'єктно-орієнтовані застосування на одній машині у рамках операційної системи Windows, що функціонує на ній, a ActiveX використовує DCOM (Distributed Component Object Model) – розподілену компонентну об'єктну модель, яку реалізують бібліотеки ActiveX, що являються за об'ємом значно менше, чим бібліотеки OLE, а за швидкістю – швидше. Іншими словами, бібліотеки OLE переписані так, щоб забезпечувати функціональність, достатню для написання мережевих застосувань. Збереглася і сумісність – будь-який програмний компонент OLE працюватиме з бібліотеками ActiveX. Моделі СОМ і DCOM спираються на базові мережеві протоколи, такі як TCP/IP, і входять до складу операційної системи.

Що таке СОМ і DCOM

COM (Component Object Model) розшифровується просто – компонентна об'єктна модель. DCOM (Distributed Component Object Model) – це, відповідно, розподілена компонентна об'єктна модель.

Microsoft розробляє і підтримує DCOM виключно для створення серверів застосувань і управління розподіленими програмними об'єктами. На противагу Microsoft, два інших комп'ютерних гіганта – Sun і IBM – спираються на міжнародний стандарт CORBA. За бажання можна спільно використати обидві ці технології.

DCOM просто розширює можливості СОМ в частині реєстрації віддалених об'єктів, тому його іноді називають "СОМ з подовженим дротом".

Прикладні інтерфейси COM API – це усе ті ж, усім відомі OLE-інтерфейси, що ведуть своє походження від DDE (Dynamic Data Exchange), – динамічного обміну даними, що дозволяє єдиним способом в Windows здійснювати обмін інформацією між процесами.

По суті своїй СОМ є простим об'єктним розширенням OLE-технології, коли в локальній моделі засобів автоматизації OLE команди від клієнта проходять через модуль-ініціалізатор (proxy), а повідомлення – в модуль-перехідник (stub), де воно розбирається, аналізується і звідки посилається команда на сервер, як показано на рис. 4.2.

 

image005

Рисунок 4.2 – Схема роботи OLE Automation

 

Наочніше ця ж схема, але вже в специфікації СОМ, представлена на рис. 4.3.

Модель СОМ значно простіша з точки зору програмістів і її набагато зручніше використати в невеликих локальних мережах.

У дистанційній моделі, яка тепер замість СОМ дістала назву DCOM, ініціалізатор і перехідник стали абсолютно іншими, тепер в них використовуються процедури дистанційного виклику (RPC) для передачі запитів клієнта по мережі до модуля Remote Server Process, що функціонує на сервері. Клієнтська частина DCOM, аналогічна колишньому механізму Automation Manager, передає дані клієнта вказаному OLE-серверу і дані у відповідь по мережі до програми-клієнта, як показано на рис. 1.15.

 Як можна бачити з приведених рисунків, чудовою властивістю DCOM є його прозорість як для користувача, так і для програміста. Можна створити і запустити на своїй машині сервер OLE, а потім пристосувати його для роботи в дистанційному режимі простим перенесенням OLE-сервера на віддалений ПК, на якому працює модуль адміністратор автоматизованого управління DCOM. Потім треба просто зареєструвати нове місце розташування OLE-сервера за допомогою звичайної утиліти (наприклад, з арсеналу засобів Visual Basic). Програмістові не доводиться міняти жодного рядка тексту програми, щоб використати розроблений OLE-сервер віддалено. Зараз майже у будь-якій RAD-системі є шаблони для створення OLE -серверів, методи і об'єкти яких доступні при роботі в дистанційному режимі. І, оскільки реєстрацію віддаленого сервера легко включити в процедуру установки програми-клієнта, не доводиться робити яких-небудь додаткових дій, щоб скористатися новими можливостями.

 

image006

image007

Рисунок 4.3 – Схема взаємодії для локального і віддаленого варіантів

 

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

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

Наприклад, трирівнева модель абсолютно не потрібна (і не обов'язково намагатися ділити програму на частини), якщо вона не вирішує загальну проблему ефективності.

 

image008

Рисунок 4.4 – Трирівнева архітектура бізнес-застосувань

 

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

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

Щоб краще зрозуміти можливості розподіленої архітектури, розглянемо приклад з реального життя. Припустимо, є велика транспортна компанія M-Trans, яка забезпечує своїх клієнтів спеціальною програмою для відстежування шляху проходження вантажу. Коли ви відправляєте вантаж з Москви в Делі, вам дається спеціальний транспортний номер. Потім, якщо ви захочете дізнатися, що сталося з вашим вантажем на шляху слідування, ви просто завантажуєте програму (назвемо її MTrack) і вводите свій транспортний номер. Діалоговий модуль зв'язується з центральною універсальною ЕОМ компанії і відшукує інформацію відносно поточного місця розташування і стану вашого вантажу. Наприклад, ви могли б дізнатися, що вантаж знаходиться нині у вузловому аеропорту відвантаження або що він був вже отриманий замовником. Електронний підпис замовника, природно, повинен свідчити про цей відрадний факт.

Поки усе звучить, подібно до банальної історії про типове обслуговування клієнтів на сервері. Проте проблема полягає в тому, що програма сильно залежить від типу присвоєного транспортного номера. Різні типи чисел  означають  різні  типи  послуг,   що надавались   користувачеві (наприклад, можливість упевнитися в підписі замовника товару, достовірності упаковки і т. д.). Щоб зробити MTrack настільки дружньою наскільки це можливо, розробники порахували, що користувач не повинен потребувати інтерпретації типу номера, який він отримав. Було б логічне покласти цю процедуру на центральну ЕОМ, але відносно неї у керівництва фірми існувала спеціальна політика і, крім того, вона була занадто завантажена іншими завданнями. Нічого не залишалося, як повернутися до ідеї відносно виконання цієї простої логіки на стороні користувача. Втім, проти такого рішення заперечувала група супроводу програмного забезпечення, мотивуючи тим, що, оскільки, можливо, розроблятимуться нові типи послуг, те програмне забезпечення не розпізнаватиме ці нові послуги і повинне час від часу модифікуватися. Оскільки програмне забезпечення в цій транспортній фірмі використовується більш ніж 50000 замовниками, це було б справжнім кошмаром. Тому було покінчено з ідеєю інтерпретувати транспортний номер користувача за допомогою відповідного діалогового вікна програми.

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

Цей приклад хороший тим, що показує, як потрібно використати сервер застосувань. Кращим варіантом завжди буде той, коли на сервері виконується програмний модуль, який може часто модифікуватися і який повинні викликати у своїй роботі одночасно тисячі клієнтів. Викликається він дистанційно і виконує корисну роботу. Клієнт і сам би міг мати на своїй машині цей модуль і усе для нього, клієнта, було б набагато простіше. Але річ у тому, що клієнтів – 50000, а модуль часто модифікується!

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

 Що мається на увазі під технологіями ActiveX

ActiveX служить одній єдиній меті: забезпечувати функціонування програмних компонентів усередині складених програмних контейнерів. Ці контейнери включають Web-браузери і інші засоби перегляду документів. ActiveX – технологія Microsoft, призначена для написання мережевих застосувань. Оскільки самим напрямом, що динамічно розвивається, в комп'ютерній індустрії є Інтернет, саме тут найприродніше можуть знайти своє місце програми, написані з використанням технології ActiveX. He випадково останнім часом поняття ActiveX і Інтернету часто зустрічаються поруч. В той же час технологія ActiveX має значно більше універсальну сферу застосування.

Стандарт ActiveX дозволяє програмним компонентам взаємодіяти один з одним по мережі незалежно від мови програмування, на якій вони написані. За допомогою ActiveX можна "оживити" Web-сторінки ефектами мультимедіа, інтерактивними об'єктами або складними застосуваннями. ActiveX забезпечує деякі зв'язні засоби, за допомогою яких окремі програмні компоненти на різних комп'ютерах "склеюються" в єдину розподілену систему.

ActiveX включає в себе клієнтску і серверну частини, а також бібліотеки для разробника.

 Керуючі елементи ActiveX (ActiveX Controls)

Що ж це таке насправді? Найбільш проста відповідь – ця нова назва для керуючих  елементів OCX, або навіть для ще раніше них існуючих VBX. Будь-який готовий або створений вами управляючий елемент OLE – це вже ActiveX-елемент, який може використовуватися в програмах. Проте подібні OLE-елементи в усьому їх незліченному різноманітті навряд чи влаштують розробників для Web.

Типовий недолік існуючих OLE-елементів – їх значні розміри. Це обумовлено складністю структури OLE-інтерфейсів, а також тим фактом, що при підготовці в Microsoft бібліотек, використовуваних для генерації управляючих елементів, розміри їх не оптимізувалися. Якщо в системі користувача якийсь з цих елементів відсутній, доводиться завантажувати його через інтернет, отже, розмір управляючих елементів, Web-сторінок має бути якомога менше. З технічної точки зору ActiveX-елемент – це деякий COM-об'єкт, через основний OLE-інтерфейс якого, IUnknown, організовується доступ до інших інтерфейсів цього об'єкту.

По суті за допомогою ActiveX-елементів програміст створює високорівневий, придатний для багатократного використання об'єкт з деякою корисною функцією. Потім цей елемент може бути переданий (чи проданий) іншому програмістові, якому згодиться як деякий "будівельний блок". Більшість програмних інструментальних систем, таких як Delphi, Visual Basic, Visual C++ підтримують засоби взаємодії з ActiveX-елементами. В ролі ActiveX-елементів може бути усе що завгодно - від звичайної кнопки до повнофункціональної електронної таблиці. У продажі є тисячі таких елементів від різних постачальників. Їх богаті функціональні можливості і різноманіття – окреме, найбільш важливе достоїнство платформи ActiveX.

Можна запитати, а яке відношення це має до Інтернету і баз даних? Відповідь i інтерпретації Microsoft звучатиме так: найпряміше і безпосереднє. За своєю суттю платформа ActiveX – це адаптація існуючих технологій Microsoft стосовно Web. По заявах Microsoft керуючі елементи ActiveX працюють швидше, ніж Java-аплети. Складні функції можна додавати клацанням миші. Головне, проте, не в тому, що ActiveX, як і Java-аплети, здатні оживити Web-сторінки. Куди важливіше той факт, що управляючі елементи ActiveX, дозволяють відвідувачам Web-вузла виконувати складні операції, отримувати потрібну інформацію від баз даних і від застосувань, працюючих на інших серверах або навіть на других Web-вузлах.

Оскільки ActiveX-файл є родичем VBX, він може використовуватися і в звичайному Visual Basic, і в мові сценаріїв VBScript. У таблиці 4.1 перераховані основні бібліотечні типи, що використовуються у Windows.

 

Таблиця 4.1 – Бібліотечні типи, використовувані в Windows

Управляючий елемент

Розши-рення

Функція

Бібліотеки (Dynamic link library), що динамічно підключається

.dll

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

Visual Basic

.vbx

Забезпечує той же призначений для користувача сервіс, що і DLL. Може застосовуватися в інтегрованих середовищах розробки, таких як Visual Basic 3.0, MSVC++ 1.52 і Delphi 1.0

ActiveX

.OCX

Забезпечує призначений для користувача сервіс, такий же, як DLL, і той же, що і VBX. На додаток, OCX є більш функціональними і краще використовує усі доступні йому ресурси. Підтримується практично усіма відомими RAD-системами

 

 

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

Контейнер і взаємодія з ним

Управляючий елемент ActiveX не може існувати сам по собі, він завжди "живе" усередині свого контейнера і тісно взаємодіє з ним. Через властивості оточення (ambient properties) об'єкт має доступ до інформації про поточний стан свого "власника". Контейнер підтримує додаткові методи, властивості і події, які для розробника виглядають як частину інтерфейсу елементів управління ActiveX.

Властивості оточення

Інформація про стан контейнера доступна ActiveX-елементу через об'єкт AmbientProperties, посилання на який може бути отримане через властивість Ambient об'єкту UserControl.

Наприклад, властивість UserControl.Ambient.BackCoior відображає поточне значення кольору фону контейнера і зазвичай використовується при відображенні ActiveX-елемента. Грамотно написаний ActiveX-елемент повинен поводитися відповідно до поточного стану контейнера. Повідомлення userControl_Ambientchanged сповіщає управляючий елемент ActiveX про зміну значення якої-небудь властивості оточення контейнера.

Додаткові властивості

Додаткові властивості (extender properties) надаються контейнером, але зовні виглядають як частину інтерфейсу елементів управління ActiveX. Розробник ActiveX-елемента має доступ до додаткових властивостей через властивість Extender об'єкту userControl. Специфікація елементів управління ActiveX вимагає, щоб усі контейнери підтримували  Наступні  Додаткові  властивості:   Name,    Visible,    Parent,    Cancel Default. Для доступу до додаткових властивостей завжди використовується механізм пізнього зв'язування (late - bound), оскільки на момент компіляції невідомо, з яким контейнером належить працювати ActiveX-елементу.

Коли користувач звертається до властивості (методу) ActiveX control, то першим управління отримує об'єкт Extender. Якщо він не підтримує цю властивість (метод), то викликається обробник ActiveX Controls.

Об’єкт UserControl

ActiveX-елемент, створений на Visual Basic, завжди містить (агрегує) об'єкт userControl. Розміщення і налаштування властивостей складових (constituent) ActiveX-елемента проводиться за допомогою редактора властивостей.

Об'єкт userControl має стандартний інтерфейс. Ви можете написати свої обробники для подій, генерованих цим об'єктом, надати для використання або перевизначити стандартні властивості. Так само ваш ActiveX-елемент може експортувати методи, властивості і події складових компонентів.

Ключові події

В процесі свого існування ActiveX-елемент отримує сповіщення про ряд подій, генерованих об'єктом UserControl. Найбільш важливими є:

-              initialize.   Найперша  подія,  завжди  відбувається  при  створенні ActiveX-елемента. У цей момент об'єкт ще не має зв'язку зі своїм контейнером.

-              initProperties. Ця подія сповіщає про розміщення нового ActiveX-елемента у формі. У момент його приходу вбудований об'єкт вже має зв'язок зі своїм контейнером. Як правило, обробник події виконує початкову ініціалізацію властивостей ActiveX-елемента.

-              ReadProperties. При завантаженні форми (як у DesignMode, так і в RunMode) вбудовані в неї елементи створюються наново і їх властивості ініціалізувалися значеннями, збереженими у файлі з розширенням .frm. Подія ReadProperties  сповіщає ActiveX-елемент про  необхідність  виконати ініціалізацію. У цей момент об'єкт має зв'язок зі своїм контейнером.

 CORBA и Enterprise JavaBeans – лідери найновіших технологій. Навіщо потрібна CORBA

Відразу обмовимося, що під CORBA ми розумітимемо CORBA/IIOP, тому що сама специфікація CORBA не стандартизує мережевий протокол передачі даних між клієнтом і сервером. Кожен виробник брокера об'єктних запитів, який, по суті і є CORBA, може запропонувати власний протокол транспортної служби передачі даних. Проте для забезпечення інтероперабельності брокерів запитів від різних виробників OMG (Object Management Group – міжнародна некомерційна організація, в яку входять промислові компанії і компанії, що займаються створенням програмного забезпечення) розробив загальний протокол GIOP. Його відображення в TCP/IP дістало назву протоколу Internet Inter ORB Protocol (IIOР). Завдяки цьому, будь-яке застосування CORBA/IIOP повинне працювати і взаємодіяти з іншими CORBA/IIOP-додатками незалежно від платформ, виробників програмного забезпечення і операційних систем.

CORBA (Common Object Request Broker Architecture) – це технологія для світу розподілених інформаційних об'єктів, що тісно взаємодіють між собою у рамках програми, що управляє ними, яка віртуально з цих об'єктів і складається. Так от, CORBA – це архітектура, яка з максимальними зручностями забезпечує створення і функціонування програм, званих CORBA -додатками. Останнім часом багато RAD-системи: Delphi, включають у свій арсенал підтримку CORBA.

Втім, традиційні RAD-системи, подібні Visual Basic, не потребують CORBA, тому що орієнтуються на наявний в Microsoft власний брокер об'єктних запитів, існуючий під іменем DCOM. Надалі виробникам програмних продуктів для програмістів стане все важче і важче підтримувати обидві технології. Delphi-програмісти можуть заспокоювати себе тим, що є можливість працювати і з CORBA, і з DCOM.

Звичайно ж, CORBA – більше масштабований, відкритіший і грандіозніший проект, ніж DCOM. CORBA розглядає вже існуючі застосування, як деякі метафори, які легко можна адаптувати і використати, правильно і одного разу описавши їх інтерфейси за допомогою спеціальної мови описів IDL (Interface Definition Language – мова опису запитів), для якого існують компілятори у більшість сучасних мов програмування. CORBA є прообразом нашого об'єктного майбутнього. У комп'ютерному світі абсолютно нормальним вважається факт, що програмісти усіх країн по мільйону разів переписують наново один і той же алгоритм, якщо він вимагає внесення деяких невеликих змін. Навіщо?

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

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

Звичайно, було б ідеально, якби повторно використовувані об'єкти самі б не були об'єктами, а їх творець мав права на плоди своєї творчості. Але ж неможливо уявити собі, що б творець якого-небудь об'єкту творив у вакуумі, він усього лише наслідує структуру якого-небудь опису, якого-небудь шаблону, класу або групи класів – пакетів. Те що зараз відбувається з програмними модулями, що оформляються на універсальній мові програмування в JavaBeans або в ActiveX, те ж, по суті, відбувається і з авторськими текстами, що перетворюються не на індивідуальні плоди творчості, а в один нескінченний і універсальний коментар. Який сенс наново описувати те, що вже одного разу описано? Проте це робиться, і текст, проходячи через безліч об'єктів, що інтерпретують його, постійно шліфується, до тих пір, поки не набуває абсолютної форми. Якщо раніше Мережа ще носила на собі яскравий відбиток індивідуалізму її творців, то тепер вона все більш і більш перетворюється на деякий Універсум, який за визначенням не терпить нічого, що виходить за його межі. Усе або майже усе в Мережі придбаває статус анонімності. Використовуються вже не повноцінні імена, а усього лише ідентифікатори, не індивідуальні паролі, а сертифікати. Творців не може бути надто багато. Врешті-решт єдиним творцем усього стає сама Мережа.

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

Приклади абсолютно прості: ви включаєте свій телевізор таким самим способом, як праску, електропіч або настільну лампу. Усі предмети, що відносяться до класу "Прилад", містять метод "включити", але в процесі включення, залежно від типу приладу (підкласу), єдиний метод "включити" поводиться поліморфно, тобто викликає абсолютно різні електричні і блокові функції: для праски – одні, для телевізора – інші. Можна так перевизначити класи і методи в телевізорі новітньої конструкції, що він поводитиметься абсолютно по-різному, залежно від того, ХТО його включив, тобто телевізор поведеться поліморфно. Більше того, існують програмні засоби (Java+XML), які здатні динамічно модифікувати контент. Попри те, що Java і XML самі по собі досить складні, інструменти, засновані на них, для звичайного користувача надзвичайно прості і приємні, бо вони відводять його від необхідності знати внутрішні механізми інформаційного джерела і призводять до дистанційного пульта управління ними.

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

Для постмодерністської епохи, завершенням якої є Інтернет, цінності в традиційному розумінні не є цінностями, бо вона маніпулює ними і будує з них структури більш високого порядку. Плоть і кров пішли з цивілізованих людей, залишилася лише електрика. Безглуздо заявляти свої права на конструкції, які існують як візерунки в калейдоскопі. Усе стає віртуальним, усе стає відносним, а точка відліку – Мережа. Сучасні люди вже не здатні круто змінити парадигму свого існування. Творчість в епоху Інтернету є витяганням усе нових і нових сенсів з відомих речей і постійне оновлення простору контенту.

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

Архітектура CORBA.

Чотири головні елементи CORBA архітектури показані на рис. 4.5.

-              Брокер об'єктних запитів (ORB – Object Request Broker) визначає механізми взаємодії об'єктів в різнорідній мережі. Посередник об'єктних запитів, ORB, або просто брокер, – це логічне ядро системи. Саме він дозволяє об'єктам посилати запити і отримувати відповіді від інших об'єктів в мережі. ORB – це проміжне програмне забезпечення, яке встановлює відношення між об'єктами в розподіленому середовищі. Брокер по посиланню знаходить на сервер, що містить об'єкт-адресат (object implementation – реалізація об'єкту); активізує його, доставляє до нього запит; передає параметри і викликає відповідний метод, після чого повертає результат клієнтові. Ролі клієнта і сервера при цьому можуть мінятися. Взаємодія може бути встановлена між безліччю об'єктів. OMG розробив спеціальну мову верхнього рівня для опису ORB і інших компонентів CORBA – так званий IDL (Interface Definition Language – мова опису інтерфейсів). У ній немає присвоєнь,    звичайних    мовних    конструкцій,    типу    if    чи    while, функцій і логічних переходів і т. д. IDL – це мова декларацій, вона описує батьківські класи, події і методи. Кожен інтерфейс визначає операції, які можуть бути викликані клієнтами, але не те – яким чином ці операції виконуються зовні IDL і CORBA. У цьому і привабливість – можна змусити працювати старі програми, якщо правильно описати їх інтерфейси і використати компілятор з IDL, який має відображення в конкретну мову програмування. Важливо зрозуміти, що є два типи інтерфейсів: динамічні і статичні. Перші визначаються на стадії розробки застосування і компілюються разом з ним, другі конструюються у момент виконання, на працюючому застосуванні.

-    Сервіси  об'єктів  (Object  Services)  є  основними  системними сервісами, які розробники використовують для створення застосувань.

-    Універсальні засоби (Common Facilities) є також системними сервісами, але більш високого рівня, орієнтованими на підтримку призначених для користувача застосувань, таких як електронна пошта, засоби друку і т. д.

-    Прикладні об'єкти  (Application  Objects)  використовуються  в конкретних прикладних завданнях.

Так, все-таки, навіщо потрібна CORBA?

 

image009

Рисунок 4.5 – Головні елементи CORBA

 

Розподілені застосування

CORBA-архітектура забезпечує каркас для розробки і виконання розподілених застосувань. Але виникає нове питання – а навіщо взагалі потрібний цей розподіл? Як тільки ви зіткнетеся з ним, то побачите перед собою величезну купу нових проблем. Проте іноді немає іншого вибору: деякі застосування просто вимагають бути розподіленими з наступних причин:

-    дані, використовувані застосуванням, – розподілені;

-    обчислення – розподілені;

-    користувачі застосування – розподілені.

Розподілені дані

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

Розподілені обчислення

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

Розподілені користувачі

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

Як вже говорилося, CORBA є ідеальною архітектурою для створення таких застосувань. Актуальність її в наші дні активно затребувана розвитком Інтернету і систем електронної комерції, де багато функцій має бути розподілені по мережі і де є удосталь безліч вже працюючих об'єктних модулів, існуючих у вигляді ActiveX, або JavaBean-компонентів.

Брокер об'єктних запитів, ORB, ставить запит об'єкту і повертає будь-який результат клієнтові (рис. 4.7).

 

image0010

Рисунок 4.6 – Розподілені користувачі

 

image0011

Рисунок 4.7 – Механізм взаємодії: клієнт запитує об'єкт через посередника ORB

 

Від клієнта до сервера

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

Можна чітко сформулювати ключові особливості CORBA-стандарту:

-    CORBA-об’єкти можуть знаходитись в будь-якому месці мережі;

-    CORBA-об’єкти можуть взаємодіяти з іншими CORBA -объектами на будь-яких платформах;

-    CORBA-об’єкти можуть бути написані на будь-якій мові програмування, для якого є інтерфейс, що реалізовується IDL-компілятором (такі є для Java, C++, C, SmallTalk, COBOL і Ada).

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

 

image0012

Рисунок 4.8 – Архітектура CORBA-сумісного застосування, що викликає безліч об'єктів з безлічі комп'ютерів

 

Клієнтська частина CORBA

Коли CORBA-сумістний об'єкт використовує метод, що знаходиться в іншому об'єкті, він викликає стаб (stub), тобто деяку порожню оболонку необхідного об'єкту, його інтерфейсну частину, що знаходиться в спеціальному stub-файлі. Цей стаб використовує локальний ORB, посилає запит і отримує відповідь. Об'єкту немає ніякої необхідності знати подробиці відносно ORB або дійсного місцезнаходження сервера. Усі CORBA-клієнти і сервери з'єднуються через брокерів ORB, використовуючи їх як посередників.

JDK містить ORB, який дозволяє створювати CORBA-сумісні програми на Java.

Клієнтський стаб створюється при першому визначенні серверного інтерфейсу в клієнтові за допомогою мови визначення інтерфейсів IDL. CORBA IDL визначає тип об'єкту, його методи, властивості і т. д. CORBA IDL – це абсолютно нейтральна і чисто декларативна мова.

Стаб потім використовує локальний ORB, посилає запит і отримує відповідь. ORB надає своєрідну шину для проходження обміну структурованими даними. Ця шина використовує IIOP як транспортний протокол між брокерами ORB.

 Серверна частина CORBA

-              При витяганні запиту IIOP сервер ORB використовує так званий Basic Object Adapter (BOA) в комбінації з депозитарієм виконання (Implementation Repository – набором конкретних класів і бібліотек, наявних на сервері) для передачі параметрів запиту до необхідного серверного об'єкту через серверний стаб. Іноді запитують – навіщо так складно? Відповідь проста, щоб легше було програмувати незалежні частини коду, зосереджуючись тільки на суті коду, а не на вирішенні системних питань, пов'язаних з мережевою специфікою і міжпрограмній взаємодії. Про них користувач взагалі не повинен замислюватися, в точності так само, як він не замислюється про внутрішній устрій телефонної трубки і телефонної станції, через які проходить голосовий сигнал.

-    Basic Object Adapter BOA – це набір системних сервісів ORB для встановлення з'єднання з серверними об'єктами по їх ідентифікаторах (об'єктні посилання).

-    Server IDL Stub Служить для забезпечення інтерфейсу до кожного сервісу. На серверній стороні такої стаб, щоб відрізнити його від клієнтського стаба, називається скелетон.

-    Implementation Repository Це набір класів на стороні сервера, доступний усім розподіленим клієнтам через систему об'єктних посилань.

Сервіси CORBA

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

 

image0013

Рисунок 4.9 – Об'єктні сервіси

 

Є безліч CORBA-сервісів. Найпопулярніші з них наведені в таблиці 4.2.

 

Таблиця 4.2 – Найбільш популярні сервіси CORBA

Сервіс

Опис

Життєвий цикл об’єкта (Object life cycle)

Визначає, яким чином CORBA-об’єкти будуть створені, видалені, переміщені або скопійовані

Іменування (Naming)

Визначає спосіб символічного позначення CORBA -объектов

Події (Events)

Обробка подій

Відношення (Relationships)

Визначають стосунки  між об'єктами  (головний, підлеглий, зв'язковий і т. д.)

Перетворення об'єктів з однієї форми в іншу (Externalization)

Координує перетворення об'єктів із зовнішніх форм у внутрішні і навпаки

Транзакції (Transactions)

Координують доступ до CORBA-об’єктів

Контроль доступу (Concurrency Control)

Забезпечує обслуговування блокування об'єктів CORBA

Властивість (Property)

Підтримує   асоціацію   пари :   ім'я-значення для об'єктів CORBA

Продавець (Trader)

Підтримує  пошук  CORBA-об’єктів,   заснований на афішованих властивостях об'єкту

Запрос (Query)

Підтримка запитів до об'єктів

 

 

CORBA-продукти

Не забувайте, що CORBA – це усього лише специфікація. Що стосується програмних виробів, що реалізовують архітектуру CORBA, то їх є множина. Окремі продавці забезпечують свої брокери CORBA і IDL для відображення в різні мови програмування. Усі вони зобов'язані підтримувати Java. У таблиці. 4.3 приведені найбільш відомі реалізації CORBA.

 

Таблиця 4.3 – Найбільш відомі реалізації CORBA

ORB

Опис

Java ORB

Java 2 ORB поставляється у складі   Sun's Java SDK. Там відсутні деякі особливості повної специфікації

VisiBroker for Java

Популярний Java ORB з Inprise Corporation. VisiBroker вбудований у багато інших продуктів. Приміром, саме він був вбудований у браузер Netscape Communicator.

OrbixWeb

Добротний Java ORB з lona Technologies (для Unix)

WebSphere

Потужний сервер застосувань зі вбудованим ORB від IBM

Free or shareware ORBs

CORBA-реалізації для різних мов програмування доступні для завантаження по мережі Інтернет з різних джерел

 

 

4.6 Розподілені об’єктні технології в інформаційних системах

 

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

Складність створення, модифікації, супроводження та інтеграції ІС, особливість розв’язуваних з їх використанням задач, визначає такі їх класи:

−           малі ІС;

−           середні ІС;

−           крупні ІС (корпоративні на рівні загальнодержавних установ).

До малих ІС відносяться системи, рівня невеликих підприємств, ознаками яких є:

−           нетривалий життєвий цикл;

−           орієнтація на масове використання;

−           невисока ціна;

−           практична відсутність засобів аналітичної обробки даних;

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

−           використання, головним чином, настільних СУБД (Clarion, FoxPro, Clipper, Paradox, Access та ін.);

−           однорідність апаратного та системного забезпечення (недорогі персональні комп’ютери (ПК));

−           практична відсутність засобів забезпечення безпеки;

−           та ін.

Ознаками класу середніх ІС є:

−           тривалий життєвий цикл і можливість росту до крупних ІС;

−           наявність аналітичної обробки даних;

−           наявність штату співробітників для здійснення функцій адміністрування апаратних та програмних засобів);

−           наявність засобів забезпечення безпеки;

−           тісна взаємодія з установами-розробниками програмного забезпечення з питань супроводження компонентів ІС;

−           та ін.

До характерних ознак корпоративних ІС відносяться:

−           тривалий життєвий цикл;

−           міграція успадкованих систем

−           розмаїття використовуваного апаратного забезпечення з меншим, порівняно

−           із створюваною системою, життєвим циклом;

−           розмаїття використовуваного програмного забезпечення (ПЗ);

−           масштабність та складність розв’язуваних задач;

−           перетин множини різних предметних галузей;

−           орієнтація на аналітичну обробку даних;

−           територіальний розподіл;

−           та ін.

Нині обговорюються питання стосовно опису продуктів, технологій та методологій створення малих та середніх ІС. Разом з тим, технології та методології побудови крупних ІС, які об’єднують у собі множину локальних ІС, практично не розглядаються і не обговорюються. Це призводить до того, що, як технології створення крупної ІС, вибираються ті, які з самого початку не це не розраховані. З цієї причини проекти, що реалізуються, не отримують належного розвитку.

Сучасний рівень розвитку суспільства визначає індустрію ІТ, як провідний і стратегічний напрямок зосередження інтелектуальних та фінансових ресурсів. Інформація та інструменти управління нею (програмні продукти різного функціонального призначення) набули статусу інформаційних ресурсів (ІР). Останні концентруються в рамках ІС. Об’єднання ресурсів на основі інформаційно-комунікаційної взаємодії ІС виводить їх на рівень корпоративних інформаційних ресурсів. Це об’єднання часто називають Єдиним Інформаційним Простором (ЄІП). Реалізація ЄІП на рівні держави, корпорації, підприємства можливе у разі створення з подальшим дотриманням стандарту на взаємодію між собою ІС, та їх окремих додатків, рис. 4.10

 

Рисунок 4.10 - Корпоративні інформаційні ресурси

 

У ряді випадків під ІР розуміють тільки дані, коли розв’язок проблеми ЄІП зводиться до Єдиного Простору Даних (ЄПД), рис. 4.11, а ІС виступають як клієнт та сервер і взаємодіють один з іншим у відповідності із схемою, наведеною на рис. 4.12.

 

 

 

Рисунок 4.11 - Єдиний простір даних (ЄПД)

 

Рисунок 4.12 - Архітектура доступу до віддалених даних

 

Інформаційна система-клієнт (ІСК) надсилає інформаційній системі-серверу (ІСС) запит, отримуючи, як результат, дані, які підлягають подальшій обробці. Як запит, використовують мову SQL - стандарт поводження з реляційними системами управління базами даних. Доступ до віддалених баз даних (БД) у більшості випадків здійснюється з використанням продуктів, які підтримують протоколи ODBC (Open Data BaseConnectivity), та JDBC (Java Data Base Connectivity), або використовуються шлюзи, які постачаються виробниками СУБД чи третіми фірмами-виробниками. При побудові єдиного простору даних використовується архітектура доступу до віддалених даних, що є аналогом дворівневої архітектури клієнт-сервер. Ця архітектура припускає реалізацію на стороні клієнта як функцій введення та відображення даних, так і прикладних функцій додатку, тобто методів обробки даних. Клієнт направляє запити до сервера, який обробляє їх і повертає клієнту результат, оформлений як блок даних.

Описаному сценарію взаємодії систем притаманні всі недоліки, характерної для дворівневої архітектури клієнт-сервер:

-    слід знати з боку ІСК особливості використовуваної СУБД та структуру віддаленої бази даних (БД) ІСС, що знижує рівень безпеки всієї системи у цілому;

-    ускладнено супроводження та модифікація тих додатків ІСК, які спілкуються з БД ІСС, оскільки будь-яка зміна схема віддаленої БД на стороні ІСС тягне за собою зміну додатків в ІСК, що ускладнює обслуговування, оновлення чи заміну додатків, встановлених на десятках-сотнях комп’ютерів;

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

Істотним недоліком розглянутого сценарію є дублювання додатків ІСС в ІСК, що призводить до неефективного використання ресурсів ІС, що взаємодіють. Зростання популярності глобальної мережі Internet та технології WWW останнім часом викликає підвищений інтерес до них з боку розробників корпоративних ІС. В самому початку WWW створювався як засіб, який надає графічний інтерфейс в Internet і спрощує доступ до інформації, розподіленої по мільйонам комп’ютерів у всьому світі. Основними компонентами були сторінки, вузли, браузери та сервери Web.Користувачам була надана можливість навігації по Internet з використанням технології гіпертексту, підтримуваної протоколами HTTP (HypertextTransfer Protocol) та стандартом мови HTML (Hypertext Markup Language).

Додаток CGI (Common Gateway Interface) розв’язав проблему обміну інформацією між сервером Web та програмами типу бази даних, які не можуть безпосередньо обмінюватися даними з браузерами Web. В результаті з’явилася можливість реалізації інтерактивної взаємодії кінцевого користувача з програмами сторони Web - серверу, які обробляли інформацію, уведену користувачем в браузері, і в як результат повертали сформовану HTML - сторінку. Багато з існуючих рішень доступні в середовищі Internet і базуються на такому підході.

Поява мови Java надала для розробників ІС абсолютно нові технологічні рішення побудови додатків у середовищі Internet/Intranet. Проте не слід розглядати технологію Java тільки як частину технології WWW, оскільки Java дає змогу розв’язувати задачі більш широкого класу, порівняно з технологіями, які базуються на мові HTML, протоколі HTTP та CGI. Можливості, які надаються WWW - технологією розширили спектр рішень, якими керуються проектувальники при побудові ІС. Проте виникає питання: що собою представляють системи ІС, що взаємодіють, які базуються на технології, чи здатні вони розв’язати проблему ЄІП? Зрозуміло, що це не так. Таке сильне твердження пов’язане з тим, що в процесі розгляду взаємодії інформаційних систем, ІСК з браузером виступає в ролі компоненти зображення, а ІСС з WWW - сервером та додатками виступає як компонента, яка реалізує функціональну логіку та доступ до даних, що відповідає дворівневій архітектурі з інтелектуальним сервером, рис. 4.13. WWW - технологія здатна покращити ситуацію з імпортом/експортом даних між ІСК та ІСС, але є недоліки, що притаманні дворівневій архітектурі з інтелектуальним сервером.

 

Рисунок 4.13 - Архітектура з інтелектуальним сервером

 

Одним з недоліків є реальна відсутність можливості реалізації процесу обробки даних, які надаються WWW - сервером, на стороні ІСК, оскільки остання отримує інформацію від ІСС у вигляді HTML - сторінок, що робить неможливим організацію процесу обробки отриманих даних компонентами ІСК. Це призводить до відсутності потрібної ефективності використання обчислювальних ресурсів ІС. Разом з тим, гостро постає проблема підтримання безпеки системи у цілому, яка нині не має цілісного розв’язку у середовищі Internet, що неприпустимо для організацій, які висувають підвищені вимоги до безпеки. Крім того істотно ускладнюється адміністрування ресурсів ІСС, яке включає в себе управління правами доступу користувачів ІСС.

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

Знання схеми бази даних (БД) необхідно тільки тому додатку, який обробляє дані з цієї БД. Використання ІСС сервісів, які надаються ІС - сервером і реалізують методи обробки даних, дає змогу розв’язати проблему зміни схеми віддаленої бази даних. Статичність інтерфейсів компонентів. які надають ІСС набір сервісів, досягається застосуванням методологій об’єктно-орієнтованого аналізу та проектування, розподілених об’єктних технологій (CORBA, Java, DCOM) на різних етапах створення ІС. Більшість нині використовуваних ІС є додатками до дворівневої архітектури клієнт-сервер. Як засіб спілкування клієнта та сервера часто використовуються неповністю стандартизовані механізми тригерів та збережених процедур. Специфіка їх реалізації, невідокремлена від ядра системи управління БД) призводить до необхідності наявності додаткових обчислювальних ресурсів на стороні сервера.

В разі збільшення виконуваних сервером робіт системи в дворівневій архітектурі клієнт-сервер стають все більше схожими на великі ЕОМ (мейнфрейми), а структури оброблюваних ними даних та способи їх представлення слабо доступні для використання разом з іншими додатками. Як правило взаємодія розглянутих клієнт-сервер організується засобами СУБД, що перевантажує серверну частину. Разом з тим, сучасні технології дають змогу створити інтегроване середовище, яке в рамках ІС, так і в рамках концепції ЄІП:

−           не залежить від апаратних та системних програмних засобів;

−           спирається на міжнародні та промислові стандарти;

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

−           забезпечує розширюваність системи, тобто простоту та легкість добавлення нових компонентів в існуючі ІС;

−           дає змогу інтегрувати старі додатки (legacy applications) в нові ІЧ;

−           допускає природну інтегрованість створюваних ІС, що гарантує її життєздатність та еволюційний розвиток;

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

−           істотно знижують сумарні витрати на створення ІС/

 

4.7 Технології RMI, CORBA, DCOM

 

Нині виділяють три різні технології, які підтримують концепцію розподілених об’єктних систем. Це технології RMI, CORBA та DCOM.

Архітектура RMI (Remote Method Invocation - виклик віддаленого методу), яка інтегрована JDK1.1, є продуктом компанії Java Soft і реалізує розподілену модель. RMI дає змогу клієнтським та серверним додаткам через мережу викликати методи клієнтів/серверів, які виконуються і Java Virtual Machine. Незважаючи на те, що RMI вважається "легкою" та менш потужною, порівняно з CORBA та DCOM, тим не менше, вона має ряд унікальних можливостей, оскільки розподілене, автоматичне управління об’єктами та можливість пересилати самі об’єкти від машини до машини. На рис. 4.14 зображені основні компоненти архітектури RMI.

 

Модель RMI.

Рисунок 4.14 - Модель RMI

 

Client Stub (перехідник для клієнта) та Server Stub (перехідник для сервера) породжені від одного інтерфейсу, але різниця між ними полягає в тому, що client stub служить для під’єднання до RMI Registry, а server stub використовується для зв’язку безпосередньо з функціями сервера.

 

4.7.1 Технологія CORBA

Технологія CORBA (Common Object Request Broker Architecture), яка розробляється OMG (Object Management Group) з 1990 року - це архітектура з брокером потрібних спільних об’єктів. На рис. 4.15 наведена основна структура

CORBA 2.0 ORB.

 

ORB (CORBA 2.0).

Рисунок 4.15 - ORB (CORBA 2.0)

 

Dynamic Invocation Interface (DII): надає клієнту змогу знаходити сервери і викликати їх під час роботи системи. IDL Stubsвизначає, яким чином клієнт здійснює виклик сервера. ORB Interfaceспільні для клієнта та для сервера сервіси. IDL Skeleton Interfaceспільні інтерфейси для об’єктів, незалежно від їх типу, які не були визначені в IDL Object Adapterздійснюють комунікаційну взаємодію між об’єктом та ORB.

 

4.7.2 Технологія DCOM

Технологія DCOM (Distributed Component Object Model), рис. 4.16, була розроблена компанією Microsoft як розв’язок для розподілених систем в 1996 р. Нині DCOM є головним конкурентом CORBA, хоч і контролюється нині не Microsoft, а групою TOG (The Open Group), аналогічною OMG. DCOM є розширенням архітектури COM до рівня мережних додатків.

 

 

Архитектура DCOM.

Рисунок 4.16 - Архітектура DCOM

 

У кожної з трьох розглянутих технологій (RMI, CORBA, DCOM) є свої унікальні особливості, які багато в чому характеризують можливість чи неможливість її застосування для розв’язку конкретної поставленої задачі.

 

4.8 Переваги та недоліки використання технологій RMI, CORBA, DCOM

 

Переваги та недоліки технології DCOM. Такими є наступні:

Переваги: мовна незалежність; динамічний/статичний виклик; динамічне находження об’єктів; масштабованість; відкритий стандарт (контроль з боку TOG).

Недоліки: складність реалізації; залежність від платформи; немає найменування через URL; немає перевірки безпеки на рівні виконанняActiveX компонент. Крім того DCOM є лише частковим рішенням проблеми розподілених об’єктних систем. Це рішення добре підходить до Microsoft - орієнтованих середовищ. Як тільки в системі виникає необхідність працювати з архітектурою, яка відрізняється від Windows NT та Windows 95, DCOM перестає бути оптимальним рішенням проблеми. Таке положення невдовзі може змінитися, оскільки Microsoft намагається перенести DCOM також на інші платформи. Зокрема, фірмою Software AG вже випущена версія DCOM для Solaris UNIX і планується випуск версій також для інших версій UNIX. Але нині DCOM є задовільним рішенням лише для систем, орієнтованих виключно на продукти Microsoft. Нарікання викликає також невирішеність питання безпеки за умови виконання ActiveX компонент, що може призвести до неприємних наслідків.

Переваги та недоліки технології RMI. Такими є наступні:

Переваги: швидке та просте створення; Java - оптимізація; динамічне завантаження компонентів - перехідників; можливість передачі об’єктів за значенням; внутрішня безпека.

Недоліки: підтримка тільки однієї мови - Java; свій власний, не IIOP - сумісний протокол взаємодії; труднощі інтегрування з існуючими додатками; погана масштабованість. Завдяки своїй Java - моделі, яка є легко використовуваною, RMI є самим простим і самим швидким способом створення розподілених систем. RMI є добрим вибором для створення RAD - компонент та невеликих додатків на мові Java. Технологія RMI не є такою потужною, як DCOM чи CORBA, зокрема RMI використовує свій (не CORBA/ IIOP) сумісний протокол передачі JRMP і може взаємодіяти лише з іншими Java об’єктами. Підтримка тільки однієї мови робить неможливою взаємодію з об’єктами, написаними не на мові Java. Тим самим, роль RMI у створенні великих, масштабованих промислових систем, знижується.

Переваги та недоліки технології CORBA. Такими є наступні:

Переваги: платформна незалежність; мовна незалежність; динамічні виклики; динамічне виявлення об’єктів; можливість масштабування;CORBA-сервіси; широка індустріальна підтримка.

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

Технологія CORBA відноситься до найефективніших, сучасних, придатних для крупних проектів, це технологія розподілених об’єктів. Причиною цього є те, що обидві технології CORBA та DCOM надзвичайно схожі за своєю функціональністю та за своїми можливостями (багатомовна підтримка, динамічний виклик, масштабованість та ін.) у DCOM відсутній важливий критичний елемент - мультиплатформна підтримка. Одного факту, що нині DCOM не підтримує цілком міжплатформну переносимість, достатньо, щоб не розглядати її як повноцінне, закінчене рішення. Крім того. в той час, як до складу OMG вже нині входять більше 700 членів (компаній - виробників програмних продуктів, комп’ютерів, телекомунікаційних систем, розробників прикладних систем та кінцевих користувачів), і практично будь-яка специфікація, розроблена цим консорціумом, фактично стає стандартом, технологія DCOM лише недавно став переходити від Microsoft до аналогічної OMG організації - групи TOG (The Open Group). Ще один плюс технології CORBA такий. Коло виробників продуктів, які підтримують дану технологію, ширше, порівняно аналогічного кола DCOM. Тобто виявляється, що саме CORBA є технологією, яка повністю призначена для промислових, відкритих, розподілених об’єктних систем.

 

4.9 Технологія CORBA

 

Наприкінці 1980 - х і на початку 1990 - х років багато провідних фірм - розробників займалися пошуком технологій, які принесли б відчутну користь на мінливому ринку комп’ютерних розробок. Такою технологією виявилася область розподілених комп’ютерних систем. Необхідно було розробити єдину структуру, яка б дала змогу здійснити повторне використання та інтеграцію коду, що важливо для розробників. Ціна за повторне використання коду та інтеграцію коду була високою, проте ніхто з розробників поодинці не міг втілити в реальність широко використовуваний, мовно-незалежний стандарт, який включає в себе підтримку складних багато зв'язних додатків. У травні 1989 р. була сформована OMG (Object Management Group). Нині OMG нараховує більше 700 членів (до OMG входять практично всі найбільші виробники програмного забезпечення (ПЗ), за виключенням Microsoft). Задачею консорціуму OMG є визначення набору специфікацій, які дають змогу будувати інтероперабельні інформаційні системи. Специфікація OMG - The Common Object Request Broker Architecture (CORBA) є індустріальним стандартом, який описує високо рівневі засоби підтримки взаємодії об’єктів в розподілених гетерогенних середовищах. CORBA специфікує інфраструктуру взаємодії компонент (об’єктів) на представницькому рівні і на рівні додатків моделі OSI. Вона дає розглядати всі додатки в розподіленій системі як об’єкти. причому об’єкти можуть одночасно відігравати роль клієнта та сервера: роль клієнта, якщо об’єкт є ініціатором виклику на ньому який-небудь метод. Об’єкти-сервери зазвичай називають "реалізацією об’єктів". Практика показує, що більшість об’єктів одночасно виконують роль клієнтів і серверів, по черзі викликаючи методи на інших об’єктах і відповідаючи на виклику ззовні. ВикористовуючиCORBA, тим самим , є можливість будувати більш гнучкі системи, ніж системи клієнт-сервер, основані на дворівневій і трирівневій архітектурі.

Мова OMG IDL (Interface Definition Language - Мова Опису Інтерфейсу) представляє собою технологічно незалежний синтаксис для опису інтерфейсу об’єктів. При описі програмної архітектури, OMG IDL добре використовується як універсальна нотація для окреслювання границь об’єкту, які визначають його поведінку у відношенні до інших компонентів ІС. OMG IDL дає змогу описати інтерфейси, які мають різні методи та атрибути. Мова також підтримує дослідження інтерфейсів, що необхідно для повторного використання об’єктів з можливістю їх розширення чи конкретизації. IDL є чисто декларативною мовою, тобто вона не містить ніякої реалізації. IDL - специфікації можуть бути відкомпільовані (відображені) в заголовкові файли та спеціальні прототипи серверів, які можуть використовуватися безпосередньо програмістом. Тобто IDL - визначені методи можуть бути написані, і далі виконані, на будь-якій мові, для якої існує відображення з IDL. До таких мов відносяться С, С++, SmallTalk, Java та Ada.

 

Рисунок 4.17 - CORBA IDL відображення в моделі Клієнт/Сервер

 

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

 

Лістинг 4.1 – Структура CORBA IDL файлу

module <identifier> {
<type declarations>;
<constant declarations>;
<exception declarations>;
interface <identifier> [:<inheritance>] {
<type declarations>;
<constant declarations>;
<attribute declarations>;
<exception declarations>;
[<op_type>]<identifier>(<parameters>)
[raises exception] [context]
.
.
[<op_type>]<identifier>(<parameters>)
[raises exception] [context]
.
.
}
interface <identifier> [:<inheritance>]
.
.
}

 

Репозитарій Інтерфейсів (Interface Repository), який містить означення інтерфейсів на IDL, дає змогу бачити інтерфейси доступних серверів в мережі і програмувати їх використання в програмах-клієнтах.

Object Management Architecture. Восени 1990 р. OMG вперше опублікувала документ Object Management Architecture Guide (OMA Guide).Він був відкоригований у вересні 1992 р. Деталі Common Facilities (Спільні засоби) були добавлені в січні 1995 р. На рис. 4.18 показані чотири основні елементи цієї архітектури:

 

OMG's Object Management Architecture

Рисунок 4.18 - OMG’s Object Management Architecture

 

1.  Object Request Broker визначає об’єктну шину CORBA.

2.  Common Object Services представляють собою колекцію служб, споряджених об’єктивними інтерфейсами, які забезпечують підтримку базових функцій об’єктів.

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

4.  Application Objects - це прикладні бізнес-об’єкти і додатки, які є основними споживачами всієї CORBA інфраструктури.

ORB, Object Request Broker (брокер об’єктних запитів) - це об’єктна шина, яка дає змогу об’єктам напряму виробляти і відповідати на запити інших об’єктів, розташованих як локально (на одному комп’ютері, але в різних процесах), так і віддалено. Клієнта не цікавлять комунікаційні та інші механізми, з використанням яких відбувається взаємодія між об’єктами, виклик і збереження серверних компонентів.CORBA - специфікації зачіпають лише IDL, відображення в інші мови, APIs для взаємодії з CORBA та сервіси, які надаються ORB. CORBA ORBне надає широкого набору розподілених middleware (проміжних) послуг. Шина ORB дає змогу об’єктам знаходити один другого прямо в процесі роботи і викликати один у другого різноманітні служби. Вона є набагато тоншою системою, порівняно з іншими клієнт/сервер middleware - системами, такими, як RPC (Remote Procedure Calls) чи MOM (Message-Oriented Middleware).

Шлях від RPC до ORBСтосовно відмінності механізму викликів CORBA та RPC можна сказати наступне. Ці механізми схожі, але між ними є серйозні відмінності. З використанням RPC можна викликати певну функцію, а з використанням ORB можна викликати метод у певного об’єкта. Різні об’єкти класів можуть по-різному відповідати на виклик одного і того ж методу. Оскільки кожний об’єкт управляє своєю власною (на додаток - особистою) інформацією, то метод буде викликаний на сугубо конкретних даних. У випадку RPC, буде виконана лише якась конкретна частина коду сервера, яка і взаємодіє з даними сервера. Всі функції з однаковими іменами будуть виконані абсолютно однаково. В RPC відсутня конкретизація викликів, в тому розумінні, в якому це відбувається в ORB. В ORB всі виклики функцій здійснюються до конкретних об’єктів, тим самим, результати цих функцій можуть бути абсолютно різними. Виклики функцій обробляються в специфічній для кожного окремого об’єкта формі.

Переваги ORB. Теоретично CORBA визначається як краща клієнт/сервер middleware - система, але на практиці вона задовільна лише настільки, наскільки задовільні продукти, що її реалізують. До основних комерційних ORB відносяться Orbix від фірми IONA Technologies;DSOM від IBM; Object Broker від Digital; JOE від Sun; Visibroker від Visigenic та Netscape; ORB+ від HP. Переваги кожної CORBA ORB такі:

-    Статистичні та динамічні виклики методів. CORBA ORB надає можливість або статично визначити виклики методів прямо під час компіляції, або знаходити їх динамічно, але вже під час роботи програми.

-    Відображення та мови високого рівня. CORBA ORB дає змогу викликати методи у серверних компонент,використовуючи будь-який з певного списку мов високого рівня - С, С++, SmallTalk, Java, Ada. Абсолютно неважливо, на якій мові написані об’єкти. CORBA відділяє інтерфейси від реалізації і надає мово незалежні типи даних, що дає змогу здійснювати виклик методів, минаючи границі якоїсь мови програмування та конкретної операційної системи.

-    - Система, що само описується. З використанням своїх метаданих, CORBA дає змогу описувати інтерфейс будь-якого сервера, відомого системі. Кожна CORBA ORB повинна підтримувати Репозитарій Інтерфейсів, який зберігає необхідну інформацію, яка описує синтаксис інтерфейсів, підтримуваних серверами. В своїй роботі клієнти використовують ці метадані для здійснення викликів до серверів.

-    - Прозорість. ORB може виконуватися як сам собою (наприклад, на портативному комп’ютері), оскільки в оточенні всіх інших ORB, з якими вона взаємодіє шляхом CORBA 2.0 ІІОР (Internet Inter- ORB Protocol) протоколу. ORB може здійснювати між об’єктну взаємодію також для одного процесу, як і для кількох процесів, які виконуються на одній машині, та для процесів , виконання яких відбувається в мережі, під різними операційними системами. Реалізація цих взаємодій ніяк не зачіпає самі об’єкти. При використанні технології CORBA, розробник не має турбуватися про розташування серверів, запуск (активування) об’єктів, вирівнювання розміру змінних в залежності від платформи та операційної системи, та про те, як здійснюється передача повідомлень. Рішення всіх цих задач бере на себе продукт, який підтримує стандарт CORBA.

-    Вбудована безпека. Всі свої запити ORB доповнює певною контекстною інформацією, яка забезпечує збереження даних.

-    Поліморфізм при виклику методів. ORB не просто викликає віддалений метод - ORB викликає метод на віддаленому об’єкті. Тобто виконання одних і тих же функцій на різних об’єктах призведуть до різних дій, в залежності від типу об’єкта.

Object Services. CORBA Object Services представляє собою набір сервісів системного рівня, які зображуються у вигляді компонентів з певними визначеними IDL - інтерфейсами. Ці компоненти доповнюють функціональність ORB, їх можна використати для створення, іменування компонентів, та ін. Нині OMG визначає 14 стандартних сервісів. Практично всі комерційні ORB не підтримують жодного із сервісів, і тільки небагато з них (Visibroker) - тільки один, два.

Common Facilities. Common Facilities (спільні засоби) заповнюють простір між ORB та об’єктивними службами з одного боку, та прикладними службами, з іншої. Тобто ORB забезпечує базову інфраструктуру, Object Services - фундаментальні об’єктивні інтерфейси, а задачаCommon Facilities - підтримка інтерфейсів сервісів високого рівня, які можуть включати спеціалізацію Object Services. Тобто операції, представлені Common Facilities, призначені, зокрема, для використання Object Services та прикладними об’єктами. Це реалізується шляхом наслідування стандартних Інтерфейсів. Спільні засоби поділяються на горизонтальні та вертикальні. До горизонтальних сервісів відносяться такі спільні сервіси, як, наприклад, управління інформацією, задачами, всією системою, тобто засоби, які не залежать від конкретних прикладних систем. До вертикальних сервісів відносяться сервіси, специфічні для якоїсь діяльності, наприклад, медицина, фінанси.

Application Objects. Об’єкти, якщо вони приймають участь в обміні з ORB з використанням IDL. Як правило, додатки складаються з кількох бізнес-об’єктів, що взаємодіють. Додатки-об’єкти будуються поверх ORB, які надаються ORB, Common Facilities та Object Facilitiesсервісів. Сутність для замовників (або системних інтеграторів) полягає в тому, щоб зібрати різні бізнес-об’єкти до одної системи, причому, поза залежністю від виробника.

CORBA та WWW. Відповідь на поставлене раніше питання - як об’єднати ІС, засновані на технології WWW, з іншими (в тому числі розподілені) ІС - полягає в наступному: слід пов’язати технологію розподілених об’єктів (тобто технологію CORBA) з технологією WWW. Метою такої роботи є детальний розгляд зв’язки CORBA та WWW. Питання впровадження CORBA в ІС виходить за рамки курсу. Є два рішення такої задачі, перше - будується на застосуванні технології CGI, а друге - на застосуванні технології Java. Досліджено практичне застосування цих технологій, з використанням продуктів Orbix та OrbixWeb від IONA Technologies.

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

 

Рисунок 4.19 - CGI та CORBA

 

До переваг цієї технології можна віднести практично всі переваги використання CORBA. Крім того, користувач працює із звичними для нього HTML - сторінками, що особливо важливо при роботі з об’ємною текстовою інформацією. Стосовно недоліків цієї технології, практика свідчить, що це невелика ефективність системи. Кожного разу при пере завантаженні сторінки слід заново виконувати CGI - скрипт, заново встановлювати з’єднання з іншими компонентами системи. Це неефективно, що особливо виявляється, коли система одночасно використовується кількома користувачами. З іншого боку, не жертвуючи ефективністю, неможливо своєчасно повідомляти користувача про зміни, які відбулися в інформації, яка ним проглядається. Вони будуть помітними лише за умови пере завантаження сторінки. Тобто користувач приймає участь в системі виключно в ролі клієнта. Окремим рішенням проблеми ефективності виконання CGI - запитів (особливо в багатокористувацькій системі), може бути розширення функціональності використовуваного WEB - сервера, шляхом добавлення до нього відповідних функцій. В цьому напрямку здійснена робота з вбудовуванню до WEB - сервера Apache (платформи SunOS, Windows NT) підтримки звернення до Orbix ORB. Складності також виникають в разі створення, складних гілкуватих користувацьких інтерфейсів. Справа в тому, що в системі, за умови виконання запитів окрім введеної у вікно браузера інформації, необхідна додаткова, скрита від користувача, яка характеризує поточний стан система інформація. Вся інтерфейсна частина системи прив’язана до вікна браузера, а та, яка виводиться на екран інформація створюється динамічно в залежності від параметрів запиту та внутрішнього стану інформаційної системи на певний момент часу. Внаслідок цього, якщо користувач виконує неконтрольовану навігацію вперед-назад за сторінками, що проглядаються, підвищується ризик десинхронізації інформації, яка проглядається користувачем і зберігається на сервері, що не є припустимим. Більше того, система повинна слідкувати і за тим, щоб вільні переходи від сторінки до сторінки мали б логічний смисл, що важливо. Тим самим, у випадках складних користувацьких інтерфейсів необхідна наявність жорсткого контролю за поточним станом ІС.

Java-CORBA. Друге рішення проблеми зв’язування технологій CORBA та WWW - мова Java, рис. 4.20. Справа в тому, що OMG стандартизувала відображення з IDL в Java. Є програмні продукти, які реалізують зв’язок CORBA та Java - наприклад, Java Virtual Machine (JVM), всередині якої і виконується завантажений аплет.

 

Рисунок 4.20 - Java та CORBA

 

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

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

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

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

В CORBA існують два різних типи передачі повідомлень - механізм PUSH та механізм PULL .

Механізми PUSH та PULL. Механізм PULL, рис. 4.21, представляє собою наступне: коли клієнт готовий обробляти повідомлення, він опитує сервер на наявність у нього нових повідомлень. Якщо таких немає, то клієнт через певний проміжок часу повторює операцію. В залежності від контексту розв’язуваної задачі та пропускних здатностей мережних каналів, тип взаємодії клієнта та сервера може бути асинхронним та синхронним. Механізм PUSH, в певному розумінні, протилежний механізму PULL. В цьому випадку сервер повідомлень сам, у міру надходження нових повідомлень, буде інформувати про це клієнтів. Тобто клієнти самі є серверами, а сервер повідомлень лише викликає в них відповідні методи, "вштовхуючи" їм повідомлення. Як і в моделі PULL, взаємодія клієнта та сервера повідомлень може бути асинхронною та синхронною.

 

Рисунок 4.21 - Механізми PULL та PUSH

 

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

В моделі PUSH сервер повідомлень завантажений помітно менше. Сервер звільнений від необхідності регулярно реагувати на виклики клієнтів, які очікують. Тепер він взаємодіє з клієнтами-слухачами. "Виштовхування" повідомлень клієнту застосовується особливо в тих випадках, коли повідомлення, які з’явилися на сервері повідомлень, повинні бути негайно оброблені клієнтом (клієнтами). За наявності неякісного зв’язку між вузлами, механізм PUSH набагато більше рентабельний, порівняно з PULL - він використовує канал лише один раз для кожного клієнта. За умови реальних розробок ІС, мають місце обидва представлених способи взаємодії компонентів. Розумна комбінація компонент ІС, які підтримують PUSH/ PULL моделі обміну повідомленнями, дає змогу досягнути високого рівня гнучкості та продуктивності створюваної ІС.

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

Застосування технологій Java-CORBA та CORBA-CGI. Практика свідчить, що технологія Java-CORBA краще за все підходить для створення WWW CORBA-клієнтів, які: мають нестандартний, або не HTML - подібний користувацький інтерфейс; активно взаємодіє з іншими компонентами ІС протягом часу; повинні приймати участь в системі в ролі клієнта, та в ролі сервера. Технологію CORBA-CGI вигідно застосовувати у випадку, якщо: відбувається робота з великими обсягами текстової інформації; системні ресурси на стороні клієнта малопотужні. Незважаючи на те, що переваги технології Java-CORBA над технологією CORBA-CGI значні, і область застосування ширша, обидві розглянуті технології добре підходять для об’єднання WWW - систем та клієнт/сервер - систем. Технологія CORBA-CGI розширює можливості CGI, а технологія Java-CORBA можливості всього WWW - до рівня розподілених об’єктних систем.

Тобто нині технології Java та CORBA добре доповнюють одна іншу як потужний і універсальний засіб для захисту проблеми об’єднання систем, які базуються на технології WWW, з подібними та іншими, особливо розподіленими, ІС. Проте з’являється нова технологія DCOM (Microsoft), яка сильно потіснила CORBA з ринку Windows - орієнтованих систем. Технологія RMI, навпаки, робить кроки назустріч CORBA. Починаючи з JDK 1.2, протокол RMI буде виконуватися поверх протоколу IIOP, що вигідно Java та CORBA розробникам. Масове використання технології Java-CORBA виведе Internet на новий рівень взаємодії. В такий спосіб відбудеться перехід від Web до нової, об’єктної мережі – Object Web.

5.1 Основні положення

 

Інфраструктура безпеки GRID (Grid Security Infrastructure – GSI) забезпечує безпечну роботу в незахищених мережах загального доступу (Інтернет), надаючи такі сервіси, як аутентифікація, авторизація, конфіденційність передачі інформації і єдиний вхід в GRID-систему. Під єдиним входом мається на увазі, що користувачеві потрібно лише один раз пройти процедуру аутентифікації, а далі система сама поклопочеться про те, щоб аутентифікувати його на всіх ресурсах, якими він збирається скористатися. GSI заснована на надійній і широко використовуваній інфраструктурі криптографії з відкритим ключем (Public Key Infrastructure – PKI).

Як ідентифікатори користувачів і ресурсів в GSI використовуються цифрові сертифікати X.509. У роботі з сертифікатами X.509 і в процедурі видачі/отримання сертифікатів задіяно три сторони:

-    Центр Сертифікації (Certificate Authority – CA) – спеціальна організація, що володіє повноваженнями видавати (підписувати) цифрові сертифікати. Різні CA зазвичай незалежні між собою. Відносини між CA і його клієнтами регулюються спеціальним документом.

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

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

-    У GSI використовуються два типи сертифікатів X.509:

-    Сертифікат користувача (User Certificate) – цей сертифікат повинен мати кожен користувач, що працює з GRID-системою. Сертифікат користувача містить інформацію про ім'я користувача, організацію, до якої він належить, і центр сертифікації, що видав даний сертифікат.

-    Сертифікат вузла (Host Certificate) – цей сертифікат повинен мати кожен вузол (ресурс) GRID-системи. Сертифікат вузла аналогічний сертифікату користувача, але в нім замість імені користувача указується доменне ім'я конкретного обчислювального вузла.

 

5.2. Вимоги безпеки

 

GRID пред'являє ряд вимог по безпеці, деякі з них приведені нижче.

Множинні інфраструктури безпеки

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

Системи безпеки периметру

Багато завдань вимагають, щоб додатки могли використовуватися і поза власним firewall’ом. Колаборація InterGrid часто вимагає перетину зон дії firewall’ів різних організацій. OGSA потрібно стандартизувати безпечні механізми взаємодії firewall’ів.

Ідентифікація, авторизація і аккоунтинг

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

Шифрування

ІТ інфраструктура і її управління вимагає шифрування комунікацій, принаймні найосновніших.

 

Firewall’и мережевого рівня і додатку

Це давня проблема. Особливо складною її робить величезна кількість правив і умов, а також різні обмеження на міжнародних сайтах.

Сертифікація

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

 

5.3 Інфраструктура захисту Grid (GSI)

 

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

 

5.3.1 Фундаментальні поняття захисту

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

-    Практическая Криптография. Bruce Schneier. John Wiley & Sons, 2003. http://www.schneier.com/book-practical.html

-              Прикладная Криптография. Bruce Schneier. John Wiley & Sons, 1996. http://www.schneier.com/book-applied.html

5.3.1.1 Безпечна комунікація

Фахівці в області захисту даних комп'ютера часто вважають, що “безпечна комунікація” – це просто будь-яка комунікація, де кодуються дані. Проте захист містить в собі набагато більше, ніж просто кодування і розшифровка даних.

Три ключові елементи безпечної комунікації

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

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

Конфіденційність

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

Наприклад, припустимо, що потрібно передати повідомлення “INVOKE METHOD ADD”, і необхідна упевненість, що якщо третя сторона перехопить це повідомлення (наприклад, використовуючи мережевий сніфер), вона не зможуть його розібрати. Можна використовувати звичайний алгоритм кодування, який просто змінює кожну букву на наступну в алфавіті. Кодоване повідомлення було б “JOWPLFANFUIPEABEE” (припустимо, що “A” слідує після символу пропуск). Якби третя сторона знала використовуваний алгоритм кодування, повідомлення не мало б сенсу. З іншого боку одержуюча сторона знала б алгоритм розшифровки заздалегідь (змінивши кожну букву напопередню в алфавіті) і тому могла розібрати повідомлення. Звичайно, цей метод тривіальний, і в даний час алгоритми кодування набагато більш ускладнені. Деякі з таких алгоритмів будуть розглянуті нижче.

Цілісність

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

Традиційні алгоритми кодування не захищають від такого роду атак. Наприклад, розглянемо простій алгоритм, який був запропонований вище. Якщо третя сторона використовувала мережевий сніфер, щоб змінити кодоване повідомлення на “JAMJAMJAMJAMJAMJA”, одержуючасторона використовувала б алгоритм розшифровки і отримала повідомлення “I LI LI LI LI LI “. Хоча атакуюча сторона, можливо, не мала б ніякого поняття, що повідомлення містить, але, проте, могла змінити його (відносно просто для деяких мережевих інструментів сніферів). Так легко ввести в оману одержуючу сторону, яка могла б сприйняти це як помилку в комунікації. Алгоритми криптографії загального ключа (буде коротко розглянутий далі) захищають від видів нападів (одержуюча сторона має спосіб дізнатися, якщо отримане повідомлення послане передавальною стороною і, таким чином, не було змінено).

Аутентифікація

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

5.3.1.2 Авторизація

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

Наприклад, як тільки буде з'ясовано, що користувач входить до складу Відділу Математики, потрібно буде потім дозволити йому звернутися до всіх Мат. служб. Проте, можливо, йому заборонили б звертаються до інших служб, що не пов'язані з його відділом (BiologyService,ChemistryService, і тому подібне)

5.3.1.3 Авторизація порівняно з Аутентифікацією

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

5.3.1.4 Введення в криптографію

Криптографія – “мистецтво запису в секретних символах”. Кодування – дія перекладу нормального повідомлення в повідомлення, записане з “секретними символами” (також відоме як кодоване повідомлення).

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

Алгоритми засновані на ключі

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

Алгоритм заснований на ключі використовує ключ кодування, щоб кодувати повідомлення. Це означає, що кодоване повідомлення генерується, використовуючи не тільки повідомлення, але і, використовуючи “ключ” (Рисунок 5.1)

 

Рисунок 5.1 – Кодування засноване на ключі

 

Одержувач може потім використовувати ключ розшифровкищоб розшифрувати повідомлення. Знову-таки, це означає, що алгоритмрозшифровки залежить не тільки від кодованого повідомлення. Також буде потрібно “ключ” (Рисунок 5.2).

 

Рисунок 5.2 – Розшифровування заснована на ключі

 

Деякі алгоритми використовують один ключ для кодування і розшифровки, а інші різні. Про різні ключі буде розказано нижче.

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

 

1 2 3 4 5 6 5 4 3 2 1

 

Виберемо ключ, який використовуватиметься для кодування повідомлення. Імовірно ключ буде “4232”. Щоб кодувати повідомленняпотрібно буде повторювати ключ, стільки скільки необхідно, для “покриття” цілого повідомлення:

 

1 2 3 4 5 6 5 4 3 2 1

4 2 3 2 4 2 3 2 4 2 3

 

Кодування повідомлення з додаванням обох номерів:

 

1 2 3 4 5 6 5 4 3 2 1

+ 4 2 3 2 4 2 3 2 4 2 3

-----------------------

5 4 6 6 9 8 8 6 7 4 4

 

Результуюче повідомлення (54669886744) – закодоване повідомлення. Повідомлення може бути розшифровано слідуючи зворотному процесу: повторюючи ключ, стільки раз скільки потрібно, щоб покрити повідомлення, а потім відняти кожен з символів ключа:

 

5 4 6 6 9 8 8 6 7 4 4

- 4 2 3 2 4 2 3 2 4 2 3

-----------------------

1 2 3 4 5 6 5 4 3 2 1

 

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

Слід зазначити, що це дуже тривіальний приклад. Поточні алгоритми, засновані на ключі, набагато складніші (ключі набагато довші, і процес кодування не такий простий, як “додавання повідомлення і ключа”). Проте ці складні алгоритми засновані на тому ж основному принципі, показаному в нашому прикладі: ключ потрібний, щоб кодувати/розшифрувати повідомлення.

Симетричні і асиметричні алгоритми, засновані на ключі

Алгоритм прикладу підпадає в категорію симетричних алгоритмів. Цей тип алгоритму використовує один ключ для кодування ірозшифровки (Рисунок 5.3).

 

Рисунок 5.3 – Симетричний алгоритм, заснований на ключі

 

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

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

Криптографія загального ключа

Алгоритми загального ключа – асиметричні алгоритми і, тому, засновані на використанні двох різних ключів, замість одного. У криптографії загального ключа, ключі називають приватний ключ і загальний ключ

-    Приватний ключ: Цей ключ повинен знати тільки його власник.

-    Загальний ключ: Цей ключ відомий кожному (він загальний).

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

Безпечний діалог, з використанням криптографії загального ключа

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

 

Рисунок 5.4 – Асиметричний алгоритм заснований на ключі

 

Переваги і недоліки систем, заснованих на загальному ключі

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

 

Рисунок 5.5 – Генерація загального ключа

 

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

Основний недолік використання систем з відкритим ключем в тому, що вони не так швидкі як симетричні алгоритми.

5.3.1.5 Цифрові підписи: Цілісність в системах з відкритим ключем

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

 

Рисунок 5.6 – Цифровий підпис

 

Цифровий підпис для повідомлення генерується на двох етапах:

-    Генерується Резюме повідомлення. Резюме повідомлення – короткий звіт передаваного повідомлення, має дві важливі властивості: (1) Він завжди менший, ніж повідомлення безпосередньо (2) Навіть найлегша зміна в повідомленні проводить різне резюме. Резюме повідомлення генерується з використанням безлічі алгоритмів хешування.

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

Цифровий підпис прикріпляється до повідомлення, і відправляється одержувачеві. Одержувач потім виконує наступне:

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

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

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

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

5.3.1.6 Аутентифікація в системах із загальним ключем

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

Деякі сценарії захисту, можливо, допускали б, що “Слабка аутентифікація”, показана в попередньому прикладі, достатня. Проте, інші сценарії, можливо, вимагали б, щоб не було абсолютне ніякого сумніву відносно особи користувача. Це досягається за допомогою цифрових сертифікатів.

5.3.1.7 Сертифікати і центри сертифікації (CA)

Цифровий сертифікат – це цифровий документ, який засвідчує, що певний загальний ключ належить конкретному користувачеві. Сертифікат підписує третя сторона іменована центр сертифікації (або CA). Рисунок 5.7 ілюструє, що є цифровим свідоцтвом.

 

Рисунок 5.7 – Цифровий сертифікат

 

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

Тому, можемо перевірити цілісність сертифікату, використовуючи загальний ключ CA.

5.3.1.8 Довіра

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

Проте все це вірно, якщо ви довіряєте сертифікату. Щоб бути точніше, вам доведеться довіряти CA який підписує сертифікат. Немає ніяких хитромудрих алгоритмів, щоб вирішити, коли CA надійний, ви повинні вирішити для себе, довіряєте ви CA чи ні. Це означає, що використовувана система з відкритим ключем буде, загалом, мати список “довірених CA”, який включає цифрові сертифікати довірених CA(кожен сертифікат, у свою чергу, містить загальний ключ CA для перевірки цифрового підпису).

Потрібно буде вирішити який CA включити в цей список. Деякі CA добре відомі і їх включають за умовчанням в багатьох системах із загальним ключем (наприклад, веб-навігатори зазвичай включають VeriSign (http://www.verisign.com) і GlobalSign (http://www.globalsign.com) сертифікати, тому що багато веб-вузлів використовують сертифікати, випущені цими компаніями. Звичайно, є можливість додати і інший CA до “Довіреного списку”. Наприклад, якщо ваш відділ встановлює CA, і ви довіряєте, що CA відділ видаватиме свідоцтва тільки надійним людям, тому ви можете додати його до списку.

5.3.1.9 Формат сертифікату X.509

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

-    Суб'єкт: Це ім'я користувача. Воно кодується як видатне ім'я (формат для різних імен буде пояснений далі).

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

-    Запрошуюча сторона: видатне ім'я CA.

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

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

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

5.3.1.10 Видатні імена

Імена в сертифікатах X.509 не кодуються просто як “загальні імена”, як наприклад “Borja Sotomayor, “Lisa Childers”, “Центр сертифікаціїXYZ”, або “Системний Адміністратор”. Вони кодуються, як видатні імена, які є списком пар значення імені відокремленими комою. Розглянемо приклад з видатними іменами:

O=University of Chicago, OU=Department of Computer Science, CN=Borja Sotomayor

O=Argonne National Laboratory, OU=Mathematics and Computer Science Division, CN=Lisa Childers

Що означають “O”, “OU”, і “CN”? Видатне ім'я може мати декілька різних атрибутів, ось основні з них:

-    O : Організація

-    OU : Організаційний Підрозділ

-    CN : Загальне Ім'я (загалом, ім'я користувача)

-    C : Країна

5.3.1.11 Ієрархії CA

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

 

Рисунок 5.8 – Ланцюг перевірки сертифікату

 

На малюнку сертифікат Borja підписує центр сертифікації FOO. Сертифікат центру сертифікації FOO, у свою чергу, підписується центром сертифікації BAR. Нарешті, сертифікат BAR підписує сам себе.

Якщо ви отримуєте сертифікат Borja, і явно не довіряєте CA FOO (запрошуюча сторона сертифікату), це не означає, що сертифікат не надійний. Ви, можливо, перевірили б, що сертифікат CA FOO випустив CA, якому ви довіряєте. Якщо з'ясується що CA BAR знаходиться у вашому “довіреному списку”, це означатиме, що свідоцтво Borja надійно.

Проте зверніть увагу, що CA (BAR) вищого рівня підписав свій власний сертифікат. Це цілком нормально, і називається само-підписанимсертифікатом. CA з само-підписаним сертифікатом називається кореневий CA, тому що немає нікого вище. Щоб довірити сертифікату, підписаному цим CA, він повинен обов'язково бути у вашому “довіреному списку” CA.

 

5.3.2 Введення в GSI

Інфраструктура Grid є основою для рівня захисту GT4. Захист – одна з найголовніших частин додатку Grid. Оскільки grid має на увазі перетин меж організації, ресурси стають доступними для інших організацій. Це формулює багато вимог:

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

Наприклад, організація AliceOrg просить BobOrg виконати певне завдання. BobOrg, з іншого боку, усвідомлює, що завдання потрібноделегувати до організації CharlieOrg. Проте можна вважати, що CharlieOrg довіряє тільки AliceOrg (але не BobOrg). Чи повинен CharlieOrgвідкинути запит, тому що він виходить від BobOrg, або приймати його, оскільки початковий прохач AliceOrg?

Залежно від додатку, можливо, також є зацікавленість в цілісності даних і конфіденційності, хоча в grid- застосуванні це, загалом, не так важливо як аутентифікація.

Інструментарій Globus 4 дозволяє долати проблеми захисту, сформульовані grid-додатками через Інфраструктуру Захисту Grid (або GSI).GSI складається з набору інструментів командного рядка для управління сертифікатами, і безліччю класів Java для легкого об'єднання захисту увеб-службах. GSI пропонує програмістам наступні характеристики:

-    Захист транспортного рівня і рівня повідомлень;

-    Аутентифікація через цифрові сертифікати X.509;

-    Різні схеми авторизації;

-    Делегація посвідчення особи і єдиний вхід (sign-on);

-    Різні рівні захисту: контейнер, обслуговування, і ресурс

5.3.2.1 Захист транспортного рівня і рівня повідомлень

Транспортний рівень використовує TLS – Transport Layer Security (SSL – Secure Sockets Layer). Рівень повідомлень має дві реалізації, засновані на різних стандартах: WSSecurity і WS-SecureConversation. При встановленні з'єднання по WS-SecureConversation визначається, так званий, контекст безпеки (secure context). Після ініціалізації обміну повідомленнями всі подальші повідомлення використовують цей контекст безпеки. Крім того, на відміну від WS-Security, WS-SecureConversation забезпечує анонімну аутентифікацію і делегування має рацію.

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

 

 

Рисунок 5.9 Захист транспортного рівня

 

 

Рисунок 5.10 – Захист рівня повідомлень

 

Як транспортний рівень, так і захист рівня повідомлень в GSI засновані на криптографії “відкритого ключа” (public-key) і, тому, може гарантувати конфіденційність, цілісність, і аутентифікацію. Проте не всім зв'язкам буде потрібно всі три характеристики. Взагалі, безпечний діалогGSI повинен як мінімум бути засвідчений. Цілісність бажана зазвичай, але може бути відключена. Кодування також може бути активізоване, щоб гарантувати конфіденційність.

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

GSI пропонує дві схеми захисту рівня повідомлень, і одна схема для транспортного. Відмінності між ними представлені в таблиці.№3.

-    Безпечне Повідомлення GSI: Забезпечує захист рівня повідомлень і засновано на запропонованому стандарті WS-Security.

-    Безпечний Діалог GSI: Забезпечує захист рівня повідомлень і заснований на специфікації WS-SecureConversation. Якщо вибраний цей метод, встановлюється контекст безпеки (secure context) між клієнтом і сервером. Після початкового обміну повідомленнями, щоб встановити контекст, всі наступні повідомлення зможуть використовувати цей контекст багато разів, що приводить до кращої роботи, чим Безпечне Повідомлення GSI (якщо верх установки контексту прийнятний). До того ж, Безпечний Діалог GSI – це схема, яка підтримує тільки делегацію посвідчення особи.

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

Ці схеми не взаємовиключні. Наприклад, передбачається використовувати Безпечний Діалог GSI, тому що додаток вимагає делегації, а потім додається Транспорт GSI тому що потрібно кодувати всю комунікацію (не тільки частину повідомлення SOAP). Важливо відзначити, що це не приводить до надмірності, оскільки можна конфігурувати Транспорт GSI для використання кодування і Безпечний Діалог GSI (без кодування).

 

Таблица 5.1 – Порівняння захисту транспортного рівня і рівня повідомлень

 

Безпечний Діалог GSI

Безпечне повідомлення GSI

Технологія

WS-SecureConversation

WS-Security

Конфіденційність (Кодируется)

так

так

Цілісність (Підписано)

так

так

Анонімнааутентифікація

так

ні

Делегація

так

ні

Робота

Хороша, якщо пересилається багато повідомлень

 

Хороша при невеликій пересилці повідомлень

 

 

 

 

5.3.2.2 Аутентифікація

Для вирішення аутентифікації і авторизації, необхідна наявність в системі центрів сертифікації (CA), а для крупних, територіально розподілених систем також і центру реєстрації (або інституту реєстраторів). Завдання CA – перевірити приналежність сертифікату даному індивідуумові. Кожен сертифікаційний центр проводить свою політику, яка визначає правила створення і підписання сертифікатів. GSI підтримує три аутентифікаційні методи:

Сертифікати X.509: Всі три схеми захисту, що вище перераховані, можуть використовуватися разом з сертифікатом X.509, щоб забезпечитипокращувану аутентифікацію.

Ім'я користувача і пароль: Більш рудиментарна форма аутентифікації, імена користувача і паролі можуть також використовуватися. Проте, використовуючи імена користувача і пароль, не можна буде використовувати можливості конфіденційності, цілісності, і делегації.

Анонімна аутентифікація: Можна запитати, щоб комунікація була анонімною, або не засвідченою. Анонімність, загалом, має сенс, коли використовується більш ніж одна схема захисту. Наприклад, можна використовувати Безпечний Діалог GSI (засвідчено з сертифікатами X.509) іанонімний Транспорт GSI, так щоб не виконувати додаткову (надмірну) аутентифікацію.

Примітка: Оскільки не засвідчені зв'язки зазвичай не використовуються, література Globus, загалом, використовує термін методиаутентифікації, щоб послатися безпосередньо на Безпечний Діалог GSI, Безпечне Повідомлення GSI, і Транспорт GSI.

5.3.2.3 Авторизація

Хоча авторизація не є одним з “Фундаментальних стовпів” безпечного діалогу, вона, проте, складає важливу частину GSI. Авторизація відзначає, хто уповноважений виконувати певне завдання. У контексті веб-служб украй важливо знати, хто уповноважений використовувати визначену веб-службу.

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

Авторизація серверної сторони

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

None: Це найпростіший вид авторизації. В цьому випадку авторизація не виконуватиметься.

Self: Клієнтові дозволяється скористатися службою, якщо є тотожність клієнта і послуги.

Gridmap: “Gridmap” – список “зареєстрованих користувачів” який схожий з ACL (Список Контролю Доступу). При використанні цього виду авторизації, тільки перераховані в “gridmap” користувачі можуть її викликати.

Identity authorization: Клієнт може звернутися до обслуговування, якщо особа клієнта відповідає вказаній особі. Це подібно до наявностіоднокористувацьког “gridmap”, за винятком авторизації особи, яка конфігурується програмно, оскільки “gridmap” представлений як файл в системі.

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

SAML Callout authorization: Можна делегувати вирішення авторизації до OGSA (сумісна служба авторизації). OGSA-Authz(http://forge.gridforum.org/projects/ogsa-authz) – робоча група GGF, чия мета – конкретизувати стандартні компоненти авторизації. Одна з основних технологій, використовуваних в цих компонентах, – SAML (Мова Затвердження Підвищення Захисту).

Авторизація клієнтської сторони

Авторизація клієнтської сторони дозволяє клієнтові з'ясовувати, коли можна буде викликати службу. Може здатися, що це не коректнийвид авторизації, оскільки авторизація, загалом, є видимою з сервера. Режими авторизації клієнтської сторони:

None: Авторизація не виконуватиметься.

Self: Клієнт авторизує виклик, якщо особа служби співпадає з особою клієнта.

Identity authorization: Як викладено вище, клієнт тільки допустить відправку запитів до служб вказаній ідентичності.

Host: Клієнт авторизує виклик, якщо служба має посвідчення особи хоста. До того ж, клієнт повинен бути здатний вирішити адресу вузла до імені хоста, вказаного в посвідченні особи вузла.

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

Custom” авторизація

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

Делегація і єдиний вхід (проксі-сертифікати)

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

 

Рисунок 5.11 – Сценарій, де необхідна делегація

 

AliceOrg просить BobOrg виконати завдання. Оскільки BobOrg довіряє AliceOrg вона погоджується виконати завдання. Припустимо, що завдання Z дуже складне, і що одну з його підзадач (Y) повинна виконати третя організація: CharlieOrg. В даному випадку, BobOrg запитаєCharlieOrg виконати subtask Y, але запит не буде виконаний, оскільки CharlieOrg довіряє тільки AliceOrg. CharlieOrg може виконати дві дії:

-    Відкинути запит BobOrg. CharlieOrg не довіряє BobOrg, от і все.

-    Прийняти запит BobOrg. Справжня запрошуюча сторона AliceOrg, хоча CharlieOrg відповідає на запит від BobOrg, вона фактично здійснюватиме завдання для AliceOrg.

У цій ситуації логічно буде, якщо CharlieOrg прийме запит BobOrg. Проте CharlieOrg повинна знати, що запит BobOrg виконується від іменіAliceOrg, як показано на Рисунку 5.12.

Рисунок 5.12 – Делегація

 

Звичайно, це не найбезпечніше рішення, оскільки хто-небудь міг запитати діяти на користь AliceOrg. Можливим рішенням може бути дляCharlieOrg контактувати з AliceOrg кожного разу, коли вона отримує запит від імені AliceOrg. Проте в цьому випадку можуть виникнути деякіпроблеми. Уявимо, що завдання Z складене з 20 різних підзадач, і що кожна підзадача відіслана до іншої організації BobOrg. AliceOrg буде переповнена повідомленнями, що повідомляють, що “BobOrg тільки що запитав виконати завдання від вашого імені... можете ви підтвердити, що це так?” У відповідь, AliceOrg довелося б засвідчити себе зі всіма тими організаціями і надати підтвердження.

Успішніше рішення могло так чи інакше змусити CharlieOrg вважати, що BobOrg – AliceOrg. Іншими словами, потрібно буде знайти законний шлях для BobOrg продемонструвати, що вона фактично, діє на користь AliceOrg. Одним із способів виконання цього може бути наданняAliceOrg пари з відкритого і приватного ключів для BobOrg. Проте, це за межами даного питання. Важливо пам'ятати, що приватний ключ повинен зберігатися в таємниці, і відправляючи його іншій організації (не має значення наскільки їй довіряють) – це велике порушення в захисті. Для вирішення цієї проблеми буде потрібний спеціальний вид сертифікату, показаний на Рисунок 5.13.

 

Рисунок 5.13 – Проксі-сертифікат

 

Рішення: проксі-сертифікати

Сертифікат, показаний на Рисунку 5.14 називається проксі-сертифікатом. Словник Вебстера визначає проксі як “інструмент, яким уповноважена персона виконує справи іншого”. Як видно на зображенні, проксі-сертифікат дозволяє утримувачеві сертифікату діяти на користь іншого. Фактично, це подібно цифровим сертифікатам X.509, за винятком того, що вони не підписуються Центром Сертифікації (CertificateAuthority); а підписується кінцевим користувачем. Дізнатися достовірність сертифікату можна, перевіривши його підпис (Організація А підписує сертифікат в цифровій формі).

Як бути із загальним ключем проксі-сертифіката, чий цей загальний ключ, організація A, організація B? Проксі-сертіфікат має пару відкритих ключів, що згенерували спеціально для проксі-сертификата. Ця пара відкритих ключів узгоджується взаємно з обома частинами (в даному випадку, А і B), і Організація А допустить діяти в її інтересах (в даному випадку B) тільки утримувача цієї пари приватних ключів.

На розглянутому зображенні є одна упущена деталь. Дозволяти кому-небудь діяти у ваших інтересах – ризикована справа. Можливо, їм довіряють зараз для виконання конкретного завдання, але хто-небудь з Організації B, можливо, скористається проксі-сертифікатом в майбутньому, щоб здійснити несанкціоновані дії від вашого імені. Тому, тривалість життя сертифікату зазвичай дуже обмежена (наприклад, до 12 годин). Це означає що, якщо проксі-сертифікат поставлений під загрозу, нападаючий не зможе довго їм користуватися. До того ж, проксі-сертифікатирозширюють звичайні сертифікати X.509 додаючи їм додаткові надбудови безпеки, щоб більше обмежити їх функціональність (наприклад, визначаючи, що проксі-сертифікат може використовуватися тільки для певних завдань). Підводячи підсумки, розглянемо більш правильне представлення проксі-сертифіката на Рисунку 5.14.


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

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

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

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

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

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

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

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

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

Политология. Универсальная шпаргалка

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

1. Место политологии среди гуманитарных наук

Политология развивается в тесном взаимодействии с другими гуманитарными науками. Их всех объединяет общий объект исследования — жизнь общества во всем многообразии ее конкретных проявлений.

Сегодня невозможно изучать сложные политические процессы, не учитывая взаимодействие общественных (гуманитарных) наук.

1) Политология тесно связана с экономикой. Экономика дает соответствующее обоснование реализации экономических...