Введення у розподілені системи. Розподілена архітектура Розширення базових рівнів

(Матеріал сайту http://se.math.spbu.ru)

Вступ.

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

Існує шість основних характеристик розподілених систем.

Спільне використання ресурсів. Розподілені системи допускають спільне використання як апаратних (жорстких дисків, принтерів), і програмних (файлів, компіляторів) ресурсів.
Відкритість.Це можливість розширення системи шляхом додавання нових ресурсів.
Паралельність.У розподілених системах кілька процесів можуть одночасно виконуватися на різних комп'ютерах у мережі. Ці процеси можуть взаємодіяти під час виконання.
Масштабованість . Під масштабованістюрозуміється можливість додавання нових властивостей та методів.
Відмовостійкість. Наявність кількох комп'ютерів дозволяє дублювання інформації та стійкість до деяких апаратних та програмних помилок. Розподілені системи у разі помилки можуть підтримувати часткову функціональність. Повний збій у роботі системи відбувається лише при мережевих помилках.
Прозорість.Користувачам надається повний доступ до ресурсів у системі, водночас від них прихована інформація про розподіл ресурсів у системі.

Розподілені системи мають і ряд недоліків.

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

З цих недоліків можна побачити, що при проектуванні розподілених систем виникає низка проблем, які треба враховувати розробникам.

Ідентифікація ресурсів . Ресурси в розподілених системах розташовуються на різних комп'ютерах, тому систему імен ресурсів слід продумати так, щоб користувачі могли легко відкривати необхідні їм ресурси і посилатися на них. Прикладом може бути система URL(уніфікований покажчик ресурсів), що визначає імена Web-страниц.
Комунікація. Універсальна працездатність Internet та ефективна реалізація протоколів TCP/IP в Internet для більшості розподілених систем є прикладом найбільш ефективного способу організації взаємодії між комп'ютерами. Однак у деяких випадках, коли потрібна особлива продуктивність або надійність, можливе використання спеціалізованих засобів.
Якість системного сервісу . Цей параметр відображає продуктивність, працездатність та надійність. На якість сервісу впливає ряд факторів: розподіл процесів, ресурсів, апаратні засоби та можливості адаптації системи.
Архітектура програмного забезпечення . Архітектура ПЗ описує розподіл системних функцій по компонентам системи, і навіть розподіл цих компонентів процесорам. Якщо потрібно підтримувати висока якістьсистемного сервісу вибір правильної архітектури є вирішальним фактором.

Завдання розробників розподілених систем – спроектувати програмне та апаратне забезпечення так, щоб надати всі необхідні характеристики розподіленої системи. А для цього потрібно знати переваги та недоліки різних архітектур розподілених систем. Виділяється три типи архітектур розподілених систем.

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

Про перші дві моделі було сказано вже не раз, зупинимося докладніше на третій.

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

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

Спочатку кілька слів про те, що таке XML взагалі. XML – універсальний формат даних, який використовується для надання Web-сервісів. В основі Web-сервісів лежать відкриті стандарти та протоколи: SOAP, UDDI та WSDL.

SOAP ( Simple Object Access Protocol), розроблений консорціумом W3C, визначає формат запитів до Web-сервісів. Повідомлення між Web-сервісом та його користувачем пакуються у звані SOAP-конверти (SOAP envelopes , іноді ще називають XML-конвертами). Саме повідомлення може містити або запит на здійснення дії, або відповідь - результат виконання цієї дії.
WSDL (Web Service Description Language).Інтерфейс Web-сервісу описується в WSDL-документах (а WSDL - це підмножина XML). Перед розгортанням служби розробник складає її опис мовою WSDL, вказує адресу Web-сервісу, протоколи, що підтримуються, перелік допустимих операцій, формати запитів і відповідей.
UDDI (Universal Description, Discovery and Integration) -протокол пошуку Web-сервісів в Internet ( http://www.uddi.org/). Є бізнес-реєстром, в якому провайдери Web-сервісів реєструють служби, а розробники знаходять необхідні сервіси для включення до своїх додатків.

З доповіді може здатися, що Web-сервіси - найкраще і безальтернативне рішення, і лише у виборі засобів розробки. Однак, це не так. Альтернатива Web-службам існує, це семантичний Web (Semantic Web), про необхідність створення якого вже п'ять років тому говорив автор WWW Тім Бернерс-Лі.

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

Список літератури

СоммервіллІ. Інженерія програмного забезпечення.
Драниця А. Java проти .NET. - "Комп'ютерра", # 516.
Ресурси Інтернет.

Гетерогенні мультикомп'ютерні системи

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

Мережа, що з'єднує їх, також може бути сильно неоднорідною.

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

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

Переходячи до питань масштабування, властивих гетерогенним системам, і враховуючи необхідність глобального підходу, властиву більшості з них, зауважимо, що створення програм для гетерогенних мультикомп'ютерних систем потребує спеціалізованого програмного забезпечення. З цією проблемою розподілені системи справляються. Щоб у розробників додатків не виникало потреби хвилюватися про використовуване апаратне забезпеченнярозподілені системи надають програмну оболонку, яка захищає програми від того, що відбувається на апаратному рівні (тобто вони забезпечують прозорість).

Найбільш ранньою та фундаментальною розподіленою архітектурою є «клієнт-сервер», в якій одна із сторін (клієнт) ініціює обмін даними, надсилаючи запит іншій стороні (серверу). Сервер обробляє запит і за необхідності посилає відповідь клієнту (рис. 2.7).

Мал. 2.7. Модель взаємодії клієнт сервер

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

Мал. 2.8. Логічні рівні програми

Розглянемо якийсь типовий додаток, який відповідно до сучасних уявлень може бути розділений на наступні логічні рівні (рис. 2.8): інтерфейс користувача (ІП), логіка додатка (ЛП) і доступ до даних (ДД), що працює з базою даних (БД) . Користувач системи взаємодіє з нею через інтерфейс користувача, база даних зберігає дані, що описують предметну область програми, а рівень логіки програми реалізує всі алгоритми, що належать до предметної області.

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

Мал. 2.9. Дволанкова архітектура

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

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

Мал. 2.10. Триланкова архітектура

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

Мал. 2.11. Розподілена система роздрібного продажу

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

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

Мал. 2.12. Система прямого обміну даними між клієнтами

Принципи створення системи обробки інформації у масштабі підприємства

Історія розвитку комп'ютерної техніки (і програмного забезпечення) розпочалася з відокремлених, автономних систем. Вчені та інженери були стурбовані створенням перших ЕОМ і в основному ламали голови над тим, як змусити працювати ці скупчення електронних ламп. Однак такий стан речей зберігався недовго - ідея об'єднання обчислювальних потужностей була цілком очевидною і витала в повітрі, насиченому гулом металевих шаф перших ENIAK'ів та Mark'ів. Адже думка об'єднати зусилля двох і більше комп'ютерів для вирішення складних, непосильних для кожного окремо завдань лежить на поверхні.

Мал. 1. Схема розподілених обчислень

Однак практична реалізація ідеї з'єднання комп'ютерів у кластери та мережі гальмувалась відсутністю технічних рішень і насамперед необхідністю створення стандартів та протоколів взаємодії. Як відомо, перші ЕОМ з'явилися наприкінці сорокових років ХХ століття, а перша комп'ютерна мережа ARPANet, що зв'язала кілька комп'ютерів на території США, - тільки 1966 р., майже через двадцять років. Звичайно, таке об'єднання обчислювальних можливостей сучасну розподілену архітектуру нагадувало дуже віддалено, проте це був перший крок у правильному напрямку.

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

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

Саме в цей період стало очевидним, що основними перевагами розподілених додатків є:

· хороша масштабованість - за необхідності обчислювальна потужність розподіленої програми може бути легко збільшена без зміни його структури;

· можливість управління навантаженням - проміжні рівні розподіленої програми дають можливість керувати потоками запитів користувачів та перенаправляти їх менш завантаженим серверам для обробки;

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

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

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

Такою є історія питання. А тепер давайте подивимося, що є розподіленими додатками.

Парадигма розподілених обчислень

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

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

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

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

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

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

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

Всім перерахованим вимогам до програмного забезпечення масштабу підприємства відповідають розподілені системи – схема розподілу обчислень наведена на рис. 1.

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

Отже, парадигма розподілених обчислень передбачає наявність кількох центрів (серверів) зберігання та обробки інформації, що реалізують різні функціїта рознесених у просторі. Ці центри, крім запитів клієнтів системи, повинні виконувати і запити один одного, оскільки в ряді випадків для вирішення першого завдання можуть знадобитися спільні зусилля декількох серверів. Для управління складними запитами та функціонуванням системи загалом необхідно спеціалізоване керуюче ПЗ. І нарешті, вся система має бути "занурена" в якесь транспортне середовище, що забезпечує взаємодію її частин.

Розподілені обчислювальні системимають такі спільні властивості, як:

· Керованість - передбачає здатність системи ефективно контролювати свої складові. Це досягається завдяки використанню керуючого;

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

· масштабованість - за необхідності фізичного підвищення продуктивності розподілена система може легко інтегрувати у своєму транспортному середовищі нові обчислювальні ресурси;

· Розширюваність - до розподілених програм можна додавати нові складові (серверне ПЗ) з новими функціями.

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

Мал. 2. Основні рівні архітектури розподіленої програми

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

Архітектура розподілених програм

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

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

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

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

· Зберігання даних (рівень даних). Це рівень серверів бази даних. Тут розташовані сервери, бази даних, засоби доступу до даних, різні допоміжні інструменти.

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

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

Мал. 3. Розподіл бізнес-логіки за рівнями розподіленої програми

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

Таким чином, можна виділити чотири основні рівні розподіленої архітектури (див. рис. 2):

· Подання даних (користувацький рівень);

· Правила бізнес-логіки (рівень обробки даних);

· Управління даними (рівень управління даними);

· Зберігання даних (рівень зберігання даних).

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

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

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

Фізична структура розподілених додатків

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

Розподіл бізнес-логіки за рівнями розподіленої програми

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

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

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

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

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

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

Рівень представлення даних

Рівень представлення даних – єдиний доступний кінцевому користувачеві. Цей рівень моделює клієнтські робочі місця розподіленої програми та відповідне програмне забезпечення. Можливості клієнтського робочого місця насамперед визначаються можливостями операційної системи. Залежно від типу інтерфейсу користувача клієнтське ПЗ ділиться на дві групи: клієнти, що використовують можливості ГІП (наприклад, Windows), і Web-клієнти. Але в будь-якому випадку клієнтська програма повинна забезпечувати виконання наступних функцій:

· отримання даних;

· Подання даних для перегляду користувачем;

· Редагування даних;

· Перевірка коректності введених даних;

· Збереження зроблених змін;

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

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

Рівень обробки даних

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

· Обробка потоків даних відповідно до бізнес-правил;

· Взаємодія з рівнем подання даних для отримання запитів та повернення відповідей;

· Взаємодія з рівнем зберігання даних для передачі запитів та отримання відповідей.

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

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

Рівень керування даними

Рівень управління даними потрібен у тому, щоб додаток залишалося єдиним цілим, було стійким і надійним, мало можливості модернізації і масштабування. Він забезпечує виконання системних завдань, без нього частини програми (сервери БД, сервери програми, проміжне програмне забезпечення, клієнти) не зможуть взаємодіяти один з одним, а зв'язки, порушені при підвищенні навантаження, не можна буде відновити.

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

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

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

Отже, до функцій рівня управління даними належать:

· Управління частинами розподіленого додатку;

· Управління з'єднаннями та каналами зв'язку між частинами програми;

· Керування потоками даних між клієнтами та серверами та між серверами;

· Управління навантаженням;

· Реалізація системних службпрограми.

Необхідно відзначити, що часто рівень управління даними створюється на основі готових рішень, що постачаються на ринок програмного забезпечення різними виробниками. Якщо розробники вибрали для свого додатку архітектуру CORBA, то в її складі є брокер об'єктних запитів (Object Request Broker, ORB), якщо платформу Windows - до їх послуг різноманітні інструменти: технологія COM+ (розвиток технології Microsoft Transaction Server, MTS), технологія обробки черг повідомлень MSMQ, технологія Microsoft BizTalk та ін.

Рівень зберігання даних

Рівень зберігання даних об'єднує сервери SQL та бази даних, що використовуються програмою. Він забезпечує вирішення наступних завдань:

· Зберігання даних у БД та підтримка їх у працездатному стані;

· Обробка запитів рівня обробки даних та повернення результатів;

· Реалізація частини бізнес-логіки розподіленого додатку;

· Управління розподіленими базами даних за допомогою адміністративного інструментарію серверів БД.

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

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

Підключення до баз даних серверів SQL здійснюється переважно з допомогою клієнтського ПЗ серверів. Крім цього, додатково можуть використовуватися різні технології доступу до даних, наприклад ADO (ActiveX Data Objects) чи ADO.NET. Але при проектуванні системи необхідно враховувати, що функціонально-проміжні технології доступу до даних не належать до рівня зберігання даних.

Розширення базових рівнів

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

Серед інших можна виділити два найбільш поширені розширення базових рівнів.

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

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

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

Рівень доступу до даних розташовується між рівнем зберігання даних та рівнем обробки даних. Він дозволяє створити структуру докладання незалежно від конкретної технології зберігання даних. У таких випадках програмні об'єкти рівня обробки даних передають запити та отримують відповіді за допомогою засобів вибраної технології доступу до даних.

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

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

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

Розподілена архітектура AggreGate надзвичайно гнучка. Технічно вона заснована на формуванні однорангових зв'язків між серверами та прикріпленні частин єдиної моделі даних одних серверів («постачальників») до інших («споживачів»).

Цілі розподілених операцій

Основними цілями розподіленої архітектури є:

Масштабованість. Сервери нижнього рівня можуть бути сильно навантажені, збираючи дані та керуючи великою кількістю пристроїв у режимі, близькому до реального часу. Однак на практиці кількість пристроїв, які можуть обслуговуватись за допомогою одного сервера, обмежена до кількох тисяч. При масштабуванні системи керувати великою кількістю пристроїв розумно встановити кілька серверів і об'єднати в рамках розподіленої установки.
Балансування навантаження. Кожен сервер у розподіленій установці вирішує своє завдання. Сервери управління мережею перевіряють доступність та продуктивність мережної інфраструктури, сервери контролю доступу обробляють запити від контролерів дверей та турнікетів. Операції контролю, такі як створення звітів та їх розсилання поштою, можуть виконуватися на центральному сервері.
Захист від вторгнень. Вторинні сервери-зонди можуть бути встановлені у віддалених місцях та підключені до центрального сервера. Системні оператори підключаються тільки до центрального сервера, при цьому відпадає необхідність у налаштуванні VPN та прокидання портів до цих серверів.
Централізація. Вторинні сервери можуть працювати повністю автоматичному режимі, у той час як їх налаштування та моніторинг здійснюється через основний сервер, встановлений у центральній диспетчерській.

Розподіл ролей сервера

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

Великомасштабна хмарна IoT-платформа

Постачальники телекомунікаційних та хмарних послуг пропонують IoT-сервіси за моделями IaaS/PaaS/SaaS. У цих випадках мова йде про мільйони пристроїв, що належать тисячам користувачів. Обслуговування такої величезної інфраструктури потребує сотні серверів AggreGate, більшість з яких можна об'єднати у дві групи:

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

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

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

Багаторівнева інфраструктура Інтернету речей

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

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

Управління розумним містом

Це приклад заснованої на AggreGate багаторівневої архітектури для комплексної автоматизації великої групи будівель:

Рівень 1: фізичне обладнання (мережеві маршрутизатори, контролери, промислове обладнання тощо)
Рівень 2: сервери управління (сервери моніторингу мережі, сервери контролю доступу, сервери автоматизації будівель та інші)
Рівень 3: центри управління серверами будівель (один сервер на будівлю, який збирає інформацію з усіх серверів другого рівня)
Рівень 4: сервери районів міста (кінцевий пункт призначення для ескалації оповіщень нижчого рівня, моніторинг у реальному часі, інтеграція з Service Desk-системами)
Рівень 5: сервери головного офісу (контроль серверів району, збір та узагальнення звітів, оповіщень)

Будь-який з вищезгаданих серверів може бути відмовостійким кластером, що складається з декількох вузлів.

Управління мультисегментною мережею

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

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

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

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

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

Високопродуктивне управління подіями

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

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

На об'єктах, що генерують події, встановлюється кілька локальних серверів, що обробляють ці події. Декілька джерел (зондів) можуть підключатися до одного обробного сервера.
Виділений сервер або мультисерверний кластер зберігання великих даних прив'язується до кожного локального сервера обробки. Кількість вузлів кластера може змінюватись в залежності від швидкості генерації подій.
Всі локальні сервери зберігання виконують префільтрацію, дедуплікацію, кореляцію (використовуючи правила, що застосовуються до зондів, що локально підключаються), збагачення і зберігання подій.
Локальні серверизберігання підключаються до центрального сервера агрегування. Сервер агрегування відповідає за кореляцію важливих подій усієї системи.
Оператори центрального сервера можуть переглядати всю базу даних подій, завдання пошуку актуальних даних розподіляються між серверами зберігання. Таким чином, можливо створити централізовану звітність та оповіщення на основі бази даних по всіх подіях.

Цифрове підприємство

AggreGate може бути координуюча платформа для цифрового підприємства. Кожен із серверів AggreGate може виконувати різні функції, починаючи від моніторингу та керування віддаленими об'єктами та закінчуючи високорівневими сервісами, такими як бізнес-аналітика або, наприклад, керування інцидентами.

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

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

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

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

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

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

Компоненти керованої розподіленої архітектури

Механізми міжсистемної взаємодії (DCI)

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

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

До DCI можна підключати різні інсталяції DIRECTUM та інші класи систем (ERP, CRM та ін.). Зазвичай, інсталяції діляться за напрямами бізнесу, з урахуванням територіального чи юридичного розміщення організацій та інших чинників.

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

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

Федеративний пошук

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

Федеративний пошук дозволяє:

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

Адміністратор може змінювати стандартні пошуки, додавати нові, а також налаштовувати, які системи буде видно користувачу.

Центр адміністрування служб DIRECTUM

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

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

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

Служби зупиняються та включаються в один клік. Стан служб миттєво з'являється на екрані.

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

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

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