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

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

Відкритість

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

Безпека

Безпека – важлива властивість будь-якої програмної системи і розподіленою зокрема. Під безпекою зазвичай розуміють сукупність наступних властивостей :

• конфіденційність (забезпечення захисту від несанкціонованого доступу в систему);

• цілісність (забезпечення цілісності і збереження даних);

• доступність (забезпечення захисту при паралельному доступі до ресурсів).

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

Важливою проблемою при проектуванні розподіленого застосування є завдання забезпечення якості обслуговування ( Quality of Service ). Під якістю обслуговування зазвичай розуміють деякі угоди по виконанню запитів клієнта (наприклад, запит повинен оброблятися не пізніше, ніж через 2 секунди після отримання і так далі). Жорстким порушенням якості обслуговування є ситуація відмови в обслуговуванні ( Denial of Service ) – вона може виникнути, якщо зловмисник бомбардує сервер запитами, які той не устигає обробляти. Вирішення цієї проблеми в загальному вигляді може бути дуже складним, проте існують рекомендації, що дозволяють обходити її у більшості випадків. Іншою важливою проблемою безпеки є використання мобільного коду (коду, що прийшов по мережі і виконуваного локально). Тут рішення полягає в застосуванні коду, що інтерпретується, і віртуальних машин.

Масштабованість

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

• використання ресурсів не повинне рости швидше, ніж О(n), де n – кількість користувачів;

• час пошуку по структурах даних не повинен рости швидше, ніж O(log(d)), де d – кількість даних.

Існують, проте, обмеження, які згубно впливають на продуктивність. Це можуть бути жорсткі обмеження середовища (наприклад, пропускна спроможність мережевого інтерфейсу), крім того, деякі ресурси просто не допускають масштабування.

Обробка помилок

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

Паралельність

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

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

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

Прозорість

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

• прозорість доступу : доступ до локальних і видалених ресурсів за допомогою однакових викликів;

• прозорість розташування : доступ до ресурсів незалежно від їх фізичного розташування;

• прозорість паралелізму : можливість декільком процесам паралельно працювати з ресурсами, не роблячи впливу один на одного;

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

• прозорість обробки помилок : захист програмних компонентів від збоїв, що сталися в інших програмних компонентах, відновлення після збоїв;

• прозорість мобільності : можливість перенесення додатка між платформами без його переробки;

• прозорість продуктивності : можливість конфігурації системи з метою збільшення продуктивності при зміні складу платформи виконання;

• прозорість масштабованості : можливість збільшення продуктивності без зміни структури програмної системи і використовуваних алгоритмів.

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

Керованість

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