ЛЕКЦІЯ 23. КОМПОНЕНТНА МОДЕЛЬ CORBA
План
23.1. Основи CORBA
23.2 Об'єктна модель CORBA
23.2.1. Брокер об'єктних запитів (Object Request Broker - ORB)
23.2.2. Базовий об'єктний адаптер
23.2.3. Мова опису інтерфейсів
23.2.4. Інтерфейс динамічного виклику
23.2.5. Репозиторій інтерфейсів
23.3. Протоколи взаємодії різних об'єктних брокерів (GIOP, IIOP)
23.4 Архітектура інформаційної системи з використанням CORBA
23.5. Архітектура управління об'єктами в CORBA
23.6. Порівняння CORBA з іншими компонентними моделями
23.6.1. Порівняння RPC і CORBA
23.6.2. Порівняння DCOM і CORBA
23.1. Основи CORBA
CORBA (Common Object Request Broker Architecture) - це набір відкритих специфікацій інтерфейсів, що визначає архітектуру технології міжпроцесної взаємодії і незалежного маніпулювання об'єктами. Розробниками технології інтерфейсів є OMG і X/Open.
Object Management Group, Inc. (OMG) - це інтернаціональна організація, заснована в 1989 р., до складу якої входить більше 800 членів: постачальників інформаційних систем, розробників програмного забезпечення і користувачів. OMG просуває теорію і практику об'єктно-орієнтованої технології в область практичної розробки програмного забезпечення. Цей процес включає розробку промислових стандартів і специфікацій управління об'єктами з метою створення загальної бази для розробки програмного забезпечення. Першочерговими завданнями є: повторне використання, переносимість і інтероперабельність (здатність до взаємодії) об'єктно-орієнтованого програмного забезпечення в розподілених, гетерогенних середовищах. Підтримка цих стандартів створює можливість розробляти кросплатформні застосування, що працюють на всіх основних платформах і операційних системах.
X/Open - незалежна всесвітня відкрита організація, підтримувана більшістю відомих постачальників інформаційних систем, користувачів і компаній-виробників програмного забезпечення. X/Open розробляє на основі існуючих і нових стандартів інтегроване системне оточення - Common Applications Environment (CAE). Компоненти CAE визначені в стандартах X/Open CAE. Основна мета CAE - створення пакетів програмних інтерфейсів (API) які можуть застосовуватися на практиці із збереженням максимальної переносимості на рівні початкових кодів програм. API також підвищують рівень взаємодії застосувань за допомогою надання визначень і посилань на протоколи і їх профілі.
Концептуальною інфраструктурою, на якій базуються всі специфікації OMG, є Object Management Architecture (OMA). До складу OMA входять стандартизовані OMG сервіси (служби), програмні зразки і шаблони (CORBAservices, horizontal and vertical CORBAfacilities), мова визначення інтерфейсів розподілених об'єктів IDL (Interface Definition Language), стандартизовані відображення IDL на мови програмування і, нарешті, об'єктна модель CORBA.
Реалізувати технологію відповідно до специфікацій може хто завгодно. Створені програмні продукти, природно, вже не є відкритими, а стають комерційними продуктами.
Завдання CORBA — здійснити інтеграцію ізольованих систем, дати можливість програмам, написаним на різних мовах, працюючих на різних вузлах мережі, взаємодіяти один з одним так само просто, неначебто вони знаходяться в адресному просторі одного процесу.
CORBA дозволяє розглядати всі застосування в розподіленій системі як об'єкти. Причому об'єкти можуть одночасно грати роль і клієнта, і сервера: роль клієнта, якщо об'єкт є ініціатором виклику методу іншого об'єкту; роль сервера, якщо інший об'єкт викликає на ньому який-небудь метод. Об'єкти-сервери зазвичай називають реалізацією об'єктів. Практика показує, що більшість об'єктів одночасно виконують роль і клієнтів, і серверів, по черзі викликаючи методи інших об'єктів і відповідаючи на виклик ззовні. Використовуючи CORBA, тим самим, є можливість будувати набагато гнучкіші системи, ніж системи клієнт-сервер, засновані на дворівневій чи трирівневій архітектурі.
Головними компонентами моделі CORBA є:
- брокероб'єктнихзапитів (Object Request Broker);
- мовавизначенняінтерфейсів (Interface Definition Language).
У специфікацію CORBA входить також декілька додаткових, але важливих служб (сервісів):
- служба динамічного формування запитів (DII);
- служба репозиторія інтерфейсів (IR);
- служба динамічної обробки запитів (DSI);
- служби особистих брокерів запитів (GIOP).
Характерні особливості розробок кросплатформних розподілених ПС за технологією CORBA полягають в наступному:
- Мова опису інтерфейсів OMGIDL дозволяє визначити інтерфейс, незалежний від мови реалізації.
- Високий рівень абстракції CORBA в семирівневій моделі відкритих систем позбавляє програміста від роботи з низькорівневими мережевими протоколами.
- Програмісту не потрібна інформація про місце сервера в мережевій інформаційній системі і способі його активації.
- Розробка клієнтської програми не залежить від серверної операційної системи і апаратної платформи.
23.2. Об'єктна модель CORBA
Об'єктна модель CORBA визначає взаємодію між клієнтами і серверами. Клієнти — це застосування, які використовують сервіси, що надаються серверами. Об'єкти-сервери містять набір сервісів, що розділяються між багатьма клієнтами. Операція вказує запрошуваний сервіс. Інтерфейси об'єктів описують операції, які можуть бути викликані клієнтами певного об'єкту. Реалізації об'єктів — це застосування, які виконують сервіси, що викликаються клієнтами.
23.2.1. Брокероб'єктнихзапитів (Object Request Broker - ORB)
Головний компонент CORBA — брокер об'єктних запитів (ORB - Object Request Broker) - програмне забезпечення, що забезпечує зв'язок між об'єктами. Його завданням є надання механізму виконання запиту об'єкту-клієнта: пошук об'єкту, до якого відноситься даний запит, передача необхідних даних, підготовка об'єкту до обробки. Брокер забезпечує прозору взаємодію клієнтського і серверного застосувань. Для розробника виклик методів віддалених об'єктів не відрізняється від звичайних локальних викликів.
Стандарт CORBA визначає, яким чином програмні компоненти, розподілені по мережі, можуть взаємодіяти один з одним незалежно від операційних систем і мов реалізації.
ORB дозволяє:
- знайти віддалений об'єкт по Об'єктному Посиланню (IOR - Interoperable Object Reference);
- викликати метод віддаленого об'єкту, передавши йому вхідні параметри (маршалінг параметрів - marshaling parameters);
- отримати значення і параметри, які повертаються від сервера (демаршалінг параметрів - unmarshaling parameters).
Обробка викликів різних видів відбувається різними способами. Виклик віддаленого об'єкту обробляється особливими методами, визначеними в CORBA-специфікації. Вони формують по зробленому запиту низькорівневе представлення, залежне від використовуваних апаратно-програмних засобів.
Клієнт може викликати методи об'єктів за допомогою ORB декількома способами. Можливі варіанти взаємодії об'єктів показані на рис. 23.1.
Рис. 23.1. Взаємодія об'єктів в CORBA
Dynamic Invocation Interface (DII): дозволяє клієнту знаходити сервери і викликати їх методи під час роботи системи.
IDL Stubs: визначає, яким чином клієнт виконує виклик сервера.
ORB Interface: загальні як для клієнта, так і для сервера служби (сервіси).
IDL Skeleton: забезпечує статичні інтерфейси для об'єктів певного типа.
Dynamic Skeleton Inerface: загальні інтерфейси для об'єктів, незалежно від їх типу, які не були визначені в IDL Skeleton.
Object Adapter: здійснює комунікаційну взаємодію між об'єктом і ORB.
Виклик операцій об'єкта-сервера, що розділяється, може бути статичним, через IDL-перехідник, або динамічним (Dynamic Invocation Interface). В разі статичного виклику описи інтерфейсів на IDL відображаються в програмний код на мовах C, С++, Smalltalk тощо. При використанні динамічного інтерфейсу запити формуються спеціальним чином, без відображення інтерфейсу об'єкту у початковий код застосування, що розробляється.
Інформація про інтерфейси об'єктів може бути отримана клієнтом під час компіляції або під час виконання. Інтерфейси можуть бути також вказані за допомогою служби репозиторія інтерфейсів (Interface Repository). Цей сервіс представляє інтерфейси, як об'єкти, забезпечуючи доступ до них під час роботи застосування.
Брокер об'єктних запитів є проміжним програмним забезпеченням, призначеним для об'єднання інформаційних ресурсів розподіленої неоднорідної системи, дозволяючи одній частині системи не піклуватися про фізичне розташування інших частин (об'єктів) системи.
На ринку представлені ORB різних виробників (наприклад, VisiBroker, WebLogic), але всі вони відповідають єдиній специфікації CORBA. Тому в принципі CORBA дозволяє будувати розподілені системи, одночасно використовуючи ORB різних виробників, і будуючи систему одночасно на різних платформах і різних мережевих протоколах.
В архітектурі CORBA кожен об'єкт, методи якого доступні іншим об'єктам (зазвичай його називають CORBA-об'єктом), має унікальне по всій доступній мережі Об'єктне Посилання (IOR - Interoperable Object Reference), по якому до нього можна звернутися. Шукати CORBA-об'єкти можна як по IOR, так і по символічних іменах, якщо вони зареєстровані (зазвичай при створенні) в спеціальному сервісі імен (NameService). Для звернення до методів CORBA-об'єкта останній має відкритий для всіх останніх CORBA-об'єктів інтерфейс. Інтерфейси CORBA- об'єктів прийнято описувати на спеціальній, визначеній специфікацією CORBA мові IDL (Interface Definition Language). Виробники ORB поставляють разом з ORB також і утиліти, що перетворюють описи інтерфейсів CORBA- об'єктів в конструкції відповідних мов програмування.
23.2.2. Базовий об'єктний адаптер
Специфікація OMG CORBA визначає базовий об'єктний адаптер (Basic Object Adapter - BOA), який має бути реалізований в усіх брокерах запитів. Базовий об'єктний адаптер — це набір інтерфейсів для створення посилань на віддалені об'єкти, реєстрації об'єктів, авторизації запитів і активізації застосувань.
Основна функція об'єктного адаптера, який використовується для реалізації CORBA-об'єкта, — забезпечення доступу до служб брокера об'єктних запитів. Об'єктний адаптер надає всі низькорівневі засоби для зв'язку об'єкту з його клієнтами. До числа цих засобів входять:
- генерація посилань на віддалені об'єкти;
- виклик методів, визначених в IDL;
- забезпечення безпеки взаємодії;
- активація і деактивація об'єктів;
- встановлення відповідності між посиланнями на віддалені об'єкти і реальними екземплярами об'єктів;
- реєстрація об'єктів.
Загалом, для кожного типа застосувань передбачається створення власного об'єктного адаптера. Базовий об'єктний адаптер є рішенням першочергової задачі забезпечення зв'язку між реалізацією об'єкту і брокером запитів. Для організації взаємодії між ORB і, наприклад, системою управління базами даних має бути розроблений свій об'єктний адаптер.
23.2.3. Мова опису інтерфейсів
Мова опису інтерфейсів (IDL) — ключовий елемент специфікації CORBA. Вона є засобом, за допомогою якого можуть бути визначені операції, що викликаються клієнтами у віддалених серверних об'єктах. IDL — повністю об'єктно-орієнтована мова, що підтримує інкапсуляцію, спадкоємство (у тому числі множинне) і поліморфізм.
Синтаксис IDL подібний до синтаксису мови С++, що спрощує його вивчення великою кількістю розробників, що володіють С++. В той же час, IDL є потужною мовою, що дозволяє описувати інтерфейси CORBA об'єктів будь-якої складності. У мову введені всі конструкції, необхідні для відображення об'єктних властивостей застосувань.
Опис інтерфейсу на IDL складається із заголовка і тіла. Заголовок містить назву інтерфейсу і вказує успадковані інтерфейси. Тіло складається з оголошень констант, типів, виняткових ситуацій, атрибутів і операцій.
IDL — не повна мова програмування. Це чисто декларативна мова, що описує інтерфейс і не містить жодної реалізації.
IDL-специфікації можуть бути відкомпільовані в заголовочні файли і спеціальні прототипи серверів, які можуть використовуватися безпосередньо програмістом. Тобто IDL-визначені методи можуть бути написані, а потім виконані, на будь-якій мові, для якої існує відображення з IDL.
Відображення також є предметом стандартизації OMG. Відомі стандартизовані відображення для Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I і Python (рис. 23.2).
Рис. 23.2. CORBA IDL відображення в моделі Клієнт/Сервер.
За допомогою IDL можна описати і атрибути компонента, і батьківські класи, які вона успадковує, і виключення, що викликаються, і, нарешті, методи, що визначають інтерфейс, причому з описом вхідних і вихідних параметрів.
23.2.4. Інтерфейс динамічного виклику
Інтерфейс динамічного виклику (DII - Dynamic Invocation Interface) дозволяє застосуванням клієнтів формувати довільні запити до об'єктів-серверів, інтерфейси яких невідомі на стадії компіляції клієнтського застосування (тобто, динамічно). Інформація про структуру інтерфейсу, до якого звертається клієнт для виклику відповідної операції, може бути отримана під час роботи програми, якщо відомі ім'я операції і список параметрів і є посилання на відповідний об'єкт-сервер. Практично DII дає можливість вести розробку клієнтських і серверних програм окремо.
23.2.5. Репозиторій інтерфейсів
Репозиторій інтерфейсів (Interface Repositоry) містить визначення інтерфейсів на IDL, дозволяє бачити інтерфейси доступних серверів в мережі і програмувати їх використання в програмах-клієнтах.
За допомогою репозиторія інтерфейсів (IR) застосування під час виконання можуть отримувати інформацію про структуру і формати IDL-інтерфейсів, необхідну для генерації динамічних запитів.
Визначення інтерфейсів зберігаються в репозиторії у вигляді сукупності об'єктів, що містять описи операцій, можливих виняткових ситуацій, типів параметрів. Репозиторій забезпечує також механізм доступу до цих об'єктів. Будучи одним з головних компонентів стандарту CORBA, IR підтримує взаємодію брокерів різних виробників.
Фізично репозиторій інтерфейсів є програмним компонентом, що має власний IDL-інтерфейс. Через цей інтерфейс різні застосування отримують дані про інші CORBA-об'єкти.
Специфікація репозиторія інтерфейсів зручна для побудови застосувань, в яких дані, параметри і функції можуть змінюватися під час роботи застосувань. До цієї категорії відносяться CASE-засоби, навігатори тощо.
23.3 Протоколи взаємодії різних об'єктних брокерів (GIOP, IIOP)
Основним завданням специфікації CORBA є забезпечення взаємодії об'єктів, які розподілені по різнорідній мережі і використовують в загальному випадку різні брокери запитів. Для зв'язку між брокерами був розроблений протокол General Inter ORB Protocol (GIOP), який стандартизує низькорівневе представлення даних і формати повідомлень.
Таким чином, GIOP - абстрактний протокол в стандарті CORBA, що забезпечує взаємодію брокерів. Архітектура GIOP включає декілька конкретних протоколів:
- InternetINTERORBProtocol (IIOP) - Міжброкерний протокол для Інтернет, це протокол для організації взаємодії між різними брокерами, опублікований консорціумом OMG. IIOP використовується GIOP в середовищі Інтернет, і забезпечує відображення повідомлень між GIOP і TCP/IP, тобто, визначає обмін повідомленнями у форматі GIOP через TCP/IP-з'єднання.
- SSLINTERORBProtocol (SSLIOP) - це IIOPнад протоколом SSL, підтримуються шифрування і аутентифікація.
- HyperTextINTERORBProtocol (HTIOP) - це IIOPнад протоколом HTTP.
За потреби, протокол GIOP може бути реалізований на основі інших транспортних протоколів, наприклад, IPX/SPX. Ієрархія специфікацій взаємодії брокерів запитів за стандартом CORBA зображена на рис. 23.3.
Рис. 23.3. Основні служби (сервіси) стандарту CORBA
23.4 Архітектура інформаційної системи з використанням CORBA
Трирівнева архітектура інформаційних систем, згідно специфікацій OMG, включає системи управління даними, мережі взаємодіючих CORBA-об'єктів і інтерфейси користувача для представлення даних. Трирівнева архітектура інформаційних систем, розроблена з використанням в якості проміжного ПЗ засобів CORBA представлена на рис. 23.4.
Рис. 23.4. Трирівнева архітектура інформаційних систем
Вочевидь, що для більшості ІС необхідна деяка множина загально-системних об'єктних сервісів (служб), які не залежать від предметної області і забезпечують базову функціональність для управління розподіленими об'єктами. З метою полегшення створення розподілених застосувань консорціум OMG стандартизував основні системні служби (сервіси)
Основні сервіси моделі CORBA:
Служба іменування (Naming service) служить для управління посиланнями на CORBA-об'єкти і їх зберігання. Її основне завдання полягає в тому, щоб універсальним чином організувати з'єднання об'єктів один з одним. Служба іменування оперує зі сховищем об'єктних посилань. Звернення до неї виконується для отримання потрібного об'єктного посилання, що ідентифікується по зрозумілому розробникові імені об'єкту.
Служба подій (Event service) забезпечує підтримку асинхронної взаємодії застосувань.
Служба зберігання об'єктів (Persistence service) надає набір універсальних інтерфейсів для збереження екземплярів об'єктів в довготривалій пам'яті. Служба розроблена таким чином, що можлива її реалізація на основі об'єктної бази даних.
Служба управління транзакціями (Transaction service) підтримує багато моделей транзакцій, включаючи вкладені транзакції. Необхідна для коректної роботи застосувань в розрахованому на багато користувачів режимі.
Служба зв'язку (Relationship service) реалізує логічні зв'язки між CORBA-об'єктами. Служба визначає два додаткові типи об'єктів: зв'язок і роль. Роль є CORBA-об'єкт, що відображає характер зв'язку, а зв'язок характеризує залежності об'єктів прикладної області.
Служба управління розподіленими ресурсами (Concurrency control service ) дозволяє клієнтам координувати свої дії при використанні ресурсів, що розділяються. Управління розподіленими ресурсами здійснюється за допомогою блокувань. Кожне блокування асоціюється з єдиним ресурсом і єдиним клієнтом. Служба визначає декілька режимів блокувань, які відповідають різним способам доступу.
Служба зовнішнього представлення (Externalization service) формує копію CORBA-об'єкта у вигляді деякого зовнішнього представлення — файлу, елементу бази даних тощо.
23.5. Архітектура управління об'єктами в CORBA
Специфікація CORBA передбачає також ряд стандартизованих сервісів (CORBA Services), а також горизонтальних і вертикальних Загальних Засобів (Common Facilities). Сервіси є звичайними CORBA-об'єктами із стандартизованими (і написаними на IDL) інтерфейсами. До таких сервісів відноситься, наприклад, вже згадуваний сервіс імен NameService, сервіс повідомлень, що дозволяє CORBA- об'єктам обмінюватися повідомленнями, сервіс транзакцій, що дозволяє CORBA- об'єктам організовувати транзакції. У реальній системі не обов'язково мають бути присутніми всі сервіси, їх набір залежить від необхідної функціональності.
Між об'єктними сервісами і загальними засобами CORBA немає чіткої межі. Останні теж є CORBA- об'єкти із стандартизованими інтерфейсами. Common Facilities діляться на горизонтальні (загальні для всіх прикладних областей) і вертикальні (для конкретної прикладної області). Наприклад, розроблені Common Facilities для медичних організацій, для ряду виробництв тощо. На рис. 23.5 зображено чотири основні елементи цієї архітектури:
Рис. 23.5. Архітектура управління об'єктами в CORBA
- Object Request Broker визначає об'єктну шину CORBA.
- Common Object Services є колекцією служб з інтерфейсами об'єктів і базових функцій об'єктів, що забезпечують підтримку.
- Common Facilities (загальні засоби) утворюють набір класів і об'єктів, що підтримують корисні в багатьох прикладних системах функції. Прикладні об'єкти представляють прикладні системи кінцевих користувачів і забезпечують функції, унікальні для даної прикладної системи.
Common Facilities заповнюють простір між ORB і об'єктними службами з одного боку, і прикладними сервісами, з іншого. Таким чином, ORB забезпечує базову інфраструктуру, Object Services — фундаментальні об'єктні інтерфейси, а завдання Common Facilities — підтримка інтерфейсів сервісів високого рівня, які, можуть включати спеціалізацію Object Services. Таким чином, операції, Common Facilities, що представляються, призначені, зокрема, для використання Object Services і прикладними об'єктами. Реалізується це за допомогою спадкоємства стандартних інтерфейсів.
Загальні засоби діляться на горизонтальні і вертикальні. До горизонтальних відносяться такі загальні сервіси, як, наприклад, управління інформацією, завданнями, всією системою, тобто засоби, не залежні від конкретних прикладнихсистем.
До вертикальних же відносяться сервіси, специфічні для якої-небудь діяльності, — наприклад, медицина, фінанси.
- Application Objects прикладні бізнес-об'єкти і застосування, які є основними споживачами всієї CORBA інфраструктури.
Application Objects - об'єкти, якщо вони беруть участь в обміні з ORB, повинні визначаться за допомогою IDL. Зазвичай застосування складаються з декількох взаємодіючих бізнес-об'єктів. І, як правило, застосування-об'єкти будуються над ORB, та сервісами, що надаються Common Facilities і Object Facilities. Завдання для замовників (або системних інтеграторів) полягає в тому, щоб зібрати різні бізнес-об'єкти в одну систему, при тому, незалежно від виробника.
23.6. Порівняння CORBA з іншими компонентними моделями
23.6.1. Порівняння RPC і CORBA
Чим механізм викликів CORBA відрізняється від механізму RPC? Ці механізми схожі, але проте між ними є серйозні відмінності в реалізації. За допомогою RPC можна викликати певну функцію. А за допомогою ORB можна викликати метод в певного об'єкту. Різні об'єкти класів можуть по-різному відповідати на виклик одного і того ж методу. Оскільки кожен об'єкт управляє своєю власною інформацією, то метод буде викликаний на суто конкретних даних.
В разі RPC, буде виконаний лише якийсь конкретний фрагмент коду сервера, який і взаємодіє з даними сервера. Всі функції з однаковими іменами будуть виконані абсолютно однаково. У RPC відсутня конкретизація викликів, в тому сенсі, в якому це відбувається в ORB. У ORB всі виклики функцій відбуваються до конкретних об'єктів, тим самим, результати цих функцій можуть бути абсолютно різні. Виклики функцій обробляються в специфічній для кожного окремого об'єкту формі.
Переваги ORB
В теорії, CORBA представляється як найкраще клієнт/сервер ПЗ проміжного рівня (middleware), але на практиці вона хороша лише настільки, наскільки хороші продукти, що її реалізують. До основних комерційних ORB відносяться: Orbix від фірми IONA Technologies; DSOM від IBM; ObjectBroker від Digital; JOE від Sun; Visibroker від Visigenic і Netscape; ORB+ від HP.
Невеликий список переваг, які має кожна CORBA ORB:
- Статичні і динамічні виклики методів. CORBA ORB надає можливість або статично визначити виклики методів прямо під час компіляції, або знаходити їх динамічно, але вже під час роботи програми.
- Відображення в мови високого рівня. CORBA ORB дозволяє викликати методи в серверних компонентів, використовуючи будь-яку з мов високого рівня — C, C++, SmallTalk, Java і Ada. Абсолютно неважливо, на якій мові написані об'єкти. CORBA відділяє інтерфейси від реалізації і надає незалежні типи даних, що дозволяє здійснювати виклик методів, минувши кордони якоїсь конкретної мови програмування і конкретної операційної системи.
- Система є самоописуємою. За допомогою своїх метаданих, CORBA дозволяє описувати інтерфейс будь-якого сервера, відомого системі. Кожна CORBA ORB повинна підтримувати Репозиторій Інтерфейсів, який зберігає необхідну інформацію, що описує синтаксис інтерфейсів, підтримуваних серверами. У своїй роботі клієнти використовують ці метадані для здійснення викликів до серверів.
- Прозорість. ORB може виконуватися як сам по собі (наприклад на портативному комп'ютері), так і в оточенні інших ORB, з якими вона взаємодіє шляхом CORBA 2.0 IIOP (Internet INTER-ORB Protocol) протоколу. ORB може здійснювати між-об'єктну взаємодію і для одного процесу, і для декількох процесів, що виконуються на одній машині, і для процесів, чиє виконання відбувається в мережі, під різними операційними системами. Реалізація цих взаємодій не зачіпає самі об'єкти. У загальних рисах, при використанні технології CORBA, розробник не повинен турбуватися ні про такі речі як розташування серверів, запуск об'єктів, вирівнювання розміру змінних залежно від платформи і операційної системи, ні про те, як здійснюється передача повідомлень. Вирішення всіх цих завдань бере на себе продукт, що підтримує стандарт CORBA.
- Вбудована безпека. Всі свої запити ORB доповнює деякою контекстною інформацією, яка забезпечує збереження даних.
- Поліморфізм при виклику методів. Як вже говорилося, ORB не просто викликає віддалений метод — ORB викликає метод на віддаленому об'єкті. Тобто виконання одних і тих же функцій на різних об'єктах приводитиме до різних дій, залежно від типу об'єкту.
23.6.2. Порівняння CORBA і DCOM
CORBA претендує на спробу створення стандартної платформи проміжного рівня для спільної роботи застосувань різних виробників.
Основною метою розробки DCOM було розширення функціональних можливостей при збереженні сумісності з існуючими версіями, які були в ранніх версіях Windows.
По різному реалізовані і інтерфейси. CORBA надає стандартну мову IDL, на якій виконуються визначення інтерфейсів з подальшим перетворенням на тексти програм на вибраній мові програмування. У DCOM використовуються бінарні інтерфейси (табличні). При такому підході інтерфейси об'єктів визначаються незалежно від мови програмування.
Висновки
В цій лекції ми розглянули основні можливості технології CORBA– базового стандарту в розробці засобів проміжного рівня. Ця технологія існує як набір специфікацій, кожний розробник може виконати свою реалізацію.
В теорії, CORBA представляється як краща клиент/сервер middleware-система, але на практиці вона хороша лише настільки, наскільки хороші продукти, що її реалізовують. До основних комерційними ORB відносяться: Orbix від фірми IONA Technologies; DSOM від IBM; ObjectBroker від Digital; JOE від Sun; Visibroker від Visigenic і Netscape; ORB+ від HP.
Переваги і недоліки використання CORBA
Переваги
|
Недоліки
|
Контрольні запитання і завдання для самостійного виконання
1. Призначення і основні завдання моделі CORBA
2. Призначення і основні складові брокера об'єктних запитів
3. Призначення мови визначенняінтерфейсів
4. У чому полягає кросплатформність моделі CORBA
5. Характеристика об'єктної моделі CORBA. Взаємодія CORBA-об'єктів
6. Засоби вертикальної і горизонтальної взаємодії
7. Базовий об'єктний адаптер і його засоби
8. Протоколи взаємодії об'єктних брокерів
9. Основні служби моделі CORBA
10. Архітектура управління об'єктами в CORBA
(Для ознайомлення з повним текстом статті необхідно залогінитись)