Віддалений виклик процедур
Ідея віддаленого виклику процедур(remote procedure call, RPC) з'явилася в середині 80-х років і полягала в тому, що за допомогою проміжного програмного забезпечення функцію на віддаленому комп'ютері можна викликати так само, як і функцію на локальному комп'ютері. Щоб віддалений виклик відбувався прозоро з погляду прикладної програми, яка виконує виклик, проміжне середовище повинне надатипроцедуру-заглушку(stub), що буде викликатися клієнтською прикладною програмою. Після виклику процедури-заглушки проміжне середовище перетворює передані їй аргументи у вид, придатний для передачі по транспортному протоколу, і передає їх на віддалений комп'ютер з функцією, що викликається. На віддаленому комп'ютері параметри вилучаються проміжним середовищем з повідомлення транспортного рівня й передаються функції, що викликається (рис. 2.40). Аналогічно на клієнтську машину передається результат виконання функції, що викликається.
Рис. 2.40 Віддалений виклик процедур
Існує три можливих варіанти віддаленого виклику процедур.
Синхронний виклик: клієнт очікує завершення процедури сервером і при необхідності одержує від нього результат виконання віддаленої функції.
Односпрямований асинхронний виклик: клієнт продовжує виконання свого завдання, одержання відповіді сервера або відсутнє, або його реалізація якось інакше передбачена при розробці (наприклад, через функцію клієнта, що віддалено викликається сервером).
Асинхронний виклик: клієнт продовжує своє виконання, при завершенні сервером виконання процедури він одержує повідомлення й результат її виконання, наприклад через callback-функцію, що викликається проміжним середовищем при одержанні результату від сервера.
Процес перетворення параметрів для передачі їх між процесами (або доменами прикладної програми у випадку використання .NET) при віддаленому виклику називається маршалізацією(marshalling). Перетворення екземпляра якого-небудь типу даних у придатний для передачі за межі викликаючого процесу набір байт називається серіалізацією.
Десеріалізація – процедура, зворотня сериалізації – полягає в створенні копії серіалізованого об'єкта на основі отриманого набору байт. Такий підхід до передачі об'єкта між процесами шляхом створення його копій називається маршалізацією за значенням (marshal by value), на відміну від маршалізації по посиланню.
Маршалізація по посиланню при передачі параметрів по посиланню використовує серіалізацію не самих вказивників, а серіалізацію об’єктів, на які вказують вказівники.
Процес серіалізаціє повинен бути визначений для всіх типів даних, переданих при віддаленому виклику. До них відносяться параметри функції, що викликається й результат, що повертається функцією. У випадку передачі параметрів по посиланню сериалізації підлягають об’єкти, на які зсилаються, оскільки для самих вказівників сериалізація не може бути застосована. Це ускладнює використання механізму віддаленого виклику в мовах, що підтримують вказівники на об'єкти невідомого типу.
Використання віддалених об'єктів
У зв'язку з переходом розроблювачів прикладних програм від структурної парадигми до об'єктного з'явилася необхідність у використанні віддалених об'єктів (remote method invocation, RMI). Віддалений об'єкт представляє собою деякі дані, сукупність яких визначає його стан. Цей стан можна змінювати шляхом виклику його методів. Звичайно можливий прямий доступ до даних віддаленого об'єкту, при цьому відбувається неявний віддалений виклик, необхідний для передачі значення поля даних об'єкту між процесами. Методи й поля об'єкта, які можуть використовуватися через віддалені виклики, доступні через деякий зовнішній інтерфейс класу об'єкту. Зовнішній інтерфейс компоненти розподіленої системи в таких системах звичайно збігається із зовнішнім інтерфейсом одного із класів, що входить компоненту.
У момент, коли клієнт починає використовувати віддалений об'єкт, на стороні клієнта створюється клієнтська заглушка, яка називається посередником(proxy). Посередник реалізує той же інтерфейс, що й віддалений об'єкт. Процес, який виконує виклик, використовує методи посередника, що маршалізує їхні параметри для передачі по мережі, і передає їх по мережі серверу. Проміжне середовище на стороні сервера десеріалізує параметри й передає їх заглушці на стороні сервера, що називаютькаркасом(skeleton) або, як і у віддаленому виклику процедур, заглушкою (рис. 2.41). Каркас зв'язується з деяким екземпляром віддаленого об'єкта. Це може бути як заново створений, так і існуючий екземпляр об'єкта, залежно від застосовуваної моделі використання віддалених об'єктів.
Весь описаний процес називається маршалізацією віддаленого об'єкта по посиланню(marshal by reference). На відміну від маршалізації за значенням, екземпляр об'єкта перебуває в процесі сервера й не залишає його, а для доступу до об'єкта клієнти використовують посередників. При маршалізації за значенням саме значення об'єкта серіалізується в набір байт для його передачі між процесами, після чого необхідне створення його копії в іншому процесі.
Рис. 2.41Використання віддалених об'єктів
Як і віддалений виклик процедур, виклик методу віддаленого об'єкта може бути як синхронним, так і асинхронним. Існує дві особливості при використанні віддалених об'єктів, що не зустрічалися у віддаленому виклику процедур. По-перше, якщо на момент формування концепції віддаленого виклику процедур виключення (exceptions) ще не підтримувалися розповсюдженими мовами й не використовувалися, то надалі вони стали методом інформування сторони, яка виконує виклик, про проблеми, що виникли на стороні, яка викликається. Таким чином, у системах, що використовують віддалені об'єкти, сериалізації підлягають як параметри методу і його результат, так і виключення, що викидаються при виконанні віддаленого методу. По-друге, як параметр або результат методів можуть теж передаватися посилання на віддалений об'єкт (рис. 2.42), якщо віддалений метод клієнт, який виконує виклик, також є сервером RMI.
Рис. 2.42 Передача віддаленому методу посилання на об'єкт, маршалізуємий по посиланню
При використанні віддалених об'єктів проблемними є питання про час їхнього життя:
у який момент часу утворюється екземпляр віддаленого об'єкта;
протягом якого проміжку часу він існує.
Для опису життєвого циклу в системах з віддаленими об'єктами використовуються два поняття прикладних програм:
активація об'єкта: процес переведення створеного об'єкта в стан обслуговування віддаленого виклику, тобто зв'язування його з каркасом і посередником;
деактивація об'єкта: процес переведення об'єкта в стан невикористання.
Виділяють три моделі використання віддалених об'єктів – модель єдиного виклику (singlecall), модель єдиного екземпляра (singleton), а також модель активації об'єктів по запиту клієнта (client activation). Перші дві моделі також іноді називають моделями серверної активації (server activation), хоча, строго кажучи, активація завжди відбувається на сервері після якого-небудь запиту від клієнта.
Модель єдиного виклику
При використанні даної моделі об'єкт активується на час єдиного віддаленого виклику. В найпростішому випадку для кожного виклику віддаленого методу об'єкта клієнтом на сервері створюється й активується новий екземпляр об'єкта, що деактивується й потім знищується відразу після завершення віддаленого виклику методу об'єкта. Таким чином, віддалені виклики різних клієнтів ізольовані один від одного. Завдяки видаленню об'єктів після виклику досягається раціональна витрата ресурсів пам'яті, але можуть витрачатися значні ресурси процесора на постійне створення й видалення об'єктів. Посередник на клієнті й заглушка на сервері існують до знищення посередника об'єкта (рис. 2.43).
Рис. 2.43Режим єдиного виклику віддаленого методу
Даний метод використання віддалених об'єктів можна розглядати як деякий варіант віддаленого виклику процедур, оскільки об'єкт не зберігає свій стан між викликами. Проте, сервер використовує свої ресурси на підтримку каркасу й каналу між посередником і заглушкою.
Певним недоліком методу одного виклику є часте створення й видалення екземплярів об'єктів, тому в проміжному середовищі може існувати сервіс, що дозволяє підтримувати деяку кількість уже створених, але ще не активованих об'єктів, які використовуються для обробки віддалених викликів. Такий набір об'єктів, що очікують своєї активації, називається пулом об'єктів(object pooling). По завершенню віддаленого виклику об'єкти деактивуються й можуть або бути поміщені в пул і використані повторно надалі, або видаляються, якщо розмір пула досягнув деякого максимального значення. Така технологія дозволяє досягти балансу між швидкістю обробки запиту й обсягом ресурсів сервера, що використовуються. Як видно з опису, у системах з пулом об'єктів активація не завжди потрібна безпосередньо після створення об'єкту, а видалення не завжди потрібне відразу за деактивації.
Відмінною рисою методу одного виклику є мінімальні витрати на організацію системи балансування навантаження і її найбільша ефективність, оскільки кожний обслуговуючі запити сервер може обробити виклик будь-якого віддаленого методу.
Модель єдиного екземпляру
При використанні моделі єдиного екземпляра віддалений об'єкт існує не більш ніж в одному екземплярі. Створений об'єкт існує, поки є хоч один клієнт, що використовує його (рис. 2.44).
Рис. 2.44Використання віддалених об'єктів у режимі єдиного екземпляра
При використанні моделі єдиного об'єкта виклики різних клієнтів працюють із тим самим екземпляром віддаленого об'єкта. Оскільки виклики клієнтів не ізольовані один від одного, то об'єкт, що використовується, не повинен мати будь-якого внутрішнього стану. Модель єдиного об'єкта дозволяє одержати найбільш високу продуктивність, оскільки об'єкти не створюються й не активуються сервером при кожному виклику методу об'єкта.
Активація по запиту клієнта
При кожному створенні клієнтом посилання на віддалений об'єкт (точніше, на посередника) на сервері створюється новий об'єкт, що існує, поки клієнт не видалить посилання на посередника. При такому методі використання виклики різних клієнтів ізольовані один від одного, і кожний об'єкт зберігає свій стан між викликами, що приводить до найменш раціонального використання ресурсів пам'яті сервера (рис. 2.45).
Рис. 2.45Об'єкти, що активуються клієнтом
Стан компоненти розподіленої системи
Програмні компоненти з погляду користувачів сервісів можна розділити на дві категорії:
компоненти без внутрішнього стану, що зберігається між віддаленими викликами своїх методів (stateless components);
компоненти із внутрішнім станом, що зберігається між віддаленими викликами своїх методів (statefull components).
Під станом у цьому випадку розуміють сукупність значень полів об'єктів, що реалізують компоненти, що зберігаються в пам'яті сервера. Якщо компонента в ході своєї роботи зберігає які-небудь дані в зовнішньому сховищі, наприклад у базі даних або черги повідомлень, це звичайно не розглядається як її внутрішній стан.
Модель єдиного виклику не зберігає стану віддаленого об'єкта між викликами його методів, у силу чого дана модель може використовуватися тільки з розподіленими компонентами без внутрішнього стану. Модель одного екземпляра може бути використана для виклику компонентів із внутрішнім станом, але це навряд чи часто має сенс, оскільки її стан буде мінятися кожним із клієнтів у довільному порядку. Модель активації по запиту клієнта може бути використана з будь-якими компонентами, але для компонент без внутрішнього стану такий підхід звичайно призводить до непродуктивного використання пам'яті при деякому виграші у витратах часу процесора в порівнянні з моделлю одного виклику.
Компоненти без збереження внутрішнього стану, що використовуються разом з моделлю єдиного виклику з пулом об'єктів, мають найбільші можливості масштабування системи при оптимальному балансі між витратами пам'яті й навантаженням на процесор.