Сутність файл-серверних і клієнт-серверних технологій доступу до даних

Основна ідея розподілених систем оброблення інформації полягає в тому, що кілька компонентів мережі (комп’ютерів або процесів) кооперуються для виконання однієї роботи (розв’язання однієї задачі чи блоку задач). Найпопулярнішим середовищем для реалізації розподілених прикладних задач на сьогоднішній день є клієнт-серверна технологія. Поняття файл-серверних і клієнт-серверних технологій увійшло в ужиток у 80-ті роки ХХ ст., коли було розроблено локальні обчислювальні мережі та з’явилися настільні робочі станції, які потребували організації колективного використовування інформаційних ресурсів. Тоді ж почали інтенсивно розробляти програмні засоби, за допомогою яких реалізовувалась відносна незалежність даних від прикладних програм, які їх використовують, тобто систем управління базами даних (СУБД).

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

Одні комп’ютери в мережі володіють і розпоряджаються інформаційно-обчислювальними ресурсами, такими як процесори, файлова система, поштова служба, служба друку, база даних. Інші мають можливість звертатися до цих служб, користуватися їхніми послугами. Комп’ютер, що керує певним ресурсом, заведено називати сервером цього ресурсу, а комп’ютер, що бажає ним скористатися, — клієнтом; конкретний сервер визначається виглядом ресурсу, яким він володіє. Якщо ресурсом є файлова система, то говорять про файл-сервер. Цей самий принцип поширюється і на взаємодію програм. Якщо одна з них виконує деякі функції, надаючи іншим відповідний набір послуг, то вона є сервером. Програми, що користуються цими послугами, заведено називати клієнтами. Так, наприклад, ядро реляційної SQL-орієнтованої СУБД часто називають сервером бази даних, або SQL-сервером, а програму, що звертається до нього за послугами з оброблення даних, — SQL- клієнтом.

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

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

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

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

Зазначені підходи реалізуються в таких моделях:

— файлового сервера (File Server — FS);

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

— сервера бази даних (Data Base Server — DBS);

— сервера додатків (Application Server — AS).

FS-модель є базовою для локальних мереж персональних комп’ютерів. На відміну від централізованої системи, архітектура «файл-сервер» не має мережевого поділу компонентів діалогу (компонент представлення), використовує персональний комп’ютер для функцій відображення, що полегшує побудову графічного інтерфейсу. Донедавна FS-модель була надзвичайно популярна серед фахівців, які розробляли інформаційні системи з використанням таких СУБД, як dBase, FoxPro, Paradox та ін., які мають мережеві версії. Один із комп’ютерів у мережі інсталюється як сервер і надає послуги з оброблення файлів іншим комп’ютерам. Файловий сервер працює під управлінням мережевої операційної системи (наприклад Novell NetWare) і виконує компоненти доступу до файлів. На комп’ютерах клієнтів функціонує додаток, у кодах якого суміщені компонент представлення і прикладний компонент. Протокол обміну являє собою набір низкорівневих викликів, що забезпечують додатку доступ до файлової системи на файл-сервері. Програмне забезпечення файл-серверної архітектури налаштоване на виконання всієї роботи з даними на робочій станції. Сервер використовується лише як спільний віддалений нагромаджувач інформації великої ємності.

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

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

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

· вузький спектр операцій маніпулювання з даними (з файлами), обмеженість на розміри бази даних (прикладна програма звертається до бази даних, яка складається з великої кількості файлів формату *.dbf. Інформація з цих файлів зчитується короткими фрагментами (до 255 байт), що, з одного боку, уповільнює обмін з базою даних, а з іншого ‑ перевантажує канал зв’язку короткими повідомленнями. Для збільшення ефективності використання каналу зв’язку на практиці використовують різні варіанти обміну даними між клієнтом і сервером (наприклад , посторінкову), однак при цьому зростає й кількість даних, переданих марно, тобто даних, що містяться на сторінці, але не використовуються для роботи) ;

· немає адекватних засобів безпеки доступу до даних (захист виконується на рівні файлової системи), одиниця захисту ‑ файл.

Усі перелічені властивості та внутрішні обмеження FS-моделі свідчать про недоцільність її використання в КІС.

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

Моделі архітектури клієнт-сервер існують у двох варіантах: дворівнева (RDA i DBS-моделі) і трирівнева (AS-модель).

Модель доступу до віддалених даних (RDA — Remote Data Access).RDA-модель істотно відрізняється як від систем з централізованою архітектурою (мейнфреймів), так і від FS-моделі характером компонента доступу до інформаційних ресурсів і позбавляє від вад, властивих цим системам. Доступ до інформації підтримується або операторами спеціальної мови (наприклад, SQL), або викликами функцій спеціальної бібліотеки. У цьому разі використовується відповідний інтерфейс прикладного програмування — АРІ (Application Program Interface), який дає змогу абстрагуватися від устаткування і низькорівневих протоколів.

Клієнт посилає запити по мережі до віддаленого сервера для отримання відповідної інформації. На сервері функціонує ядро СУБД, яке обробляє запити, виконуючи прописані в запиті дії, і повертає клієнтові результат, оформлений як блок даних. При цьому ініціатором маніпулювання з даними є прикладна програма, яка виконується на комп’ютері клієнта. Ядру СУБД відводиться роль обслуговування запитів і їх опрацювання.

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

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

Основна перевага RDA-моделі — це уніфікація інтерфейсу «клієнт-сервер» за допомогою мови SQL. Взаємодія прикладного компонента з ядром СУБД неможлива без стандартного засобу спілкування. Запити, що їх посилає прикладна програма до ядра СУБД, мають бути зрозумілі обом сторонам (прикладній програмі та ядру СУБД). Для цього їх потрібно сформулювати на спеціальній мові. Такою мовою може бути SQL, яка вже існує в ядрі СУБД і яку доцільно використати не лише як засіб доступу до даних, але і як засіб стандарту спілкування клієнта й сервера.

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

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

Рис.. Модель доступу до віддалених даних — RDA

Модель сервера бази даних (DBS—Data Base Server).Поряд з RDA-моделлю дедалі популярнішою стає перспективна DBS-модель.

Рис. 2.6. Модель сервера бази даних — DBS

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

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

Окрім переваг, які притаманні RDA-моделі, DВS-модель низку додаткових переваг:

— можливість централізованого адміністрування прикладних функцій за рахунок перенесення їх на сервер;

— додаткове зниження завантаження локальної мережі завдяки тому, що по мережі прямують не SQL-запити, а виклики процедур, які зберігаються на сервері;

— можливість розподілу процедур між кількома додатками, що дає змогу організувати завдання підтримки цілісності даних незалежно від прикладних програм, що використовують ці дані;

— економія ресурсів комп’ютера за рахунок використання створеного плану виконання процедури.

DBS-модель найпоширеніша у відомих реляційних СУБД, таких як Oracle, Informix, Sybase, InterBase, Ingres і т. ін.

Вади DBS-моделі такі.

По-перше, додаткові витрати коштів, необхідних для написання процедур, що зберігаються на сервері.

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

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

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

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

— розширення образотворчих і функціональних засобів мов процедур;

— реалізації засобів налагодження і тестування збережених процедур;

— запобігання конфліктам процедур з іншими програмами;

— підтримки пріоритетного оброблення запитів.

На практиці доволі часто під час створення КІС використовують змішані моделі, коли підтримка цілісності бази даних і деякі найпростіші прикладні функції підтримуються процедурами DBS-моделі, а складніші реалізовуються безпосередньо в прикладній програмі на комп’ютері клієнта (RDA-модель).

Незважаючи на те, що RDA і DBS-моделі значно розширили можливості клієнт-серверної технології щодо FS-моделі, жорсткі вимоги до роботи в КІС висунули на порядок денний нові підходи до вдосконалення цієї технології, які реалізовано в AS-моделі.

Модель прикладного сервера (AS—Application Server).Ця модель набула популярності із середини 90-х років. У ній реалізовано трирівневу систему розподілу функцій (рис. 2.7).

Рис. 2.7. Модель прикладного сервера — AS

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

Другий рівень — це прикладний сервер, який є відмітною ознакою трирівневої архітектури клієнт-сервер. Основне його приз-начення — зберігання і виконання бізнес-правил. Він реалізований як група процедур, що виконують прикладні функції, і називається прикладним сервером (Application Server). Виокремлення прикладної логіки в самостійний архітектурний рівень дає змогу реалізувати її адекватними мовами програмування (С, С++, Cobol, Pascal), що мають значні переваги перед мовами роботи з БД (типу SQL чи систем візуального програмування), оскільки вони є достатньо спеціалізованими.

Завдяки такому виокремленню прикладної логіки підвищується незалежність функціональних компонентів одного рівня від змін чи вдосконалень компонентів другого.

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

Трирівнева архітектура дає змогу краще оптимізувати розподіл ресурсів у системі. Наприклад, AS-сервер може бути зв’язаний швидкодіючим каналом зв’язку (100 Мбіт/сек) із сервером бази даних (DBS-сервером) і звичайним каналом (до 10 Мбіт/сек) — із клієнтським рівнем. Крім того, значно спрощується масштабування прикладних компонентів (наприклад, перенесення офісних прикладень на рівень усього підприємства).

AS-модель є фундаментом для моніторів оброблення трансакцій (TPM — Transaction Processing Monitors), які виокремлюються як особливий вид програмного забезпечення, що дає змогу ефективно керувати інформаційно-обчислювальними ресурсами в розподіленій системі.

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

Застосування нового архітектурного рішення дало змогу:

— забезпечити доступ з віддалених робочих місць до прикладного сервера в режимі «on-line» без застосування додаткових програмних засобів;

— збільшити продуктивність системи за рахунок переходу до 32-розрядної системи обміну;

— у разі потреби використовувати для роботи морально застарілу техніку на робочих місцях клієнтів унаслідок зниження технічних вимог до них;

— ефективно використовувати сучасні багатопроцесорні комплекси як прикладні сервери;

— значно підвищити рівень захисту інформації, оскільки робочі станції взаємодіють лише з AS-сервером.

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

Тільки-но кілька комп’ютерів різних моделей під управлінням різних операційних систем з’єднуються в мережу, відразу постає проблема, яким чином організувати їх узгоджену роботу в мережі. Передусім виникає питання про узгодження форматів представлення даних, оскільки в мережі можуть бути комп’ютери, що відрізняються розрядністю (16-, 32- і 64- розрядні процесори). У неоднорідному комп’ютерному середовищі під час взаємодії клієнта й сервера виникає також завдання трансляції кодів. Сервер може працювати з однією кодовою таблицею, наприклад EBCDIC (Extended Binary-Coded Decimal Interchange Code) — розширений двійково-кодований десятковий код для обміну інформацією, а клієнт — з іншою, наприклад, ASCII (American Standard Code Information Interchange). При цьому відбувається неузгодженість трактування кодів символів. Вирішення всіх трьох завдань, про які йшлося вище, покладено на спеціальний компонент СУБД ‑ сервер розподілених баз даних (DDS ‑ Distributed Database Server).