Процеси створення програмного забезпечення

1.

ТЕМА 3:
ПРОЦЕСИ
Трофимчук І.М.
ТМ-41м, ІТС

2. ЗМІСТ

3.1. Потоки виконання.
3.2. Клієнти.
3.3. Сервери.
3.4. Перенесення коду.
3.5. Програмні агенти.
3.6. Висновки.

3. 3.1. ПОТОКИ ВИКОНАННЯ (ПВ)

Процеси – будівельні блоки розподільчих систем.
Подрібнення на процеси, яке здійснюється ОС, на базі
яких будуються розподільчі системи, недостатньо.
Наявність більш тонкого подрібнення у формі декількох
потоків виконання (threads)
на процес спрощує побудову розподільчих додатків.
Основний вклад:
ПВ дозволяють створювати клієнти і сервери так, що
взаємодія і локальна обробка виконуються паралельно, що
дає виграш в продуктивності.

4.

Будь-який потік складається з двох компонентів:
об'єкту ядра, через який операційна система управляє потоком. Там
же зберігається статистична інформація про потік (додаткові потоки
створюються також ядром);
стека потоку, який містить параметри всіх функцій і локальні змінні,
необхідні потоку для виконання коду.
Процес 1
Процес 1
Процес 1
Процес
Потік
Потік
Ядро
Ядро
Рис. 4.1 Схема реалізації потоку процессу
Головна відмінність процесів від потоків, полягає в тому, що процеси
ізольовані один від одного, використовують різні адресні простори, а потоки,
можуть використовувати один і той же простір (усередині процесу) при
цьому, виконуючи дії не заважаючи один одному.

5.

Співвідношення процесів і потоків виконання.
Для виконання програм операційна система створює декілька
віртуальних процесорів, окремо для кожної програми.
Аби відстежувати ці віртуальні процесори, операційна система
підтримує таблицю процесів (process table), яка містить записи для
збереження значень регістрів процесора, карт пам'яті, відкритих файлів,
облікових записах користувачів, привілеях і тому подібному.
Процес (process) часто визначають як виконувану програму,
тобто програму, яка в даний час виконується на одному з віртуальних
процесорів операційної системи.
Множина процесів спільно використовують один і той же
процесор та інші апаратні ресурси, це є прозорим (не заважають один
одному).
Для того, щоб так само відділяти процеси один від одного,
операційній системі потрібна апаратна підтримка.

6. 3.1. ПОТОКИ ВИКОНАННЯ Процеси

ПРОЦЕС
ОС створює віртуальні процесори для виконання програм.
ОС підтримує таблицю процесів (process table) для того, щоб
відслідковувати віртуальні процесори.
Процес (process)
програма, що виконується.
Тобто це програма, яка на даний момент виконується на
віртуальному процесорі ОС.
ОС приділяє увагу гарантіям того, щоб незалежні процеси не
порушили правильну роботу інших процесів.
Тобто той факт, що велика кількість процесів спільно
використовує один і той самий процесор та інші апаратні
ресурси, є прозорим.

7. 3.1. ПОТОКИ ВИКОНАННЯ Процеси і ПВ

ПОТОКИ ВИКОНАННЯ
Потік виконання дуже схожий на процес – може розглядатися як
програма, що виконується на віртуальному процесорі.
На відміну від процесу не потрібно намагатися досягти високого
ступеню прозорості, оскільки це приводить до падіння
продуктивності.
Система потоків виконання забезпечує лише той мінімум
інформації, який дозволяє спільно використовувати процесор для
різних потоків виконання.
В частності, контекст потоку виконання (thread context) містить просто
контекст процесору і деяку іншу інформацію, необхідну для управління
потоком виконання.

8. 3.1. ПОТОКИ ВИКОНАННЯ Властивість ПВ

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

9. 3.1. ПОТОКИ ВИКОНАННЯ Багатопотокові клієнти/сервери

КЛІЄНТИ
традиційний спосіб приховати затримки зв’язку –
ініціювавши взаємодію перейти до іншої роботи.
типовий приклад – web-браузери.
СЕРВЕРИ
Переваги багатопотоковості:
суттєво спрощує код сервера;
спрощує розробку серверів, в яких для досягнення
високої продуктивності необхідне паралельне
виконання декількох додатків.

10. 3.1. ПОТОКИ ВИКОНАННЯ Багатопотоковий сервер

1. запит, що
2.
3.
4.
5.
надходить з
мережі;
потік-диспетчер;
запит перенаправляється
робочому потоку;
сервер;
робочий потік.

11. 3.1. ПОТОКИ ВИКОНАННЯ Багатопотоковий сервер

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

12. 3.1. ПОТОКИ ВИКОНАННЯ Однопотоковий сервер (без ПВ)

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

13. 3.1. ПОТОКИ ВИКОНАННЯ Кінцевий автомат

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

14. 3.1. ПОТОКИ ВИКОНАННЯ Способи побудови серверу

МОДЕЛЬ
ХАРАКТЕРИСТИКИ
Багатопотоковий сервер
паралельність
блокуючі системні виклики
Однопотоковий сервер
(без ПВ)
відсутність паралельності
блокуючі системні виклики
Кінцевий автомат
паралельність
неблокуючі системні виклики

15. 3.2. КЛІЄНТИ Інтерфейси користувачів

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

16. 3.2. КЛІЄНТИ Cистема X-Windows (X)

Х можна розглядати як частину ОС, яка
відповідає за термінали.
Х-ядро (X-kernel) – серце системи:
містить всі необхідні для управління терміналами
драйвери пристроїв - сильно залежить від апаратної
конфігурації;
представляє собою низькорівневий інтерфейс для
управління екраном і перехвату повідомлень, котрі
потрапляють від клавіатури і мишки. Цей інтерфейс
доступний для додатків у вигляді бібліотеки X-lib.

17. 3.2. КЛІЄНТИ Базова організація системи X-Windows

1.
2.
3.
4.
5.
додаток;
X-lib;
інтерфейс X-lib;
Х- протокол;
термінал
(із дисплеєм,
клавіатурою,
мишкою і т.д.).

18. 3.2. КЛІЄНТИ Програми системи X-Windows

Звичайні/нормальні
додатки
зазвичай здійснюють
(через X-lib) створення
на екрані вікна, яке
потім використовується
для вводу-виводу чи
іншої роботи.
Менеджери вікон
додаток, який має
особливе право на
роботу із всім екраном.
Звичайні додатки
зобов’язані підчинятися
обмеженням на роботу з
екраном, які реалізовані
в менеджері вікон.

19. 3.2. КЛІЄНТИ Система X-Windows

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

20. 3.2. КЛІЄНТИ Система X-Windows

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

21. 3.3. СЕРВЕРИ

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

22. 3.3. СЕРВЕРИ Види і організація серверів

Ітеративний сервер
(iterative server)
сервер сам обробляє
запит і при
необхідності
повертає клієнту
повідомленнявідповідь.
Паралельний сервер
(concwrent server)
не обробляє повідомлення сам, а
передає його в окремий ПВ чи інший
процес, після чого відразу переходить
в стан очікування слідуючого вхідного
повідомлення. Потік чи процес, який
обробляв запит, відповідає за
відправлення відповіді клієнту, який
прислав запит.
(Багатопотоковий сервер)

23. 3.3. СЕРВЕРИ Види серверів

Сервер без фіксації зв’язку Cервер з фіксацією зв’язку
(stateless server)
(stateful server)
не зберігає інформацію про
стан своїх клієнтів і може
змінювати свій власний
стан, не інформуючи про
це своїх клієнтів.
(Web-сервер).
зберігає і обробляє
інформацію про своїх
клієнтів.
(Файловий сервер).

24. 3.3. СЕРВЕРИ Способи переривання зв’язку

користувач негайно закриває клієнтський додаток, що
автоматично спричиняє розрив із сервером;
більш правильний спосіб – пересилка між клієнтом і
сервером сигналу кінця зв’язку (out-ofband), який повинен
опрацьовуватися сервером раніше всіх інших даних, які
передає клієнт. Рішення:
необхідно, щоб сервер проглядав окрему кінцеву точку, на
яку клієнт буде відсилати сигнал кінця зв’язку і одночасно
(з меньшим пріоритетом) – кінцеву точку, через яку
передаються дані;
пересилати сигнал кінця зв’язку через те ж з’єднання,
через яке клієнт переслав свій запит.

25. 3.3. СЕРВЕРИ Сервери об’єктів

СЕРВЕР ОБ’ЄКТІВ
(object server)
сервер, орієнтований на підтримку розподільчих об’єктів.
Різниця між стандартним сервером об’єктів і іншими серверами:
сам по собі сервер об’єктів не представляє конкретних служб.
Вони реалізуться об’єктами, розташованими на сервері.
Сервер надає лише засоби звернення до локальних об’єктів
на основі запитів від віддалених клієнтів.
Таким чином, можна відносно легко змінити набір служб просто
додаючи чи видаляючи об’єкти.

26. 3.3. СЕРВЕРИ Сервери об’єктів

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

27. 3.3. СЕРВЕРИ Альтернативи звернень до об’єктів

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

28. 3.3. СЕРВЕРИ Адаптер об’єктів

Правила звернення до об’єкта зазвичай називають
політикою активізації (activation policies),
щоб підкреслити той факт, що в багатьох випадках об’єкт, перед тим
як до нього можна буде звернутися,повинен бути переміщений в
адресний простір серверу (тобто активізований).
Механізм групування об’єктів у відповідності з політикою активації –
адаптер об’єктів (object adapter).
Адаптер об’єктів контролює один або декілька об’єктів.
Оскільки сервер повинен одночасно підтримувати об’єкти з різною
політикою активізації, то на одному сервері може одночасно
працювати декілька адаптерів об’єктів.

29. 3.3. СЕРВЕРИ Організація сервера об’єктів

1. сервер;
2. об’єкти;
3. заглушка об’єкта
(скелетон);
4. адаптер об’єктів;
5. демультиплексор
запитів.

30. 3.4. ПЕРЕНЕСЕННЯ КОДУ Причини перенесення коду

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

31. 3.4. ПЕРЕНЕСЕННЯ КОДУ Причини перенесення коду

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

32. 3.4. ПЕРЕНЕСЕННЯ КОДУ Моделі перенесення коду

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

33. 3.4. ПЕРЕНЕСЕННЯ КОДУ Види сегментів

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

34. 3.4. ПЕРЕНЕСЕННЯ КОДУ Модель слабкої мобільності

Абсолютний мінімум для перенесення коду пропонує модель
слабкої мобільності (weak mobility).
За цією моделлю допускається перенесення тільки сегмента
коду, можливо разом з деякими даними ініціалізації.
Характерною рисою слабкої мобільності є те, що перенесена
програма завжди запускається із свого вихідного стану.
Перевагою даного підходу є його простота.
Слабка мобільність потрібна лише для того, щоб машина, на
яку переноситься код, була в змозі його виконувати. Цього
цілком достатньо, щоб зробити код переносним.

35. 3.4. ПЕРЕНЕСЕННЯ КОДУ Модель сильної мобільності

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

36. 3.4. ПЕРЕНЕСЕННЯ КОДУ Клонування

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

37. 3.4. ПЕРЕНЕСЕННЯ КОДУ Варіанти перенесення коду

Слабка
мобільність
Перенесення,
ініційоване
відправником
Перенесення,
ініційоване
отримувачем
Механізм
перенесення
Сильна
мобільність
Виконання в процесіприймачі
Виконання в окремому
процесі
Виконання в процесіприймачі
Виконання в окремому
процесі
Перенесення,
ініційоване
відправником
Перенесення процесу
Перенесення,
ініційоване
отримувачем
Перенесення процесу
Клонування процесу
Клонування процесу

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

ПРОГРАМНИЙ АГЕНТ
(software agent)
автономний процес, який здатний реагувати на
середовище виконання і викликати зміни в середовищі
виконання, можливо, в кооперації з користувачами або з
іншими агентами.
Властивість, яка робить агента більшим за процес –
здатність функціонувати автономно і, в частності,
проявляти при необхідності ініціативу.

39. 3.5. ПРОГРАМНІ АГЕНТИ Кооперативні агенти

Крім автономності важливою якістю агентів є можливість
кооперуватися з іншими агентами.
Об’єднання автономності і кооперативності приводить до поняття
КООПЕРАТИВНИЙ АГЕНТ
(collaborative agent)
агент, який є складовою частиною мультиагентної системи, тобто
системи, в якій агенти, кооперуючись, виконують деякі загальні
задачі.
Здатність до кооперації з іншими абонентами є системною
властивістю агентів.

40. 3.5. ПРОГРАМНІ АГЕНТИ Мобільні агенти

МОБІЛЬНИЙ АГЕНТ
(mobile agent)
просто агент, у якого є властивість переміщуватися з
машини на машину.
Мобільні агенти часто потребують підтримки сильної мобільності,
хоча це і не являється абсолютно необхідним. Вимога сильної
мобільності випливає з того факту, що агенти автономні і
активно взаємодіють зі своїм середовищем.
Перенесення агента на іншу машину без врахування його стану є
достатньо складним процесом.
Мобільність — це загальна властивість агентів, наявність якої не
приводить до виділення особливого їх класу.

41. 3.5. ПРОГРАМНІ АГЕНТИ Інтерфейсні агенти

ІНТЕРФЕЙСНИЙ АГЕНТ
(interface agent)
агент, який допомагає кінцевому користувачу працювати з
одним чи декількома додатками.
Традиційною властивістю інтерфейсного агента можна вважати
здатність до навчання.
Найчастіше вони взаємодіють з користувачами, забезпечуючи
таким чином їм підтримку.
Для розподілених систем інтерфейсним агентом може бути
агент, що слідкує за взаємодіями між агентами і
користувачами в деякому середовищі.

42. 3.5. ПРОГРАМНІ АГЕНТИ Інформаційні агенти

Дуже близький до інтерфейсного агенту
ІНФОРМАЦІЙНИЙ АГЕНТ
(information agent)
Основна функція таких агентів — управління інформацією із великої
множини різноманітних джерел.
Управління інформацією включає в себе: упорядкування,
фільтрацію, порівняння і т.д.
Інформаційні агенти є важливими завдяки тому факту, що вони
можуть працювати з інформацією із фізично різних джерел.
Стаціонарні інформаційні агенти зазвичай працюють із вхідними
потоками інформації.

43. 3.5. ПРОГРАМНІ АГЕНТИ Важливі властивості агентів

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

44. 3.6. ПРОГРАМНІ АГЕНТИ Модель платформи агента

1. агент;
2. кінцева точка
3.
4.
5.
6.
агента;
платформа агента;
міжплатформений
зв’язок;
компоненти
управління
агентами;
канал зв’язку між
агентами.

45. 3.6. ПРОГРАМНІ АГЕНТИ Модель платформи агента

Організацією FIPA (Foundation for Intelligent Physical Agents) було розроблено
узагальнену модель програмних агентів.
Згідно цієї моделі, агенти реєструються і працюють під управлінням
платформи агентів (рис).
Платформа агентів надає основні служби, необхідні мультиагентній системі.
Сюди входят: механізмі створення і видалення агентів, механізми
розпізнавання агентів і механізми взаємодії між агентами.
Компонент управління агентами відслідковує агентів на відповідній
платформі. Він представляє механізми створення і видалення агентів.
Важливий компонент платформи агента :
канал зв’язку між агентами (Agent Communication Channel, АСС).
В більшості моделей мультиагентних систем агенти зв’язуються один з одним
надсилаючи повідомлення. АСС відповідає за всі взаємодії між різними
платформами агентів. В частності, АСС відповідає за надійний і направлений
зв’язок точка-точка з іншими платформами. Канал АСС може бути
реалізований просто у вигляді сервера, який відслідковує деякий порт,
призначений для вхідних повідомлень, які перенаправляються іншим
серверам чи агентам, що являються частиною платформи агентів.

46. 3.6. ПРОГРАМНІ АГЕНТИ Мови взаємодії агентів

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

47. 3.5. ПРОГРАМНІ АГЕНТИ Мета і опис повідомлення

МЕТА
ПОВІДОМЛЕННЯ
ОПИС
ЗМІТ ПОВІДОМЛЕННЯ
INFORM
Інформувати, що дане
припущення вірне
Припущення
QUERY –IF
Запитати чи вірне дане
припущення
Припущення
QUERY – REF
Запит даного об’єкту
Вираз
PROPOSE
Надати пропозицію
Пропозиція
ACCEPT –
PROPOSAL
Повідомити, що дана
пропозиція прийнята
Ідентифікатор пропозиції
REJECT –
PROPOSAL
Повідомити, що дана
пропозиція відхилена
Ідентифікатор пропозиції
SUBSCRIBE
Підписатися на джерело
інформації
Посилання на джерело

48. 3.6. ВИСНОВКИ

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

49. 3.6. ВИСНОВКИ

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

50. 3.6. ВИСНОВКИ

Для того, щоб підримувати перенос коду існує 2 причини:
підвищення продуктивності та мобільність.
Перенос коду приносить проблеми використання
локальних ресурсів. Інша проблема – при переносі коду
необхідно звертати увагу на гетерогенність системи.
Кращий спосіб вирішення проблеми з гетерогенністю –
віртуальні машини, які ефективно приховують
гетерогенність за допомогою коду.
Програмні агенти – спеціальний вид процесів, що
працюють як автономні модулі, але здатні на
кооперування з іншими агентами.

51. 3.6. ВИСНОВКИ

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

52.

ДЯКУЮ ЗА
УВАГУ !