Розподілена архітектура

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

Клієнт і сервер - логічні поняття. Клієнт (client) - це обчислювальний процес, який здійснює запити до процесу сервера. Сервер (server) - це обчислювальний процес, який обслуговує запити сервера. Зазвичай процеси клієнта і сервера виконуються на різних комп'ютерах, але цілком можливо реалізувати систему клієнт/сервер на одній машині.

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

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

Рис. 3.1. Архітектура системи розподіленої обробки

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

Триланкова архітектура

Аналогічно клієнтському і серверному процесу прикладний процес являє собою логічне поняття, яке може підтримуватися або не підтримуватися спеціально виділеним для цієї мети апаратним забезпеченням. Логіка додатка може з рівним успіхом виконуватися на клієнтському або серверному вузлі, тобто може бути вбудована в клієнтський або серверний процес і реалізована у вигляді бібліотеки DLL (Dynamic Link Library - динамічно компонуєма бібліотека), API-інтерфейсу (Application Programming Interface - інтерфейс прикладного програмування), RPC-викликів (Remote Procedure Calls - віддалений виклик процедури) і т.д.

Якщо логіка додатка скомпільована з клієнтом, говорять про архітектуру товстого клієнта (thick client architecture) ("клієнт на стероїдах"). Якщо вона скомпільована з сервером, говорять про архітектуру тонкого клієнта (thin client architecture) ("клієнт" "шкіра так кістки"). Можливі також проміжні архітектури, у яких логіка додатка частково скомпільована з клієнтом, а частково - з сервером. Логіку додатка можна також розгорнути на окремих обчислювальних вузлах, як показано на рис. 3.2.

Рис. 3.2. Триланкова архітектура

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