Архітектура клієнт-сервер
7.1.Архітектура "клієнт-сервер".
7.1.1.Основние поняття.
Як правило комп'ютери і програми, що входять до складу інформаційної системи, не є рівноправними. Деякі з них володіють ресурсами (файлова система, процесор, принтер, база даних і т.д.), інші мають можливість звертатися до цих ресурсів. Комп'ютер (або програму), керуючий ресурсом, називають сервером цього ресурсу (файл-сервер, сервер бази даних, обчислювальний сервер.). Клієнт і сервер будь-якого ресурсу можуть знаходиться як в рамках однієї обчислювальної системи, так і на різних комп'ютерах, пов'язаних мережею.
Основний принцип технології "клієнт-сервер" полягає в поділі функцій додатка на три групи:- введення і відображення даних (взаємодія з користувачем);
- прикладні функції, характерні для даної предметної області;
- функції управління ресурсами (файловою системою, базою даних і т.д.)
- компонент представлення даних
- прикладної компонент
- компонент управління ресурсом
7.1.2.Моделі взаємодії клієнт-сервер.
Компанією Gartner Group. що спеціалізується в області дослідження інформаційних технологій, запропонована наступна класифікація двухзвенних моделей взаємодії клієнт-сервер (Дволанковий ці моделі називаються тому, що три компонента додатка різним чином розподіляються між двома вузлами):
Історично першою з'явилася модель розподіленого представлення даних, яка реалізовувалася на універсальній ЕОМ з підключеними до неї неінтелектуальними терміналами. Управління даними та взаємодія з користувачем при цьому поєднувалися в одній програмі, на термінал передавалася тільки "картинка", сформована на центральному комп'ютері.
Потім, з появою персональних комп'ютерів (ПК) і локальних мереж, були реалізовані моделі доступу до віддаленої базі даних. Деякий час базової для мереж ПК була архітектура файлового сервера. При цьому один з комп'ютерів є файловим сервером, на клієнтах виконуються додатки, в яких поєднані компонент уявлення та прикладної компонент (СУБД і прикладна программма). Протокол обміну при цьому представляє набір нізкоуровнених викликів операцій файлової системи. Така архітектура, реалізована, як правило, за допомогою персональних СУБД (див. Параграф 4.8), має очевидні недоліки - високий мережевий трафік і відсутність уніфікованого доступу до ресурсів.
З появою перших спеціалізованих серверів баз даних з'явилася можливість іншої реалізації моделі доступу до віддаленої базі даних. В цьому випадку ядро СУБД функціонує на сервері, протокол обміну забезпечується за допомогою мови SQL. Такий підхід в порівнянні з файловим сервером веде до зменшення завантаження мережі й уніфікації інтерфейсу "клієнт-сервер". Однак, мережевий трафік залишається досить високим, крім того, як і раніше неможливо задовільний адміністрування додатків, оскільки в одній програмі поєднуються різні функції.
Пізніше була розроблена концепція активного сервера, який використовував механізм збережених процедур. Це дозволило частину прикладного компонента перенести на сервер (модель розподіленого додатка). Процедури зберігаються в словнику бази даних, розділяються між декількома клієнтами і виконуються на тому ж комп'ютері, що і SQL-сервер. Переваги такого підходу: можливо централізоване адміністрування прикладних функцій, значно знижується мережевий трафік (тому що передаються не SQL-запити, а виклики збережених процедур). Недолік - обмеженість коштів розробки збережених процедур у порівнянні з мовами загального призначення (C і Pascal).
На практиці зараз звичайно використовуються змішаний підхід:- найпростіші прикладні функції виконуються збереженими процедурами на сервері
- складніші реалізуються на клієнті безпосередньо в прикладній програмі
Зараз ряд постачальників комерційних СУБД оголосило про плани реалізації механізмів виконання збережених процедур з використанням мови Java. Це відповідає концепції "тонкого клієнта", функцією якого залишається тільки відображення даних (модель вилученого подання даних).
Останнім часом також спостерігається тенденція до все більшого використання моделі розподіленого додатка. Характерною рисою таких додатків є логічне поділ додатка на дві і більше частин, кожна з яких може виконуватися на окремому комп'ютері. Виділені частини додатка взаємодіють один з одним, обмінюючись повідомленнями в заздалегідь узгодженому форматі. В цьому випадку двухзвенная архітектура клієнт-сервер стає триланкової, а до деяких випадках, вона може включати і більше ланок.
7.1.3.Монітори транзакцій.
У тому випадку, коли інформаційна система об'єднує досить велику кількість різних інформаційних ресурсів та серверів додатків, постає питання про оптимальне управління всіма її компонентами. У цьому випадку використовують спеціалізовані засоби - монітори обробки транзакцій (часто їх називають просто "монітори транзакцій"). При цьому поняття транзакції розширюється в порівнянні з використовуваним в теорії баз даних. В даному випадку це не атомарному дію над базою даних, а будь-яка дія в системі - видача повідомлення, запис в індексний файл, друк звіту і т.д.
Для спілкування прикладної програми з монітором транзакцій використовується спеціалізований API (Application Program Interface - інтерфейс прикладного программмірованія), який реалізується у вигляді бібліотеки, що містить виклики основних функцій (встановити з'єднання, викликати певний сервіс і т.д.). Сервери додатків (сервіси) також створюються за допомогою цього API, кожному сервісу присвоюється унікальне ім'я. Монітор транзакцій, отримавши запит від прикладної програми, передає її виклик відповідного сервісу (якщо той не запущений, породжується необхідний процес), після обробки запиту сервером додатків повертає результати клієнту. Для взаємодії моніторів транзакцій з серверами баз даних розроблений протокол XA. Наявність такого уніфікованого інтерфейсу дозволяє використовувати в рамках однієї програми кілька різних СУБД.