1. 5.1. Архітектура інформаційних систем
2. 5.1.2. централізована архітектура
3. 5.1.3. Архітектура "файл-сервер"
4. 5.1.4. Архітектура "клієнт-сервер"

Анотація: У даній лекції описуються архітектурні особливості побудови Веб-додатків і застосування шаблонів проектування при їх розробці, а також способи передачі даних в Інтернет.

Презентацію до даної лекції Ви можете завантажити тут .

5.1. Архітектура інформаційних систем

5.1.1. Загальні відомості

Сучасні програмні додатки і інформаційні системи досягли такого рівня розвитку, що термін "архітектура" в застосуванні до них вже давно не дивує. Грамотно побудувати інформаційну систему, ефективно і надійно функціонує чи не простіше, ніж сконструювати і звести сучасний багатофункціональний будинок [ 1 ].

Коли мова заходить про "архітектурі інформаційної системи", зазвичай не виникає нестачі в визначеннях. Є навіть Web-сайти, які збирають такі визначення [ 2 ].

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

• Архітектура - це організаційна структура системи [ 3 ].
• Архітектура інформаційної системи - концепція, яка визначає модель, структуру, виконувані функції і взаємозв'язок компонентів інформаційної системи [ 4 ].
• Архітектура - це базова організація системи, втілена в її компонентах, їхні стосунки між собою і з оточенням, а також принципи, що визначають проектування і розвиток системи [ 5 ].
• Архітектура - це набір значущих рішень з приводу організації системи програмного забезпечення, набір структурних елементів і їх інтерфейсів, за допомогою яких компонується система, разом з їх поведінкою, обумовленим у взаємодії між цими елементами, компонування елементів в поступово укрупнюються підсистеми, а також стиль архітектури, який направляє цю організацію - елементи та їх інтерфейси, взаємодії і компоновку [ 6 ].
• Архітектура програми або комп'ютерної системи - це структура або структури системи, які включають елементи програми, видимі ззовні властивості цих елементів і зв'язки між ними [ 7 ].
• Архітектура - це структура організації та пов'язане з нею поводження системи [ 8 ]. Архітектуру можна рекурсивно розібрати на частини, які взаємодіють за допомогою інтерфейсів, зв'язку, які з'єднують частини, і умови складання частин. Частини, які взаємодіють через інтерфейси, включають класи, компоненти і підсистеми.
• Архітектура програмного забезпечення системи або набору систем складається з усіх важливих проектних рішень з приводу структур програми і взаємодій між цими структурами, які складають системи [ 9 ]. Проектні рішення забезпечують бажаний набір властивостей, які повинна підтримувати система, щоб бути успішною. Проектні рішення надають концептуальну основу для розробки системи, її підтримки та обслуговування.

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

Під архітектурою програмних систем будемо розуміти сукупність рішень щодо [ 1 , 10 ]:

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

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

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

Для того щоб побудувати правильну і надійну архітектуру і грамотно спроектувати інтеграцію програмних систем необхідно чітко слідувати сучасним стандартам в цих областях. Без цього велика ймовірність створити архітектуру, яка нездатна розвиватися і задовольняти зростаючі потреби користувачів ІТ. Як законодавців стандартів в цій галузі виступають такі міжнародні організації як SEI (Software Engineering Institute), WWW (консорціум World Wide Web), OMG (Object Management Group), організація розробників Java - JCP (Java Community Process), IEEE (Institute of Electrical and Electronics Engineers) та інші.

Розглянемо класифікацію програмних систем по їх архітектурі:

• Централізована архітектура;
• Архітектура "файл-сервер";
• Двухзвенная архітектура "клієнт-сервер";
• Багатоланкова архітектура "клієнт-сервер";
• Архітектура розподілених систем;
• Архітектура Веб-додатків;
• Сервіс-орієнтована архітектура.

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

Далі детально розглянемо особливості кожної архітектури.

5.1.2. централізована архітектура

Централізована архітектура обчислювальних систем була поширена в 70-х і 80-х роках і реалізовувалася на базі мейнфреймів (наприклад, IBM-360/370 або їх вітчизняних аналогів серії ЄС ЕОМ), або на базі міні-ЕОМ (наприклад, PDP-11 або їх вітчизняного аналога СМ-4) [ 11 ]. Характерна особливість такої архітектури - повна "неінтелектуальність" терміналів. Їх роботою керує хост-ЕОМ.

Переваги такої архітектури [ 11 , 12 ]:

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

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

Використання такої архітектури є виправданим, якщо хост-ЕОМ дуже дорога, наприклад, супер-ЕОМ.

Класичне уявлення централізованої архітектури показано на Мал. 5.1 .

Мал.5.1.

Класичне уявлення централізованої архітектури

Центральна ЕОМ повинна мати велику пам'ять і високу продуктивність, щоб забезпечувати комфортну роботу великої кількості користувачів.

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

5.1.3. Архітектура "файл-сервер"

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

• Функції сервера: зберігання даних і коду програми.
• Функції клієнта: обробка даних відбувається виключно на стороні клієнта.

Класичне уявлення інформаційної системи в архітектурі "файл-сервер" представлено на Мал. 5.2 .

Мал.5.2.

Класичне уявлення архітектури "файл-сервер"

Організація інформаційних систем на основі використання виділених файлів-серверів все ще є поширеною в зв'язку з наявністю великої кількості персональних комп'ютерів різного рівня розвиненості і порівняну дешевизну зв'язування PC в локальні мережі [ 14 ].

Звичайно, основною перевагою даної архітектури є простота організації. Проектувальники і розробники інформаційної системи знаходяться в звичних і комфортних умовах IBM PC в середовищі MS-DOS, Windows або будь-якого полегшеного варіанту Windows Server. Є зручні та економічно розвинені засоби розробки графічного інтерфейсу користувача, прості у використанні засоби розробки систем баз даних і / або СУБД.

Переваги такої архітектури [ 12 , 13 , 14 ]:

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

недоліки [ 12 , 13 , 14 ]:

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

Просте, яке працює з невеликими обсягами інформації та розраховане на застосування в режимі одного, файл-серверний додаток можна спроектувати, розробити і налагодити дуже швидко [ 14 ]. Дуже часто для невеликої компанії для ведення, наприклад, кадрового обліку досить мати ізольовану систему, що працює на окремому PC. Однак, в уже ненабагато більше складних випадках (наприклад, при організації інформаційної системи підтримки проекту, що виконується групою) файл-серверні архітектури стають недостатніми.

5.1.4. Архітектура "клієнт-сервер"

Клієнт-сервер (Client-server) - обчислювальна або мережева архітектура, в якій завдання або мережева навантаження розподілені між постачальниками послуг (сервісів), які називаються серверами, і замовниками послуг, званих клієнтами [ 15 ]. Нерідко клієнти і сервери взаємодіють через комп'ютерну мережу і можуть бути як різними фізичними пристроями, так і програмним забезпеченням.

Спочатку системи такого рівня базувалися на класичній дворівневої клієнт-серверній архітектурі (Two- tier architecture). Під клієнт-серверних додатком в цьому випадку розуміється інформаційна система, заснована на використанні серверів баз даних.

Схематично таку архітектуру можна уявити, як показано на Мал. 5.3 [ 16 ].

Мал.5.3.

Класичне уявлення архітектури "клієнт-сервер"

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

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

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

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

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

• Сервер виробляє компіляцію отриманого оператора.
• Далі (якщо компіляція завершилася успішно) відбувається виконання оператора.

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

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

Перевагами даної архітектури є [ 12 , 15 ]:

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

недоліки [ 12 , 15 ]:

• непрацездатність сервера може зробити непрацездатною всю обчислювальну мережу;
• адміністрування даної системи вимагає кваліфікованого професіонала;
• висока вартість обладнання;
• бізнес логіка додатків залишилася в клієнтському ПО.

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

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

Також даний вид архітектури називають архітектурою з "товстим" клієнтом.