Архітектура "клієнт-сервер» (лекція)
Як правило, комп'ютери і програми, що входять до складу інформаційної системи, не є рівноправними. Деякі з них володіють ресурсами (файлова система, процесор, принтер, база даних і т.д.), інші мають можливість звертатися до цих ресурсів. Комп'ютер (або програму), керуючий ресурсом, називають сервером цього ресурсу (файл-сервер, сервер бази даних, обчислювальний сервер.). Клієнт і сервер будь-якого ресурсу можуть перебувати як в рамках однієї обчислювальної системи, так і на різних комп'ютерах, пов'язаних мережею.
Основний принцип технології "клієнт-сервер" полягає в поділі функцій додатка на три групи:
· Введення і відображення даних (взаємодія з користувачем);
· Прикладні функції, характерні для даної предметної області;
· Функції управління ресурсами (файловою системою, базою даних і т.д.)
Тому, в будь-якому додатку виділяються наступні компоненти:
· Компонент представлення даних
· Компонент управління ресурсом
Зв'язок між компонентами здійснюється за певними правилами, які називають "протокол взаємодії".
Компанією Gartner Group, що спеціалізується в області дослідження інформаційних технологій, запропонована наступна класифікація двухзвенних моделей взаємодії клієнт-сервер (Дволанковий ці моделі називаються тому, що три компонента додатка різним чином розподіляються між двома вузлами):
Історично першою з'явилася модель розподіленого представлення даних, яка реалізовувалася на універсальній ЕОМ з підключеними до неї неінтелектуальними терміналами. Управління даними та взаємодія з користувачем при цьому поєднувалися в одній програмі, на термінал передавалася тільки "картинка", сформована на центральному комп'ютері.
Потім, з появою персональних комп'ютерів (ПК) і локальних мереж, були реалізовані моделі доступу до віддаленої базі даних. Деякий час базової для мереж ПК була архітектура файлового сервера. При цьому один з комп'ютерів є файловим сервером, на клієнтах виконуються додатки, в яких поєднані компонент уявлення та прикладної компонент (СУБД і прикладна програма). Протокол обміну при цьому представляє набір низькорівневих викликів операцій файлової системи. Така архітектура, реалізована, як правило, за допомогою персональних СУБД, має очевидні недоліки - високий мережевий трафік і відсутність уніфікованого доступу до ресурсів.
З появою перших спеціалізованих серверів баз даних з'явилася можливість іншої реалізації моделі доступу до віддаленої базі даних. В цьому випадку ядро СУБД функціонує на сервері, протокол обміну забезпечується за допомогою мови SQL. Такий підхід в порівнянні з файловим сервером веде до зменшення завантаження мережі й уніфікації інтерфейсу "клієнт-сервер". Однак. мережевий трафік залишається досить високим, крім того, як і раніше неможливо задовільний адміністрування додатків, оскільки в одній програмі поєднуються різні функції.
Пізніше була розроблена концепція активного сервера, який використовував механізм збережених процедур. Це дозволило частину прикладного компонента перенести на сервер (модель розподіленого додатка). Процедури зберігаються в словнику бази даних, розділяються між декількома клієнтами і виконуються на тому ж комп'ютері, що і SQL-сервер. Переваги такого підходу: можливо централізоване адміністрування прикладних функцій, значно знижується мережевий трафік (тому що передаються не SQL-запити, а виклики збережених процедур). Недолік - обмеженість коштів розробки збережених процедур у порівнянні з мовами загального призначення (C і Pascal).
На практиці зараз звичайно використовуються змішаний підхід:
· Найпростіші прикладні функції виконуються збереженими процедурами на сервері
· Більш складні функції реалізуються на клієнті безпосередньо в прикладній програмі
Зараз ряд постачальників комерційних СУБД оголосило про плани реалізації механізмів виконання збережених процедур з використанням мови Java. Це відповідає концепції "тонкого клієнта", функцією якого залишається тільки відображення даних (модель вилученого подання даних).
Останнім часом також спостерігається тенденція використання моделі розподіленого додатка. Характерною рисою таких додатків є логічне поділ додатка на дві і більше частин, кожна з яких може виконуватися на окремому комп'ютері. Виділені частини додатка взаємодіють один з одним, обмінюючись повідомленнями в заздалегідь узгодженому форматі. В цьому випадку двухзвенная архітектура клієнт-сервер стає триланкової, а до деяких випадках, вона може включати і більше ланок.
У тому випадку, коли інформаційна система об'єднує досить велику кількість різних інформаційних ресурсів та серверів додатків, постає питання про оптимальне управління всіма її компонентами. У цьому випадку використовують спеціалізовані засоби - монітори обробки транзакцій (часто їх називають просто "монітори транзакцій"). При цьому поняття транзакції розширюється в порівнянні з відомим в теорії баз даних. В даному випадку це не атомарному дію над базою даних, а будь-яка дія в системі - видача повідомлення, запис в індексний файл, друк звіту і т.д.
Для спілкування прикладної програми з монітором транзакцій використовується спеціалізований API (Application Program Interface - інтерфейс прикладного програмування), який реалізується у вигляді бібліотеки, що містить виклики основних функцій (встановити з'єднання, викликати певний сервіс і т.д.). Сервери додатків (сервіси) також створюються за допомогою цього API, кожному сервісу присвоюється унікальне ім'я. Монітор транзакцій, отримавши запит від прикладної програми, передає її виклик відповідного сервісу (якщо той не запущений, породжується необхідний процес), після обробки запиту сервером додатків повертає результати клієнту. Для взаємодії моніторів транзакцій з серверами баз даних розроблений протокол XA. Наявність такого уніфікованого інтерфейсу дозволяє використовувати в рамках однієї програми кілька різних СУБД.
Використання моніторів транзакцій в великих системах дає наступні переваги:
· Концентрація всіх прикладних функцій на сервері додатків забезпечує значну незалежність як від реалізації інтерфейсу з користувачем, так і від конкретного способу управління ресурсами. При цьому також забезпечується централізоване адміністрування додатків, оскільки все додаток знаходиться в одному місці, а не "розмазати" по мережі по клієнтським робочим місцям.
· Монітор транзакцій в стані сам запускати і зупиняти сервери додатків. Залежно від завантаження мережі і обчислювальних ресурсів він може перенести або скопіювати частину серверних процесів на інші вузли. Це забезпечує досягнення балансу завантаження.
· Забезпечується динамічна конфігурація системи, тобто без її зупинки може бути доданий новий сервер ресурсів або сервер додатків.
· Підвищується надійність системи, тому що в разі збоїв сервер додатків може бути переміщений на резервний комп'ютер.
· З'являється можливість управління розподіленими базами даних (докладніше див. Наступний параграф).
У сучасному бізнесі дуже часто виникає необхідність надати доступ до одних і тих же даних групам користувачів, територіально віддалених один від одного. Як приклад можна привести банк, який має кілька відділень. Ці відділення можуть перебувати в різних містах, країнах або навіть на різних континентах, проте необхідно організувати обробку фінансових транзакцій (переміщення грошей по рахунках) між відділеннями. Результати фінансових операцій повинні бути видні одночасно у всіх відділеннях.
Існують два підходи до організації обробки розподілених даних.
1. Технологія розподіленої бази даних. Така база включає фрагменти даних, розташовані на різних вузлах мережі. З точки зору користувачів вона виглядає так, як ніби всі дані зберігаються в одному місці. Природно, така схема пред'являє жорсткі вимоги до продуктивності і надійності каналів зв'язку.
2. Технологія тиражування. В цьому випадку в кожному вузлі мережі дублюються дані всіх комп'ютерів. При цьому:
· Передаються тільки операції зміни даних, а не самі дані
· Передача може бути асинхронної (неодночасної для різних вузлів)
· Дані розташовуються там, де обробляються
Це дозволяє знизити вимоги до пропускної здатності каналів зв'язку, більш того при виході з ладу лінії зв'язку будь-якого комп'ютера, користувачі інших вузлів можуть продовжувати роботу. Однак при цьому допускається неоднакове стан бази даних для різних користувачів в один і той же момент часу. Отже, неможливо виключити конфлікти між двома копіями однієї і тієї ж записи.
Final Fantasy XIV: DLC StormBlood
Warhammer 40000: Dawn of War III