Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Архітектура «файл-сервер» та «клієнт-сервер»

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

Об'єктами розробки у файл-серверному використанні є компоненти застосування, що визначають логіку діалогу PL, а також логіку обробки BL і управління даними DL. Розроблене застосування реалізується або у вигляді закінченого завантажувального модуля, або у вигляді спеціального коду для інтерпретації.

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

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

Архітектура «клієнт-сервер» призначена для дозволу проблем файл-серверних застосувань шляхом розподілу компонентів застосування і розміщення їх там, де вони функціонуватимуть найефективніше. Особливістю архітектури клієнт-сервер є використання виділених серверів баз даних, що працюють з запитами на мові структурованих запитів SQL (Structured Query Language) і виконують пошук, сортування та агрегацію інформації. Особливість серверів БД – наявність довідника даних, в якому записана структура БД, обмеження цілісності даних, формати і навіть серверні процедури обробки даних за викликом або за подіями в програмі. Об'єктами розробки в таких застосуваннях окрім діалогу і логіки обробки є, передусім, реляційна модель даних і пов'язаний з нею набір SQL–операторів для типових запитів до бази даних.

Більшість конфігурацій «клієнт-сервер» використовують дворівневу модель, в якій клієнт звертається до послуг сервера. Передбачається, що діалогові компоненти PS і PL розміщуються на клієнтові, що дозволяє забезпечити графічний інтерфейс. Компоненти управління даними DS і FS розміщуються на сервері, а діалог (PS, PL), логіка BL і DL – на клієнтові. Дворівневе визначення архітектури «клієнт-сервер» використовує саме цей варіант: застосування працює у клієнта, а СУБД - на сервері.

Оскільки ця схема вимагає найменші вимоги до сервера, вона має найкращу масштабованість. Проте складні застосування, що викликають тісну взаємодію з БД, можуть сильно завантажити як клієнта, так і мережу. Результати SQL-запиту повинні повернутися клієнтові для обробки, тому, що там знаходиться логіка прийняття рішення. Така схема призводить до додаткового ускладнення адміністрування застосувань, розкиданих по клієнтських вузлах.

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

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

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

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

 

Багаторівнева архітектура

Багаторівнева архітектура стала розвитком архітектури «клієнт-сервер» і у своїй класичній формі складається з трьох рівнів:

· нижній рівень є застосуваннями клієнтів, що виділені для виконання функцій і логіки представлень PS і PL і мають програмний інтерфейс для виклику застосування на середньому рівні;

· середній рівень є сервером застосувань, на якому виконується прикладна логіка BL;

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

Подібну концепцію обробки даних пропагують, зокрема фірми Oracle, Sun, Borland та ін.

Трирівнева архітектура дозволяє ще більше збалансувати навантаження на різні вузли і мережу, а також сприяє спеціалізації інструментів для розробки застосувань і усуває недоліки дворівневої моделі «клієнт-сервер».

Централізація логіки застосування спрощує адміністрування і супровід. Чітко розділяються платформи і інструменти для реалізації інтерфейсу і прикладної логіки, що дозволяє з найбільшою віддачею реалізовувати їх фахівцями вузького профілю. Нарешті, зміни прикладної логіки не зачіпають інтерфейсу, і навпаки. Але оскільки межі між компонентами PL, BL і DL розмиті, прикладна логіка може з'явитися на усіх трьох рівнях. Сервер застосувань за допомогою монітора транзакцій забезпечує інтерфейс з клієнтами і іншими серверами, може управляти транзакціями і гарантувати цілісність розподіленої бази даних. Засоби видаленого виклику процедур найбільш відповідають ідеї розподілених обчислень: вони забезпечують з будь-якого вузла мережі виклик прикладної процедури, розташованої на іншому вузлі, передачу параметрів, видалену обробку і повернення результатів.

Із поширенням систем «клієнт-сервер» необхідність трьох рівнів стає усе більш очевидною. Продукти для триланкової архітектури, так звані монітори транзакцій, є відносно новими. Ці інструменти в основному орієнтовані на середовище UNIX, проте прикладні сервери можна будувати на базі Windows NT з використанням виклику віддалених процедур для організації зв'язку клієнтів з сервером. На практиці в локальній мережі може використовуватися змішана архітектура (дворівневі і трирівневі) з одним і тим же сервером БД. З урахуванням глобальних зв'язків архітектура може мати більше трьох ланок. Нині з'явилися нові інструментальні засоби для гнучкої сегментації застосувань «клієнт-сервер» по різних вузлах мережі.

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

Тема 6. Управління проектами

План

Последнее изменение этой страницы: 2016-06-09

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...