Ppt - серверні і клієнтські сценарії web-додатків powerpoint presentation

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

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

Мережа Інтернет організована за схемою клієнт-сервер. У класичному випадку дана схема функціонує наступним чином:

клієнт формує і посилає запит на сервер баз даних;

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

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

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

У сервісі WWW для передачі інформації застосовується протокол НТТР (HyperText Transmition Protocol).

Основні транзакцій HTTP:

Браузер декодує першу частину URL (Universal Resource Locator) і встановлює з'єднання з сервером.

Браузер передає решту URL на сервер.

Сервер визначає по URL шлях і ім'я файлу.

Сервер пересилає вказаний файл браузеру.

Сервер перериває з'єднання.

Браузер відображає документ.

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

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

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

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

Архітектура "товстий клієнт - тонкий сервер": велика частина функцій програми вирішувалася клієнтом, сервер займався тільки обробкою SQL-запитів.

Архітектура "товстий" клієнт має такі недоліки:

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

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

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

слабкий захист даних, оскільки складно правильно розподілити повноваження.

Архітектура "тонкий клієнт - товстий сервер": використання на сервері процедур (stored procedure - відкомпілювалися програми з внутрішньою логікою роботи), призвело до тенденції переносити все більшу частину функцій на сервер. Збережені процедури реалізовували частина бізнес-логіки і гарантували виконання операції в рамках єдиної транзакції. Таке рішення має очевидні переваги, наприклад його легше підтримувати, т. К. Все зміни потрібно вносити тільки в одному місці - на сервері.

Архітектура "товстий" сервер має такі недоліки:

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

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

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

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

Для вирішення перерахованих проблем використовуються багаторівневі (три і більше рівнів) архітектури клієнт-сервер.

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

Сервер додатків обробляє наступні компоненти:

презентаційна логіка (Presentation Layer - PL) - призначена для роботи з даними користувача;

бізнес-логіка (Business Layer - BL) - призначена для перевірки правильності даних, підтримки посилальної цілісності;

логіка доступу до ресурсів (Access Layer - AL) - призначена для зберігання даних.

Підхід Remote Data Access (RDA) має на увазі об'єднання в клієнтському додатку PL і BL (проте в разі потреби виконання будь-яких змін в клієнтському додатку доведеться змінювати вихідний код), а серверна частина являє собою сервер баз даних, реалізує AL.

Будь-яка інформаційна система, побудована на основі клієнт-серверних технологій, повинна містити наступні компоненти:

шлюз-сервер, керуючий правами доступу до інформаційної системи;

сервер баз даних;

сервер додатків і (або) сервер обробки транзакцій.

Взаємодія WWW сервера з базами даних може бути організовано двома способами:

через сервер (менеджер) транзакцій;

через API інтерфейс WWW сервера або сервера додатків.

Менеджери транзакцій дозволяють одного сервера додатків одночасно обмінюватися даними з декількома серверами баз даних.

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

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

Перші менеджери транзакцій з'явилися на початку 70-х рр. (Наприклад, CICS); з тих пір вони незначно змінилися ідеологічно, але має велике значення - технологічно.

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

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

Логічно MT ділиться на кілька частин:

комунікаційний менеджер (Communication Manager) - контролює обмін повідомленнями між компонентами інформаційної системи;

менеджер транзакцій (Transaction Manager) - управляє розподіленими операціями;

менеджер ведення журнальних записів (Log Manager) - стежить за відновленням і відкотом розподілених операцій;

менеджер блокувань (Lock Manager) - забезпечує правильний доступ до спільно використовуваних даних.

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

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

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

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

Рівень 2.Сервер баз даних реалізує основні функції вибірки інформації з БД. Для публічної інформаційної системи ці функції зводяться до наступних:

отримання запиту з рівня 3;

логічний розбір рядка запиту;

повернення даних на рівень 3.

Відповідно до цього сервер БД обробляє наступні запити.

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

Форматний - запит на надання списку визначених форматів виводу даних. У вхідному потоці - ідентифікатор БД, в вихідному - пронумерований список визначених форматів для даної БД.

Основний - запит на надання даних в необхідному форматі з параметрами. У вхідному потоці - ідентифікатор БД, рядок запиту, номер запису початку виведення, кількість записів для виведення, ідентифікатор формату, в вихідному - Форматована вибірка з БД.

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

Рівень 3. "клієнт-сервер" Сервер WWW з модулем управління серверами БД - диспетчер БД - призначений для обробки запитів користувачів, формування запитів до серверів БД і повернення клієнтам отриманої інформації по протоколу HTTP і специфікаціям HTML. Оптимальним варіантом є Windows NT + IIS з підтримкою JAVA і ASP (Active Server Pages) з огляду на тісну інтеграцію IIS з операційною системою і можливістю організації багатопотокової обробки даних порівняно простими і дешевими засобами. Керуючий модуль (диспетчер БД) може бути реалізований у вигляді динамічної бібліотеки і (або) набору об'єктів ASP.

Диспетчер БД виконує наступні функції:

зберігання та надання користувачам поточної інформації про доступні БД;

формування запитів до серверів БД і повернення клієнтам отриманої інформації у необхідній кодуванні;

зберігання інформації про права доступу на кожну доступну БД і перевірка їх для кожного користувача;

облік і збір статистики звернень до БД відповідно до поточних установками;

синхронізація версій серверів БД і їх оновлення;

при наявності рівня 4 передача службової інформації про себе та про підтримувані базах даних на рівень 4.

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

Рівень 4.Головними диспетчер (ГД) інформаційної системи являє собою сервер WWW, функціонально ідентичний сервера рівня 3, але наділений додатковою функцією зберігання інформації про всієї інформаційної системи в цілому. В ідеальному випадку кожен з серверів рівня 3 повинен бути готовий взяти на себе роль головного диспетчера. Основне завдання ГД - отримати інформацію про конфігурацію кожного сервера рівня 3 і розтиражувати її по всіх серверів.

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

Схожі статті

Ppt - проект на тему «секрети двійковій системи числення» powerpoint presentation