Розподілені системи управління процесами

Рис. 3.14. Варіанти перенесення коду

6.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 і інколи виявляється дуже дорогою.

Приклад

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

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

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

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

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

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

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

6.4 Перенесення коду в гетерогенних системах

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

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

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

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

Перенесення коду обмежене декількома конкретними моментами виконання програми. Точніше, перенесення можливе лише у момент виклику чергової підпрограми. Під підпрограмою мається на увазі функція в С, метод в Java і тому подібне. Виконуюча система створює власну копію програмного стека, причому машинно-незалежну. Ця копія називається стеком перенесення (migration stack). Стек перенесення оновлюється під час виклику підпрограми або поверненні управління з підпрограми.

Під час виклику підпрограми виконуюча система виконує маршалінг даних, які були поміщені в стек під час попереднього виклику (рис. 3.15). Ці дані є значеннями локальних змінних, а також значеннями параметрів поточного виклику процедури. Дані після маршалінга поміщаються в стек перенесення разом з ідентифікатором викликаної підпрограми. Крім того, в стек перенесення поміщається адреса (у формі мітки переходу), з якої повинне продовжуватися виконання після повернення з підпрограми.

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

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

Приклад

В кінці 70-х років було запропоновано просте рішення, що дозволило вирішити безліч проблем з перенесенням мови Pascal на різні машини. Таким рішенням стала генерація проміжного машинно-незалежної коду для абстрактної віртуальної машини. Ця машина вимагала реалізації на ряді різних платформ, завдяки якій програми на мові Pascal могли працювати на них всіх. Ця проста ідея деякий час знаходила широке використання, однак вона ніколи не вважалася загальним рішенням всіх проблем переносимості для інших мов, особливо С.

Рис. 3.15. Перенесення коду в гетерогенних системах

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

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

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

Приклад

Аби проілюструвати перенесення коду, розглянемо тепер платформу проміжного рівня, який підтримує різні форми перенесення коду. D'Agent, або повністю Agent TCL, - це система, побудована на основі концепції агента. Агентом в системі D'Agent називається програма, яка в гетерогенній системі здатна переміщатися з однієї машини на іншу.

6.5 Огляд перенесення коду в D'Agent

Агент в системі D'Agent - це програма, яка може переміщуватися з однієї машини на іншу. В принципі програми можуть бути написані на різних мовах, головне, аби машина, на яку переноситься код, могла виконати його. На практиці це означає, що програми в D'Agent пишуться на інтерпретованих мовах, а конкретніше, на командній мові утиліт (Tool Command Language, TCL), Java або Scheme. Використання виняткове інтерпретованих мов значно полегшує підтримку гетерогенних систем.

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

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

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

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

І, нарешті, підтримується клонування процесів за допомогою команди agent_fork. Ця команда працює майже так само, як і agent_jump, за винятком того, що процес, який запустив агента на вихідній машині, просто продовжує роботу з інструкції, наступної за викликом agent_fork. Подібно до операції fork в UNIX-системах, команда agent_fork повертає значення, по якому процес, що її викликає, може визначити, що перед ним: клонована версія (у UNIX іменована «дочірньою») або оригінальний процес («батьківським»). Аби розглянути деякі деталі внутрішньої реалізації, розглянемо написані на TCL агенти. Зсередини система D'Agent складається з п'яти рівнів (рис. 3.16).

Рис. 3.16. Склад системи D'Agent

Найнижчий рівень схожий з сокетами Берклі, в тому сенсі, що він реалізує єдиний інтерфейс механізмів взаємодії базової мережі. У D'Agent передбачається, що базова мережа надає механізми для роботи з повідомленнями TCP і електронної пошти.

Наступним рівнем є сервер, що працює на кожній машині, на якій виконується D'Agent. Сервер відповідає за управління агентами, авторизацію і управління зв'язком між агентами. Для останнього виду діяльності сервер привласнює кожному агентові локальний унікальний ідентифікатор. Якщо використовувати мережеву адресу сервера, то кожен з агентів може бути позначений парою (адреса, локальний ідентифікатор). Подібне ім'я низького рівня використовується для установки зв'язку між двома агентами.

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

Четвертий рівень містить по одному на кожну підтримуючу в D'Agent мову інтерпретатори. Кожен інтерпретатор містить компонент інтерпретації мови, модуль безпеки, інтерфейс з рівнем ядра і окремий модуль для перехоплення стану працюючого агента. Цей останній модуль необхідний для підтримки сильної мобільності.

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

Найскладніша частина реалізації D'Agent - це здобуття стану працюючого агента і передача його на іншу машину.

Інтерпретатору необхідна таблиця, в якій зберігаються глобальні змінні. Так, обробник подій може повідомляти інтерпретатор, яку процедуру слід викликати в разі приходу повідомлення від деякого агента. Пари (подія, обробник) зберігаються в таблиці інтерпретатора. У іншій таблиці містяться глобальні системні змінні, в яких зберігаються коди помилок, рядки з повідомленнями про помилки, коди результатів, рядки повідомлень, що виводяться разом з результатами і тому подібне. Є також окрема таблиця, в якій зберігаються всі визначені користувачем глобальні змінні програми. І, нарешті, в окремій таблиці зберігаються визначення процедур, зв'язаних з агентами. Ці визначення процедур потребують перенесення разом з агентами для вибору інтерпретатора на цільовій машині.

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

Спочатку розглянемо, що відбувається при виконанні базової команди TCL, тобто команди, яка викликається не з призначеної для користувача процедури. Інтерпретатор аналізує команду і будує запис, який поміщається в те, що називається стеком команд (command stack). Цей запис містить всі необхідні для виконання команди поля: значення параметрів, покажчик на процедуру реалізації команди і тому подібне. Запис поміщається в стек, після чого може бути використаний компонентом, який відповідає за виконання команди. Іншими словами, стек команд є місцем зберігання поточного стану виконання агента.

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

Приклад

Розглянемо тепер, що відбувається, наприклад, коли агент викликає команду agent_jump, за допомогою якої він переноситься на іншу машину. У цей момент повний стан агента, описаний вище, піддається маршалингу і перетворюється в послідовність байтів. Іншими словами, всі чотири таблиці і два стеки укладаються в масив байтів і пересилаються на іншу машину. Сервер D'Agent на цільовій машині створює новий процес, запускаючи інтерпретатор TCL. Процес обробляє отримані дані, виконує їх демаршалинг і в результаті отримує стан агента, в якому він знаходився перед викликом команди agent_jump. Виконання агента продовжується шляхом простого зняття з вершини стека команд чергової команди.

7. ПРОГРАМНІ АГЕНТИ

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

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

7.1 Програмні агенти в розподілених системах

Програмний агент (software agent) визначається як автономний процес, здатний реагувати на середовище виконання і викликати зміни в середовищі виконання, можливо, в кооперації з користувачами або з іншими агентами.

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

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

Окрім автономності найважливіша якість агентів - можливість кооперуватися з іншими агентами. Поєднання автономності і кооперації приводить до класу кооперативних агентів.

Кооперативний агент (collaborative agent) - це агент, що становить частину мультиагентної системи, тобто системи, в якій агенти, кооперуючись, виконують деякі загальні завдання.

Приклад

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

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

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

Здатність до кооперації з іншими агентами або переміщення між машинами - це системні властивості агентів. Вони не говорять нічого про призначення агента. Для визначення функціональності агента потрібна інша класифікація.

Клас, який традиційно виділяється, - це клас інтерфейсних агентів. Інтерфейсний агент (interface agent) - це агент, що допомагає кінцевому користувачу працювати з одним або декількома програмними засобами.

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

Приклад

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

Дуже близький до інтерфейсного агента інформаційний агент (information agent). Інформаційний агент (information agent) - агент, що займається управлінням інформацією з безлічі різних джерел.

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

Приклад

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

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

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

Таблиця 3.2

Деякі важливі властивості агентів

Властивість	Спільність для агентів	Опис
Автономність	Так	Здатність працювати незалежно від інших
Реактивність	Так	Здатність своєчасно реагувати на зміни в своєму оточенні
Проектна	Так	Здатність ініціювати дії, що впливають на їх оточення
Комунікативність	Так	Здатність обмінюватися інформацією з користувачами і іншими агентами
Тривалість	Немає	Відносно довгий час життя
Мобільність	Немає	Здатність переміщатися з місця на місце
Адаптивність	Немає	Здібність до навчання

7.2 Технологія агентів

Уявлення про те, що таке агенти, не має сенсу в тому випадку, якщо відсутня підтримка у вигляді реально існуючих систем агентів. Дуже корисною була б можливість виділити постійно використовувані компоненти агентів в розподілених системах і включити їх в програмне забезпечення проміжного рівня. Як вихідну точку організація FIPA (Foundation for Intelligent Physical Agents) розробила узагальнену модель програмних агентів. Згідно цієї моделі агенти реєструються і працюють під управлінням платформи агентів, як показано на рис. 3.17. Платформа агентів надає основні служби, необхідні будь-якій мультиагентній системі. Сюди входять механізми створення і знищення агентів, механізми розпізнавання агентів і механізми взаємодії між агентами.

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

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

Рис. 3.17. Узагальнена модель платформи агента

Важливий компонент платформи агента - канал зв'язку між агентами (Agent Communication Channel - АСС). У більшості моделей мультиагентних систем агенти зв'язуються один з одним, пересилаючи повідомлення. Модель FIPA - не виключення, вона покладає на АСС відповідальність за всю взаємодію між різними платформами агентів. Зокрема, АСС відповідає за надійний і направлений зв'язок точка-точка з іншими платформами. Канал АСС може бути реалізований просто у вигляді сервера, що відстежує деякий порт, призначений для вхідних повідомлень, які перенаправляються іншим серверам або агентам, що є частиною платформи агентів. Для забезпечення міжплатформеної взаємодії зв'язок між АСС відповідає інтернет-протоколу IIОР (Internet INTER-ORB Protocol). У архітектурі D'Agent як АСС виступає сервер.

7.3 Мови взаємодії агентів

Отже, в платформі агентів є своя специфіка. Відмінність від інших підходів до розподілених систем стає зрозумілою при розгляді характеру інформації, якою реально обмінюються агенти. Зв'язок між агентами відбувається за допомогою комунікаційного протоколу прикладного рівня, відомого під назвою мови взаємодії агентів (Agent Communication Language -ACL). B ACL присутнім є жорстке розділення між метою повідомлення і його змістом. Повідомлення може мати лише обмежений набір цілей.

Приклад

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

Ідея ACL полягає в тому, що агент-відправник і агент-одержувач як мінімум однаково розуміють мету повідомлення. Більш того, мета повідомлення зазвичай визначає і реакцію одержувача.

Приклад

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

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

Рис. 3.18 Структура повідомлення ACL

Тепер необхідно, щоб приймаючому агентові була надана вся необхідна інформація для правильної інтерпретації вмісту. Для цього заголовок повідомлення ACL повинен також визначати мову або схему декодування вмісту. Цей підхід добре працює до тих пір, доки відправник і одержувач однаково інтерпретують дані, або, точніше, символи повідомлення. Якщо єдине розуміння відсутнє, незрідка потрібні додаткові поля, що ідентифікують стандартне відображення символів в їх сенс. Таке відображення зазвичай називається онтологією (ontology).

ВИСНОВКИ

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

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

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

4. При побудові серверів приміняються різні архітектурні моделі. Сервери можуть бути інтеративними або паралельними, реалізовувати одну або декілька служб, зберігати інформацію про стан або не зберігати. Архітектурні особливості стосуються адресації служб і механізмів переривання серверів після надходження запиту на обслуговування і можливо в ході його виконання.

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

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

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

8. Програмні агенти - спеціальний вид процесів, що працюють як автономні модулі, які здатні кооперуватися з іншими агентами. З точки зору розподілених систем, відмінність агентів від звичайних програмних засобів в тому, що агенти взаємодіють один з одним за допомогою комунікаційного протоколу прикладного рівня, який називається мовою взаємодії агентів (ACL). У ACL є чітке розділення між метою повідомлення і його змістом.

ПИТАННЯ ДЛЯ САМОКОНТРОЛЮ

1. Що розуміється під поняттям процес?

2. Що таке потоки виконання?

3. З яких елементів складається потік виконання?

4. Побудуйте схему потоку виконання та поясніть її.

5. Назвіть стани в яких можуть знаходитись процеси та потоки виконання.

6. Назвіть способи організації побудови сервери. В чому полягають відмінності між ними?

7. Охарактеризуйте організацію багатопотоковогу серверу.

8. Перерахуйте задачі клієнтського програмного забезпечення.

9. Як реалізується прозорість реплікації на стороні клієнта?

10. Що розуміється під поняттям сервер?

11. Які існують способи організації серверів?

12. Що таке сервер об'єктів?

13. Які існують підходи до обробки об'єктів?

14. Дайте обгрунтування необхідності перенесення коду.

15. Сформулюйте основні підходи до перенесення коду.

16. В чому полягає процедура перенесення локальних ресурсів?

17. Як реалізується перенесення коду в гетерогенних системах?

18. Як реалізується перенесення коду в D'Agent?

19. Що розуміється під поняттям агент?

20. Які існують види агентів?

21. В чому полягає технологія агентів?

Размещено на Allbest.ru