Ім'я файлу: Ксьонов. ІТІР-19-1. ПтРІС. Реферат.docx
Розширення: docx
Розмір: 421кб.
Дата: 07.04.2023
скачати
Пов'язані файли:
метод рек.pdf
Датчики Холла, принцип дії та застосування_Микитченко Дмитро_ЕП-
Попов. ІТІР-19-1. ПтРІС. Презентація.Паралельні структури обчисл

Міністерство освіти і науки України

Харківський національний університет радіоелектроніки

Кафедра РТІКС


Дисципліна:

«Паралельні та розподільні інформаційні системи»


Реферат

на тему: "Технології розподілених систем та паралельних обчислень"


Виконав:

Студент групи ІТІР-19-1

Ксьонов Богдан




Прийняла:

Старший викладач кафедри

Штих Інна Анатолівна

з оцінкою «____________»

«____»_______________20___р.



Харків 2023

ЗМІСТ



ВСТУП 3

1 КЛАСИЧНА ДВОРІВНЕВА АРХІТЕКТУРА «КЛІЄНТ – СЕРВЕР» 5

2. ТРИРІВНЕВА МОДЕЛЬ 10

3. РІЗНІ МОДЕЛІ ТЕХНОЛОГІЇ «КЛІЄНТ – СЕРВЕР» 13

ВИСНОВКИ 21

ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ 22


ВСТУП



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

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

Наприклад, у випадку веб-додатків, клієнтська частина (браузер) звертається до сервера за отриманням вмісту веб-сторінки або виконанням певної операції, а сервер обробляє запит, генерує вміст та повертає результат клієнту.



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

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

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

Згодом малофункціональну модель файлового сервера для локальних мереж (FS) замінили моделі структури «Клієнт-сервер» (RDA, DBS і AS), що з'явилися одна за одною.

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

Обчислювальні системи, побудовані на основі Intranet, мають у своєму складі центральні сервери інформації та розподілені компоненти подання інформації кінцевого користувача (програми-навігатори, або браузери).

Взаємодія між клієнтом та сервером у Intranet відбувається за допомогою web – технологій.

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


1 КЛАСИЧНА ДВОРІВНЕВА АРХІТЕКТУРА «КЛІЄНТ – СЕРВЕР»



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

Технологія «Клієнт – сервер» - це архітектура програмного комплексу, в якій відбувається розподіл прикладної програми за двома логічно різними компонентами (клієнт і сервер), що взаємодіють за схемою «запит-відповідь» і вирішують свої завдання (рисунок 1.1)[1].


Рисунок 1.1 – Архітектура «Клієнт – сервер»
Комп'ютер (або програма), що управляє та/або володіє яким-небудь ресурсом, називають сервером цього ресурсу.

Комп'ютер (або програма), що запитує та користується якимось ресурсом, називають клієнтом цього ресурсу.

Клієнт та сервер можуть перебувати як на одному комп'ютері (ПК), так і на різних ПК у мережі. Також може виникати така ситуація, коли деякий програмний блок одночасно виконуватиме функції сервера по відношенню до одного блоку і клієнта по відношенню до іншого[4].

Основний принцип технології «Клієнт-сервер» полягає у розділенні функцій програми як мінімум на три групи:

  • модулі інтерфейсу з користувачем;

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

  • модулі зберігання даних;

Цю групу також називають бізнес-логікою. Бізнес-логіка визначає, навіщо конкретно призначено додаток (наприклад, прикладні функції, притаманні даної предметної області). Розподіл програми за межами між програмами забезпечує природну основу для розподілу програми на кількох комп'ютерах.

  • модулі обробки даних (функції управління ресурсами);

Цю групу називають логікою доступу до даних або алгоритмами доступу до даних. Алгоритми доступу до даних історично розглядалися як специфічний для конкретного застосування інтерфейс механізму постійного зберігання даних на кшталт файлової системи або СУБД[7]. За допомогою модулів обробки даних організується специфічний додаток інтерфейс до СУБД.

За допомогою інтерфейсу додаток управляє з'єднаннями з базою даних та запитами до неї (переклад специфічних для конкретного додатка запитів на мову SQL, отримання результатів та переведення цих результатів назад у специфічні для конкретного додатка структури даних).

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

Відповідно до розділення функцій у будь-якій програмі виділяються такі компоненти:

  • Компонент представлення даних;

  • Прикладний компонент;

  • Компонент управління ресурсом.

У класичній архітектурі клієнт-сервер доводиться розподіляти три основні частини програми за двома фізичними модулями.

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

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

Щоб уникнути неузгодженості різних елементів архітектури, було створено дві модифікації дволанкової архітектури «Клієнт – сервер»: «Товстий клієнт» («Тонкий сервер») та «Тонкий клієнт» («Товстий сервер»).

У цих архітектурах розробники спробували виконувати обробку даних однією з двох фізичних частин - або за клієнта («Товстий клієнт»), або сервері («Тонкий клієнт).

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

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

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

Якщо все-таки розробляється дворівнева класична архітектура «Клієнт – сервер», необхідно пам'ятати таке:

  • архітектура "Товстий сервер" аналогічна архітектурі "Тонкий клієнт" (рисунок 1.3);



Рисунок 1.2 – Архітектура «Тонкий клієнт»
Передача запиту від клієнта на сервер, обробка запиту на сервер і передача результату клієнту. При цьому архітектури мають такі недоліки:

  • ускладнюється реалізація, оскільки мови типу SQL не пристосовані розробки такого ПЗ немає хороших засобів налагодження;

  • продуктивність програм, написаних мовами типу SQL, значно нижча, ніж створених іншими мовами, що має значення для складних систем;

  • програми, написані на СУБД-мовах, зазвичай працюють недостатньо надійно; помилка в них може призвести до виходу з експлуатації всього сервера баз даних;

  • програми, що вийшли таким чином, повністю нестерпні на інші системи і платформи.

  • архітектура "Тонкий сервер" аналогічна архітектурі "Товстий клієнт" (рисунок 1.2).

Обробка запиту відбувається за клієнта, тобто відбувається передача клієнту всіх необроблених даних із сервера. При цьому архітектури мають такі недоліки:

  • ускладнюється оновлення ПЗ, оскільки його заміну потрібно проводити одночасно по всій системі;

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

  • перевантажується мережа внаслідок передачі необроблених даних; - слабкий захист даних, оскільки важко правильно розподілити повноваження.



Рисунок 1.3 – Архітектура «Товстий клієнт»
Для вирішення цих проблем використовуються багаторівневі (три і більше рівнів) архітектури «Клієнт-сервер».

2. ТРИРІВНЕВА МОДЕЛЬ




З середини 90-х років минулого століття визнання фахівців отримала триланкова архітектура «Клієнт – сервер», яка розділила інформаційну систему за функціональними можливостями на три окремі компоненти: логіка уявлення, бізнес-логіка та логіка доступу до даних.

На відміну від дволанкової архітектури, у триланковій з'являється додаткова ланка - сервер додатків, який призначений для здійснення бізнес-логіки, при цьому повністю розвантажується клієнт, який надсилає запити проміжному програмному забезпеченню, та максимально використовуються всі можливості серверів[2].

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

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

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

Сервер програм – це програмне забезпечення, яке є проміжним шаром між клієнтом та сервером (рисунок 2.1).



Рисунок 2.1 - Сервер додатків
Існує кілька категорій продуктів проміжного шару:

  • Message orientated – яскраві представники MQseries та JMS;

  • Object Broker – яскраві представники CORBA та DCOM;

  • Component based – яскраві представники .NET та EJB.

Використання сервера програм дає більше можливостей, наприклад, зменшується навантаження на клієнтські комп'ютери, тому що сервер програм розподіляє навантаження і забезпечує захист від збоїв. Оскільки бізнес-логіка зберігається на сервері додатків, то за будь-яких змін у звітності чи розрахунках клієнтські програми аж ніяк не зачіпаються[3].

Існує кілька серверів додатків від таких знаменитих компаній як Sun Microsystem, Borland, IBM, Oracle і кожен з них відрізняється набором сервісів, що надаються (продуктивність в даному випадку враховувати не будемо). Ці послуги полегшують програмування та розгортання додатків масштабу підприємства. Зазвичай сервер додатків надає такі послуги:

  • WEB Server – найчастіше включають у постачання найпопулярніший і найпотужніший Apache;

  • WEB Container – дозволяє виконувати JSP та сервлети. Для Apache таким сервісом є Tomcat;

  • CORBA Agent – може надавати розподілену директорію для зберігання CORBA об'єктів;

  • Messaging Service – брокер повідомлень;

  • Transaction Service – з назви зрозуміло, що це обслуговування транзакцій;

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

  • Java Mail – цей сервіс може надавати сервіс до SMTP;

  • JMS (Java Messaging Service) – обробка синхронних та асинхронних повідомлень;

  • RMI (Remote Method Invocation) – виклик віддалених процедур.

Багаторівневі клієнт-серверні системи досить легко можна перевести на Web-технологію - для цього достатньо замінити клієнтську частину на універсальний або спеціалізований браузер, а сервер додатків доповнити Web-сервером і невеликими програмами виклику процедур сервера. Для розробки цих програм можна використовувати як Common Gateway Interface (CGI), так і сучаснішу технологію Java[6].

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

З усього вищесказаного можна дійти невтішного висновку, що дворівнева архітектура сильно поступається багаторівневої архітектурі, у час використовується лише багаторівнева архітектура «Клієнт – сервер», у якій розрізняють три модифікації - RDA, DBS і AS[8].

3. РІЗНІ МОДЕЛІ ТЕХНОЛОГІЇ «КЛІЄНТ – СЕРВЕР»




Найпершою базовою технологією для локальних мереж була модель файлового сервера (FS). У свій час ця технологія була дуже серед вітчизняних розробників, які використовували такі системи, як FoxPro, Clipper, Clarion, Paradox і так далі[3].

У моделі FS функції всіх трьох компонентів (компонент представлення, прикладний компонент та компонент доступу до ресурсів) поєднані в одному коді, який виконується на комп'ютері-сервері (хості).

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

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

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

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



Рисунок 3.1 - Модель файлового сервера

Перевагами даної технології є:

  • Простота розробки додатків;

  • Зручність адміністрування та оновлення ПЗ через компактне розташування всіх компонентів на одному комп'ютері;

  • Низька вартість обладнання робочих місць (термінали або дешеві комп'ютери з невисокими характеристиками в режимі емуляції терміналу завжди дешевші за повноцінні ПК).

Але переваги FS – моделі перекривають її недоліки:

  • Велике завантаження мережі;

Незважаючи на невеликий обсяг даних, що пересилаються по мережі, час відгуку є критичним, оскільки кожен символ, введений користувачем на терміналі, повинен бути переданий на сервер, оброблений програмою і повернутий назад для виведення на екран терміналу. Крім цього, існує проблема розподілу навантаження між кількома комп'ютерами[5].

Завдяки вирішенню проблем, властивих технології «Файл – сервер» з'явилася прогресивніша технологія, що отримала назву «Клієнт – сервер».

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

Відмінності у реалізації додатків у рамках технології «Клієнт-сервер» визначаються чотирма чинниками:

  • Які види програмного забезпечення у логічних компонентах;

  • Які механізми програмного забезпечення застосовуються для реалізації функцій логічних компонентів;

  • Як логічні компоненти розподіляються комп'ютерами у мережі; - які механізми використовують для зв'язку компонент між собою.

Виходячи з цього, виділяються три підходи, кожен з яких реалізований у відповідній моделі технології «Клієнт – сервер»:

  • Модель доступу до віддалених даних (Remote Date Access – RDA); - модель сервера бази даних (DateBase Server – DBS); - Модель сервера додатків (Application Server - AS).

Розглянемо функції та характеристики різних моделей технології «Клієнтсервер».

Модель доступу до віддалених даних (RDA) – мережна архітектура технології «Клієнт – сервер», за якої коди компонента представлення та прикладного компонента поєднані та виконуються на комп'ютері-клієнті. Доступ до інформаційних ресурсів забезпечується за допомогою непроцедурної мови (наприклад, SQL – запитів для баз даних) або викликами функцій спеціальної бібліотеки (якщо є спеціальний інтерфейс прикладного програмування – API).

Запити до інформаційних ресурсів надсилаються по мережі віддаленому комп'ютеру, який обробляє та виконує їх, повертаючи клієнту блоки даних (рисунок 3.2).



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

При цьому RDA-модель має низку обмежень.

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

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

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

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

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

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

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

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



Рисунок 3.3 – Модель сервера бази даних
Переваги DBS-моделі перед RDA-моделлю очевидні: це і можливість централізованого адміністрування різних функцій, і зниження трафіку мережі через те, що замість SQL-запитів по мережі передаються виклики процедур, що зберігаються, і можливість поділу процедури між декількома додатками, і економія ресурсів комп'ютера за рахунок використання одного разу створеного плану виконання процедури. Проте є недоліки.

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

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

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

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

Всі недоліки DBS - моделі враховані в AS-моделі, яка найбільше відображає сильні сторони технології клієнт-сервер.

Модель сервера додатків (AS) (рисунок 3.4) - мережева архітектура технології «Клієнт – сервер», що є процесом, що виконується на комп'ютері-клієнті і відповідальний за інтерфейс з користувачем (введення та відображення даних). Основним елементом даної моделі є прикладний компонент, що називається сервером програми, що функціонує на віддаленому комп'ютері (або кількох комп'ютерах). Сервер додатків реалізований як група прикладних функцій, оформлених як сервісів (служб). Кожен сервіс надає деякі послуги всім програмам, які бажають та можуть ними скористатися.



Рисунок 3.4 – Модель сервера додатків

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

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

Запити, що надходять від клієнта, вишиковуються в чергу до AS-процесу, який витягує та передає їх для обробки службі відповідно до пріоритетів.

Так як дані «заховані» за сервером додатків, у якому зазвичай вбудована перевірка повноважень клієнта, СУБД забезпечується високий рівень захисту даних[9].

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

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

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

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

В AS-моделі реалізована триланкова схема поділу функцій, де прикладний компонент виділено як найважливіший ізольований елемент програми, що має стандартизовані інтерфейси з іншими двома компонентами.

Незважаючи на свою назву технологія «Клієнт-сервер» також є системою розподілених обчислень. У разі розподілені обчислення розглядаються як архітектура «Клієнт – сервер» з участю кількох серверів. Стосовно розподіленої обробки термін "сервер" означає просто програму, що відповідає на запити та виконує необхідні дії на запит клієнта.

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

Оскільки обробка здійснюється у будь-якому місці мережі, розподілені обчислення в архітектурі «Клієнт-сервер» гарантують ефективне масштабування. Щоб досягти балансу між клієнтом та сервером, компонент програми повинен виконуватися на сервері лише в тому випадку, коли централізована обробка ефективніша. Якщо логіка програми, що взаємодіє з централізованими даними, зосереджена на тій же машині, що і дані, їх необов'язково передавати через мережу, тому вимоги до мережевого середовища можуть бути знижені[10].

ВИСНОВКИ



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

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

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



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

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

ПЕРЕЛІК ДЖЕРЕЛ ПОСИЛАННЯ





  1. "Distributed Systems: Principles and Paradigms" by Andrew S. Tanenbaum and Maarten Van Steen.

  2. "TCP/IP Illustrated, Volume 1: The Protocols" by W. Richard Stevens.

  3. "High Performance Browser Networking" by Ilya Grigorik.

  4. "RESTful Web Services" by Leonard Richardson, Sam Ruby, and David Heinemeier Hansson.

  5. "Service-Oriented Architecture: Concepts, Technology, and Design" by Thomas Erl.

  6. "Building Microservices" by Sam Newman.

  7. "Architecting Modern Web Applications with ASP.NET Core and Azure" by Steve Smith and Shawn Wildermuth.

  8. "Scalability Rules: 50 Principles for Scaling Web Sites" by Martin L. Abbott and Michael T. Fisher.

  9. "Designing Data-Intensive Applications" by Martin Kleppmann.

  10. "The Client-Server Architecture" by Douglas E. Comer.

скачати

© Усі права захищені
написати до нас