Застосування архітектури клієнт-сервер дає змогу уникнути вад, притаманних локальним СУБД. У таких програмних продуктах запити до бази даних (найчастіше мовою SQL) посилаються на сервер, який їх обробляє і повертає результат клієнту. Ураховуючи, що частину обчислювальної роботи бере на себе сервер БД, підвищення загальної продуктивності роботи корпоративних додатків можна досягти значною мірою за рахунок модернізації лише незначної кількості ЕОМ-серверів БД.
Моделі архітектури клієнт-сервер існують у двох варіантах: дворівнева (RDA i DBS-моделі) і трирівнева (AS-модель).
Модель доступу до віддалених даних (RDA — Remote Data Access). RDA-модель істотно відрізняється як від систем із централізованою архітектурою (мейнфреймів), так і від FS-моделі характером компонента доступу до інформаційних ресурсів і позбавляє вад, властивих цим системам. Доступ до інформації підтримується або операторами спеціальної мови (наприклад, SQL), або викликами функцій спеціальної бібліотеки. У цьому разі використовується відповідний інтерфейс прикладного програмування — АРІ (Application Program Inter-face) (рис. 2.5), який дає змогу абстрагуватися від устаткування і низькорівневих протоколів.
Рис. 2.5. Модель доступу до віддалених даних — RDA
Клієнт посилає запити мережею до віддаленого сервера для отримання відповідної інформації. На сервері функціонує ядро СУБД, яке обробляє запити, виконуючи прописані в запиті дії, і повертає клієнтові результат, оформлений як блок даних. При цьому ініціатором маніпулювання з даними є прикладна програма, яка виконується на комп’ютері клієнта. Ядру СУБД відводиться роль обслуговування запитів і їх опрацювання.
Виконання компонента представлення і прикладного компонента на комп’ютері клієнта, на відміну від централізованої архітектури, істотно розвантажує сервер БД, зводячи до мінімуму загальну кількість процесів в операційнійсистемі сервера. Сервер БД звільняється від невластивих йому функцій і цілковито завантажується операціями оброблення даних, запитів і трансакцій. Це стає можливим завдяки відмові від терміналів і оснащенню робочих місць персональними комп’ютерами, які володіють власними локальними обчислювальними ресурсами, що цілковито використовуються програмами переднього плану.
Порівняно з FS-моделлю різко зменшується завантаження мережі, оскільки нею передаються тільки запити на дані й опрацьовані результати запитів, обсяг яких значно менший.
Основна перевага RDA-моделі — це уніфікація інтерфейса «клієнт-сервер» за допомогою мови SQL. Взаємодія прикладного компонента з ядром СУБД неможлива без стандартного засобу спілкування. Запити, що їх надсилає прикладна програма до ядра СУБД, мають бути зрозумілі обом сторонам (прикладній програмі та ядру СУБД). Для цього їх потрібно сформулювати спеціальною мовою. Такою мовою може бути SQL, яка вже існує в ядрі СУБД і яку доцільно використовувати не лише як засіб доступу до даних, а й як засіб стандарту спілкування клієнта та сервера.
Поряд із перевагами RDA-модель не позбавлена низки вад. По-перше, взаємодія клієнта й сервера за допомогою SQL-запитів істотно завантажує мережу. Тільки-но кількість клієнтів зростає, мережа перетворюється на «вузьке горло», гальмуючи швидкість роботи всієї інформаційної системи.
По-друге, поєднання в одній програмі різних за своєю природою функцій (функції представлення і прикладні), що виконуються на комп’ютері клієнта, внеможливлює ефективне централізоване адміністрування додатків у RDA-моделі.
Модель сервера бази даних (DBS
— Data Base Server). Разом із RDA-моделлю дедалі популярнішою стає перспективна DBS-модель (рис. 2.6).
Рис. 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). Ця модель набула популярності від середини 1990-х років. У ній реалізовано трирівневу систему розподілу функцій (рис. 2.7). оброблення
Рис. 2.7. Модель прикладного сервера — AS
Перший рівень — це комп’ютер клієнта, на якому розміщено користувацький інтерфейс (графічний і об’єктно орієнтований), функції локального редагування, логіка для перевірки даних, а також система взаємодії з мережею. Тобто на комп’ютері виконуються функції першої групи, які відповідають за інтерфейс із користувачем. Звертаючись до прикладного компонента, який розміщено на окремому сервері, комп’ютер першого рівня виконує роль клієнта додатка (прикладного клієнта) (AC — Application Client).
Другий рівень — це прикладний сервер, який є відмітною ознакою трирівневої архітектури клієнт-сервер. Основне його призначення — зберігання і виконання бізнес-правил. Він реалізований як група процедур, що виконують прикладні функції, і називається прикладним сервером (Application Server). Виокремлення прикладної логіки в самостійний архітектурний рівень дає змогу реають значні переваги перед мовами роботи з БД (на кшталт SQL чи систем візуального програмування), оскільки вони є вельми спеціалізованими.
лізувати її адекватними мовами програмування (С, С++, Cobol, Pascal), що малізувати її адекватними мовами програмування (С, С++, Cobol, Pascal), що ма
Завдяки такому виокремленню прикладної логіки підвищується незалежність функціональних компонентів одного рівня від змін чи вдосконалень компонентів другого.
Третій рівень — це сервер бази даних. Він забезпечує зберігання і підтримку даних включенням їх узгодженого перетворення, запобіганням несанкціонованому або некоректному коригуванню БД, створенням резервних копій тощо, тобто забезпечує осмислення інформації, що зберігається в БД.
Трирівнева архітектура дає змогу краще оптимізувати розподіл ресурсів у системі. Наприклад, AS-сервер може бути зв’язаний швидкодіючим каналом зв’язку (100 Мбіт/сек) із сервером бази даних (DBS-сервером) і звичайним каналом (до 10 Мбіт/сек) — із клієнтським рівнем. Крім того, значно відчутно спрощується масштабування прикладних компонентів (зокрема, перенесення офісних прикладень на рівень усього підприємства). AS-модель є фундаментом для моніторів оброблення трансакцій (TPM
— Transaction Processing Monitors), які виокремлюються як особливий вид програмного забезпечення, що дає змогу ефективно управляти інформаційно-обчислювальними ресурсами в розподіленій системі.
Монітори оброблення трансакцій являють собою гнучке, відкрите середовище для розроблення й управління мобільними додатками, зорієнтованими на оперативне оброблення розподілених трансакцій. Серед найважливіших характеристик ТРМ — масштабованість, підтримка функціональної повноти й цілісності додатків, досягнення максимальної продуктивності під час оброблення незначних обсягів даних, підтримка цілісності даних.
Застосування нового архітектурного рішення дало змогу:
— забезпечити доступ з віддалених робочих місць до прикладного сервера в режимі «on-line» без застосування додаткових програмних засобів;
— збільшити продуктивність системи за рахунок переходу до 32-розрядної системи обміну;
— у разі потреби використовувати для роботи морально застарілу техніку на робочих місцях клієнтів унаслідок зниження технічних вимог до них;
— ефективно використовувати сучасні багатопроцесорні комплекси як прикладні сервери;
— значно підвищити рівень захисту інформації, оскільки робочі станції взаємодіють лише з AS-сервером.
Підсумовуючи, доцільно зауважити, що RDA- i DBS-моделі спираються на дворівневу схему розподілу функцій. Основна відмінність їх полягає в тому, що в RDA-моделі прикладні функції реалізуються на комп’ютері клієнта, а в DBS-моделі відповідальність за їх виконання бере на себе ядро СУБД, що функціонує на сервері. У першому випадку прикладний компонент об’єднується з компонентом представлення (інтерфейс), у другому інтегрується із компонентом забезпечення доступу до бази даних. В AS-моделі реалізовано трирівневу схему розподілу функцій, де прикладний компонент виокремлено в самостійний блок — компонент прикладання.
