CORBA

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

CORBA (англ. Common Object Request Broker Architecture — загальна архітектура брокера об'єктних запитів) — це запропонований консорціумом OMG технологічний стандарт розробки розподілених застосунків.

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

Історія[ред.ред. код]

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

У травні 1989 р. була сформована OMG (Object Management Group). Нині OMG нараховує більше 700 членів (до OMG входять практично всі найбільші виробники програмного забезпечення (ПЗ), за винятком Microsoft). Задачею консорціуму OMG є визначення набору специфікацій, які дають змогу будувати інтероперабельні інформаційні системи.

Специфікація OMG — The Common Object Request Broker Architecture (CORBA) є індустріальним стандартом, який описує високорівневі засоби підтримки взаємодії об'єктів в розподілених гетерогенних середовищах. CORBA специфікує інфраструктуру взаємодії компонент (об'єктів) на представницькому рівні і на рівні додатків моделі OSI. Вона дає розглядати всі додатки в розподіленій системі як об'єкти. Причому, об'єкти можуть одночасно відігравати роль клієнта та сервера: роль клієнта, якщо об'єкт є ініціатором виклику на ньому який-небудь метод. Об'єкти-сервери зазвичай називають «реалізацією об'єктів». Практика показує, що більшість об'єктів одночасно виконують роль клієнтів і серверів, по черзі викликаючи методи на інших об'єктах і відповідаючи на виклики ззовні. Використовуючи CORBA, тим самим, є можливість будувати більш гнучкі системи, ніж системи клієнт-сервер, основані на дворівневій і трирівневій архітектурі.

Загальний огляд[ред.ред. код]

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

CORBA використовує мову опису інтерфейсів OMG IDL для визначення протоколів взаємодії об'єктів із зовнішнім світом. Стандарт CORBA описує правила відображення IDL у мову реалізації об'єкта: Ada, C, C++, Lisp, Smalltalk, Java, COBOL, Pl/i і Python. Також існують нестандартні відображення у Perl, Visual Basic, Ruby і Tcl, які реалізовані розробленими для них засобами ORB.

Ключові поняття технології[ред.ред. код]

Об'єкти за значенням (ОЗЗ)[ред.ред. код]

Крім віддалених об'єктів в CORBA 3.0 визначено поняття ОЗЗ. Код методів таких об'єктів за замовчуванням виконується локально. Якщо ОЗЗ був отриманий з віддаленого боку, то необхідний код повинен або бути наперед відомий обом сторонам, або бути динамічно завантажений. Щоб це було можливо, запис, що визначає ОЗЗ, містить поле Code Base — список URL, звідки може бути завантажено код. У ОЗЗ можуть також бути і віддалені методи.

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

Компонентна модель CORBA (CCM)[ред.ред. код]

Компонентна модель CORBA (CCM) — недавнє доповнення до сімейства визначень CORBA. CCM була введена починаючи з CORBA 3.0 і описує стандартний каркас додатку для компонент CORBA. CCM побудований під сильним впливом Enterprise Javabeans (EJB) і фактично є його незалежним від мови розширенням. CCM надає абстракцію суті, яка може надавати і отримувати сервіси через чітко визначені іменовані інтерфейси, порти.

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

Загальний протокол взаємодії брокерів (GIOP)[ред.ред. код]

GIOP — абстрактний протокол в стандарті CORBA, що забезпечує взаємодію брокерів. Стандарти, пов'язані з протоколом, випускає Object Management Group (OMG). Архітектура GIOP включає декілька конкретних протоколів:

  1. Internet INTERORB Protocol (IIOP) — Міжброкерний Протокол Інтернету, протокол для організації взаємодії між різними брокерами, опублікований консорціумом OMG. IIOP використовується GIOP в середовищі інтернет і забезпечує відображення повідомлень між GIOP і шаром TCP/IP.
  2. SSL INTERORB Protocol (SSLIOP) — IIOP поверх SSL, підтримуються шифрування і аутентифікація.
  3. Hypertext INTERORB Protocol (HTIOP) — IIOP поверх HTTP.

Corba Location[ред.ред. код]

Corbaloc — це скорочення від Corba Location і є рядковим посиланням на об'єкт CORBA і виглядає схоже на URL.

Всі реалізації CORBA повинні підтримувати як мінімум два варіанти певний OMG URL: corbaloc: і corbaname:. Їхнє призначення в тому, щоб надати людині можливість читати/редагувати посилання, за допомогою якого можна отримати IOR.

Ось приклад corbaloc:

corbaloc::160.45.110.41:38693/standardns/nameserver-poa/_root

Реалізація CORBA може надавати підтримку форматів "http: ", "ftp: " і "file: ". Призначення цих форматів в тому, щоб вказати спосіб, звідки узяти рядкове представлення IOR.

Мова OMG IDL[ред.ред. код]

Мова OMG IDL (Interface Definition Language — Мова Опису Інтерфейсу) представляє собою технологічно незалежний синтаксис для опису інтерфейсу об'єктів. При описі програмної архітектури, OMG IDL добре використовується як універсальна нотація для окреслювання границь об'єкту, які визначають його поведінку у відношенні до інших компонентів ІС. OMG IDL дає змогу описати інтерфейси, які мають різні методи та атрибути. Мова також підтримує дослідження інтерфейсів, що необхідно для повторного використання об'єктів з можливістю їх розширення чи конкретизації. IDL є чисто декларативною мовою, тобто вона не містить ніякої реалізації. IDL — специфікації можуть бути відкомпільовані (відображені) в заголовкові файли та спеціальні прототипи серверів, які можуть використовуватися безпосередньо програмістом. Тобто IDL — визначені методи можуть бути написані, і далі виконані, на будь-якій мові, для якої існує відображення з IDL. До таких мов відносяться С, С++, SmallTalk, Java та Ada.

рис.1. CORBA IDL відображення в моделі Клієнт/Сервер

Object Management Architecture[ред.ред. код]

Восени 1990 р. OMG вперше опублікувала документ Object Management Architecture Guide (OMA Guide). Він був відкоригований у вересні 1992 р. Деталі Common Facilities (Спільні засоби) були добавлені в січні 1995 р. На рис. 2 показані чотири основні елементи цієї архітектури:

рис 2. OMG's Object Management Architecture
  • Object Request Broker визначає об'єктну шину CORBA.
  • Common Object Services представляють собою колекцію служб, споряджених об'єктивними інтерфейсами, які забезпечують підтримку базових функцій об'єктів.
  • Common Facilities утворюють набір класів та об'єктів, які підтримують корисні в багатьох системах функції. Прикладні об'єкти представляють прикладні системи кінцевих користувачів і забезпечують функції, які є унікальними для даної прикладної системи.
  • Application Objects — це прикладні бізнес-об'єкти і додатки, які є основними споживачами всієї CORBA інфраструктури.

ORB, Object Request Broker[ред.ред. код]

ORB, Object Request Broker (брокер об'єктних запитів) — це об'єктна шина, яка дає змогу об'єктам напряму виробляти і відповідати на запити інших об'єктів, розташованих як локально (на одному комп'ютері, але в різних процесах), так і віддалено. Клієнта не цікавлять комунікаційні та інші механізми, з використанням яких відбувається взаємодія між об'єктами, виклик і збереження серверних компонентів. CORBA — специфікації зачіпають лише IDL, відображення в інші мови, APIs для взаємодії з CORBA та сервіси, які надаються ORB. CORBA ORB не надає широкого набору розподілених middleware (проміжних) послуг. Шина ORB дає змогу об'єктам знаходити один другого прямо в процесі роботи і викликати один у другого різноманітні служби. Вона є набагато тоншою системою, порівняно з іншими клієнт/сервер middleware — системами, такими, як RPC (Remote Procedure Calls) чи MOM (Message-Oriented Middleware).

Шлях від RPC до ORB[ред.ред. код]

Шлях від RPC до ORB. Стосовно відмінності механізму викликів CORBA та RPC можна сказати наступне. Ці механізми схожі, але між ними є серйозні відмінності. З використанням RPC можна викликати певну функцію, а з використанням ORB можна викликати метод у певного об'єкта. Різні об'єкти класів можуть по-різному відповідати на виклик одного і того ж методу. Оскільки кожний об'єкт управляє своєю власною (на додаток — особистою) інформацією, то метод буде викликаний на сугубо конкретних даних. У випадку RPC, буде виконана лише якась конкретна частина коду сервера, яка і взаємодіє з даними сервера. Всі функції з однаковими іменами будуть виконані абсолютно однаково. В RPC відсутня конкретизація викликів, в тому розумінні, в якому це відбувається в ORB. В 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 викликає метод на віддаленому об'єкті. Тобто виконання одних і тих же функцій на різних об'єктах призведуть до різних дій, в залежності від типу об'єкта.

CORBA та WWW[ред.ред. код]

CORBA та WWW. Відповідь на поставлене раніше питання — як об'єднати ІС, засновані на технології WWW, з іншими (в тому числі розподілені) ІС — полягає в наступному: слід пов'язати технологію розподілених об'єктів (тобто технологію CORBA) з технологією WWW. Метою такої роботи є детальний розгляд зв'язки CORBA та WWW. Питання впровадження CORBA в ІС виходить за рамки курсу. Є два рішення такої задачі, перше — будується на застосуванні технології CGI, а друге — на застосуванні технології Java. Досліджено практичне застосування цих технологій, з використанням продуктів Orbix та OrbixWeb від IONA Technologies.

CORBA — CGI[ред.ред. код]

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

рис 3. CGI та CORBA

До переваг цієї технології можна віднести практично всі переваги використання CORBA. Крім того, користувач працює із звичними для нього HTML — сторінками, що особливо важливо при роботі з об'ємною текстовою інформацією. Стосовно недоліків цієї технології, практика свідчить, що це невелика ефективність системи. Кожного разу при пере завантаженні сторінки слід заново виконувати CGI — скрипт, заново встановлювати з'єднання з іншими компонентами системи. Це неефективно, що особливо виявляється, коли система одночасно використовується кількома користувачами. З іншого боку, не жертвуючи ефективністю, неможливо своєчасно повідомляти користувача про зміни, які відбулися в інформації, яка ним проглядається. Вони будуть помітними лише за умови пере завантаження сторінки. Тобто користувач бере участь у системі виключно в ролі клієнта. Окремим рішенням проблеми ефективності виконання CGI — запитів (особливо в багатокористувацькій системі), може бути розширення функціональності використовуваного WEB — сервера, шляхом добавлення до нього відповідних функцій. В цьому напрямку здійснена робота з вбудовуванню до WEB — сервера Apache (платформи SunOS, Windows NT) підтримки звернення до Orbix ORB. Складності також виникають в разі створення, складних гілкуватих користувацьких інтерфейсів. Справа в тому, що в системі, за умови виконання запитів окрім введеної у вікно браузера інформації, необхідна додаткова, скрита від користувача, яка характеризує поточний стан система інформація. Вся інтерфейсна частина системи прив'язана до вікна браузера, а та, яка виводиться на екран інформація створюється динамічно в залежності від параметрів запиту та внутрішнього стану інформаційної системи на певний момент часу. Внаслідок цього, якщо користувач виконує неконтрольовану навігацію вперед-назад за сторінками, що проглядаються, підвищується ризик десинхронізації інформації, яка проглядається користувачем і зберігається на сервері, що не є припустимим. Більше того, система повинна слідкувати і за тим, щоб вільні переходи від сторінки до сторінки мали б логічний смисл, що важливо. Тим самим, у випадках складних користувацьких інтерфейсів необхідна наявність жорсткого контролю за поточним станом ІС.

Java-CORBA[ред.ред. код]

Друге рішення проблеми зв'язування технологій CORBA та WWW — мова Java, рис. 4. Справа в тому, що OMG стандартизувала відображення з IDL в Java. Є програмні продукти, які реалізують зв'язок CORBA та Java — наприклад, Java Virtual Machine (JVM), всередині якої і виконується завантажений аплет.

рис.4 Java та CORBA

Java — аплет, який є CORBA — клієнтом, встановлює всі необхідні з'єднання з іншими (серверними) додатками системи і саме через нього до користувача йде вся інформація. Аплет відіграє роль користувацького інтерфейсу для даної розподіленої системи. Кількість виконуваних аплетів нічим не обмежена — питання лише в достатніх обчислювальних ресурсах системи. Переваги та недоліки технології Java- CORBA такі. Переваги: Java — платформо-незалежна мова, всі аплети виконуватимуться однаково на будь-якій системі; існує можливість створення складних користувацьких інтерфейсів; аплети можуть виконувати роль клієнта та сервера; всі переваги технологій CORBA та Java; не виникає проблем за умови одночасної роботи декількох користувачів. Немає необхідності кожного разу заново завантажувати аплет, як це відбувається у випадку і CGI. Недоліки: для ефективного виконання Java — додатків, система користувача повинна мати достатньо потужні обчислювальні ресурси, що особливо важливо для складних (насичених) користувацьких інтерфейсів; не всі браузери підтримують Java, чи її останні версії. Такі вбудовані в Java засоби як багато потоковість, дають змогу легко реалізувати синхронну та асинхронну взаємодію аплетів з іншими додатками. В технології Java — CORBA практично відсутні слабкі місця. Єдина проблема, яка може виникнути — необхідність наявності обчислювальних ресурсів на стороні користувача, що є серйозним недоліком, який скоріше за все є недоліком мови Java.

Застосування технологій Java-CORBA та CORBA-CGI[ред.ред. код]

Практика свідчить, що технологія Java-CORBA краще за все підходить для створення WWW CORBA-клієнтів, які: мають нестандартний, або не HTML — подібний користувацький інтерфейс; активно взаємодіє з іншими компонентами ІС протягом часу; повинні брати участь у системі в ролі клієнта, та в ролі сервера. Технологію CORBA-CGI вигідно застосовувати у випадку, якщо: відбувається робота з великими обсягами текстової інформації; системні ресурси на стороні клієнта малопотужні. Незважаючи на те, що переваги технології Java-CORBA над технологією CORBA-CGI значні, і область застосування ширша, обидві розглянуті технології добре підходять для об'єднання WWW — систем та клієнт/сервер — систем. Технологія CORBA-CGI розширює можливості CGI, а технологія Java-CORBA можливості всього WWW — до рівня розподілених об'єктних систем. Тобто нині технології Java та CORBA добре доповнюють одна іншу як потужний і універсальний засіб для захисту проблеми об'єднання систем, які базуються на технології WWW, з подібними та іншими, особливо розподіленими, ІС. Проте з'являється нова технологія DCOM (Microsoft), яка сильно потіснила CORBA з ринку Windows — орієнтованих систем. Технологія RMI, навпаки, робить кроки назустріч CORBA. Починаючи з JDK 1.2, протокол RMI буде виконуватися поверх протоколу IIOP, що вигідно Java та CORBA розробникам. Масове використання технології Java-CORBA виведе Internet на новий рівень взаємодії. В такий спосіб відбудеться перехід від Web до нової, об'єктної мережі — Object Web.


Список брокерів (CORBA Orbs)[ред.ред. код]

  • Borland Enterprise Server, VisiBroker Ed. — CORBA 2.6-сумісний комерційний ORB від Borland, підтримує Java і C++.
  • MICO — Вільний (LGPL) ORB з підтримкою C++.
  • omniORB — Вільний (LGPL) ORB для C++ і Python.
  • ORBit2  — Вільний (LGPL) ORB для C, C++ і Python.
  • JacORB — Вільний (LGPL) ORB з підтримкою Java.
  • TAO — The ACE ORB, відкритий ORB для C++.
  • Orbacus — комерційний ORB від IONA Technologies.

Література[ред.ред. код]

  • Б. В. Кузьменко, О. А. Чайковська «ТЕХНОЛОГІЯ РОЗПОДІЛЕНИХ СИСТЕМ ТА ПАРАЛЕЛЬНИХ ОБЧИСЛЕНЬ» Навчальний посібник. — Київ — 2011. 19-32 с.
  • Корнеев В. В. Параллельные вычислительные системы. — М.: Нолидж, 1999 г.

Див. також[ред.ред. код]

Посилання[ред.ред. код]