ЛЕКЦІЯ 20. АРХІТЕКТУРА ТА ПРОЕКТУВАННЯ КОМПОНЕНТНИХ СИСТЕМ
План
20.1. Основні види архітектур ПЗ
20.2. Розподілена архітектура компонентних систем. Модель Клієнт-сервер
20.2.1. Дворівнева архітектура клієнт-сервер
20.2.2. Трирівнева архітектура клієнт-сервер
20.2.3. Багаторівневі архітектури
20.3. Сервісо-орієнтованана архітектура програмного забезпечення.
20.3.1. Поняття сервісо-орієнтованої архітектури
20.3.2. Основи веб-сервісів
20.3.3. Стек технологій веб-сервісів
20.3.4. Взаємодія з веб-сервісами
20.1. Основні види архітектур програмного забезпечення
У попередніх лекціях ми розглядали створення локальних (автономних) Windows-застосунків. В результаті компіляції і збирання застосунку створювався один програмний компонент у формі збірки.
У вигляді локальних застосунків розробляють сервісні програми, системні утиліти, текстові і графічні редактори, компілятори, прості корпоративні програми.
Розвинена корпоративна інформаційна система, як правило, не може складатися з окремих, не зв'язаних між собою компонентів. Тому сучасні розподілені інформаційні системи будуються з використанням розподілених архітектур серед який найбільшого поширення набули:
- клієнт-серверна;
- сервісо-орієнтована.
Клієнт-серверна архітектура набула поширення з початку 1990-х років на тлі зростання ринку персональних комп'ютерів і зниження попиту на мейнфрейми. У архітектурі "клієнт-сервер" програмне забезпечення розділене на дві частини – клієнтську частину і серверну частину. Завдання клієнтської частини (програми-клієнта) полягає у взаємодії з користувачем, передачі запиту користувача серверу, отримання результату запиту від серверної частини (програми-сервера) і представлення його в зручному для користувача вигляді. Програма-сервер обробляє запити клієнта і видає відповіді.
Класичні приклади: Web-технології (клієнт-браузер, Web-сервер), робота з розподіленими системами керування базами даних (СКБД).
В цій лекції ми розглянемо різні архітектури моделі "Клієнт-сервер" (п.20.2).
20.2. Розподілена архітектура компонентних систем. Модель Клієнт-сервер
Базовою моделлю архітектури в компонентних системах є дворівнева модель Клієнт-сервер.
У цій моделі всі процеси в системі діляться на дві групи, що можливо перекриваються. Процеси, що реалізують деяку службу, наприклад, службу файлової системи або БД, називаються серверами. Процеси, що запрошують служби в серверів шляхом посилки запиту і подальшого чекання відповіді від сервера, називаються клієнтами.
Рис. 20.1. Модель «Клієнт-сервер»
Ця модель завжди була предметів суперечок серед розробників ПЗ, що стосуються в, першу чергу, розділення функцій компонентів системи між клієнтом і сервером. Зазвичай чіткої відмінності немає. Наприклад, сервер РБД може виступати клієнтом, який передає запити на файлові сервери, що відповідають за реалізацію таблиць цією БД.
Проте, розглядаючи різні застосування типу клієнт-сервер, для роботи з БД, рекомендують розділяти їх на три логічні рівні:
- рівень інтерфейсу користувача;
- рівень обробки;
- рівень даних.
Рівень інтерфейсу. Зазвичай реалізується на клієнті.
Рівень обробки. На цьому рівні зазвичай реалізується основна логіка компонента (функціональність).
Рівень даних. Містить програми, які надають дані застосуванням, які їх обробляють. Особливою властивістю цього рівня є вимога збереження (persistence). Це означає, що коли застосування не працює, дані повинні зберігатися у визначеному місці (файлі або БД) для подальшого використання. Цей рівень зазвичай реалізується на сервері.
Рис. 20.2. Логічні рівні застосунку
Окрім зберігання даних, цей рівень забезпечує підтримку цілісності даних для різних застосувань. Для БД підтримка цілісності означає, що схеми БД, специфічні умови застосунків, збережувані процедури і інше також зберігаються на цьому рівні.
Зазвичай рівень даних реалізується у формі реляційної БД. Це забезпечує незалежність даних від програм. Використання реляційних баз даних в моделі клієнт-сервер допомагає відокремити рівень обробки від рівня даних, розглядаючи дані і їх обробку незалежно один від одного.
Варіанти архітектури клієнт-сервер
Розділення системи на три логічні рівні призводить до проблеми фізичного розподілу компонентів по окремих комп'ютерах в моделі клієнт-сервер. Найпростіша організація передбачає використання двох типів машин:
1. Клієнтські машини (робочі станції), на яких встановлюються програми-клієнти, що реалізують інтерфейс.
2. Сервери, що реалізують все інше, тобто рівні обробки і даних.
Проблема такої організації полягає в тому, що компонентна система не є розподіленою, все відбувається на сервері, а клієнт використовується як простий термінал.
20.2.1. Дворівнева архітектура клієнт-сервер
Один з підходів – розподіл програм на два типи машин, клієнти і сервери, що призводить до фізично дворівневої архітектури (two-tiered architecture).
Архітектурні рішення варіюються від мінімізації функцій інтерфейсу користувача на клієнті (тонкий клієнт) до передачі клієнту всієї роботи з інтерфейсом користувача (товстий клієнт). В обох випадках ми відділяємо від застосування графічний зовнішній інтерфейс, пов'язаний з рештою застосування (що знаходиться на сервері) за допомогою конкретного для даного застосування протоколу. У цьому підході зовнішній інтерфейс робить лише те, що потрібне для надання інтерфейсу застосування (рис. 20.2).
Рис. 20.2. Дворівнева архітектура
Архітектуру побудованих за таким принципом застосувань називають клієнт-серверною або дворівневою. На практиці подібні системи часто не відносять до класу розподілених, але формально вони можуть вважатися простими представниками розподілених систем.
Розвиток архітектури "клієнт-сервер", а особливо поява сучасних графічних інтерфейсів, призвела спочатку до появи варіанту архітектури клієнт-сервер, яка отримала назву "архітектура з товстим клієнтом". В цій архітектурі логіка представлення даних і бізнес-логіка розміщуються на клієнті, який (скажімо, у разі, коли сервером є СКБД) спілкується з логікою зберігання і накопичення даних на сервері, використовуючи мову структурованих запитів SQL. Проте необхідність установки "товстих клієнтів", що вимагають значної кількості спеціальних бібліотек і спеціального налаштування оточення, на велику кількість користувачів з різними операційними середовищами, як правило викликає масу проблем.
Тому, як альтернатива, виникла також дворівнева архітектура "з тонким клієнтом". При цьому в ідеалі програма-клієнт реалізує лише графічний інтерфейс користувача (GUI) і передає/отримує запити, а вся бізнес-логіка виконується сервером баз даних. У ідеалі клієнтом є інтернет-браузер, який не вимагає спеціального налаштування, установки спеціалізованого ПЗ тощо. На жаль, така схема теж не вільна від недоліків тому, що серверу доводиться брати на себе інколи не властиві для нього функції реалізації бізнес-логіки застосунку (наприклад, серверу СКБД доводиться виконувати розрахунки).
20.2.2. Трирівнева архітектура клієнт-сервер
Подальший розвиток архітектури клієнт-сервер призвів до трирівневої архітектури (three-tiered architecture).
У такій архітектурі програми, які входять до складу рівня обробки, виносяться на окремий сервер (сервер застосувань), але крім цього, можуть частково знаходитися на машинах клієнтів і серверів (рис. 20.3).
Таким чином, разом з клієнтською частиною застосунку і сервером баз даних з'явилися сервери застосувань (Application Servers).
В такій трирівневій архітектурі:
- програма-клієнт реалізує інтерфейс користувача, передає запити серверу застосувань і приймає від нього відповідь;
- сервер застосувань реалізує бізнес-логіку і звертається із запитами до сервера "третього рівня" (наприклад, сервера бази даних за даними);
- сервер третього рівня обслуговує запити сервера застосувань.
Програма-клієнт, таким чином, може бути "тонким клієнтом". Переваги такої архітектури очевидні:
- зміни на кожній з ланок можна здійснювати незалежно;
- знижуються навантаження на мережу, оскільки ланки не обмінюються між собою великими об'ємами інформації;
- забезпечується масштабування і проста модернізація устаткування і програмного забезпечення, що підтримує кожна з ланок, у тому числі оновлення серверного парку і термінального устаткування, СКБД і т.д.;
- Застосування можуть створюватися на стандартних мовах програмування (Java, C/C++/C#, PHPтощо).
Рис. 20.3. Трирівнева архітектура клієнт-сервер
Запит користувача в подібних системах послідовно обробляється клієнтською частиною системи, сервером логіки застосування і сервером баз даних.
Ця архітектура була домінуючою протягом останніх 15 років при створенні Веб-застосувань. Останнім часом, з ростом популярності веб-технологій виникла потреба в зменшенні навантаження на веб-сервер, тому з'явилася потреба в розробці "товстих клієнтів" в рамках трирівневої архітектури. Ця технологія отримала назву AJAX (асинхронний Javascript і XML).
Проте зазвичай під розподіленою системою розуміють систему із складнішою архітектурою, ніж трирівнева.
Наступний логічний крок - подальше збільшення числа ланок, причому зросте не лише за рахунок розбиття, коли "тоншає" кожна з відомих технічних ланок, але вся бізнес-модель будується як багатоланкова. Сучасні корпоративні програмні системи є, як правило, складними системами, взаємодіючими між собою на різних рівнях компонентів, кожен з яких може бути клієнтом для одних компонентів і сервером для інших.
20.2.3. Багаторівневі архітектури
Сучасні варіанти архітектури – багаторівневі
Багаторівнева архітектура клієнт-сервер – це пряме продовження розділення застосувань на рівні інтерфейсу користувача, компонентів обробки і даних.
Різні рівні взаємодіють відповідно до логічної організації застосування. У багатьох бізнес-застосуваннях розподілена обробка еквівалентна організації багаторівневої архітектури застосувань клієнт-сервер. Такий тип розподілу називається вертикальним розподілом.
Головна його особливість – це розміщення логічно різних компонентів на різних машинах.
Рис. 20.4.Багатрівнева архітектура клієнт-сервер
У сучасній архітектурі компонентних систем розподіл на клієнти і сервери відбувається способом, який називається горизонтальним розподілом. При такому типі розподілу клієнт або сервер може містити фізично розділені частини логічно однорідного модуля, причому робота з кожною з частин може відбуватися незалежно. Це робиться для вирівнювання навантаження.
Приклад – web-сервер, який реплікований на декілька машин в локальній мережі. При зміні однієї web-сторінки – зміни розсилаються по всіх серверах. Сервер, якому буде переданий запит, що приходить, вибирається за принципом «каруселі». Така форма розподілу використовується для вирівнювання навантаження на сервери популярних web-сайтов.
Також можуть бути розподілені і клієнти. Для простих застосувань можна обійтися без серверів. В цьому випадку говорять про одноранговий розподіл. Подібне відбувається, наприклад, при зв'язку двох (або більше) користувачів. Обоє повинні запустити одне і те ж застосування, щоб почати сеанс.
Є і інші варіанти організації архітектури, наприклад, які розподілені як вертикально, так і горизонтально.
Основною проблемою систем, заснованих на дворівневій архітектурі "клієнт-сервер", або тим більше на багаторівневій архітектурі, є те, що від них вимагається мобільність в як можна ширшому класі апаратно-програмних середовищ. Навіть якщо обмежитися UNIX-локальними мережами, в різних мережах застосовується різна апаратура і протоколи зв'язку. Спроби створення систем, що підтримують всі можливі протоколи, призводить до їх перевантаження мережевими деталями в збиток функціональності. Ще складніший аспект цієї проблеми пов'язаний з можливістю використання різних представлень даних в різних вузлах неоднорідної локальної мережі. У різних комп'ютерах може існувати різна адресація, представлення чисел, кодування символів і так далі Це особливо важливе для серверів високого рівня: телекомунікаційних, обчислювальних, баз даних.
Загальним вирішенням проблеми мобільності такого роду систем є використання технологій, що реалізовують протоколи віддаленого виклику процедур (RPC - Remote Procedure Call) стандартизованим і незалежним способом. При використанні таких технологій звернення до сервісу у віддаленому вузлі виглядає як звичайний виклик процедури (методів видалених об'єктів). Засоби RPC, в яких міститься вся інформація про специфіку апаратури локальної мережі і мережевих протоколів, переводить виклик в послідовність мережевих взаємодій. Тим самим, специфіка мережевого середовища і протоколів прихована від прикладного програміста.
При виклику віддаленої процедури, програми RPC виконують перетворення форматів даних клієнта в проміжні машинно-незалежні формати, і потім перетворення у формати даних сервера. При передачі у відповідь параметрів виконуються зворотні перетворення. Таким чином, якщо система реалізована на основі стандартного пакету RPC, вона може бути легко перенесена в будь-яке відкрите середовище.
20.3. Сервісо-орієнтованана архітектура програмного забезпечення
20.3.1. Поняття сервісо-орієнтованої архітектури
Сервісно-орієнтоване програмування (або архітектура) (service-oriented architecture) – це подальший розвиток компонентного підходу до розробки компонентних програмних систем (ПС), заснований на використанні програм-сервісів із стандартизованими інтерфейсами. Компоненти ПС можуть бути розподілені по різних вузлах мережі, і пропонуватися як незалежні, слабо зв'язані, замінювані сервіси-застосування. Інтерфейс компонентів ПС забезпечує інкапсуляцію деталей реалізації кожного конкретного компоненту від інших. Таким чином, сервісно-орієнтована архітектура надає гнучкий спосіб комбінування і повторного використання компонентів для побудови складних розподілених програмних систем, зокрема, корпоративних програмних систем.
Сервісом (service) будемо називати ресурс, що реалізує бізнес-функцію та має наступні властивості:
- є повторно використовуваним;
- визначається одним або декількома явними незалежними інтерфейсами;
- слабо пов'язаний з іншими подібними ресурсами і може бути викликаний за допомогою комунікаційних протоколів, що забезпечують можливість взаємодії ресурсів між собою.
Таким чином, сервісо-орієнтована архітектура (SOA) — це засіб, що дозволяє представити програмну систему як набір взаємозв'язаних сервісів. Однією з її переваг є гнучкість і простота розробки нових застосувань. SOA створює комунікаційне середовище для модулів, що реалізовують прикладну бізнес-логіку. Інформація про модулі публікується в такій формі, що їх використання не вимагає знань про використані в них рішення і технології.
Програмні системи, розроблені відповідно до цієї парадигми, часто реалізуються як набір Web-сервісів, інтегрованих за допомогою відомих стандартних протоколів (SOAP, WSDL, і т.п.).
20.3.2. Основи веб-сервісів
Веб-сервісом (Веб-службою) (див. документ W3C “Web-services architecture requirements”) називається програмна система, що ідентифікується рядком URI, чиї інтерфейси і прив'язки визначені і описані на мові XML. Опис цієї програмної системи може бути знайдений іншими програмними системами, які можуть взаємодіяти з нею згідно цьому опису за допомогою повідомлень, заснованих на мові XML, і передаються за допомогою інтернет-протоколів.
Концепція архітектури веб-сервісів виникла в кінці 90-х років XX століття. Зараз ця концепція встигла устоятися і архітектура, яку вона пропонує, стала галузевим стандартом у сфері інформаційних технологій (IT).
Стандартизацією архітектури веб-сервісів займаються робочі групи комітету W3C.
Стандарти веб-сервісів визначають формат повідомлень, інтерфейс, якому передається повідомлення, правила прив'язки вмісту повідомлення до застосування, що реалізує сервіс, а також механізми публікації і пошуку інтерфейсів.
Механізм обміну повідомленнями визначається в описі сервісів (Web Services Description), який є специфікацією інтерфейсу сервісу і охоплює формати повідомлень, типів даних, транспортні протоколи, використовувані при обміні між агентами замовника і постачальника послуг. Крім того, опис сервісу містить вказівку на один або декілька вузлів в мережі (endpoint), звідки доступний постачальник.
Завдяки веб-сервісам функції будь-якої програми в мережі можуть стати доступними через Інтернет.
У основі веб-сервісів лежать наступні універсальні технології:
TCP/IP – універсальний протокол, який "розуміють" всі мережеві пристрої, від мейнфреймів до мобільних телефонів і PDA;
HTML – універсальна мова розмітки, яка використовується для відображення інформації пристроями користувачів;
XML (Extensible Markup Language) – універсальна мова для роботи з будь-якими типами даних.
Універсальність цих технологій – основа для розуміння веб-сервісів. Вони засновані лише на загальноприйнятих, відкритих і формально незалежних від постачальників технологіях. Лише за допомогою цього досягається головна перевага веб-сервісів як концепції побудови розподілених ІС – їх універсальність, тобто можливість використання для будь-яких операційних систем, мов програмування, серверів застосувань тощо.
Таким чином, веб-сервіси вирішують головну задачу – задачу інтеграції застосувань різної природи і побудови кросплатформних розподілених ІС.
Переваги і недоліки веб-сервісів
Переваги
- веб-сервіси забезпечують взаємодію програмних систем незалежно від платформи;
- веб-сервіси використовують відкриті стандарти і протоколи. Завдяки використанню XML досягається простота розробки і відладки веб-сервісів;
- використання інтернет-протоколу HTTP забезпечує взаємодію програмних систем через міжмережевий екран.
Недоліки
Менша продуктивність і більший розмір мережевого трафіку в порівнянні з технологіями RMI, CORBA, DCOM за рахунок використання текстових XML-повідомлень.
Веб-сервіси подібні до DLL-бібліотек, але мають наступні особливості:
- виконуються на стороні сервера;
- надають набір методів, доступних зовнішнім клієнтам;
- виконують веб-методи і повертають результати клієнтам;
- веб-сервіси і їх клієнти можуть бути написані на різних мовах і різних платформах.
20.3.3. Стек технологій веб-сервісів
Веб-сервіси вимагають використання декількох суміжних XML-технологій, які утворюють так званий стек технологій (рис. 20.5.).
- Мова XML - фундамент, на якому будуються веб-сервіси. Він надає мову визначення даних і порядок їх обробки. XML представляє сімейство зв'язаних специфікацій, що публікуються і підтримуються інтернет-консорціумом (W3C) і іншими організаціями.
- SOAP (Simple Object Access Protocol), розроблений консорціумом W3C, визначає формат запитів до веб-сервісів. Повідомлення між веб-сервісом і його користувачем пакуються в так звані SOAP-конверти (SOAP envelopes, інколи їх ще називають XML-конвертами). Саме повідомлення може містити або запит на здійснення якої-небудь дії, або відповідь - результат виконання цієї дії.
- WSDL (Web Services Description Language) - технологія, заснована на XML, що визначає інтерфейси веб-сервісів, типів даних і повідомлень, а також моделі взаємодії і протоколи зв'язку. Перед розгортанням сервісу розробник складає його опис на мові WSDL, вказує адресу веб-сервісу, підтримувані протоколи, перелік допустимих операцій, формати запитів і відповідей.
- Технологія UDDI (Universal Description, Discovery and Integration) - реєстр веб-сервісів і механізм пошуку. Він використовується для зберігання і впорядкування інформації про веб-сервіси, а також для знаходження покажчиків на інтерфейси веб-сервісів.
Рис. 20.5. Стік технологій веб-сервісів
Ці технології забезпечують реалізацію базових властивостей веб-сервісу, які описані в його визначенні. На їх основі розробляються нові мови взаємодії і сервісо-орієнтовані архітектури.
20.3.4. Взаємодія з веб-сервісами
Інтерфейси веб-сервісів отримують з мережевого середовища стандартні XML-повідомлення, перетворюють XML-дані в формат, що "розуміє" конкретна прикладна програмна системв, і відправляють у відповідь повідомлення (останнє - не обов'язково). Програмна реалізація веб-сервісів (базове програмне забезпечення, нижній рівень) може бути створена на будь-якій мові програмування з використанням будь-якої операційної системи і будь-якого проміжного програмного забезпечення (middleware).
Взаємодія програмних систем з веб-сервісами представлена на рис. 20.5.
Рис. 20.5. Взаємодія з веб-сервісами
Розрізняють наступні три основні архітектурні компоненти сервісно-орієнтованої архітектури:
- користувач сервісу: застосування, програмний модуль або сервіс, що здійснює пошук і виклик необхідного сервісу з реєстру сервісів відповідно до опису сервісу, а також використовує сервіс, що надається провайдером сервісу, відповідно до інтерфейсу сервісу;
- провайдер сервісу: застосування, програмний модуль або сервіс, що здійснює реалізацію сервісу у вигляді веб-сервісу, прийом і виконання запитів користувачів сервісу, а також публікацію сервісу в реєстрі сервісів;
- реєстр сервісів: бібліотека сервісів, що надає користувачам сервісу засобу пошуку і виклику необхідного сервісу і приймає запити провайдерів сервісів на публікацію сервісів.
Кожен компонент може виконувати або лише одну роль (бути, наприклад, лише користувачем сервісу) або одночасно відразу декілька ролей (наприклад, бути провайдером одних сервісів і користувачем інших).
В ході взаємодії один з одним компоненти сервісо-орієнтованої архітектури виконують наступні основні операції:
- публікація: для того, щоб сервіс був доступним користувачам сервісу, необхідно зробити його інтерфейс відомим їм;
- пошук: користувач сервісу повинен мати можливість знайти в реєстрі сервісів необхідний сервіс, що задовольняє заданим критеріям;
- зв'язування і виклик: після отримання опису сервісу, користувач сервісу повинен мати можливість викликати і використовувати сервіс відповідно до опису сервісу.
Розглядаючи взаємодію компонентів сервісо-орієнтованої архітектури необхідно відзначити наявність (і відмінність) наступних двох артефактів:
- опис сервісу: визначає формат запиту і відгуку при взаємодії користувача сервісу і провайдера сервісу, а також необхідна якість сервісу;
- сервіс: власне сервіс, який може бути викликаний і використаний користувачем сервісу відповідно до опублікованого інтерфейсу сервісу.
Висновки
Для кожної розподіленої компонентної програмної системи важлива схема її внутрішньої організації. Найбільш поширена модель – Клієнт-сервер. Ця модель тісно пов'язана з традиційним програмуванням, в якому сервіси реалізуються у вигляді процедур в окремих модулях. Подальше уточнення зазвичай полягає в підрозділі на рівень інтерфейсу користувача, рівень обробки і рівень даних. Сервер зазвичай відповідає за рівень даних, а рівень інтерфейсу користувача реалізується на стороні клієнта. Рівень обробки може бути реалізований на клієнті, на сервері або роздільний між ними. Прикладом такої організації є будь-яка корпоративна інформаційна система підприємства.
У сучасних розподілених системах для побудови великих систем такої вертикальної організації застосувань моделі клієнт-сервер недостатньо. Необхідний горизонтальний розподіл, при якому клієнти і сервери фізично розподілені і реплікуються на декілька комп'ютерів. Типовим прикладом успішного використання горизонтального розподілу є Web.
Подальшим розвитком компонентної архітектури застосувань є сервісо-орієнтована архітектура, зокрема архітектура веб-сервісів.
Технологія Web-сервісів - це сучасна технологія, яка забезпечує новий рівень розподіленості. Замість розробки або придбання компонентів і їх вбудовування в ІС пропонується купувати час їх роботи і формувати програмну систему, яка здійснює виклики методів з компонентів, які належать і підтримуються незалежними провайдерами.
Контрольні запитання і завдання для самостійної роботи
1. Яка різниця між дворівневою та трирівневою архітектурою?
2. Як розподіляються функції застосування у разі дворівневої архітектури?
3. Як розподіляються функції застосування у разі трирівневої архітектури?
4. Які недоліки має дворівнева архітектура клієнто-сервер?
5. Яка різниця між тонким і товстим клієнтом?
6. Основні функції, які виносяться на сервер застосувань?
7. Характеристики багаторівневої архітектури?
8. Характеристика сервісо-орієнтованої архітектури.
9. Охарактеризуйте стек технологій веб-сервісів.
10. Яким чином виконується взаємодія програм з веб-сервіісами?
(Для ознайомлення з повним текстом статті необхідно залогінитись)