2.2. Розширені моделі rpc.

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

Входи.

Базова модель RPC припускає, що викликаюча і викликаєма системи можуть зв'язуватися одна з одною після обміну повідомленнями по мережі. В загальному випадку це припущення правдиве. Однак розглянемо варіант, коли клієнт і сервер встановлені на одній машині. У стандартному випадку ми повинні використовувати засоби локальної міжпроцесорної взаємодії (Inter Process Communication, IPC), які базова операційна система надає процесам, запущеним на одній машині.

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

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

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

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

Рис.11. Принципи використання входів в якості механізму IPC

Асинхронний виклик RPC.

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

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

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

Рис.12 Взаємодія між клієнтом і сервером в RPC традиційні схемі (а). Взаємодія з використанням асинхронного виклику RPC(б).

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

Рис.13. Взаємодія клієнта і сервера за допомогою двох асинхронних викликів RPC.

Слід окремо відзначити варіант асинхронного виклику КЗС, який реалізується в тих випадках, коли клієнт продовжує роботу відразу після відправлення запиту на сервер. Іншими словами, клієнт не очікує від сервера підтвердження в отриманні запиту. Такі виклики називаються односторонніми викликами RPC (one-way RPC). Проблема такого підходу полягає в тому, що при відсутності гарантій надійності клієнт не може бути точно впевнений, що його запит буде виконаний.

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

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

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

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

Розподілені об'єкти.

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

Це розподілення на інтерфейси і об'єкти, що реалізують їх, дуже важливі для розподілених систем. Чіткій поділ дозволяє нам поміщати інтерфейс на одну машину при тому, що сам об'єкт знаходиться на іншій. Структура показана на рис.14. називається розподіленим об'єктом (distributed object).

Рис.14. Узагальнена організація віддалених об'єктів з використанням заміщувача клієнта.

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

Характерною особливістю більшості розподілених об'єктів є те, що їх стан (дані) не розподіляється - він локалізований на одній машині. З інших машин доступні тільки інтерфейси, реалізовані в об'єкти. Такі об'єкти ще називають віддаленими (remote object).

Об'єкти часу компіляції проти об'єктів часу виконання.

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

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

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

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

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

Збережені і не резидентні об'єкти.

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

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

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