Клієнт-серверна дворівнева архітектура ІС
Ключовою відмінністюАрхітектура клієнт-сервер від архітектури файл-сервер є абстрагування від внутрішнього представлення даних (фізичної схеми даних). За такої архітектури клієнтські програми маніпулюють даними на рівні логічної схеми. Для реалізації архітектури клієнт-сервер зазвичай використовують розраховані на багато користувачів СУБД, наприклад, Oracle або Microsoft SQL Server.
Клієнт-серверна інформаційна системаскладається з трьох основних компонентів: програмне забезпеченнясервера; програмне забезпечення кінцевого користувача; проміжне програмне забезпечення (рис.1.7). Програмне забезпечення сервера, крім управління базами даних, забезпечує обслуговування клієнтів.
У таких СУБД передбачені механізми блокування та елементи управління розрахованим на багато користувачів доступом, які забезпечують захист даних від ризиків, властивих паралельному доступу. Крім цього, серверу баз даних доводиться захищати дані від несанкціонованого доступу, оптимізувати запити до бази даних, забезпечувати цілісність даних та контроль завершення транзакцій. У клієнт-серверної організаціїклієнти можуть бути досить "тонкими", а сервер повинен бути "товстим" настільки, щоб задовольняти потреби всіх клієнтів. До програмного забезпечення кінцевого користувача належать засоби розробки прикладних програм та генератори звітів, у тому числі електронні таблиціі текстові процесориЗа допомогою цього програмного забезпечення користувачі встановлюють зв'язок із сервером, формують запити, які автоматично генеруються у запити на мові SQL та надсилаються на сервер. Сервер приймає та обробляє запити, а потім передає отримані результати клієнтам. Проміжне програмне забезпечення – частина системи клієнт-сервер, яка пов'язує програмне забезпечення кінцевого користувача із сервером.
Використання архітектури клієнт-сервер дозволило створювати надійні (в сенсі цілісності даних) розраховані на багато користувачів ІВ з централізованою базою даних, незалежні від апаратної (а часто і програмної) частини сервера БД і підтримуючі графічний інтерфейскористувача на клієнтських станціях, пов'язаних локальною мережею. Причому витрати на розробку додатків значно скорочувалися.
Така архітектура має два рівні, характерною особливістюякою є те, що клієнтські програми працює з даними через запити до серверного ПЗ, а базові функціїдодатки розділені між клієнтом та сервером (рис.1.8).
До переваг цієї архітектури ставляться:
· повна підтримкарозрахованої на багато користувачів роботи;
· Забезпечення цілісності даних.
Двохрівневу архітектуру доцільно використовувати на підприємствах з кількістю користувачів кілька десятків, оскільки операційна система сервера під час обслуговування великої кількостіклієнтів занадто перевантажується керуванням численними з'єднаннями із сервером.
Недоліками дворівневої клієнт-серверної архітектури є:
· Бізнес логіка додатків залишилася у клієнтському ПЗ. При будь-якій зміні алгоритмів, треба оновлювати користувальницьке програмне забезпечення на кожному клієнті.
· Високі вимоги до пропускну здатність комунікаційних каналівіз сервером, що перешкоджає використання клієнтських станцій інакше як у локальній мережі.
· Слабка захист даних від злому, особливо недобросовісних користувачів системи.
· Висока складність адміністрування та налаштування робочих місць користувачів системи.
· Необхідність використання потужних ПК на клієнтських місцях.
· Висока складність розробки системи через необхідність виконувати бізнес-логіку та забезпечувати користувальницький інтерфейсв одній програмі.
Технологія клієнт-сервер вважається одним із "китів" сучасного світукомп'ютерних мереж. Але завдання, на вирішення яких її було розроблено, йдуть у минуле. Нові завдання та технології вимагають переосмислення принципів клієнт-серверних систем. Одна з таких технологій World Wide Web. p align="justify"> Web-технологія є розвитком архітектури клієнт-сервера, тобто. за допомогою одного клієнта можна підключитися до багатьох серверів. Інформаційна система, крім інтерфейсу, повинна мати рівні обробки даних та їх зберігання. Проблема розробників інтермереж у відповідності роботи Webз іншими елементами системи, наприклад, базами даних. Одним із перспективних способів вирішення цієї проблеми – багаторівневі системи клієнт-сервер.
Класична системаклієнт-сервер працює за схемою "запит-відповідь" (дворівнева архітектура). Клієнт виконує активну функцію (запити), сервер пасивно відповідає.
Будь-яка інформаційна система повинна мати щонайменше три функціональні частини - модулі зберігання даних, їх обробки та інтерфейсу з користувачем.
Кожна з цих частин може бути реалізована незалежно від двох інших.
Наприклад . Не змінюючи програм, що використовуються для зберігання та обробки даних, можна змінити інтерфейс з користувачем таким чином, що одні й ті самі дані відображатимуться у вигляді таблиць, графіків або гістограм. Не змінюючи програм представлення даних та їх зберігання, можна змінити програми обробки, змінивши алгоритм повнотекстового пошуку. Не змінюючи програм подання та обробки даних, можна змінити програмне забезпечення для зберігання даних, перейшовши на іншу файлову систему.
У класичній архітектурі клієнт-сервер три основні частини програми розподіляються за двома фізичними модулями. Зазвичай ПЗ зберігання даних розташовується на сервері (/: сервер бази даних), інтерфейс з користувачем - на стороні клієнта, а ось обробку даних доводиться розподіляти між клієнтською і серверною частинами. У цьому основний недолік цієї архітектури. Розбиття алгоритмів обробки даних потребує синхронізації дій обох частин системи. Щоб уникнути неузгодженості різних елементівархітектури, що намагаються виконувати обробку даних на одній з двох частин - або на стороні клієнта ("товстий" клієнт), або на сервері ("тонкий" клієнт, або "2,5-рівневий клієнт-сервер"). Кожен підхід має свій недолік: в першому випадкуневиправдано перевантажується мережу, т.к. по ній передаються необроблені (надлишкові) дані, ускладнюється підтримка та зміна системи, оскільки заміна алгоритму обчислень або виправлення помилки потребує одночасної повної замінивсіх інтерфейсних програм, інакше піде неузгодженість даних; у другому випадку, коли вся обробка інформації виконується на сервері, виникає проблема опису вбудованих процедур та їх налагодження (опис є декларативним і не допускає покрокового налагодження). Крім того, систему з обробкою інформації на сервері абсолютно неможливо перенести на іншу платформу.
Більшість сучасних засобівшвидкої розробки додатків (RAD), які працюють з різними БД, реалізує першу модель ("товстий" клієнт), що забезпечує інтерфейс із сервером БД через мову SQL.. Цей варіант, крім перерахованих вище недоліків, має низький рівеньбезпеки.
Наприклад. У банківських системахвсі операційні мають право на запис в основну таблицю облікової системи. Крім того, цю системумайже неможливо перекласти на Web-технології, оскільки для доступу до сервера БД використовується спеціалізоване програмне забезпечення.
Недоліки розглянутих вище моделей:
1. "Товстий" клієнт
F складність адміністрування;
F складність у оновленні ПЗ, т.к. його заміну необхідно проводити одночасно по всій системі;
F складність у розподілі повноважень, оскільки розмежування доступу відбувається за діями, а, по таблицям;
F перевантаження мережі через передачі необроблених даних;
F слабкий захист даних.
2. "Товстий" сервер
ð ускладнюється реалізація, оскільки мови PL/SQL не пристосовані для розробки подібного ПЗ і немає засобів налагодження;
ð продуктивність програм мовами PL/SQL нижче, ніж іншими мовами, що важливо для складних систем;
ð програми, написані на СУБД-мовах, працюють ненадійно, що може призвести до виходу з експлуатації всього сервера БД;
ð створені таким чином програми повністю нестерпні на інші системи та платформи.
 |
Для вирішення цих проблем використовуються багаторівневі (три і більше) моделі клієнт-сервер.
Багаторівневі архітектури клієнт-сервер - розумніше розподіляють модулі обробки даних, які виконуються на одному або кількох окремих серверах.
Ці програмні модулівиконують функції серверадля інтерфейсів з користувачами та клієнта- Для серверів БД. Крім того, різні сервери програм можуть взаємодіяти між собою для більш точного поділу системи на функціональні блоки, що виконують певні ролі.
Наприклад.Можна виділити сервер керування персоналом, який виконуватиме всі необхідні для керування персоналом функції. Зв'язавши з ним окрему БД, можна приховати від користувачів всі деталі реалізації цього сервера, дозволивши звертатися лише до загальнодоступних функцій. Така система простіше адаптується до Web, т.к. Легше розробити html-форми для доступу користувачів до певних функцій БД, ніж до всіх даних.
У трирівневій моделі "тонкий" клієнт не перевантажений функціями обробки даних, а виконує основну роль системи представлення інформації, що надходить із сервера додатків. (Такий інтерфейс реалізується за допомогою стандартних засобів Web-технології - браузера, CGI та Java). Це зменшує обсяг даних, що передаються між клієнтом та сервером додатків, дозволяючи підключати клієнтів із повільними телефонними каналами.
Трирівнева модель клієнт-сервер дозволяє більш точно призначати повноваження користувачів, тому що вони набувають права не до самої БД, а до певних функцій сервера додатків, що підвищує захищеність системи.
Багаторівневі клієнт-серверні системилегко можна перекласти на Web-технологію - для цього достатньо замінити клієнтську частинууніверсальним браузером, а сервер додатків доповнити Web-сервером і невеликими програмами виклику процедур сервера. У трирівневій системі каналом зв'язку між сервером додатків і БД передається багато інформації, у своїй не сповільнюються обчислення, оскільки зв'язку зазначених елементіввикористовуються більш швидкісні лінії. Це вимагає менших витрат, оскільки обидва сервери знаходяться в одному приміщенні. Але при цьому постає проблема узгодженості спільних обчислень, яку мають вирішувати менеджери транзакцій - нові елементи багаторівневих систем.
Менеджери транзакцій
МТ -дозволяють одному серверу додатків одночасно обмінюватись даними з кількома серверами БД. Хоча сервери Oracleмають механізм виконання розподілених транзакцій, але якщо користувач зберігає частину інформації в БД Oracle, частина в БД Informix, а частина в текстових файлах, то без МТ не обійтися. МТ використовується для управління розподіленими різнорідними операціями та узгодження дій різних компонентівінформаційної системи Будь-яке складне програмне забезпечення вимагає використання МТ.
Наприклад.Банківські системи мають здійснювати різні перетворення подань документів, тобто. працювати одночасно з даними, що зберігаються як у БД, так і в звичайних файлах, - саме ці функції допомагає виконувати МТ.
МТ - це програма чи комплекс програм, з допомогою яких можна узгодити роботу різних компонентів инф-ой системи.
Логічно МТ ділиться на кілька частин:
· Комунікаційний менеджер (контролює обмін повідомленнями між компонентами інф-ой системи;
· Менеджер транзакцій (керує розподіленими операціями);
· Менеджер ведення журнальних записів (стежить за відновленням та відкатом розподілених операцій);
· менеджер блокувань (забезпечує правильний доступдо спільно використовуваних даних).
Зазвичай М-комунікаційний об'єднаний з М-авторизації, а М-транзакцій з М-блокувань та системних записів. Причому такий М рідко входить у комплект поставки, оскільки його функції (ведення записів, розподіл ресурсів та контроль операцій), як правило, виконує сама БД (наприклад, Oracle).
Найбільші змінисталися у М-комунікації, оскільки у цій галузі з'явилися нові об'єктно-орієнтовані технології (CORBA, DCOM тощо.). Багаторівнева модельклієнт-сервер дозволяє суттєво спростити розподілені обчислення, роблячи їх не лише надійнішими, а й доступнішими.
4.4. Системи технологічної пошти -
це гарантована доставка інформації та засіб для інтеграції додатків
Проектування інформаційних систем ставить перед системними аналітиками рішення наступних проблем:
ð розподіленість системи;
ð інтеграція різних додатків;
ð зручність адміністрування.
Сучасні ЗС переважно є розподіленими, тому постає завдання вибору способу взаємодії між окремими частинами таких систем. Злиття кількох інформаційних систем потребує вирішення інтеграції великої кількості різноманітних додатків. Така (інтегрована) система повинна мати всю функціональність об'єднаних підсистем і зберегти простоту і зручність використання. Вирішення цієї проблеми можливо здійснити за допомогою систем технологічної пошти(СТП).
Термін «технологічна пошта» використовується для позначення взаємодії між додатками ("електронна пошта" - взаємодія між людьми), інформація, що передається, є технологічною її формування і передача можуть здійснюватися без/або з мінімальною участю людини.
Система технологічної пошти включає два різних способувзаємодії, що використовуються у сучасних розподілених системах.
Один із них ґрунтується на концепції з'єднання (рис.1), а інший – на ідеї обміну повідомленнями.
1
Рис.1. Механізм взаємодії із встановленням з'єднання
Процес взаємодії додатків та використанням встановлення з'єднання можна розділити на три фази:
1. встановлення з'єднання;
2. передача інформації;
3. закриття з'єднання.
Така взаємодія вимагає наявність з'єднання всіх трьох фаз і одночасної роботидодатків, що завжди можливо.
Системи, побудовані за принципом обміну повідомленнями, використовують із взаємодії технологію черг повідомлень (рис.2).
 |
Рис.2. Взаємодія програм із використанням технології черг повідомлень
Програми, які обмінюються інформацією, адресують її не безпосередньо один одному, а в асоційовані з додатками черги повідомлень. З'єднання між додатком та чергою відбувається, як правило, у режимі on-line, що дозволяє уникнути витрати часу на встановлення з'єднання. Керуюче програмне забезпечення може перебувати як на одній машині з додатками, так і на виділеному сервері. Системи, що використовують технологію черг повідомлень, на відміну від систем встановлення з'єднань, не вимагають постійного з'єднання в процесі взаємодії, ні одночасної роботи взаємодіючих додатків. Ці властивості забезпечують їм гнучкість та прийнятність у різних галузях застосування.
Універсальність систем технологічної пошти дозволяє їм працювати на гетерогенних (Розмаїття програмно-апаратних платформ, на яких працюють окремі компонентиСТП, а також різноманіття способів з'єднання та протоколів взаємодії, що застосовуються в системі структурах. Гетерогенність досягається за рахунок поділу серверної та клієнтських частин СТП. Клієнтські частини мають невелику функціональність і можуть бути перенесені на різні платформи. Т.ч., для функціонування СТП не потрібні витрати на додаткове обладнання- система адаптується до існуючим засобам(як апаратним і програмним, і до існуючих каналів передачі) і вимагає їх заміни.
Перевага використання СТП:
Ø Гарантованість доставки повідомлення. Сервери черг повідомлень
самі визначають, як забезпечити гарантованість доставки при відмові окремих частинсистеми: зробити повторне пересилання, знайти альтернативний маршрут або застосувати інші способи. Так як СТП забезпечують обмін інформацією між додатками, то факт недоставки повідомлення повинен бути відстежений та оброблений (на відміну від електронної пошти, де у разі недоставки повідомлення, користувач повинен сам виконати будь-які дії, що коригують);
Ø Відсутність блокування програми тимчасово передачі, т.к. діє технологія черг повідомлень та виділення серверної частини системи ТП, що відповідає за доставку повідомлення. Відсутність блокування дозволяє зменшити час простою програм;
Ø Можливість встановлення пріоритетів повідомлень та опцій при надсиланні. Пріоритети дозволяють реалізувати декілька паралельних системпередачі повідомлень. При цьому повідомлення з нижчим пріоритетом не будуть впливати на процес доставки повідомлень з більш високим пріоритетом. Це має позитивну властивість при проектуванні та налаштуванні великих систем, і навіть при адмініструванні систем;
Ø Можливість обміну інформацією в гетерогенному середовищі, де можлива модернізація як технічних, так і програмних засобів.
Класична архітектура клієнт-сервер
Термін "клієнт-сервер" означає таку архітектуру програмного комплексу, В якій його функціональні частини взаємодіють за схемою "запит-відповідь". Якщо розглянути дві взаємодіючі частини цього комплексу, одна з них (клієнт) виконує активну функцію, т. е. ініціює запити, іншу (сервер) пасивно ними відповідає. У міру розвитку системи ролі можуть змінюватися, наприклад, деякий програмний блокодночасно виконуватиме функції сервера по відношенню до одного блоку і клієнта по відношенню до іншого.
Зауважимо, що будь-яка інформаційна система повинна мати щонайменше три основні функціональні частини - модулі зберігання даних, їх обробки та інтерфейсу з користувачем. Кожна з цих частин може бути реалізована незалежно від двох інших. Наприклад, не змінюючи програм, які використовуються для зберігання та обробки даних, можна змінити інтерфейс з користувачем таким чином, що одні й ті самі дані відображатимуться у вигляді таблиць, графіків або гістограм. Не змінюючи програм представлення даних та їх зберігання, можна змінити програми обробки, наприклад, змінивши алгоритм повнотекстового пошуку. І нарешті, не змінюючи програм представлення та обробки даних, можна змінити програмне забезпечення для зберігання даних, перейшовши, наприклад, іншу файлову систему.
У класичній архітектурі клієнт-сервер доводиться розподіляти три основні частини програми за двома фізичними модулями. Зазвичай ПЗ зберігання даних розташовується на сервері (наприклад, сервері бази даних), інтерфейс з користувачем - на стороні клієнта, а ось обробку даних доводиться розподіляти між клієнтською та серверною частинами. У цьому й полягає основний недолік дворівневої архітектури, з якого випливають кілька неприємних особливостей, що сильно ускладнюють розробку клієнт-серверних систем.
Під час розбиття алгоритмів обробки даних необхідно синхронізувати поведінку обох частин системи. Усі розробники повинні мати повну інформаціюо останніх змінах, внесених до системи, і розуміти ці зміни. Це створює великі складності при розробці клієнт-серверних систем, їх установці та супроводі, оскільки необхідно витрачати значні зусилля на координацію дій різних групспеціалістів. У діях розробників часто виникають протиріччя, а це гальмує розвиток системи та змушує змінювати вже готові та перевірені елементи.
Щоб уникнути неузгодженості різних елементів архітектури, намагаються виконувати обробку даних на одній із двох фізичних частин - або на стороні клієнта ("товстий" клієнт), або на сервері ("тонкий" клієнт, або архітектура, звана "2,5-рівневий клієнт- сервер"). Кожен підхід має недоліки. У першому випадку невиправдано перевантажується мережа, оскільки нею передаються необроблені, отже, надлишкові дані. Крім того, ускладнюється підтримка системи та її зміна, оскільки заміна алгоритму обчислень або виправлення помилки потребує одночасної повної заміни всіх інтерфейсних програм, інакше можуть виникнути помилки або неузгодженість даних. Якщо ж вся обробка інформації виконується на сервері (коли таке взагалі можливо), виникає проблема опису вбудованих процедур та їх налагодження. Справа в тому, що мова опису вбудованих процедур зазвичай є декларативною і, отже, у принципі не допускає покрокового налагодження. Крім того, систему з обробкою інформації на сервері абсолютно неможливо перенести на іншу платформу, що є серйозним недоліком.
Більшість сучасних засобів швидкої розробки додатків (RAD), які працюють з різними базами даних, реалізують першу стратегію, тобто "товстий" клієнт забезпечує інтерфейс із сервером бази даних через вбудований SQL. Такий варіант реалізації системи з "товстим" клієнтом, крім перерахованих вище недоліків, зазвичай забезпечує неприпустимо низький рівень безпеки. Наприклад, у банківських системах доводиться всім операціоністам давати права на запис до основної таблиці облікової системи. Крім того, цю систему майже неможливо перекласти на Web-технологію, оскільки для доступу до сервера бази даних використовується спеціалізоване програмне забезпечення.
Отже, розглянуті вище моделі мають такі недоліки.
1. "Товстий" клієнт:
складність адміністрування;
# ускладнюється оновлення ПЗ, оскільки його заміну потрібно проводити одночасно по всій системі;
# ускладнюється розподіл повноважень, оскільки розмежування доступу відбувається за діям, а, по таблицям;
перевантажується мережа внаслідок передачі по ній необроблених даних;
слабкий захист даних, оскільки складно правильно розподілити повноваження.
2. "Товстий" сервер:
# ускладнюється реалізація, оскільки мови типу PL/SQL не пристосовані розробки такого ПЗ і немає хороших коштівналагодження;
# продуктивність програм, написаних мовами типу PL/SQL, значно нижча, ніж створених іншими мовами, що має важливе значеннядля складних систем;
програми, написані на СУБД-мовах, зазвичай працюють недостатньо надійно; помилка в них може призвести до виходу з експлуатації всього сервера баз даних;
програми, що вийшли таким чином, повністю нестерпні на інші системи і платформи.
Для вирішення цих проблем використовуються багаторівневі (три і більше рівнів) архітектури клієнт-сервер.
Багаторівневі архітектури клієнт-сервер
Такі архітектури розумніше розподіляють модулі обробки даних, які у разі виконуються однією чи кількох окремих серверах. Ці програмні модулі виконують функції сервера для інтерфейсів з користувачами та клієнта – для серверів баз даних. Крім того, різні сервери програм можуть взаємодіяти між собою для більш точного поділу системи на функціональні блоки, що виконують певні ролі. Наприклад, можна виділити сервер керування персоналом, який виконуватиме всі необхідні для керування персоналом функції. Зв'язавши з ним окрему базу даних, можна приховати від користувачів всі деталі реалізації цього сервера, дозволивши їм звертатися лише до загальнодоступних функцій. Крім того, таку систему дуже просто адаптувати до Web, оскільки простіше розробити html-форми для доступу користувачів до певних функцій бази даних, ніж до всіх даних.
У трирівневій архітектурі "тонкий" клієнт не перевантажений функціями обробки даних, а виконує свою основну роль системи представлення інформації, що надходить із сервера додатків. Такий інтерфейс можна реалізувати за допомогою стандартних засобів Web-технології – браузера, CGI та Java. Це зменшує обсяг даних, що передаються між клієнтом та сервером додатків, що дозволяє підключати клієнтські комп'ютеринавіть повільними лініями типу телефонних каналів. Крім того, клієнтська частина може бути настільки простою, що в більшості випадків її реалізують за допомогою універсального браузера. Але якщо міняти її таки доведеться, то цю процедуру можна здійснити швидко та безболісно. Трирівнева архітектура клієнт-сервер дозволяє більш точно призначати повноваження користувачів, оскільки вони отримують права доступу не до самої бази даних, а до певних функцій сервера додатків. Це підвищує захищеність системи (проти звичайно архітектурою) як від навмисного нападу, а й від помилкових дій персоналу.
Наприклад розглянемо систему, різні частини якої працюють на кількох віддалених друзіввід одного серверів. Припустимо, що від розробника надійшла нова версія системи, для встановлення якої у дворівневій архітектурі необхідно одночасно поміняти все системні модулі. Якщо цього не зробити, то взаємодія старих клієнтів з новими серверами може призвести до непередбачуваних наслідків, оскільки розробники зазвичай не розраховують на таке використання системи. У трирівневій архітектурі ситуація спрощується. Справа в тому, що змінивши сервер додатків і сервер зберігання даних (це легко зробити одночасно, так як обидва вони зазвичай знаходяться поруч), ми відразу змінюємо набір доступних сервісів. Таким чином, ймовірність помилки через невідповідність версій серверної та клієнтської частин різко скорочується. Якщо в нової версіїбудь-який сервіс зник, то елементи інтерфейсу, які обслуговували його в старій системіпросто не працюватимуть. Якщо ж змінився алгоритм роботи сервісу, то він коректно працюватиме навіть зі старим інтерфейсом.
Багаторівневі клієнт-серверні системи досить легко можна перевести на Web-технологію - для цього достатньо замінити клієнтську частину на універсальний або спеціалізований браузер, а сервер додатків доповнити Web-сервером і невеликими програмами виклику процедур сервера. Для розробки цих програм можна використовувати як Common Gateway Interface (CGI), так і більше сучасну технологію Java.
Слід зазначити і той факт, що в трирівневій системі каналом зв'язку між сервером додатків і базою даних передається досить багато інформації. Однак це не уповільнює обчислень, тому що для зв'язку зазначених елементів можна використовувати швидкісні лінії. Це вимагає мінімальних витрат, оскільки обидва сервери зазвичай знаходяться в одному приміщенні. Таким чином, збільшується сумарна продуктивність системи - над одним завданням тепер працюють два різних сервера, а зв'язок між ними можна здійснювати по найбільш швидкісних лініях з мінімальними витратамикоштів. Щоправда, постає проблема узгодженості спільних обчислень, яку покликані вирішувати менеджери транзакцій – нові елементи багаторівневих систем.
Переклад з англійської: Чорнобай Ю. А.
Розвиток клієнт-серверних систем
Архітектура комп'ютерної системирозвинулася поряд зі здібностями апаратних засобів використовувати програми, що запускаються. Найпростішою (і ранньою) з усіх була «Mainframe Architecture», в якій всі операції та функціонування проводяться в межах серверного (або "host") комп'ютера. Користувачі взаємодіяли із сервером через «dumb» термінали, які передали інструкції, захопивши натискання клавіші, серверу та показали результати виконання інструкцій для користувача. Такі програми мали типовий характер і, незважаючи на відносно велику обчислювальну потужність серверних комп'ютерів, були в основному відносно незручними у використанні, через необхідність передавати кожне натискання клавіші серверу.
Введення та широке поширення PC, з його власною обчислювальною потужністюі графічним інтерфейсом користувача дозволяли додаткам стати більш складними, і розширення мережевих системпризвело до другого головного типу архітектури системи, "Файлового поділу". У цій архітектурі PC (або " робоча станція") завантажує файли від спеціалізованого "файл сервера" і потім управляє додатком (включаючи дані) локально. Це працює добре, коли невелике використання загальних даних, оновлення даних, і обсяг даних, які будуть передані. Однак незабаром стало ясно, що поділ файлу все більше засмічувало мережу, і програми ставали складнішими і вимагали, щоб усі Велика кількістьданих було передано в обох напрямках.
Проблеми, пов'язані з обробкою додатками даних через файл, розділений по мережі, призвели до розвитку архітектури клієнт-сервер на початку 1980-х. У цьому підході файл сервер замінений сервером баз даних, який замість того, щоб просто передати і зберегти файли підключеним робочим станціям (клієнтам), отримує і фактично виконує запити про дані, повертаючи тільки результат, що запитується клієнтом. Передаючи лише дані, які запитують клієнт, а не весь файл, ця архітектура значно зменшує навантаження на мережу. Це дозволило створити систему, в якій багато користувачів могли оновлювати дані через інтерфейси GUI, пов'язані з єдиною розділеною базою даних.
Зазвичай обмінюватись даними між клієнтом і сервером використовується або Structured Query Language (SQL) або Remote Procedure Call (RPCs). Нижче наведено кілька основних варіантів організації архітектури клієнт-сервер.
У дворівневій архітектурі навантаження розподіляється між сервером (в якому знаходиться база даних) і клієнтом (в якому знаходиться інтерфейс користувача). Як правило, вони розташовані на різних фізичних машинахале це не є обов'язковою вимогою. За умови, що рівні логічно відокремлені, вони можуть бути розміщені (наприклад, для розробки та тестування) на одному комп'ютері (рис. 1).
Малюнок 1: Двохрівнева архітектура
Розподіл логіки докладання та обробки даних у цій моделі був і залишається проблематичним. Якщо клієнт «smart» і проводить основну обробку даних, то виникають проблеми, пов'язані з розповсюдженням, встановленням та обслуговуванням програми, оскільки кожен клієнт потребує власної локальної копії програмного забезпечення. Якщо клієнт «dumb» застосування логіки та обробки повинні бути реалізовані в базі даних, а, отже, він стає повністю залежним від конкретної СУБД, що використовується. У будь-якому випадку, кожен клієнт повинен пройти реєстрацію та залежно від отриманих ним прав доступу виконувати певні функції. Тим не менш, дворівнева архітектура клієнт-сервер була гарним рішеннямколи кількість користувачів була відносно невеликою (приблизно до 100 одночасно працюючих користувачів), але зі зростанням користувачів з'явився ряд обмежень на використання цієї архітектури.
Продуктивність: Оскільки кількість користувачів зростає, продуктивність починає погіршуватися. Погіршення продуктивності прямопропорційне кількості користувачів, кожен з яких має власне підключеннядо сервера, що означає, що сервер повинен підтримувати всі ці з'єднання (з використанням "Keep-Alive" повідомлення), навіть коли робота з базою не ведеться.
Безпека: Кожен користувач повинен мати власний індивідуальний доступдо бази даних, і мати права, наданими для експлуатації програми. Для цього необхідно зберігати права доступу для кожного користувача у базі даних. Коли потрібно додати функціональності додатку і потрібно оновити права користувача.
Функціональність: Незалежно від того, який тип клієнта використовується, більша частина обробки даних повинна знаходитися в базі даних, це означає, що вона повністю залежить від можливостей, передбачених у базі даних виробником. Це може серйозно обмежити функціональність програми, оскільки різні базиДані підтримують різні функції, використовують різні мови програмування і навіть реалізують такі основні засоби, як тригери по-різному.
Мобільність: Двохрівнева архітектура настільки залежить від конкретної реалізації бази даних, що перенесення існуючих додатківдля різних СУБД стає серйозною проблемою. Це особливо очевидно у разі додатків на вертикальних ринках, де вибір СУБД не визначений постачальником.
Але, незважаючи на це, дворівневу архітектуру знайшли нове життяв епоху Інтернету. Вона може добре працювати в роз'єднаній навколишньому середовищіде UI є «dumb» (наприклад, браузер). Однак, у багатьох відношеннях ця реалізація є поверненням до початкової архітектури мейнфреймів.
У прагненні подолати обмеження дворівневої архітектури, описаних загальних рисахвище, було запроваджено додатковий рівень. Така архітектура є стандартною моделлюклієнт-сервер із трирівневою архітектурою. Мета додаткового рівня (зазвичай його називають "middle" або "rules" рівень) - керувати прикладним виконанням та керуванням базою даних. Як і з дворівневою моделлю, рівні можуть розташовуватися або на різних комп'ютерах(Малюнок 2), або на одному комп'ютері в тестовому режимі.
Рисунок 2: Трирівнева архітектура
Ввівши середній ряд, обмеження дворівневої архітектури значною мірою були усунуті, в результаті вийшла набагато гнучкіша і масштабована система. Оскільки тепер клієнти з'єднуються лише з прикладним сервером, а чи не безпосередньо до серверу даних, навантаження збереження з'єднань видаляється, як і необхідність здійснити прикладну логіку не більше бази даних. База даних тепер може виконувати тільки функції зберігання та пошуку даних, а завдання приймання та обробки заявок можуть виконувати середній рівеньтрирівневої архітектури. Розвиток операційних систем, Що включає такі елементи, як пул з'єднань, черги та обробки розподілених транзакцій зміцнив (і спростив) розвиток середнього рівня.
Зверніть увагу на це, у цій моделі, прикладний серверне керує інтерфейсом користувача, і при цьому користувач фактично не звертається із запитами безпосередньо до бази даних. Натомість це дозволяє численним клієнтам розділяти ділову логіку, обчислення, та доступ до пошуковій системіданих. Головна перевага полягає в тому, що клієнт вимагає менше програмного забезпечення і йому більше не потрібно пряме підключеннядо бази даних, що підвищує безпеку. Отже, додаток більш масштабований, витрати на підтримку та встановлення на один сервер значно менші, ніж для підтримки програм прямо на комп'ютері клієнта або навіть на дворівневу архітектуру.
Є багато варіантів основних трирівневих моделей, призначених для виконання різних функцій. До них відносяться обробка розподілених транзакцій (коли кілька СУБД оновлюються в одному протоколі), програми, що базуються на повідомленнях (де програми не спілкуються в режимі реального часу) та крос-платформної сумісності (Object Request Brokerабо "ORB" програми).
Багаторівнева архітектура або N-рівнева архітектура
З розвитком інтернет-додатків на тлі загального підвищення кількості користувачів основна трирівнева клієнт-серверна модель була розширена шляхом введення додаткових рівнів. Такі архітектури називають багаторівневі, зазвичай вони складаються з чотирьох рівнів (рисунок 3), де в мережі сервер відповідає за обробку з'єднання між клієнтом браузером і сервером додатків. Вигода полягає в тому, що кілька веб-серверів можуть підключатися до одного сервера додатків тим самим, збільшуючи обробку більшого числаодночасно підключених користувачів.
Малюнок 3: N-рівнева архітектура
Рівні проти верств
Ці терміни (на жаль) часто плутають. Проте з-поміж них велика різниця і мають певний сенс. Основна відмінність полягає в тому, що рівні знаходяться фізичному рівніа шари на логічному. Іншими словами рівень, теоретично, може бути розгорнутий незалежно на окремому комп'ютері, а шар логічний поділвсередині рівня (рис. 4). Типова трирівнева модель, описана вище, зазвичай містить, щонайменше сім шарів, розділених на всіх трьох рівнях.
Головне, що потрібно пам'ятати про багаторівневу архітектуру є те, що запити та відповіді кожного потоку в одному напрямку проходять по всіх шарах, і що шари ніколи не можуть бути пропущені. Таким чином, у моделі, показаній на малюнку 4, єдиний шар, який може звернутися до шару "E" (шар доступу до даних) є шар "D" (шар правил). Аналогічно шар "C" (прикладний шар ратифікації) може тільки відповідати на запити з шару "B" (шару обробка помилок).
Рисунок 4: Ряди поділені на логічні шари
Багаторівнева архітектура клієнт-сервер
Багаторівнева архітектура клієнт-сервер - різновид архітектури клієнт-сервер, в якій функція обробки даних винесена на один або декілька окремих серверів. Це дозволяє розділити функції зберігання, обробки та подання даних для більш ефективного використанняможливостей серверів та клієнтів.
Приватні випадки багаторівневої архітектури:
· Трирівнева архітектура
· Мережа з виділеним сервером
· Мережа з виділеним сервером (англ. Client/Server network) – це локальна обчислювальна мережа(LAN), в якій мережеві пристроїцентралізовані та керуються одним або декількома серверами. Індивідуальні робочі станції або клієнти (такі як ПК) повинні звертатися до ресурсів мережі через сервер(и).
Мережева операційна система- операційна система з вбудованими можливостями для роботи в комп'ютерних мережах. До таких можливостей можна віднести:
· Підтримку мережевого обладнання
· Підтримку мережевих протоколів
· Підтримку протоколів маршрутизації
· Підтримку фільтрації мережевого трафіку
· Підтримка доступу до віддалених ресурсів, таких як принтери, диски тощо по мережі
· Наявність в системі мережевих службщо дозволяє віддаленим користувачамвикористовувати ресурси комп'ютера
Приклади мережевих операційних систем:
· Novell NetWare
· Microsoft Windows(95, NT, XP, Vista, Seven)
· Різні UNIX системи, такі як Solaris, FreeBSD
· Різні GNU/Linux системи
· ZyNOS компанії ZyXEL
Сучасні мережеві ОС (UNIX,WIN2000,NOWELL NW) реалізують повний стек протоколів моделі OSI.Так у UNIX підтримується стек протоколів (TCP/IP,NW LINK,NET BIOS). У Nowell NW підтримується стек протоколів IPX/SPX. Aplle Mac використовується свій набір протоколів.
Незалежно від виробника всі мережеві ОС здійснюють наступні функції:
1. Розподіл функцій між вузлами мережі (клієнти та сервери);
2. Підтримка комунікаційних протоколів;
3. Підтримка мережної файлової системи;
4. Захист даних.
Усі мережні ОС можна розділити на 2 види:
1. Однорангові або рівноправні мережі (кожен із кожних). Приклад Windows 9x;
2. Мережа з урахуванням виділеного сервера.
К1.В одноранговій мережі всі ПК рівноправні, однак у мережі є клієнти і сервери. Зазвичай кожен ПК може перекладатися режим сервера, якщо користувач сам цього захоче (виділяється загальний ресурс).
Мережева ОС для однорангової мережі не відрізняється надійною продуктивністю та рівнем захисту. Використовується в мережі, коли 10-15 пк. Прикладом однорангової мережі є Win94/98/OS/2/LANtastic
K2.У цій мережі завжди існує головний ПК - сервер, який спеціально оптимізований для швидкої обробкизапитів від багатьох клієнтів (порядку -100) та для управління захистом файлів та каталогів. У великих мережахвиділяються окремі серверидля окремих додатків(WEB – сервер, Файл – сервер, Принт – сервер, сервер БД та поштовий сервер)
Серверне програмне забезпечення відрізняється високою складністю, надійністю та продуктивністю. Воно може працювати на різних платформах.
