Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Лекції Паралельні та розподілені обчислення
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
О
Факультет:
УІ
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Конспект лекцій
Предмет:
Паралельні та розподілені обчислення
Частина тексту файла (без зображень, графіків і формул):
Зміст
Передмова 5
1. Технології побудови розподілених об’єктних систем 7
1.1. Розподілені об’єктні технології в інформаційних системах 7
1.2. Технології RMI, CORBA, DCOM 15
1.2.1. Технологія CORBA 15
1.2.2. Технологія DCOM 16
1.3. Переваги та недоліки використання технологій RMI, CORBA, DCOM 17
1.4. Технологія CORBA 19
1.5. Контрольні питання 32
2. Паралельні обчислювальні системи та паралельні обчислення. 32
2.1. Побудова паралельних обчислювальних систем, аналіз і моделювання паралельних обчислень. 32
2.1.1. Класифікація обчислювальних систем. 38
2.1.2. Моделювання і аналіз паралельних обчислень 47
2.1.3. Навчальний приклад обчислення часткових сум послідовності числових значень 54
2.1.4. Оцінка максимально досяжного паралелізму 61
2.1.5. Аналіз масштабованості паралельних обчислень 64
2.2. Оцінка комунікаційної трудомісткості паралельних алгоритмів 66
2.3. Принципи розробки паралельних методів 83
2.4. Контрольні питання 98
3. Паралельне програмування на основі МРІ 98
3.1. МРІ: основні поняття та означення 100
3.2. Вступ до розробки паралельних програм з використанням МРІ 103
3.3. Управління групами процесів і комунікаторами. 146
3.4. Контрольні питання 160
Література 161
Передмова
У міру того, як комп’ютери стають усе більш швидкодіючими, може скластися враження, що комп’ютери працюватимуть достатньо швидко, а потреба збільшення обчислювальної потужності зменшуватиметься. Проте історія розвитку комп’ютерної техніки свідчить, що в міру того як нова технологія задовольняє усі відомі прикладні проблеми, з’являються нові, інтерес до яких був викликаний цією технологією. Вони вимагають розробки новішої технології. Зокрема перші дослідження ринку збуту фірмою Cray Research пророкували ринок у десяток суперкомп’ютерів, проте з тих пір їх продано тисячі.
Збільшення обчислювальної потужності мотивувалося чисельним моделюванням складних систем, таким як автомобілебудування, нафто - і газовидобування, фармакологія, прогноз погоди і моделювання зміни клімату, сейсмологічна розвідка, проектування електронних та механічних пристроїв, синтез нових матеріалів, виробничі процеси, фізичні і хімічні процеси. На сьогоднішній день найбільш істотними потребами, що вимагають розробки більш швидких комп’ютерів, стають комерційні додатки, для яких необхідно, щоб комп’ютер був здатний обробити величезні об’єми даних з використанням складних методів. Ці додатки, включають бази даних (особливо, якщо вони використовуються у процесі прийняття рішень), відео конференції, спільні робочі середовища, автоматизацію діагностування в медицині, розвинуті графічну і віртуальну реальності (особливо для промисловості потреб).
Комерційні додатки можуть у достатній мірі визначити архітектуру більшості майбутніх паралельних комп’ютерів, а традиційні наукові додатки залишатимуться важливими споживачами паралельних обчислювальних технологій. Оскільки нелінійні ефекти ускладнюють сприйняття результатів теоретичних досліджень, то експерименти стають усе більш вартісними, непрактичними чи неможливими з різних причин (наприклад, США проводить ядерні іспити, використовуючи лише суперкомп’ютери), то обчислювальні дослідження складних систем стають усе більш і більш важливими. Витрати, пов’язані з обчисленнями, істотно збільшуються із збільшенням точності обчислень. Дослідження характеризуються великими вимогами до об’єму пам’яті, підвищеними вимогами до організації процесу введення-введення.
Відомо багато означень поняття суперкомп’ютер. Паралельний комп’ютер - це набір процесорів, здатних спільно функціонувати за умови розв’язку задач обчислювального типу. Таке означення включає як паралельні суперкомп’ютери, що мають сотні чи тисячі процесорів, так і мережі робочих станцій. Ефективність найшвидших комп’ютерів істотно зросла. Перші комп’ютери виконували десятки операцій (з плаваючою комою) за секунду, а продуктивність паралельних комп’ютерів середини дев’яностих років ХХ ст. досягала десятки-сотні мільярдів операцій у секунду, і надалі таке зростання продовжуватиметься. Проте архітектура обчислювальних систем, які визначають це зростання, радикально змінилася - від послідовної до паралельної. Період одно процесорних комп’ютерів продовжувався до появи сім’ї CRAY X-MP / Y-MP - слабо паралельних векторних комп’ютерів з 4 - 16 процесорами, які у свою чергу змінили комп’ютери з масовим паралелізмом, тобто комп’ютери із сотнями тисяч процесорів.
Ефективність комп’ютера залежить безпосередньо від тривалості виконання базової операції та кількості базових операцій, які можна виконати одночасно. Тривалість виконання базової операції обмежена тривалістю виконання внутрішньої елементарної операції процесора (тактом процесора). Зменшення такту обмежене на основі фізичних міркувань, наприклад, такими як, швидкість світла. Щоб обійти ці обмеження, виробники процесорів намагаються реалізувати паралельну роботу всередині чіпу - при виконанні елементарних і базових операцій. Проте теоретично показано, що стратегія Надвисокого Рівня Інтеграції (Very Large Scale Integration - VLSI) є дорогою, що час виконання розрахунків сильно залежить від розміру мікросхеми. Поряд з VLSI для підвищення продуктивності комп’ютера використовуються також інші способи: конвеєрна обробка (різні стадії окремих команд виконуються одночасно), багатофункціональні модулі (окремі множники, суматори, і.т.д., управляються одним потоком команд).
Все більше до ЕОМ включається “обчислювальних блоків” та відповідна логіка їхнього з’єднання. Кожний такий "обчислювальний блок" має свої власні процесор і пам’ять. Успіхи VLSI технології у зменшенні числа компонент комп’ютера, полегшують створення таких ЕОМ. Крім того, оскільки, хоч і досить приблизно, вартість ЕОМ пропорційна числу наявних у ній компонент, то збільшення інтеграції компонент дає змогу збільшити чисельність процесорів в ЕОМ при не досить значному підвищенні вартості.
Інша важлива тенденція розвитку обчислень – це величезне збільшення продуктивності мереж ЕОМ. Донедавна мережі мали швидкодію в 1.5 Mбіт/с, а сьогодні вже існують мережі із швидкодією в декілька Гб за секунду. Поряд із збільшенням швидкодії мереж збільшується надійність передачі даних. Це дає змогу розробляти додатки, що використовують фізично розподілені ресурси, ніби вони є частинами одного багатопроцесорного комп’ютера. Наприклад, колективне використання вилучених баз даних, обробка графічних даних на одному чи кількох графічних комп’ютерах, а вивід і управління в реальному масштабі часу на робочих станціях.
1. Технології побудови розподілених об’єктних систем
1.1. Розподілені об’єктні технології в інформаційних системах
За умови пошуку покращених виробничих процесів та швидкого розвитку обчислювальної техніки та прикладного програмного забезпечення, має місце швидке зростання складності інформаційних систем. З’являються нові напрямки, технології та архітектурні рішення побудови інформаційних систем (ІС). Здійснюється перехід до динамічної, гнучкої структури ІС, яка базується на розподілених системах отримання та обробки інформації. Сучасний рівень розвитку суспільства виводить індустрію інформаційних технологій (ІТ), на провідне і стратегічне місце, в якому зосереджуються величезні інтелектуальні та фінансові ресурси.
Складність створення, модифікації, супроводження та інтеграції ІС, особливість розв’язуваних з їх використанням задач, визначає такі їх класи:
малі ІС;
середні ІС;
крупні ІС (корпоративні на рівні загальнодержавних установ).
До малих ІС відносяться системи, рівня невеликих підприємств, ознаками яких є:
нетривалий життєвий цикл;
орієнтація на масове використання;
невисока ціна;
практична відсутність засобів аналітичної обробки даних;
відсутність можливості незначної модифікації без участі розробників;
використання, головним чином, настільних СУБД (Clarion, FoxPro, Clipper, Paradox, Access та ін.);
однорідність апаратного та системного забезпечення (недорогі персональні комп’ютери (ПК));
практична відсутність засобів забезпечення безпеки;
та ін.
Ознаками класу середніх ІС є:
тривалий життєвий цикл і можливість росту до крупних ІС;
наявність аналітичної обробки даних;
наявність штату співробітників для здійснення функцій адміністрування апаратних та програмних засобів);
наявність засобів забезпечення безпеки;
тісна взаємодія з установами-розробниками програмного забезпечення з питань супроводження компонентів ІС;
та ін.
До характерних ознак корпоративних ІС відносяться:
тривалий життєвий цикл;
міграція успадкованих систем
розмаїття використовуваного апаратного забезпечення з меншим, порівняно
із створюваною системою, життєвим циклом;
розмаїття використовуваного програмного забезпечення (ПЗ);
масштабність та складність розв’язуваних задач;
перетин множини різних предметних галузей;
орієнтація на аналітичну обробку даних;
територіальний розподіл;
та ін.
Нині обговорюються питання стосовно опису продуктів, технологій та методологій створення малих та середніх ІС. Разом з тим, технології та методології побудови крупних ІС, які об’єднують у собі множину локальних ІС, практично не розглядаються і не обговорюються. Це призводить до того, що, як технології створення крупної ІС, вибираються ті, які з самого початку не це не розраховані. З цієї причини проекти, що реалізуються, не отримують належного розвитку.
Сучасний рівень розвитку суспільства визначає індустрію ІТ, як провідний і стратегічний напрямок зосередження інтелектуальних та фінансових ресурсів. Інформація та інструменти управління нею (програмні продукти різного функціонального призначення) набули статусу інформаційних ресурсів (ІР). Останні концентруються в рамках ІС. Об’єднання ресурсів на основі інформаційно-комунікаційної взаємодії ІС виводить їх на рівень корпоративних інформаційних ресурсів. Це об’єднання часто називають Єдиним Інформаційним Простором (ЄІП). Реалізація ЄІП на рівні держави, корпорації, підприємства можливе у разі створення з подальшим дотриманням стандарту на взаємодію між собою ІС, та їх окремих додатків, рис. 1.1
Рис. 1.1. Корпоративні інформаційні ресурси
У ряді випадків під ІР розуміють тільки дані, коли розв’язок проблеми ЄІП зводиться до Єдиного Простору Даних (ЄПД), рис. 1.2, а ІС виступають як клієнт та сервер і взаємодіють один з іншим у відповідності із схемою, наведеною на рис. 1.3.
Рис. 1.2. Єдиний простір даних (ЄПД)
Рис. 1.3. Архітектура доступу до віддалених даних
Інформаційна система-клієнт (ІСК) надсилає інформаційній системі-серверу (ІСС) запит, отримуючи, як результат, дані, які підлягають подальшій обробці. Як запит, використовують мову SQL - стандарт поводження з реляційними системами управління базами даних. Доступ до віддалених баз даних (БД) у більшості випадків здійснюється з використанням продуктів, які підтримують протоколи ODBC (Open Data Base Connectivity), та JDBC (Java Data Base Connectivity), або використовуються шлюзи, які постачаються виробниками СУБД чи третіми фірмами-виробниками. При побудові єдиного простору даних використовується архітектура доступу до віддалених даних, що є аналогом дворівневої архітектури клієнт-сервер. Ця архітектура припускає реалізацію на стороні клієнта як функцій введення та відображення даних, так і прикладних функцій додатку, тобто методів обробки даних. Клієнт направляє запити до сервера, який обробляє їх і повертає клієнту результат, оформлений як блок даних.
Описаному сценарію взаємодії систем притаманні всі недоліки, характерної для дворівневої архітектури клієнт-сервер:
слід знати з боку ІСК особливості використовуваної СУБД та структуру віддаленої бази даних (БД) ІСС, що знижує рівень безпеки всієї системи у цілому;
ускладнено супроводження та модифікація тих додатків ІСК, які спілкуються з БД ІСС, оскільки будь-яка зміна схема віддаленої БД на стороні ІСС тягне за собою зміну додатків в ІСК, що ускладнює обслуговування, оновлення чи заміну додатків, встановлених на десятках-сотнях комп’ютерів;
значно ускладнюється адміністрування БД ІСС, яке включає в себе управління правами доступу користувачів ІСК.
Істотним недоліком розглянутого сценарію є дублювання додатків ІСС в ІСК, що призводить до неефективного використання ресурсів ІС, що взаємодіють. Зростання популярності глобальної мережі Internet та технології WWW останнім часом викликає підвищений інтерес до них з боку розробників корпоративних ІС. В самому початку WWW створювався як засіб, який надає графічний інтерфейс в Internet і спрощує доступ до інформації, розподіленої по мільйонам комп’ютерів у всьому світі. Основними компонентами були сторінки, вузли, браузери та сервери Web. Користувачам була надана можливість навігації по Internet з використанням технології гіпертексту, підтримуваної протоколами HTTP (Hypertext Transfer Protocol) та стандартом мови HTML (Hypertext Markup Language).
Додаток CGI (Common Gateway Interface) розв’язав проблему обміну інформацією між сервером Web та програмами типу бази даних, які не можуть безпосередньо обмінюватися даними з браузерами Web. В результаті з’явилася можливість реалізації інтерактивної взаємодії кінцевого користувача з програмами сторони Web - серверу, які обробляли інформацію, уведену користувачем в браузері, і в як результат повертали сформовану HTML - сторінку. Багато з існуючих рішень доступні в середовищі Internet і базуються на такому підході.
Поява мови Java надала для розробників ІС абсолютно нові технологічні рішення побудови додатків у середовищі Internet/Intranet. Проте не слід розглядати технологію Java тільки як частину технології WWW, оскільки Java дає змогу розв’язувати задачі більш широкого класу, порівняно з технологіями, які базуються на мові HTML, протоколі HTTP та CGI. Можливості, які надаються WWW - технологією розширили спектр рішень, якими керуються проектувальники при побудові ІС. Проте виникає питання: що собою представляють системи ІС, що взаємодіють, які базуються на технології, чи здатні вони розв’язати проблему ЄІП? Зрозуміло, що це не так. Таке сильне твердження пов’язане з тим, що в процесі розгляду взаємодії інформаційних систем, ІСК з браузером виступає в ролі компоненти зображення, а ІСС з WWW - сервером та додатками виступає як компонента, яка реалізує функціональну логіку та доступ до даних, що відповідає дворівневій архітектурі з інтелектуальним сервером, рис. 1.4. WWW - технологія здатна покращити ситуацію з імпортом/експортом даних між ІСК та ІСС, але є недоліки, що притаманні дворівневій архітектурі з інтелектуальним сервером.
Рис. 1.4. Архітектура з інтелектуальним сервером
Одним з недоліків є реальна відсутність можливості реалізації процесу обробки даних, які надаються WWW - сервером, на стороні ІСК, оскільки остання отримує інформацію від ІСС у вигляді HTML - сторінок, що робить неможливим організацію процесу обробки отриманих даних компонентами ІСК. Це призводить до відсутності потрібної ефективності використання обчислювальних ресурсів ІС. Разом з тим, гостро постає проблема підтримання безпеки системи у цілому, яка нині не має цілісного розв’язку у середовищі Internet, що неприпустимо для організацій, які висувають підвищені вимоги до безпеки. Крім того істотно ускладнюється адміністрування ресурсів ІСС, яке включає в себе управління правами доступу користувачів ІСС.
В концепції єдиного інформаційного простору має передбачатися, що як інформаційні ресурси ІС, у відношенні до неї, виступають як дані, так і різні додатки ІС. Тоді у кожній з ІС частина методів обробки даних реалізується як додатки, доступні з інших ІС, зокрема в разі взаємодії двох ІС, перша - використовується сервісами, які надаються другою, в результаті чого вона отримує вже оброблені дані, які можна піддати подальшій обробці компонентами першої ІС. Такий підхід відповідає розподіленій, одноранговій архітектурі взаємодії. Згідно цієї архітектури, будь-які додатки з різних ІС можуть виступати як в ролі клієнта, так і в ролі сервера по відношенню одна до одної, сумісно розв’язуючи ті чи інші задачі. Такий підхід мінімізує дублювання додатків. Розподіл додатків по різним ІС дає змогу досягти оптимального балансу завантаження додатків та апаратних засобів, що призведе до ефективного використання інформаційних ресурсів систем у цілому.
Знання схеми бази даних (БД) необхідно тільки тому додатку, який обробляє дані з цієї БД. Використання ІСС сервісів, які надаються ІС - сервером і реалізують методи обробки даних, дає змогу розв’язати проблему зміни схеми віддаленої бази даних. Статичність інтерфейсів компонентів. які надають ІСС набір сервісів, досягається застосуванням методологій об’єктно-орієнтованого аналізу та проектування, розподілених об’єктних технологій (CORBA, Java, DCOM) на різних етапах створення ІС. Більшість нині використовуваних ІС є додатками до дворівневої архітектури клієнт-сервер. Як засіб спілкування клієнта та сервера часто використовуються неповністю стандартизовані механізми тригерів та збережених процедур. Специфіка їх реалізації, невідокремлена від ядра системи управління БД) призводить до необхідності наявності додаткових обчислювальних ресурсів на стороні сервера.
В разі збільшення виконуваних сервером робіт системи в дворівневій архітектурі клієнт-сервер стають все більше схожими на великі ЕОМ (мейнфрейми), а структури оброблюваних ними даних та способи їх представлення слабо доступні для використання разом з іншими додатками. Як правило взаємодія розглянутих клієнт-сервер організується засобами СУБД, що перевантажує серверну частину. Разом з тим, сучасні технології дають змогу створити інтегроване середовище, яке в рамках ІС, так і в рамках концепції ЄІП:
не залежить від апаратних та системних програмних засобів;
спирається на міжнародні та промислові стандарти;
дає змогу розробити єдину інформаційну модель представлення підприємства як сукупності керованих ресурсів та потоків діяльності, настроюються на реалізацію правил управління колективної діяльності кожного конкретного підприємства;
забезпечує розширюваність системи, тобто простоту та легкість добавлення нових компонентів в існуючі ІС;
дає змогу інтегрувати старі додатки (legacy applications) в нові ІЧ;
допускає природну інтегрованість створюваних ІС, що гарантує її життєздатність та еволюційний розвиток;
дає змогу накопичувати, тиражувати та розвивати формалізовані знання спеціалістів;
істотно знижують сумарні витрати на створення ІС/
1.2. Технології RMI, CORBA, DCOM
Нині виділяють три різні технології, які підтримують концепцію розподілених об’єктних систем. Це технології RMI, CORBA та DCOM.
Архітектура RMI (Remote Method Invocation - виклик віддаленого методу), яка інтегрована JDK1.1, є продуктом компанії Java Soft і реалізує розподілену модель. RMI дає змогу клієнтським та серверним додаткам через мережу викликати методи клієнтів/серверів, які виконуються і Java Virtual Machine. Незважаючи на те, що RMI вважається "легкою" та менш потужною, порівняно з CORBA та DCOM, тим не менше, вона має ряд унікальних можливостей, оскільки розподілене, автоматичне управління об’єктами та можливість пересилати самі об’єкти від машини до машини. На рис. 1.5 зображені основні компоненти архітектури RMI.
Рис. 1.5. Модель RMI
Client Stub (перехідник для клієнта) та Server Stub (перехідник для сервера) породжені від одного інтерфейсу, але різниця між ними полягає в тому, що client stub служить для під’єднання до RMI Registry, а server stub використовується для зв’язку безпосередньо з функціями сервера.
1.2.1. Технологія CORBA
Технологія CORBA (Common Object Request Broker Architecture), яка розробляється OMG (Object Management Group) з 1990 року - це архітектура з брокером потрібних спільних об’єктів. На рис. 1.6 наведена основна структура
CORBA 2.0 ORB.
Рис. 1.6. ORB (CORBA 2.0)
Dynamic Invocation Interface (DII): надає клієнту змогу знаходити сервери і викликати їх під час роботи системи. IDL Stubs: визначає, яким чином клієнт здійснює виклик сервера. ORB Interface: спільні для клієнта та для сервера сервіси. IDL Skeleton Interface: спільні інтерфейси для об’єктів, незалежно від їх типу, які не були визначені в IDL Object Adapter: здійснюють комунікаційну взаємодію між об’єктом та ORB.
1.2.2. Технологія DCOM
Технологія DCOM (Distributed Component Object Model), рис. 1.7, була розроблена компанією Microsoft як розв’язок для розподілених систем в 1996 р. Нині DCOM є головним конкурентом CORBA, хоч і контролюється нині не Microsoft, а групою TOG (The Open Group), аналогічною OMG. DCOM є розширенням архітектури COM до рівня мережних додатків.
Рис. 1.7. Архітектура DCOM
У кожної з трьох розглянутих технологій (RMI, CORBA, DCOM) є свої унікальні особливості, які багато в чому характеризують можливість чи неможливість її застосування для розв’язку конкретної поставленої задачі.
1.3. Переваги та недоліки використання технологій RMI, CORBA, DCOM
Переваги та недоліки технології DCOM. Такими є наступні:
Переваги: мовна незалежність; динамічний/статичний виклик; динамічне находження об’єктів; масштабованість; відкритий стандарт (контроль з боку TOG). Недоліки: складність реалізації; залежність від платформи; немає найменування через URL; немає перевірки безпеки на рівні виконання ActiveX компонент. Крім того DCOM є лише частковим рішенням проблеми розподілених об’єктних систем. Це рішення добре підходить до Microsoft - орієнтованих середовищ. Як тільки в системі виникає необхідність працювати з архітектурою, яка відрізняється від Windows NT та Windows 95, DCOM перестає бути оптимальним рішенням проблеми. Таке положення невдовзі може змінитися, оскільки Microsoft намагається перенести DCOM також на інші платформи. Зокрема, фірмою Software AG вже випущена версія DCOM для Solaris UNIX і планується випуск версій також для інших версій UNIX. Але нині DCOM є задовільним рішенням лише для систем, орієнтованих виключно на продукти Microsoft. Нарікання викликає також невирішеність питання безпеки за умови виконання ActiveX компонент, що може призвести до неприємних наслідків.
Переваги та недоліки технології RMI. Такими є наступні:
Переваги: швидке та просте створення; Java - оптимізація; динамічне завантаження компонентів - перехідників; можливість передачі об’єктів за значенням; внутрішня безпека. Недоліки: підтримка тільки однієї мови - Java; свій власний, не IIOP - сумісний протокол взаємодії; труднощі інтегрування з існуючими додатками; погана масштабованість. Завдяки своїй Java - моделі, яка є легко використовуваною, RMI є самим простим і самим швидким способом створення розподілених систем. RMI є добрим вибором для створення RAD - компонент та невеликих додатків на мові Java. Технологія RMI не є такою потужною, як DCOM чи CORBA, зокрема RMI використовує свій (не CORBA/ IIOP) сумісний протокол передачі JRMP і може взаємодіяти лише з іншими Java об’єктами. Підтримка тільки однієї мови робить неможливою взаємодію з об’єктами, написаними не на мові Java. Тим самим, роль RMI у створенні великих, масштабованих промислових систем, знижується.
Переваги та недоліки технології CORBA. Такими є наступні:
Переваги: платформна незалежність; мовна незалежність; динамічні виклики; динамічне виявлення об’єктів; можливість масштабування; CORBA-сервіси; широка індустріальна підтримка.
Недоліки: відсутність передачі параметрів "за значенням"; відсутність динамічного завантаження компонент - перехідників; відсутність найменування через URL. До основних переваг CORBA можна віднести міжмовну ті міжплатформенну підтримку. Незважаючи те, що CORBA - сервіси віднесені до переваг технології CORBA, їх в рівній мірі можна одночасно віднести до недоліків CORBA, внаслідок повної відсутності їх реалізації.
Технологія CORBA відноситься до найефективніших, сучасних, придатних для крупних проектів, це технологія розподілених об’єктів. Причиною цього є те, що обидві технології CORBA та DCOM надзвичайно схожі за своєю функціональністю та за своїми можливостями (багатомовна підтримка, динамічний виклик, масштабованість та ін.) у DCOM відсутній важливий критичний елемент - мультиплатформна підтримка. Одного факту, що нині DCOM не підтримує цілком міжплатформну переносимість, достатньо, щоб не розглядати її як повноцінне, закінчене рішення. Крім того. в той час, як до складу OMG вже нині входять більше 700 членів (компаній - виробників програмних продуктів, комп’ютерів, телекомунікаційних систем, розробників прикладних систем та кінцевих користувачів), і практично будь-яка специфікація, розроблена цим консорціумом, фактично стає стандартом, технологія DCOM лише недавно став переходити від Microsoft до аналогічної OMG організації - групи TOG (The Open Group). Ще один плюс технології CORBA такий. Коло виробників продуктів, які підтримують дану технологію, ширше, порівняно аналогічного кола DCOM. Тобто виявляється, що саме CORBA є технологією, яка повністю призначена для промислових, відкритих, розподілених об’єктних систем.
1.4. Технологія CORBA
Наприкінці 1980 - х і на початку 1990 - х років багато провідних фірм - розробників займалися пошуком технологій, які принесли б відчутну користь на мінливому ринку комп’ютерних розробок. Такою технологією виявилася область розподілених комп’ютерних систем. Необхідно було розробити єдину структуру, яка б дала змогу здійснити повторне використання та інтеграцію коду, що важливо для розробників. Ціна за повторне використання коду та інтеграцію коду була високою, проте ніхто з розробників поодинці не міг втілити в реальність широко використовуваний, мовно-незалежний стандарт, який включає в себе підтримку складних багато зв'язних додатків. У травні 1989 р. була сформована OMG (Object Management Group). Нині OMG нараховує більше 700 членів (до OMG входять практично всі найбільші виробники програмного забезпечення (ПЗ), за виключенням Microsoft). Задачею консорціуму OMG є визначення набору специфікацій, які дають змогу будувати інтероперабельні інформаційні системи. Специфікація OMG - The Common Object Request Broker Architecture (CORBA) є індустріальним стандартом, який описує високо рівневі засоби підтримки взаємодії об’єктів в розподілених гетерогенних середовищах. CORBA специфікує інфраструктуру взаємодії компонент (об’єктів) на представницькому рівні і на рівні додатків моделі OSI. Вона дає розглядати всі додатки в розподіленій системі як об’єкти. причому об’єкти можуть одночасно відігравати роль клієнта та сервера: роль клієнта, якщо об’єкт є ініціатором виклику на ньому який-небудь метод. Об’єкти-сервери зазвичай називають "реалізацією об’єктів". Практика показує, що більшість об’єктів одночасно виконують роль клієнтів і серверів, по черзі викликаючи методи на інших об’єктах і відповідаючи на виклику ззовні. Використовуючи CORBA, тим самим , є можливість будувати більш гнучкі системи, ніж системи клієнт-сервер, основані на дворівневій і трирівневій архітектурі.
Мова OMG IDL (Interface Definition Language - Мова Опису Інтерфейсу) представляє собою технологічно незалежний синтаксис для опису інтерфейсу об’єктів. При описі програмної архітектури, OMG IDL добре використовується як універсальна нотація для окреслювання границь об’єкту, які визначають його поведінку у відношенні до інших компонентів ІС. OMG IDL дає змогу описати інтерфейси, які мають різні методи та атрибути. Мова також підтримує дослідження інтерфейсів, що необхідно для повторного використання об’єктів з можливістю їх розширення чи конкретизації. IDL є чисто декларативною мовою, тобто вона не містить ніякої реалізації. IDL - специфікації можуть бути відкомпільовані (відображені) в заголовкові файли та спеціальні прототипи серверів, які можуть використовуватися безпосередньо програмістом. Тобто IDL - визначені методи можуть бути написані, і далі виконані, на будь-якій мові, для якої існує відображення з IDL. До таких мов відносяться С, С++, SmallTalk, Java та Ada.
Рис. 1.8. CORBA IDL відображення в моделі Клієнт/Сервер
З використанням IDL, рис. 1.8, можна описати також атрибути компоненти, і батьківські класи, які вона наслідує, і викликувані виключення, і, зрештою, вкінець, методи, які визначають інтерфейс, причому з описом вхідних та вихідних параметрів. Структура CORBA IDL файлу має такий вигляд:
module <identifier> {
<type declarations>;
<constant declarations>;
<exception declarations>;
interface <identifier> [:<inheritance>] {
<type declarations>;
<constant declarations>;
<attribute declarations>;
<exception declarations>;
[<op_type>]<identifier>(<parameters>)
[raises exception] [context]
.
.
[<op_type>]<identifier>(<parameters>)
[raises exception] [context]
.
.
}
interface <identifier> [:<inheritance>]
.
.
}
Репозитарій Інтерфейсів (Interface Repository), який містить означення інтерфейсів на IDL, дає змогу бачити інтерфейси доступних серверів в мережі і програмувати їх використання в програмах-клієнтах.
Object Management Architecture. Восени 1990 р. OMG вперше опублікувала документ Object Management Architecture Guide (OMA Guide). Він був відкоригований у вересні 1992 р. Деталі Common Facilities (Спільні засоби) були добавлені в січні 1995 р. На рис. 1.9 показані чотири основні елементи цієї архітектури:
Рис. 1.9. OMG’s Object Management Architecture
Object Request Broker визначає об’єктну шину CORBA.
Common Object Services представляють собою колекцію служб, споряджених об’єктивними інтерфейсами, які забезпечують підтримку базових функцій об’єктів.
Common Facilities утворюють набір класів та об’єктів, які підтримують корисні в багатьох системах функції. Прикладні об’єкти представляють прикладні системи кінцевих користувачів і забезпечують функції, які є унікальними для даної прикладної системи.
Application Objects - це прикладні бізнес-об’єкти і додатки, які є основними споживачами всієї CORBA інфраструктури.
ORB, Object Request Broker (брокер об’єктних запитів) - це об’єктна шина, яка дає змогу об’єктам напряму виробляти і відповідати на запити інших об’єктів, розташованих як локально (на одному комп’ютері, але в різних процесах), так і віддалено. Клієнта не цікавлять комунікаційні та інші механізми, з використанням яких відбувається взаємодія між об’єктами, виклик і збереження серверних компонентів. CORBA - специфікації зачіпають лише IDL, відображення в інші мови, APIs для взаємодії з CORBA та сервіси, які надаються ORB. CORBA ORB не надає широкого набору розподілених middleware (проміжних) послуг. Шина ORB дає змогу об’єктам знаходити один другого прямо в процесі роботи і викликати один у другого різноманітні служби. Вона є набагато тоншою системою, порівняно з іншими клієнт/сервер middleware - системами, такими, як RPC (Remote Procedure Calls) чи MOM (Message-Oriented Middleware).
Шлях від RPC до ORB. Стосовно відмінності механізму викликів CORBA та RPC можна сказати наступне. Ці механізми схожі, але між ними є серйозні відмінності. З використанням RPC можна викликати певну функцію, а з використанням ORB можна викликати метод у певного об’єкта. Різні об’єкти класів можуть по-різному відповідати на виклик одного і того ж методу. Оскільки кожний об’єкт управляє своєю власною (на додаток - особистою) інформацією, то метод буде викликаний на сугубо конкретних даних. У випадку RPC, буде виконана лише якась конкретна частина коду сервера, яка і взаємодіє з даними сервера. Всі функції з однаковими іменами будуть виконані абсолютно однаково. В RPC відсутня конкретизація викликів, в тому розумінні, в якому це відбувається в ORB. В ORB всі виклики функцій здійснюються до конкретних об’єктів, тим самим, результати цих функцій можуть бути абсолютно різними. Виклики функцій обробляються в специфічній для кожного окремого об’єкта формі.
Переваги ORB. Теоретично CORBA визначається як краща клієнт/сервер middleware - система, але на практиці вона задовільна лише настільки, наскільки задовільні продукти, що її реалізують. До основних комерційних ORB відносяться Orbix від фірми IONA Technologies; DSOM від IBM; Object Broker від Digital; JOE від Sun; Visibroker від Visigenic та Netscape; ORB+ від HP. Переваги кожної CORBA ORB такі:
- Статистичні та динамічні виклики методів. CORBA ORB надає можливість або статично визначити виклики методів прямо під час компіляції, або знаходити їх динамічно, але вже під час роботи програми.
- Відображення та мови високого рівня. CORBA ORB дає змогу викликати методи у серверних компонент,використовуючи будь-який з певного списку мов високого рівня - С, С++, SmallTalk, Java, Ada. Абсолютно неважливо, на якій мові написані об’єкти. CORBA відділяє інтерфейси від реалізації і надає мово незалежні типи даних, що дає змогу здійснювати виклик методів, минаючи границі якоїсь мови програмування та конкретної операційної системи.
- Система, що само описується. З використанням своїх метаданих, CORBA дає змогу описувати інтерфейс будь-якого сервера, відомого системі. Кожна CORBA ORB повинна підтримувати Репозитарій Інтерфейсів, який зберігає необхідну інформацію, яка описує синтаксис інтерфейсів, підтримуваних серверами. В своїй роботі клієнти використовують ці метадані для здійснення викликів до серверів.
- Прозорість. ORB може виконуватися як сам собою (наприклад, на портативному комп’ютері), оскільки в оточенні всіх інших ORB, з якими вона взаємодіє шляхом CORBA 2.0 ІІОР (Internet Inter- ORB Protocol) протоколу. ORB може здійснювати між об’єктну взаємодію також для одного процесу, як і для кількох процесів, які виконуються на одній машині, та для процесів , виконання яких відбувається в мережі, під різними операційними системами. Реалізація цих взаємодій ніяк не зачіпає самі об’єкти. При використанні технології CORBA, розробник не має турбуватися про розташування серверів, запуск (активування) об’єктів, вирівнювання розміру змінних в залежності від платформи та операційної системи, та про те, як здійснюється передача повідомлень. Рішення всіх цих задач бере на себе продукт, який підтримує стандарт CORBA.
- Вбудована безпека. Всі свої запити ORB доповнює певною контекстною інформацією, яка забезпечує збереження даних.
- Поліморфізм при виклику методів. ORB не просто викликає віддалений метод - ORB викликає метод на віддаленому об’єкті. Тобто виконання одних і тих же функцій на різних об’єктах призведуть до різних дій, в залежності від типу об’єкта.
Object Services. CORBA Object Services представляє собою набір сервісів системного рівня, які зображуються у вигляді компонентів з певними визначеними IDL - інтерфейсами. Ці компоненти доповнюють функціональність ORB, їх можна використати для створення, іменування компонентів, та ін. Нині OMG визначає 14 стандартних сервісів. Практично всі комерційні ORB не підтримують жодного із сервісів, і тільки небагато з них (Visibroker) - тільки один, два.
Common Facilities. Common Facilities (спільні засоби) заповнюють простір між ORB та об’єктивними службами з одного боку, та прикладними службами, з іншої. Тобто ORB забезпечує базову інфраструктуру, Object Services - фундаментальні об’єктивні інтерфейси, а задача Common Facilities - підтримка інтерфейсів сервісів високого рівня, які можуть включати спеціалізацію Object Services. Тобто операції, представлені Common Facilities, призначені, зокрема, для використання Object Services та прикладними об’єктами. Це реалізується шляхом наслідування стандартних Інтерфейсів. Спільні засоби поділяються на горизонтальні та вертикальні. До горизонтальних сервісів відносяться такі спільні сервіси, як, наприклад, управління інформацією, задачами, всією системою, тобто засоби, які не залежать від конкретних прикладних систем. До вертикальних сервісів відносяться сервіси, специфічні для якоїсь діяльності, наприклад, медицина, фінанси.
Application Objects. Об’єкти, якщо вони приймають участь в обміні з ORB з використанням IDL. Як правило, додатки складаються з кількох бізнес-об’єктів, що взаємодіють. Додатки-об’єкти будуються поверх ORB, які надаються ORB, Common Facilities та Object Facilities сервісів. Сутність для замовників (або системних інтеграторів) полягає в тому, щоб зібрати різні бізнес-об’єкти до одної системи, причому, поза залежністю від виробника.
CORBA та WWW. Відповідь на поставлене раніше питання - як об’єднати ІС, засновані на технології WWW, з іншими (в тому числі розподілені) ІС - полягає в наступному: слід пов’язати технологію розподілених об’єктів (тобто технологію CORBA) з технологією WWW. Метою такої роботи є детальний розгляд зв’язки CORBA та WWW. Питання впровадження CORBA в ІС виходить за рамки курсу. Є два рішення такої задачі, перше - будується на застосуванні технології CGI, а друге - на застосуванні технології Java. Досліджено практичне застосування цих технологій, з використанням продуктів Orbix та OrbixWeb від IONA Technologies.
CORBA - CGI. В чистому вигляді, технологія CGI полягає в наступному: для формування HTML - сторінки WEB - сервер запускає деякий CGI - скрипт, який може реалізувати достатньо складну функціональну логіку і звертатися, наприклад, до бази даних. CGI - скрипт представляє собою окремий виконуваний додаток і мова, на якій написаний скрипт, не відіграє великої ролі. Рішення CORBA- CGI, рис.1.10, базується на тому, що CGI - скрипт є одночасно однією з компонент розподіленої системи. Головна відмінність від технології CGI полягає в тому, що CGI - скрипт є не просто виконуваним модулем, а він є одночасно і CORBA - клієнтом. В певному смислі, скрипт служить точкою входу і виходу в розподіленій системі, усередині якої можуть відбуватися різноманітні процеси.
Рис. 1.10. CGI та CORBA
До переваг цієї технології можна віднести практично всі переваги використання CORBA. Крім того, користувач працює із звичними для нього HTML - сторінками, що особливо важливо при роботі з об’ємною текстовою інформацією. Стосовно недоліків цієї технології, практика свідчить, що це невелика ефективність системи. Кожного разу при пере завантаженні сторінки слід заново виконувати CGI - скрипт, заново встановлювати з’єднання з іншими компонентами системи. Це неефективно, що особливо виявляється, коли система одночасно використовується кількома користувачами. З іншого боку, не жертвуючи ефективністю, неможливо своєчасно повідомляти користувача про зміни, які відбулися в інформації, яка ним проглядається. Вони будуть помітними лише за умови пере завантаження сторінки. Тобто користувач приймає участь в системі виключно в ролі клієнта. Окремим рішенням проблеми
14.05.2018 22:05-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора