Тема 2. Розподілене пз.

1. Особливості реалізації пз для розподілених систем

2. Вимоги до розподіленого пз.

3. Шаблони рішень для розподіленого пз.

1. Особливості реалізації пз для розподілених систем

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

Залежність від вибраної архітектури

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

Гетерогенне середовище

Оскільки різні частини розподіленого програмного комплексу можуть виконуватися на різних вузлах системи, які можуть відрізнятися апаратною, мережевою, програмною архітектурою, це спричиняє за собою серйозні проблеми в програмуванні таких систем. Досить сказати, що навіть представлення такого фундаментального поняття, як тип даних, залежить від використовуваної мови програмування і від апаратної архітектури. Найкращим виходом з цієї ситуації може вважатися або використання прийнятих і підтримуваних стандартів (таких як протокол TCP/IP для мережевої взаємодії або POSIX для системних викликів), або застосування спеціальних проміжних засобів ( middleware ), що маскують гетерогенність ( CORBA, Java RMI, . NET і так далі). Цікавим рішенням проблеми гетерогенності є використання віртуальних машин (наприклад, jvm ), виконуючих деякий незалежний від використовуваної цільової системи код. При цьому можуть бути створені системи, працюючі і взаємодіючі один з одним на будь-яких платформах 1). Попутно вирішується ще ряд серйозних проблем, пов'язаних, наприклад, з безпекою. Одним з серйозних недоліків такого підходу є те, що при цьому знижується продуктивність (за рахунок введення додаткового посередника – віртуальної машини). Проте те, що провідні гравці на ринку – Sun, IBM і Microsoft – нині активно працюють в цьому напрямі, говорить про те, що цей підхід перспективний. Альтернативним методом ("метод грубої сили") є підхід, при якому усі модулі системи компілюються під усі платформи, на яких система використовуватиметься (застосовується нині дуже часто).

Складність розгортання

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

Складність відладки

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