Архітектура КІС
Химия

Архітектура КІС


7. Архітектура КІС.

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

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

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

clip_image001

Рисунок 3.1 – Двохрівнева клієнт-серверна архітектура

Дана клієнт-серверна архітектура характеризується наявністю двох взаємодіючих самостійних модулів – автоматизованого робочого місця (АРМа) та сервера бази даних, якою може виступати Microsoft SQL Server, Oracle, Sybase та інші. Сервер БД відповідає за зберігання, керування та цілісність даних, а також забезпечує можливість одночасного доступу кількох користувачів. Клієнтська частина представлена ​​так званим «товстим» клієнтом, тобто додатком (АРМ) на якому сконцентровані основні правила роботи системи та розташований інтерфейс програми користувача. При всій простоті побудови такої архітектури, вона має безліч недоліків, найбільш суттєві з яких – це високі вимоги до мережевих ресурсів та пропускної спроможності мережі компанії, а також складність оновлення програмного забезпечення через “розмазану” бізнес-логіку між АРМ і сервером БД. Крім того, при великій кількості АРМів зростають вимоги до апаратного забезпечення сервера БД, а це, як відомо, найдорожчий вузол у будь-якій інформаційній системі.

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

clip_image002

Рисунок 3.2 – Трирівнева клієнт-серверна архітектура (Three-tier architecture)

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

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

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

clip_image003

Рисунок 3.3 – Розподілена архітектура системи

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

Понад 95 % даних, які у управлінні підприємством, може бути розміщено одному персональному комп’ютері, забезпечивши можливість його незалежної роботи. Потік виправлень і доповнень, що створюється на цьому комп’ютері, мізерний у порівнянні з обсягом даних, які використовуються при цьому. Тому якщо зберігати безперервно використовувані дані на самих комп’ютерах, і організувати обмін між ними виправленнями і доповненнями до даних, що зберігаються, то сумарний трафік, що передається, різко знизитися. Це дозволяє знизити вимоги до каналів зв’язку між комп’ютерами та частіше використовувати асинхронний зв’язок, і завдяки цьому створювати надійно функціонуючі розподілені інформаційні системи, що використовують для зв’язку окремих елементів нестійкий зв’язок типу Інтернету, мобільний зв’язок, комерційні супутникові канали. А мінімізація трафіку між елементами зробить цілком доступною вартість експлуатації такого зв’язку. Звичайно, реалізація такої системи не є елементарною, і вимагає вирішення низки проблем, одна з яких своєчасна синхронізація даних.

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *