Що дозволяє архітектура клієнт сервер

0 Comments

Розуміння Клієнт-Серверної Архітектури на прикладах

Переклав популярну статтю на тему «Клієнт-Серверної Архітектури» українською! Приємного читання та гарного навчання у сфері QA, дорогий читачу.

Ви, ймовірно, часто стикаєтеся з Клієнт-Серверною Архітектурою, коли купуєте квитки в кіно онлайн, бронюєте путівку на море або записуєтеся до лікаря.

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

Визначення та принцип роботи

Уявімо Артема, який мріє про придбання автомобіля. Як на рекламі — швидкий, потужний, гарний! Але вартість такої машини можна порівняти з ціною літака, а Артем не має таких грошей.

Звісно, Артем може відкладати гроші кілька років і лише потім купити машину. Але бажання возитися своєю машиною є вже зараз! Плюс, йому потрібний засіб пересування.

До того ж Артем не надто вміє збирати — отримав зарплату, одразу витратив на основні потреби, сплатив житло, і всі залишки пішли на різні витрати. Для таких випадків існують банки, куди можна звернутись та взяти гроші в кредит.

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

Артем обдумав ситуацію, і сказав:

— Так, я хочу саме так вчинити! Я можу віддавати 200 грн. зі своєї зарплати до банку, але відкладати гроші не виходить. Я все одно все витрачу.

І тому Артем прямує до банку і каже:

— Я Артем Романюк, і мені потрібний автокредит на 5000 грн.

Марія, операціоністка, має перевірити його кредитну історію. Можливо, йому не варто надавати кредит через його несприятливу історію? Можливо, він уже нагромадив 10 кредитів і не виплачує жодного з них? Чи раптом у нього зв’язки з терористами?! Необхідно провести перевірку, оскільки операціоністи не можуть знати всі чорні списки напам’ять.

Марія має спеціальну програму для перевірки даних про клієнтів. Ця програма може бути представлена як web-додаток, що відкривається в браузері, подібно до Google або Facebook, так і desktop додатком, що запускається на комп’ютері, наприклад, як Microsoft Word або калькулятор.

Не має значення, чи Марія працює через браузер або запускає програму безпосередньо на комп’ютері. У будь-якому разі це буде клієнтська частина. Клієнт— це ваш додаток. Саме з цією частиною взаємодіє наша операторка.

Коли Марія вводить дані клієнта ‘Артем Романюк’ у програму, вона отримує інформацію — чи він у чорних списках? Чи має він кредитну історію з минулого і т.д. Але що відбувається всередині програми, як вона обробляє ці запити?

Коли Марія внесла дані в клієнтську програму і натиснула кнопку «перевірити», клієнт надіслав запит на сервер із проханням надати інформацію про людину на ім’я ‘Артем Романюк’.

Сервер зробив запит до Бази Даних:

— SELECT * FROM clients WHERE fio = ’Артем Романюк’. (Надай всю інформацію по ПІБ ’Артем Романюк’)

База даних надала таку інформацію, що вдалося знайти.

Сервер передав цю інформацію назад клієнту:

Клієнт відобразив цю інформацію для Марії:

Марія переглядає інформацію та каже:

— Оце так, кредитна історія хороша.

І Артему запропонували таке:

— Якщо вам цікавий кредит, ми готові надати 5000 гривень на 20 років під 90% річних. Вас влаштує така пропозиція?

Артем висловив своє задоволення:

— Так, все мені підходить! Будь ласка, надайте мені гроші, і я поїду вибирати машину!

Тепер усі задоволені та раді.

Марія не усвідомлює повного шляху даних у програмі після того, як вона вводить ПІБ свого клієнта. Але давайте розберемося разом, як відбувається цей процес і чому використовуються такі складнощі. Навіщо потрібні клієнт та сервер, і чому застосовується саме така структура?

Для чого використовується клієнт?

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

Навіщо використовується сервер?

Сервер має більшу потужність.

Число клієнтів може бути значним. Наприклад, у випадку з банком у нас може бути 10 відділень у 10 містах України, та у кожному відділенні по 10 операціоністок. Це означає, що ми матимемо тисячу Марій, і кожна з них буде використовувати свій власний комп’ютер.

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

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

Уникаємо дублювання коду

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

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

Ця архітектура є безпечнішою.

На сервері та базі даних зберігається інформація, яка недоступна простому операционисту. До цієї інформації входять:

  • Персональні дані клієнтів
  • Відомості про фінансове становище клієнтів
  • Чорний список банку
  • І багато іншого.

Показувати всю цю інформацію всім та кожному недоцільно. Операціоніст бачить лише свій інтерфейс. Коли він вводить ПІБ клієнта, отримує відповідь, надавати кредит чи ні. І цієї інформації достатньо. Операціоністу не потрібний доступ до інших даних.

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

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

Навіщо потрібна База Даних?

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

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

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

Коли ми маємо БД, ми можемо бути впевнені в збереженні даних і легко виконувати пошук по них.

Переваги цієї архітектури

Давайте підіб’ємо підсумок переваг даної архітектури:

  • Економія ресурсів: Використання одного потужного сервера замість 100+ клієнтських машин дозволяє забезпечити хорошу продуктивність програми, кілька серверів можуть знадобитися тільки при великих навантаженнях, але їх кількість буде значно меншою, ніж клієнтів.
  • Відсутність дублювання коду: Основний код програми зберігається на сервері, тоді як клієнтська частина відповідає за візуалізацію та прості перевірки даних, такі як довжина рядків або числові значення.
  • Захист персональних даних: Прості користувачі не мають доступу до зайвої інформації, такої як ключові слова, паспортні дані або рахунки з грошима, що забезпечує безпеку та конфіденційність даних.

Недоліки цієї архітектури

Якщо виникне збій у роботі однієї з ключових компонентів архітектури, всі страждають

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

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

Як у такій ситуації клієнт визначає, куди направити свій запит?

Рішення полягає в установці балансувальника перед серверами, і клієнт надсилає запит саме туди. Не важливо, скільки серверів є в кластері, для клієнта це не відіграє ролі. У нього є лише одна URL-адреса балансувальника.

І в цей момент клієнт надсилає запит:

— Надайте мені всю інформацію про Артема Романюка.

— Друзі, у нас новий запит! Хто з вас має менше завантаження?

Перший сервер повідомляє:

— У мене у черзі стоїть 5 запитів.

Другий сервер відповідає:

— А у мене всього 2.

Балансувальник вирішує надіслати запит до другого сервера.

Така архітектура використовується у випадку високонавантажених додатків, коли кількість запитів, що надходять, настільки велика, що один окремий сервер не в змозі впоратися з ними.

Прикладами таких програм є Facebook, Amazon і Google, які мають мільйони користувачів. Через високе навантаження на один сервер стає недостатньо. Натомість впроваджується кластеризація, де кілька серверів об’єднуються, і балансувальник розподіляє навантаження між ними. У таких випадках у кластері може бути не тільки 2 сервери, а набагато більше, наприклад, 10 або 15, залежно від вимог програми.

Крім того, ми також маємо можливість розподіляти навантаження на базу даних. У нас може бути кілька копій баз даних, розміщених на різних серверах, і балансувальник надсилає запити до однієї чи іншої з них.

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

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

Однак, якщо виникнуть проблеми з першим сервером і він вийде з ладу, балансувальник автоматично перерозподілить навантаження на другий сервер:

У цей час адміністратори мають змогу розібратися із ситуацією на Сервері 1.

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

Простий може виникнути не тільки внаслідок несправностей. Іноді відбувається планове оновлення програми. Обидва варіанти резервування дозволяють оновлювати програму плавно. Якщо в кластері є два Сервери, процедура оновлення може виглядати так:

  1. Перенаправляємо все навантаження на Сервер 2.
  2. Зупиняємо роботу Сервера 1.
  3. Здійснюємо оновлення Сервера 1.
  4. Запускаємо Сервер 1 і спрямовуємо на нього все навантаження.
  5. Зупиняємо Сервер 2.
  6. Обновляємо Сервер 2.
  7. Запуск Сервера 2.
  8. Знову розподіляємо навантаження (у разі гарячого резерву).

Таким чином, робота програми не переривається взагалі.

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

Висока вартість обладнання

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

— Для HDD це включає спеціальну мікропрограму контролера, оптимізовану для роботи диска в RAID, що не є необхідним для домашнього використання.

— Для SSD це включає наявність групи конденсаторів, які зберігають енергію під час вимкнення живлення. Це забезпечує можливість перенесення даних з DDR кешу в незалежну пам’ять, запобігаючи втраті даних.

SSD є швидким носієм даних, тоді як HDD — це звичайний диск. RAID — це об’єднання N дисків для спільної роботи, а DDR кеш представляє оперативну пам’ять.

Крім того, серверні рішення зазвичай мають набагато більш тривалу гарантію — 5 років замість одного.

Що тестувати?

Для визначення того, що потрібно протестувати, необхідно зрозуміти з якою взаємодією стикається користувач.

Користувач взаємодіє із клієнтською частиною. Це може бути як web-додаток, так і desktop-додаток — це несуттєво. Марія, операціоністка, отримала робоче місце, ознайомилася із запуском програми та тим, як з нею працювати. Вона не має уявлення про наявність Серверів та Баз Даних, вона працює лише з клієнтською частиною.

Саме тому тестувальник у пріоритетному порядку перевіряє клієнтську частину! Тому що навіть якщо сервер працює ідеально, і тести на рівні API видають успішний результат, це може створити ілюзію ідеальності. Однак користувач може спробувати завантажити звіт.

Проблема полягає на стороні клієнта, навіть якщо сервер працює нормально. Багато «зелених» автотестів не мають значення, коли у користувача виникає помилка. Наша мета полягає в тому, щоб поглянути на систему з погляду користувача.

Однак, якщо у вас є доступ до сервера програми та його бази даних, рекомендується також провести перевірку для них. Це може допомогти виявити «потенційний баг». Наприклад:

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

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

— Можливо їх просто не заповнили.

Однак, насправді дані були введені. Проблема виникла через некоректну операцію збереження. Тому, якщо ми маємо доступ до внутрішнього пристрою (чорну скриньку), слід перевірити, чи справді дані були збережені. Якщо це виконано, варто перевірити картку товару в новому вікні або викликати інформацію через API-метод.

Якщо доступ до Бази Даних надано, рекомендується перевірити, чи все гаразд. Якщо у вас є доступ до Серверних логів, варто також перевірити їх на наявність помилок.

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

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

Тестувальник аналізує потенційні вразливості і потім інформує команду:

— Колеги, я перевірив і виявив можливі вразливості. Давайте обговоримо, чи варто нам закривати їх чи ні.

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

Однак, варто вивчити та виконати базові перевірки, такі як SQL-ін’єкції або атаки на безпеку веб-застосунків (XSS), на своїй програмі. Це дозволить хоча б оцінити їхню ступінь важливості. Адже якщо атака вплине на клієнтську сторону, це може бути не так критично. А якщо вона зашкодить серверу, це вже становить велику загрозу. Важливо хоча б уявити про можливі джерела вразливостей.

На закінчення

Клієнт є програмою, з якою взаємодіє користувач. Не має значення, чи усвідомлює користувач, що програма повністю встановлена на його комп’ютері, або ж за нею приховані Сервер і База Даних, можливо, навіть у складі RAID-масиву. Клієнт може функціонувати у браузері (web) або як desktop-додаток, а його основний інтерес — це «куди і як натискати».

Для клієнта потрібна лише невелика кількість пам’яті, місця на диску та інших ресурсів. Це дозволяє тримати витрати на робочі місця у розумних межах. Це особливо актуально, наприклад, під час закупівлі устаткування операціоністів у банку.

Сервер, з іншого боку, є комп’ютером, на якому розміщується програма. Тут зберігається весь код, логіка роботи, а також додаткові матеріали та довідники.

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

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

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

Об’єм пам’яті, який потрібний для бази даних, залежить від обсягу даних. Бувають великі Бази даних у банках, де навіть 1 ТБ може виявитися недостатнім. Тим не менш, також існують невеликі бази даних, які можна встановити на власному комп’ютері. Наприклад, можна встановити XAMPP. Ймовірно, вам не потрібно стільки даних, щоб заповнити базу до краю.

Іноді може бути відсутня окрема база даних, що призведе до появи дволанкової структури: клієнт-сервер. І це все!

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

Переклад: Дмитро Семков

PDF Формат (Google Drive): Завантажити!

2.3. МОДЕЛІ АРХІТЕКТУРИ КЛІЄНТ-СЕРВЕР І ЗАГАЛЬНА ХАРАКТЕРИСТИКА ЇХ

Застосування архітектури клієнт-сервер дає змогу уникнути вад, притаманних локальним СУБД. У таких програмних продуктах запити до бази даних (найчастіше мовою 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-моделі реалізовано трирівневу схему розподілу функцій, де прикладний компонент виокремлено в самостійний блок — компонент прикладання.