Розподілені мережеві системи

Размещено на http://www.allbest.ru

ТЕМА: РОЗПОДІЛЕНІ МЕРЕЖЕВІ СИСТЕМИ

1. СУТНІСТЬ РОЗПОДІЛЕНИХ МЕРЕЖЕВИХ СИСТЕМ

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

На тих комп'ютерах, ресурси яких повинні бути доступні всім користувачам мережі, мають бути встановлені модулі, які будуть постійно знаходитись у режимі очікування запитів, що надходять мережею від інших комп'ютерів. Зазвичай такі модулі називаються програмними серверами (server), тому що їхнє головне завдання - обслуговувати (to serve) запити на доступ до ресурсів свого комп'ютера. На комп'ютерах, користувачі яких хочуть отримати доступ до ресурсів інших комп'ютерів, також потрібно додати до операційної системи деякі спеціальні програмні модулі, що повинні виробляти запити на доступ до віддалених ресурсів і передавати їх мережею на потрібний комп'ютер. Такі модулі звичайно називають програмними клієнтами (client). Власне, мережеві адаптери і канали зв'язку вирішують у мережі достатньо просте завдання - вони передають повідомлення з запитами і відповідями від одного комп'ютера до іншого, а основну роботу з організації спільного використання ресурсів виконують клієнтські і серверні частини операційних систем. Пара модулів «клієнт-сервер» забезпечує спільний доступ користувачів до визначеного типу ресурсів, наприклад, до файлів. У такому випадку користувач має справу з файловою службою. Звичайно, мережева операційна система підтримує декілька видів мережевих служб для своїх користувачів - файлову службу, службу друку, службу електронної пошти, службу віддаленого доступу і т.п.

У технічній літературі англомовний термін «service» звичайно перекладається як «служба» або «сервіс». Часто ці терміни використовуються як синоніми. Водночас, деякі спеціалісти розрізняють термін «служба», з одного боку, і терміни «сервіс» і «послуга», з іншого.

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

Терміни «клієнт» і «сервер» використовуються не тільки для позначення програмних модулів, але і комп'ютерів, підключених до мережі. Якщо комп'ютер надає свої ресурси іншим комп'ютерам мережі, то він називається сервером, а якщо він їх споживає - клієнтом. Іноді один комп'ютер може одночасно виступати і в ролі сервера, і в ролі клієнта. Мережеві служби завжди є розподіленими програмами.

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

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

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

розподілений мережевий клієнт сервер

2. ОСНОВИ МЕРЕЖЕВОЇ ВЗАЄМОДІЇ

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

Рис. 2.1. Модель взаємодії обчислювальних систем

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

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

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

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

- забезпечення цілісності даних: управління транзакціями, розподіленими між віддаленими компонентами системами;

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

- виявлення віддалених компонентів.

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



Рис. 2.2. Гетерогенна розподілена система,

де ІК - інтерфейс користувача, ЛП - логіка прикладних програм, ДД - доступ до даних, БД - база даних

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

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

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

3. МОДЕЛІ РОЗПОДІЛЕНИХ МЕРЕЖЕВИХ СИСТЕМ

3.1 Модель клієнт-сервер

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

Рис. 2.3. Базова модель взаємодії «клієнт-сервер»

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

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

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

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

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

- рівень користувацького інтерфейсу;

- рівень обробки;

- рівень даних.

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

Рівень користувацького інтерфейсу

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

Размещено на http://www.allbest.ru

Рис. 2.5. Логічні рівні прикладної програми

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

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

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

Рівень обробки

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

Рівень даних

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

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

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

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

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

Варіанти архітектури клієнт-сервер

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

Рис. 2.6. Дволанкова архітектура

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



Рис. 2.7. Триланкова архітектура

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

Рис. 2.8. Розподілена система роздрібних продажів,

де ІК - інтерфейс користувача, ЛП - логіка прикладних програм, ДД - доступ до даних, БД - база даних

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

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

Як інший приклад розподіленої системи можна привести мережі прямого обміну даними між клієнтами (peer-to-peer networks). Якщо попередній приклад мав "деревоподібну" архітектуру програмного забезпечення, то мережі прямого обміну організовані складніше, рис. 2.9. Подібні системи є в даний момент, імовірно, одними з найбільших існуючих розподілених систем, що поєднують мільйони комп'ютерів.

Рис. 2.9. Система прямого обміну даними між клієнтами,

де ІК - інтерфейс користувача, ЛП - логіка прикладних програм, ДД - доступ до даних, БД - база даних

Багатоланкові архітектури клієнт-сервер

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

Рис. 2.10. Альтернативні форми організації архітектури клієнт-сервер

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

Розглядаючи розподілення програмного забезпечення на клієнтське і серверне, необхідно враховувати те, що сервер іноді має працювати як клієнт. Така ситуація, зображена на рис. 2.11, приводить до фізично триланкової архітектури (physically three-tiered architecture).

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

Рис. 2.11. Приклад сервера, що діє як клієнт

Сучасні варіанти архітектури клієнт-сервер

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

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

Як розповсюджений приклад горизонтального розподілу розглянемо web-сервер, реплікований на кілька машин локальної мережі, як показано на рис. 2.12. На кожному із серверів утримується той самий набір web-сторінок, і щораз, коли одна з web-сторінок обновлюється, її копії одразу розсилаються на всі сервери. Сервер, якому буде переданий вхідний запит, вибирається за правилом «каруселі» (round-robin). Ця форма горизонтального розподілу досить успішно використовується для вирівнювання навантаження на сервери популярних web-сайтів. У такий же спосіб, хоча й менш очевидно, можуть бути розподілені й клієнти.



Для нескладного прикладного програмного забезпечення, призначеного для колективної роботи, можливо не мати сервера взагалі. У цьому випадку зазвичай говорять про одноранговий розподіл (peer-to-peer distribution). Подібне відбувається, наприклад, якщо користувач хоче зв'язатися з іншим користувачем. Обоє вони повинні запустити одну й ту саму прикладну програму, щоб почати сеанс. Третій клієнт може спілкуватися з одним із них або обома одночасно, для чого йому потрібно запустити ту саму прикладну програму.

3.2 Програмні компоненти розподілених систем

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

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

Ряд компонентів користувацького інтерфейсу надають свій сервіс кінцевому користувачеві.

Стосовно програм з використанням платформи Call Level Interface (CLI) - прикладного програмного інтерфейсу рівня викликів, під процесом у наведеному визначенні компоненти слід розуміти домен прикладної програми (application domain), який можна розглядати як аналог процесу в керованому коді.

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



Рис. 2.13. Компоненти розподіленої системи

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

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

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

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

Опис програмної компоненти

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

Для повного формального опису взаємодії двох компонент розподіленої системи необхідні у загальному випадку три мови:

- мова повідомлень, яка описує результат «серіалізації об'єктів»;

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

- мова опису «інтерфейсу компоненти», що визначає набір її сервісів.

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

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

- методи об'єкту, що активується сервером;

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

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

Адреса сервісу залежить від проміжного середовища і є комбінацією мережевої адреси компоненти та публічного імені сервісу. Мережева адреса програмної компоненти ґрунтується на імені її комп'ютера для систем віддаленого виклику, або на адресі менеджера черги для систем обміну повідомленнями. Така адреса є адресою протоколу, на якому засноване це проміжне середовище. У ролі такого протоколу можуть виступати HTTP, TCP, NetBIOS, або протокол нижнього рівня проміжного середовища.

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

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

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

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

Таким чином, кожний сервіс програмної компоненти характеризується трьома сутностями:

- повною адресою сервісу;

- єдиною специфікацією прийнятих сервісом повідомлень (запитів);

- єдиною специфікацією прийнятих від сервісу повідомлень (відповідей).

Сукупність специфікацій всіх сервісів програмної компоненти утворює її інтерфейс (рис. 2.14).

Размещено на http://www.allbest.ru

Рис. 2.14. Інтерфейс компоненти розподіленої системи

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

3.3 Концепції взаємодії компонент розподіленої системи

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

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

Обмін повідомленнями

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

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

Існує кілька розробок в області проміжного програмного забезпечення, що реалізують високорівневі сервіси для обміну повідомленнями між програмними компонентами. До них відносяться Microsoft Message Queuing, IBM MQSeries і Sun Java System Message Queue. Такі системи дають можливість прикладним програмам використовувати наступні базові примітиви по використанню черг:

- додати повідомлення в чергу;

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

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

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

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

Рис. 2.15. Системи черг повідомлень

Використання черг повідомлень орієнтовано на асинхронний обмін даними. Основні переваги таких систем:

- час функціонування сервера може бути не зв'язаний з часом роботи клієнтів;

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

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

Недоліки систем черг повідомлень є продовженням їхніх переваг:

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

- складність реалізації синхронного обміну;

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

- складність одержання відповіді: передача відповіді може вимагати окремої черги на кожний компонент, що посилає заявки.

Віддалений виклик процедур

Ідея віддаленого виклику процедур (remote procedure call, RPC) з'явилася в середині 80-х років і полягала в тому, що за допомогою проміжного програмного забезпечення функцію на віддаленому комп'ютері можна викликати так само, як і функцію на локальному комп'ютері. Щоб віддалений виклик відбувався прозоро з погляду прикладної програми, яка виконує виклик, проміжне середовище повинне надати процедуру-заглушку (stub), що буде викликатися клієнтською прикладною програмою. Після виклику процедури-заглушки проміжне середовище перетворює передані їй аргументи у вид, придатний для передачі по транспортному протоколу, і передає їх на віддалений комп'ютер з функцією, що викликається. На віддаленому комп'ютері параметри вилучаються проміжним середовищем з повідомлення транспортного рівня й передаються функції, що викликається (рис. 2.16). Аналогічно на клієнтську машину передається результат виконання функції, що викликається.

Рис. 2.16. Віддалений виклик процедур

Існує три можливих варіанти віддаленого виклику процедур.

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

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

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

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

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

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

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

Використання віддалених об'єктів

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

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

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

Рис. 2.17. Використання віддалених об'єктів

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



Рис. 2.18. Передача віддаленому методу посилання на об'єкт, маршалізуємий по посиланню

При використанні віддалених об'єктів проблемними є питання про час їхнього життя:

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

- протягом якого проміжку часу він існує.

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

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

- деактивація об'єкта: процес переведення об'єкта в стан невикористання.

Виділяють три моделі використання віддалених об'єктів - модель єдиного виклику (singlecall), модель єдиного екземпляра (singleton), а також модель активації об'єктів по запиту клієнта (client activation). Перші дві моделі також іноді називають моделями серверної активації (server activation), хоча, строго кажучи, активація завжди відбувається на сервері після якого-небудь запиту від клієнта.

Модель єдиного виклику

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

Рис. 2.20. Режим єдиного виклику віддаленого методу

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

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

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

Модель єдиного екземпляру

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

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

Рис. 2.21. Використання віддалених об'єктів у режимі єдиного екземпляра

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

Активація по запиту клієнта

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

Рис. 2.22. Об'єкти, що активуються клієнтом

3.4 Стан компоненти розподіленої системи

Програмні компоненти з погляду користувачів сервісів можна розділити на дві категорії:

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

- компоненти із внутрішнім станом, що зберігається між віддаленими викликами своїх методів (statefull components).

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

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

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

4. РОЗПОДІЛЕНІ ПОДІЇ

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

...