Освітній веб-сайт, лекції з різних

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

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

Спочатку СУБД мали централізовану архітектуру. У ній СУБД функціонувала на центральному комп'ютері (велика ЕОМ або міні-комп'ютер). Там же розташовувалася база даних. До центрального комп'ютера були підключені термінали, які виступали в якості робочих місць користувачів. Всі процеси, пов'язані з обробкою даних, а саме: підтримка введення користувача, формування, оптимізація і виконання запитів, обмін з пристроями зовнішньої пам'яті і т. Д. Виконувалися на центральному комп'ютері, що подавала жорсткі вимоги до його продуктивності.

У сучасній СУБД, що має модель «клієнт-сервер», прикладні програми носять розподілений характер. Частина функцій прикладної програми (додатки) реалізується в програмі-клієнті, інша - в

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

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

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

Відповідно до цього поділом будь-якої програми виділяються наступні логічні компоненти:

- компонент уявлення, який реалізує введення і відображення даних;

- прикладної компонент, що підтримує чисто прикладні функції;

- компонент доступу до інформаційних ресурсів.

Крім того вводиться угода про способи їх взаємодії (протокол взаємодії).

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

Є чотири варіанти втілення моделі "клієнт-сервер":

- модель файлового сервера (File Server - FS);

- модель доступу до віддалених даних (Remote Data Access - RDA);

- модель сервера бази даних (DataBase Server - DBS);

- модель сервера додатків (Application Server - AS).

FS-модель є базовою для локальних мереж персональних комп'ютерів. Нещодавно вона була виключно популярною серед розробників, які використовували такі системи, як FoxPRO, Clipper, Paradox. Суть моделі в наступному. Один з комп'ютерів в мережі вважається файловим сервером і надає послуги з обробки файлів інших комп'ютерів. Файловий сервер працює під управлінням мережевої операційної системи і грає роль компонента доступу до інформаційних ресурсів (т. Е. До файлів). На всіх інших комп'ютерах функціонує додаток, в кодах якого суміщені компонент уявлення та прикладної компонент. Протокол обміну являє собою набір низькорівневих викликів, що забезпечують додатком доступ до файлової системи на файл-сервері.

FS-модель послужила фундаментом для розширення можливостей персональних СУБД в напрямку підтримки багато режиму. У таких системах на кожному персональному комп'ютері виконуються копії програми та ядра СУБД, а база даних міститься в поділюваних файлах, які знаходяться на файловому сервері. Коли прикладна програма звертається до бази даних, СУБД направляє запит на файловий сервер. У цьому запиті вказані файли, що містять запитувані дані. У відповідь на запит файловий сервер направляє по мережі необхідний блок даних. Система управління, отримавши його, виконує над даними дії, які були декларовані в прикладній програмі.

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

Більш технологічна RDA-модель відрізняється від FS-моделі компонентом доступу до інформаційних ресурсів. У RDA-моделі коди компонента уявлення і прикладного компонента також поєднані і також виконуються на комп'ютері-клієнті, однак для доступу до інформаційних ресурсів використовуються або оператори спеціальної мови (наприклад, мови запитів SQL, описуваного в розд. 4), або виклики функцій спеціальної бібліотеки . Клієнт направляє по мережі запит на доступ до бази даних віддаленого комп'ютера. На цьому комп'ютері функціонує ядро ​​СУБД, яке обробляє запити, виконуючи зазначені в них дії, і повертає клієнтові результат, оформлений як блок даних. Сервер бази даних виконує операції обробки даних, відпрацьовує запити і транзакції, що різко зменшує завантаження мережі, так як по ній передаються від клієнта до сервер не файли, а запити на мові високого рівня (зазвичай, мовою SQL) з істотно меншим обсягом. Важливе значення RDA-моделі - уніфікація інтерфейсу "клієнт-сервер" у вигляді мови SQL, вже використовуваного як мова запитів в СУБД.

Поряд з RDA-моделлю все більшої популярності набуває вважається перспективною DBS-модель. Вона реалізована в сучасних реляційних СУБД Informix, Ingres, Sybase, Oracle. Її основу становить механізм збережених процедур як засіб програмування SQL-сервера. Процедури зберігаються в словнику бази даних на SQL-сервері і розділяються між декількома клієнтами. Мова, на якому розробляються збережені процедури, представляє собою процедурне розширення мови запитів SQL і унікальний для кожної конкретної СУБД.

У DBS-моделі компонент подання виконується на комп'ютері-клієнті, в той час як прикладної компонент оформлений як набір збережених процедур і функціонує на комп'ютері-сервері БД. Там же виконується компонент доступу до даних, т. Е. Ядро СУБД. Переваги DBS-моделі укладені в можливості централізованого адміністрування прикладних функцій, в деякому зниженні трафіку (замість SQL-запитів по мережі направляються виклики збережених процедур), в можливості поділу процедури між декількома додатками і в економії ресурсів комп'ютера за рахунок використання раз створеного плану виконання процедури. До недоліків моделі можна віднести обмеженість коштів, які використовуються для написання збережених процедур, які представляють собою різноманітні процедурні розширення SQL, помітно поступаються за образотворчим засобам і функціональним можливостям таких мов програмування, як Сі або Паскаль. Сфера їх використання обмежена конкретною СУБД; в більшості СУБД відсутні можливості налагодження і тестування розроблених збережених процедур.

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

В AS-моделі процес, що виконується на комп'ютері-клієнті, відповідає за інтерфейс з користувачем, т. Е. Є компонентом уявлення. Звертаючись за виконанням послуг до прикладного компоненту, цей процес відіграє роль клієнта додатка (Application Client - AC). Прикладний компонент реалізований як група процесів, що виконують прикладні функції, і називається сервером додатка (Application Server - AS). Всі операції над інформаційними ресурсами виконуються відповідним компонентом, по відношенню до якого AS грає роль клієнта.

З прикладних компонентів доступні ресурси різних типів - бази даних, черги, поштові служби і ін.

RDA- і DBS-моделі спираються на двухзвенную схему поділу функцій. У RDA-моделі прикладні функції додані програми-клієнта, в DBS-моделі відповідальність за їх виконання бере на себе ядро ​​СУБД на сервері. У першому випадку прикладної компонент зливається з компонентом уявлення, в другому - інтегрується в компонент доступу до інформаційних ресурсів.

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