3. Перенесення і локальні ресурси

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

Приклад.

Розглянемо процес, який містить посилання на конкретний порт TCP, за допомогою якого він взаємодіє з іншими (віддаленими) процесами. Це посилання знаходиться в сегменті ресурсів процесу. При перенесенні процесу на іншу машину процес повинен звільнити зайнятий ним порт і запитати інший – на тій машині, на яку він був переміщений. У деяких випадках перенесення посилання проблем не створює. Наприклад, посилання на файл з використанням абсолютної URL-адреси залишиться вірним незалежно від того, на якій машині виконується процес, який містить цю URL-адрес.

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

Приклад.

Подібна прив'язка по ідентифікатору (binding by identifier) є використання процесом URL-адреси для посилання на конкретний web-сайт або інтернет-адреси для посилання на FTP-сервер. По цих же причинах посилання на локальну кінцеву точку взаємодії також вважатиметься прив'язкою по ідентифікатору.

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

Приклад.

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

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

Приклад.

Подібна прив'язка за типом (binding by type) може бути проілюстрована посиланнями на локальні пристрої, такі як принтери, монітори і тому подібне.

При перенесенні коду часто необхідна зміна посилань на ресурси, при цьому змінювати типа прив'язки ресурсу до процесу заборонено. Чи можна змінювати ресурси, і якщо так, то як це залежить від того, чи можуть вони бути перенесені на машину-приймач разом з кодом? Якщо конкретніше, то необхідно визначити зв'язок ресурсів з машиноюі розглянути варіанти.Неприєднанні ресурси (unattached resources)можуть бути з легкістю перенесені з машини на машину.Файли (даних)в цьому випадку зазвичай пов'язані лише з програмою, що переноситься. В протилежність їм, перенесення або копіюваннязв'язаних ресурсів (fastened resources)можливо лише з відносно значними витратами. Типовими прикладами зв'язаних ресурсів можуть бутилокальні бази даних або web-сайти цілком. Не дивлячись на те, що ці ресурси теоретично не залежать від поточної машини, часто буває неможливо перенести їх в інше середовище.

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

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

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

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

Приклад

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

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

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

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

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

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

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