Модель серверу баз даних

Рис. 1.4. Модель серверу баз даних

Реалізована в СУБД Informix, Ingres, Oracle.

Основні властивості:

− основа модель-механізм збережених процедур - засіб програмування SQL -сервера;

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

− компонент подання виконується на комп'ютері-клієнті;

− прикладної компонентів і ядро ​​СУБД на комп'ютері-сервері бази даних.

Переваги:

− можливість централізованого адміністрування;

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

Недоліки:

− в більшості СУБД недостатньо можливостей для налагодження та зведення до одного типу збережених процедур;

− обмеженість коштів для написання збережених процедур.

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

Модель серверу додатків

Рис. 1.5. Модель серверу додатків

Основні властивості:

− на комп'ютері-клієнті виконується процес, що відповідає за інтерфейс з користувачем;

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

− прикладної компонент реалізований як група процесів, що виконують прикладні функції, і називається сервером додатка (AS);

− всі операції над БД виконуються відповідним компонентом, для якого AS - клієнт.

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

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

AS -модель є фундаментом для моніторів обробки транзакцій.

Методи передачі даних між клієнтом і сервером

REST

REST - метод взаємодії компонентів розподіленого додатка в мережі Інтернет, при якому виклик віддаленої процедури являє собою звичайний HTTP -запит (зазвичай GET або POST; такий запит називають REST -запит), а необхідні дані передаються як параметри запиту. Цей спосіб є альтернативою більш складним методам, таким як SOAP.

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

Вимогами до створення REST -додатків є:

− Клієнт-серверна архітектура.

− Сервер не зобов'язаний зберігати інформацію про стан клієнта.

− У кожному запиті клієнта повинно явно міститися вказівка ​​про можливість кешування відповіді і отримання відповіді з існуючого кешу.

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

− Уніфікований програмний інтерфейс сервера. URI як приклад формату запитів до сервера, а як приклад відповіді сервера формати HTML, XML і JSON.

Додатки, що не відповідають наведеним умовам, не можуть називатися REST -додатками. Якщо ж всі умови дотримані, то додаток отримає такі переваги: ​

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

− продуктивність (за рахунок використання кешу);

− масштабованість;

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

− простота інтерфейсів;

− портативність компонентів;

− легкість внесення змін;

− здатність еволюціонувати, пристосовуючись до нових вимог.

SOAP

SOAP - протокол обміну структурованими повідомленнями в розподіленої обчислювальної середовищі. Спочатку SOAP призначався в основному для реалізації RPC. Зараз протокол використовується для обміну довільними повідомленнями у форматі XML, а не тільки для виклику процедур. Офіційна специфікація останньої версії 1.2 протоколу ніяк не розшифровує назву SOAP. SOAP є розширенням протоколу XML - RPC.

SOAP може використовуватися з будь-яким протоколом прикладного рівня: SMTP, FTP, HTTP, HTTPS та ін. Однак його взаємодія з кожним із цих протоколів має свої особливості. Найчастіше SOAP використовується над HTTP.

Таблиця 1.2

Структура SOAP

Елемент	Опис	Необхідність
Конверт	Визначає XML документ як SOAP повідомлення	Так
Заголовок	Містить інформацію заголовку	Ні
Тіло	Містить виклик і інформацію відповіді	Так
Помилки	Надає інформацію про помилки, що виникли під час обробки повідомлення	Ні

Переваги:

− SOAP достатньо універсальний, і находить використання в різних транспортних протоколів. Стандартні стеки використовують HTTP в якості транспортного протоколу, але і інші протоколи, такі як SMTP також можуть бути використані;

− Так як модель SOAP добре проходить через HTTP post / response модель, вона з легкістю проходить через фаерволи та проксі без втручання та змін в SOAP протокол.

Недоліки:

− При використанні стандартних можливостей і стандартного SOAP / HTTP зв’язування, XML набір даних визначається як XML. Через це SOAP може бути більш повільним ніж необхідно;

− При використанні HTTP в якості транспортного протоколу ролі взаємодіє сторін фіксовані. Тільки одна сторона(клієнт) може використовувати послуги іншого. Розробники мають використовувати запит замість того щоб використовувати повідомлення.

Дата добавления: 2015-12-07