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

ОГЛЯД

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

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

З автором, керівником інформаційного відділу Генеральної сервісної компанії, можна зв'язатися за адресою: [email protected].

Версія для друку

Тільки зареєстровані користувачі можуть залишати коментарі.