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

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

Agent TCL (D’Agent) – це система, побудована на основі концепції агента, яким у цій системі називають програму, яка в гетерогенній системі здатна переміщуватися з однієї машини на другу.

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

7.1. Підходи до перенесення коду

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

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

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

Рис. 13. Принцип динамічної конфігурації клієнта для зв’язку із сервером.

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

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