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

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

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

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

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

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

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

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

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

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

Таблиця 2.1. – Розподіл систем на шари

Додатки, сервіси

Проміжне програмне забезпечення ( Middleware )

ОС

Апаратне забезпечення

Два нижні шари часто об'єднують загальним терміном "платформа".

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

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

• CORBA (OMG) – що розробляється консорціумом OMG технологія, що дозволяє викликати методи віддалених об'єктів. Об'єкти можуть бути створені з використанням різних мов програмування;

• Java (Sun) – технологія виконання проміжного байт-кода на віртуальній машині. Байт-код, що одного разу відкомпілювався, може виконуватися на будь-якій платформі, для якої реалізована JVM ( Java Virtual Machine ), без перекомпіляції;

• .NET (Microsoft) – технологія, заснована на виконанні компонентів, що заздалегідь відкомпілювалися в проміжний код. Такий компонент може виконуватися на будь-якій платформі, для якої реалізована підтримка бібліотеки часу виконання . NET ;

• Remote Procedure Call (Sun), Java Remote Method Invocation (Sun);

• MPI, PVM і багато інших.

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

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