Перенесення коду

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

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

Перенесення кодiв збiльшує також гнучкiсть системи за рахунок динамiчного реконфiгурування розподiленої системи. Наприклад, клiєнт може спочатку активiзувати потрiбне програмне забезпечення i лише потiм звертатись до сервера, як показано на рис. 8.8.

Рис. 8.7. Сервер об'єктiв з рiзною полiтикою активiзацiї

Рис. 8.8. Динамiчне конфiгурування клiєнта для зв'язку iз сервером

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

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

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

Моделi перенесення коду можна подiлити на моделi зi слабкою мобiльнiстю (weak mobility) i сильною мобiльнiстю (strong mobility). У слабкої мобiльностi переноситься лише сегмент коду i, можливо, деякi данi iнiцiалiзацiї, а перенесена програма завжди запускається зi свого вихiдного стану (наприклад, Java-аплети). Перевагою таких моделей є простота.

Варiанти перенесення показано на рис. 8.9.

Рис. 8.9. Способи перенесення коду

У разi сильної мобiльностi додатково переноситься сегмент виконання. При цьому процес може бути призупинений i продовжено виконання пiсля перенесення на iншу машину. Прикладом є система D'Agents.

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

Якщо перенесення iнiцiюється одержувачем (наприклад, Java-аплети), машина iнiцiює виконання перенесення. Приклад виконання коду в процесi-приймачi - Java-аплети, завантаженi у Web-браузер. Недолiком є слабка захищенiсть вiд випадкового або зловмисного виконання.

Пiд час клонування створюється i виконується процес на вiддаленiй машинi, наприклад в UNIX зi створенням дочiрнiх процесiв.

Перенесення сегмента ресурсу залежить вiд типу зв'язку процесу з ресурсами. Серед основних типiв можна виокремити такi:

· сильний зв'язок, коли процес використовує саме той ресурс, на який посилається, наприклад, прив'язування за iдентифiкатором (binding by identifier) з використанням URL-адреси або посилання на FTP-сервер;

· зв'язок, за яким процес потребує лише значення ресурсу, наприклад, у разi прив'язування за значенням (binding by value) до стандартних бiблiотек С або Java;

· слабкий зв'язок використання ресурсу певного типу, зокрема прив'язування за типом (binding by type) з посиланням на принтери, монiтори тощо;

· зв'язок ресурсу з машиною можна подiлити на неприєднанi ресурси (unattached resource), зв'язанi ресурси (fastened resource) i фiксованi ресурси (fixed resource), якi неможливо перенести з машини.

У результатi отримуємо такi комбiнацiї перенесення ресурсу, як наведено в табл. 8.1.

Таблиця 8.1 Варiанти перенесення коду на iншу машину

Примiтка:
GR - органiзувати глобальне посилання;
MV - перенести ресурс;
CP - копiювати значення ресурсу;
RB - виконати нове прив'язування процесу до локального ресурсу.

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

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

У разi слабкої мобiльностi мета полягає у створеннi варiантiв компiльованого коду кожної платформи. За сильної мобiльностi сегмент виконання не змiнюється лише в разi збiжностi архiтектури й ОС приймача з вiдправником. Сегмент виконання мiстить закритi данi процесу, свiй стек i лiчильник програми. Стек мiстить поточнi данi, наприклад, значення поточних змiнних, i може включати залежнi вiд платформи данi, зокрема значення регiстрiв. Якщо вдається позбавитись даних, залежних вiд платформи, то перенесення стає можливим. Так, у мовах С, Java перенесення можливе лише в момент виклику пiдпрограми. Тому виконувальна система створює машинонезалежну копiю - стек перенесення (migration stack), який оновлюється пiд час виклику пiдпрограми або повернення керування з пiдпрограми.

Поширеним для гетерогенних систем є пiдхiд, за яким перенесення коду вирiшується засобами мов сценарiїв, зокрема Java, з використанням вiртуальних машин.

Прикладом системи з перенесенням коду є система d'Agent (або Agent TCL), побудована на концепцiї програмного агента, який перемiщується з машини на машину. Програма пишеться на iнтерпретаторi, а мобiльнiсть пiдтримується слабкою мобiльнiстю, сильною мобiльнiстю з перенесенням процесiв i з клонуванням процесiв.

Система складається з п'яти рiвнiв, з яких нижнiй подiбний до сокiтiв Берклi i надає механiзми для роботи з повiдомленнями TCP та E-mail. Архiтектуру системи показано на рис. 8.10.

Рис. 8.10. Архiтектура системи

Нижнiй рiвень забезпечує механiзм роботи з повiдомленнями TCP/IP та E-mail.

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

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

Найважливiшою частиною є подання стану агента. Так, у Tcl застосовують таблицi глобальних змiнних iнтерпретатора i системних програм разом зi стеком командних викликiв i визначення процесiв сценарiїв. Для виконання базової команди Tcl, яка викликається не з процедури користувача, будується запис, який вмiщується в стек команд (command stack) i визначає стан агента. Запис мiстить всi данi, потрiбнi для виконання (значення параметрiв, значення вказiвникiв на процедури реалiзацiї команди тощо).

Поиск по сайту: