Огляд технології CORBA

Зміст

Вступ 3
1. Брокер об'єктних Заявок 4
2. Мова визначення інтерфейсів 7
3. Мережева модель CORBA 8
4. Об'єктна модель CORBA 9
5. Клієнти і сервери CORBA 10
6. Стаб і скелетон 10
7. Основні об'єктні служби CORBA 11
8. Універсальні засоби CORBA 13
Висновок 15
Список використаних джерел 16

Введення

CORBA (Common Object Request Broker Architecture) - Загальна Архітектура
Брокера об'єктних запитів - це стандарт, набір специфікацій дляпроміжного програмного забезпечення (ППО, middleware) об'єктного типу.
Завдання ППО, як відомо, полягає у зв'язуванні програмних додатківдля обміну даними. Еволюція ППО - це шлях від програм передачі інформаціїміж конкретними додатками, через засоби імпорту-експорту даних іорганізацію мостів між деякими додатками, через SQL, RPC (Remote
Procedure Call), TP монітори (Transaction Proceesing) обробки транзакцій,
Groupware - управління різними неструктурованими даними (тексти,факси, листи електронної пошти, календарі тощо) і, нарешті, MOM -
Message-Oriented Middleware (асинхронний обмін повідомленнями між сервером іклієнтом), до створення розподілених комп'ютерних систем. Елементи цихсистем можуть взаємодіяти один з одним як на одній локальній машині,так і по мережі. CORBA дозволяє організувати єдину інформаційну середу,елементи якої можуть спілкуватися один з одним, незалежно від їхконкретної реалізації, "прописки" в розподіленої системи, платформи імови їх реалізації [1]. CORBA утворює нижній шар архітектурипроміжного шару, що забезпечує технологічну платформуінтероперабельності. Семантика об'єктів на цьому рівні не береться доувагу [8].

1 Брокер об'єктних Заявок

Брокер об'єктних Заявок (Object Request Broker - ORB) - цепроміжне ПЗ, що встановлює клієнт-серверні відносини міжоб'єктами в розподіленої комп'ютерної середовищі [1]. ORB забезпечуємеханізми, що дозволяють об'єктам посилати або приймати заявки, відповідати наних і отримувати результати, не піклуючись про становище інших об'єктів урозподіленої середовищі і способі їх реалізації. ORB відповідає за пошукреалізації об'єкта сервера для виконання заявки, підготовку реалізаціїцього об'єкта до прийому заявки і за передачу даних, які є результатомвиконання заявки [8]. Брокер являє собою механізм, що дозволяєоб'єктам видавати заявки і отримувати відповіді прозорим чином. Завдякицьому забезпечується інтероперабельність між програмами на різнихапаратних платформах у неоднорідних розподілених середовищах. Необхіднопідкреслити, що мова йде тут про технічну інтероперабельності в томусенсі, як це поняття інтерпретується в [3].

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

Інтероперабельность брокерів OMG трактується як здатність об'єкта -клієнта, керованого брокером-1, викликати певні IDL-специфікаціямиоперації об'єкта сервера, керованого брокером-2, за умови, що брокер-
1 і брокер-2 були розроблені незалежно один від одного. Інакше кажучи, таківиклики повинні бути незалежні від того, одним і тим же або різними
(можливо, різнотипними) брокерами підтримуються взаємодіючіоб'єкти.

CORBA визначає середовище для різних реалізацій ORB, що підтримуютьзагальні сервіси та інтерфейси (рис.1). Це забезпечує мобільність клієнтів іреалізацій об'єктів по відношенню до різних реалізацій ORB. ORBзабезпечує інтероперабельність компонентів глобального об'єктногопростору. Визначення інтерфейсів об'єктів можуть бути поміщені в
Сховище Інтерфейсів (Interface Repository) двома способами: статично
- В результаті специфікації на IDL, або динамічно. Сховищепредставляє компоненти інтерфейсу як об'єкти і забезпечує доступ до нихв період виконання.

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

Клієнт може безпосередньо взаємодіяти з ORB. У цьому випадку
ORB шукає відповідний код реалізації об'єкта, пересилає йому параметризаявки та передає управління. Реалізація об'єкта приймає параметри заявкичерез згенерований компілятором IDL скелетон (Skeleton) і при цьому можезвертатися до об'єктної Адаптеру (Object Adaptor) і ORB [8]. Основнафункція об'єктного адаптера, що використовується для реалізації CORBA-об'єкта, --забезпечення доступу до сервісів брокера об'єктних запитів. Об'єктнийадаптер надає всі низькорівневі кошти для зв'язку об'єкта з йогоклієнтами. До числа цих засобів входять:

1) генерація посилань на віддалені об'єкти,

2) виклик методів, визначених у IDL,

3) забезпечення безпеки взаємодії,

4) активація і деактивація об'єктів,

5) встановлення відповідності між посиланнями на віддалені об'єкти і реальними примірниками об'єктів,

6) реєстрація об'єктів.

Специфікація OMG CORBA визначає базовий об'єктний адаптер, якийповинен бути реалізований у всіх брокерів запитів. Basic Object Adapter
(BOA) - це набір інтерфейсів для створення посилань на віддалені об'єкти,реєстрації об'єктів, авторизації запитів і активізації додатків.
Базовий об'єктний адаптер є вирішенням першочергового завданнязабезпечення зв'язку між реалізацією об'єкта і брокером запитів. Дляорганізації взаємодії між ORB і, наприклад, системою управліннябазами даних повинен бути розроблений свій об'єктний адаптер [10].

Скелетон - серверна програма, яка пов'язує сервант з об'єктнимадаптером, дозволяючи об'єктному адаптера перенаправляти запити довідповідному сервант. При статичних методах виклику скелетонформується при компіляції IDL коду. При динамічних - невикористовується [12].

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

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

Для певного мовного відображення забезпечується програмнийінтерфейс до стаб для кожного типу інтерфейсу. Стаб здійснюють зверненнядо ORB, використовуючи приховані і, можливо, оптимізовані для певногоядра ORB інтерфейси. Для певного мовного відображення і, можливо, вЗалежно від використовуваного об'єктного Адаптера буде забезпечуватисядоступ до методів, які реалізують кожен об'єктний тип. Виклик цих методівздійснюється через скелетон. Наявність скелетона не має на увазііснування відповідного стаб клієнта. Можливо, і зворотне. Можнанаписати Об'єктний Адаптер, який не використовує скелетон для дзвінкаметодів реалізації об'єктів [10].

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

ORB, що включається в клієнтський і серверний додаток.

Якщо є відповідний механізм комунікацій, то можлива реалізація
ORB-а у вигляді набору підпрограм як з боку клієнта, так і з бокуреалізації об'єкта. Виклики методів можуть транслюватися в роботу ззасобами взаємодії процесів (Inter Process Communication - IPC).

ORB, виконаний у вигляді сервера.

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

ORB як частина системи.

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

ORB, заснований на бібліотеках.

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

2 Мова визначення інтерфейсів

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

Визначення інтерфейсу об'єкта засобами OMG IDL повністюхарактеризує всі операції, що можуть виконуватися даним об'єктом позаявками клієнтів. Це визначення служить джерелом інформації длярозробки програм-клієнтів, які звертаються до об'єктів із заявками навиконання операцій, передбачених визначеннями їх інтерфейсів.
Оскільки визначення використовується клієнтом інтерфейсу повинно бутидоступно його реалізації, необхідно здійснювати відображення специфікацій,заданих в мові OMG IDL, в мову реалізації клієнта.
Для опису синтаксису мови в специфікаціях стандарту CORBA використовуєтьсянотація, аналогічна EBNF (Extended Backus-Naur Format - Розширений формат
Бекуса-Наура).
:: = - Є за визначенням
| - Або
<> - Нетермінальний символ, що представляється укладеним в дужки поняттям
"текст" - літерал
* - Можливість повторення попередньої синтаксичної конструкції нульабо більше разів
+ - Можливість повторення попередньої синтаксичної конструкції одинабо більше разів
() - Укладені в дужки синтаксичні конструкції розглядаються якєдина конструкція
[] - Укладена в дужки синтаксична конструкція єнеобов'язковою.

При відображенні IDL в різні мови програмування CORBA вимагає,щоб конструкції IDL були адекватно відображені: всі базові іконструюються типи, посилання на об'єкти і константи, які визначаються в IDL,виклики операцій, виняткові ситуації, доступ до атрибутів, сигнатуриоперацій у вигляді, визначеному ORB (інтерфейс динамічного виклику).
Реалізація відображення дає можливість програмісту мати доступ до всіхфункцій ORB у вигляді, зручному для відповідної мови програмування.
Всі реалізації ORB повинні слідувати стандарту OMG відображення дляконкретної мови програмування.

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

До теперішнього часу OMG визначені відображення IDL у мови C, C + + і
Smalltalk. Завершується розробка стандарту відображення IDL в мову Ada. Цяробота не проста. Так, тільки обговорення і прийняття відображення IDL в С + +зайняло більше двох років напруженої роботи, яка підтвердила важливість технологіїприйняття стандартів, що використовується OMG [10].

3 Мережева модель CORBA

Інтероперабельность брокерів підтримується Універсальним
Межброкерним Протоколом (General Inter-ORB Protocol, скорочено GIOP). GIOPє універсальним, оскільки він не залежить від конкретної мережноїтранспортної середовища і може бути відображений в будь-який транспортний протокол,підтримує віртуальні з'єднання. Одне з таких відображень --відображення GIOP до протоколу TCP/IP - визначено CORBA 2.0 як
Межброкерного Протоколу Internet (Internet Inter-ORB Protocol, скорочено
IIOP). Призначення протоколу GIOP/IIOP полягає в тому, щоб підтриматимережі брокерів в рамках Internet і за її межами.

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

1) визначення Загального уявлення даних (Common Data

Representation - CDR), який є, по суті, комунікаційним синтаксисом, що відображає значення типів даних OMG IDL у формат передачі даних між брокерами і межброкернимі мостами

(агентами);

2) формати переданих між агентами повідомлень GIOP, які введені для підтримки об'єктних заявок, встановлення місця розташування об'єктів та реалізацій керування транспортними з'єднаннями;

3) визначення обмежень на допустимий мережевий транспорт GIOP.

Протокол IIOP, який можна вважати спеціалізацією GIOP, визначаєдодатково, як агенти відкривають з'єднання TCP/IP і використовують їх дляпередачі повідомлень GIOP. GIOP трактує транспортне сполучення якасиметрична. Визначаються дві різні ролі використання з'єднання:роль клієнта і роль сервера. Клієнт утворює з'єднання і посилаєоб'єктні заявки, сервер приймає заявки та надсилає відповіді. Сервер неможе посилати об'єктних заявок. З'єднання може використовуватися спільночисленними клієнтами в одному брокер для посилки незалежних заявокрізних об'єктів в певному брокер чи сервері. Допускаєтьсяасинхронна посилка заявок при їх довільному чергуванні в з'єднанні.

У переданих повідомленнях допускається довільний порядок байтів
(залежить від архітектури процесора), що встановлюється відправникомповідомлення. Одержувач повідомлення повинен змінити цей порядок потрібне длясебе чином. Встановлено вирівнювання значень базових типів IDL (char,octet, short, unsigned short, long, unsigned long, float, double, boolean,enum) по межі природних для них полів. Встановлено кодуванняконструюються типів IDL (struct, union, array, sequence, string), ненакладає додаткові вимог вирівнювання по відношенню до тих,які встановлені для базових типів [9].

Об'єктна модель CORBA

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

Об'єктна модель OMG визначається у вигляді об'єктної моделі - ядра
(Core Object Model - COM) і сукупності розширень. Об'єктна модель --ядро - специфікує деякий набір базових понять. Прикладами понять COMє об'єкти, операції, типи, ставлення тип/підтип, спадкування,інтерфейс типу. Кожне розширення вводить додатковий набір понять.
Розширюватися може або COM, або вже існуючі та узгодженірозширення. При цьому вводиться поняття профілю, як деякої комбінації
COM, і одного або декількох розширень, разом підтримують певнуцільову архітектуру [3].

Об'єктна модель CORBA визначає взаємодію між клієнтами ісерверами. Клієнти - це програми, які запитують сервіси,що надаються серверами. Об'єкти-сервери містять набір сервісів,розділяються між багатьма клієнтами. Операція вказує запитанийсервіс. Інтерфейси об'єктів описують безліч операцій, які можутьбути викликані клієнтами певного об'єкта. Реалізації об'єктів - цепрограми, які виконують сервіси, запитувані клієнтами [10].

Клієнти і сервери CORBA

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

4 Стаб і скелетон

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

5 Основні об'єктні служби CORBA

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

Однак очевидно, що в більшості ІС потрібен якийсь безлічсистемних об'єктних сервісів, які не залежать від предметної області ізабезпечують базову функціональність для управління розподіленимиоб'єктами. З метою полегшення створення розподілених додатків консорціум
OMG стандартизований найбільш часто вживані сервіси (специфікація
CORBAservices 1.0) [10].
Сервіс Жізненнго Циклу (Life Cycle Service) визначає операції створення,копіювання, переміщення й видалення компонентів на шині [7].
Сервіс іменування (Naming service) служить для керування і зберігання посиланьна CORBA-об'єкти. Його основне завдання полягає в тому, щоб універсальнимчином організувати підключення об'єктів один з одним. Служба іменявляє собою сховище об'єктних посилань. Звернення до цього сервісувиконується для отримання потрібної об'єктної посилання, ідентифікованої почитає (зрозумілому розробнику) імені об'єкта.
Сервіс Подій (Event service) забезпечує підтримку асинхронноговзаємодії додатків.
Сервіс довготривалого зберігання (Persistence service) надає набіруніверсальних інтерфейсів для збереження примірників об'єктів вдовготривалої пам'яті. Сервіс розроблений таким чином, що можлива йогореалізація на основі об'єктної бази даних.
Сервіс транзакцій (Transaction service) підтримує безліч моделейтранзакцій, включаючи вкладені транзакції. Сервіс транзакцій необхідний длякоректної роботи додатків в многопользовательском режимі.
Сервіс Відносин (Relationship service) реалізує логічні зв'язки між
CORBA-об'єктами. Сервіс визначає два додаткових типу об'єктів: зв'язокі роль. Роль являє собою CORBA-об'єкт, що відображає характер зв'язку, азв'язок характеризує залежності об'єктів прикладної області.
Сервіс Контролю Спільного Доступу (Concurrency control service) дозволяєклієнтам координувати свої дії при використанні поділюванихресурсів. Управління розділяються ресурсами здійснюється за допомогоюблокувань. Кожна блокування асоціюється з єдиним ресурсом ієдиним клієнтом. Сервіс визначає також кілька режимівблокувань, які відповідають різним способам доступу.
Сервіс Зовнішнього Вистави (Externalization service) формує копію
CORBA-об'єкта у вигляді деякого зовнішнього подання - файла, елементабази даних і т. д. [10].
Сервіс Запросов (Query Sevice) забезпечує підтримку запитів дляоб'єктів. Він являє собою надмножество SQL і заснований на розширенихспецифікаціях SQL3 і мовою об'єктних запитів (Object Query Language -
OQL).
Сервіс Ліцензування (Licensing Service) надає операції длявідслідковування використання компонентів, щоб забезпечити законнукомпенсацію їх використання. Даний сервіс підтримує певну модельвикористання компонента в будь-якій точці його життєвого циклу.
Сервіс властивостей (Properties Service) надає операції, якідозволяють вам асоціювати іменовані величини (або властивості) з будь-якимкомпонентом.
Сервіс Часу (Time Service) надає інтерфейс для синхронізаціїчасу в середовищі розподілених об'єктів. Крім того, передбачаєоперації для визначення та управління подіями, орієнтованими напевний час.
Сервіс Безпеки (Security Sercice) надає повну інфраструктурудля забезпечення безпеки розподілених об'єктів. Він підтримуєаутентифікацію, списки контролю доступу, конфіденційність, безвідмовністьі делегування прав доступу між об'єктами.
Сервіс Комерції (Trade Service) забезпечує «Жовті сторінки» дляоб'єктів; це дає можливість об'єктах сповіщати про свої сервіси івиставляти заявки про себе на «ринок праці».
Сервіс Контейнерів (Collection Service) надає інтерфейси CORBA длястворення та підтримки загальнодоступних контейнерів [7].

Відомо, що служби OMG не є незалежними один від одного.
Частина з них може бути створена на базі інших служб. Згіднорекомендаціям OMG, існує представлений на рис. 3 граф залежностейоднієї служби від іншої [11].

6 Універсальні засоби CORBA

Універсальні засоби надають підтримку інтерфейсів високогорівня і діляться на два типи: горизонтальні і вертикальні.

Горизонтальні універсальні засоби визначають інтерфейси, незалежать від предметної області. В даний час існуєпопередня специфікація горизонтальних універсальних засобів,яка складається з таких розділів:
1) Коштів для користувача інтерфейсу. Вони покривають аспекти, що стосуються представлення інформації, і включають інструменти для розробки інтерфейсу, засоби для автоматизації цієї роботи, специфікації на робочий стіл (desktop) користувача і т. д.
2) Коштів управління інформацією. Вони надають операції, за допомогою яких можна моделювати, описувати, зберігати, вибирати, переміщати інформацію і обмінюватися нею. Передбачається, що даний набір повинен складатися з наступних специфікацій: а) інформаційне моделювання (визначає правила, за якими здійснюється структуризація і доступ до інформації), б) зберігання та вибірка інформації (визначає використання баз даних і систем каталогів), в) інформаційний обмін, г) стандарти перекодування і уявлення, що підтримують обмін інформацією через колективні ресурси, мережеві протоколи чи програмні інтерфейси.
3) Коштів управління системою. Вони задають безліч утиліт, що реалізують функції системного адміністрування, тобто визначають інтерфейси основних операцій, що відповідають за управління, моніторинг, безпека, конфігурація і т. д.
4) Коштів управління завданнями. Передбачається, що даний набір буде представлений чотирма специфікаціями: служби управління потоками робіт

(workflow facility), служби програмних агентів (agent facility), служби управління правилами (rule management facility), служби автоматизації < p> (automation facility).

Вертикальні кошти призначені для підтримки конкретних областейринку: фінансової діяльності, промислового виробництва, медицини тощод. Розробляються специфікації наступних засобів:
1) Коштів обробки зображень. Специфікує доступ і обмін графічними даними. Роль цієї служби полягає у підтримці програм з кінцевим користувачем з перевірки, обробки, візуалізації і збереження графічних даних.
2) Коштів підтримки інформаційної супермагістралі (superhighway facility). Специфікується безліч мереж, протоколів і правил їх використання, а також безліч репозітарієв інформації і набір засобів, що забезпечують користувачам і програмам доступ до цієї інформації.
3) Коштів інтегрованого автоматизованого виробництва. Забезпечують інтеграцію виробничих функцій підприємства за допомогою комп'ютерів. У число об'єднуються функцій можуть входити також управління процесами розробки, контроль якості, фінансові і маркетингові операції.
4) Коштів емуляції розподілених процесів. Служби цієї специфікації повинні забезпечити базис, на основі якого можливе швидке побудову та функціонування емуліруемой моделі.
5) Коштів інформатизації в газовій та нафтовій промисловості. Ця предметна область характеризується великою кількістю даних і високою складністю алгоритмів.
6) Коштів фінансових комунікацій (accounting facility). Чи включають всі форми комерційних транзакцій: обмін валюти, управління платежами, продажами і т.п.
7) Коштів підтримки розробки додатків. Обслуговують вибір, розробку, побудова та еволюцію додатків, які складають корпоративну інформаційну систему. Дані специфікації включають засоби аналізу, проектування, реалізації, тестування та підтримки системи [10].

7 Висновок

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

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

1) забезпечення функціонування систем в умовах інформаційної та реалізаційної неоднорідності, розподіленості і автономності інформаційних ресурсів;

2) інтеграція систем;

3 ) реінженерії систем;

4) міграція успадкованих систем;

5) повторне використання неоднорідних інформаційних ресурсів;

6) продовження життєвого циклу систем.

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

Аншіна М. Симфонія CORBA. «Відкриті системи» № 3 1998 г.

Ахтирченко К. В., Леонтьев В. В. Розподілені об'єктні технології вінформаційних системах. «СУБД» № 5-6 1997 г.

Черево Д.О, Задорожний В.І., Калініченко Л.А, Курош М.Ю, Шумілов С.С
Інтероперабельность інформаційні системи: архітектури і технології. «СУБД»
№ 4 1995 г.

Єлманова Н. Розподілені обчислення і технології Inprise. «Ком'ютера-
Прес »№ 1-5 1999 г.

Єлманова Н. Оптимізація додатків С + + Builder в архітектурі клієнт/сервер.
«Комп'ютер-Прес» № 4 1998 г.

Коржов В. Багаторівневі системи клієнт-сервер. «Мережі» № 6 1997 г.

Орфа Р., Харкін Д., Едвардс Д. Основи CORBA: Пер. з англ. - М.: МАЛІП,
Гаряча Лінія - Телеком, 1999 р.

Калиниченко Л.А., Когаловскій М.Р. Стандарти OMG: Мова визначенняінтерфейсів IDL в архітектурі CORBA. «СУБД» № 2 1996 р.

Калиниченко Л.А., Когаловскій М.Р. Інтероперабельность брокерів у стандарті
CORBA 2.0. «СУБД» № 3 1996 г.

Пуха Ю. Об'єктні технології побудови розподілених інформаційнихсистем. «СУБД» № 3 1997 г.

Ахтирченко К. В. Застосування технології CORBA при побудові розподіленихінформаційних систем. «СУБД» № 1, № 2 1998р.

Аншіна М. Захоплююча подорож з CORBA 3: по широких просторахрозподілених додатків. «СУБД» № 5, № 6 1999р.

-----------------------

Рис. 3

Граф залежностей служб, специфіковані OMG

Рис. 2

Структура інтерфейсів брокера об'єктних Заявок

Рис. 1

Відносини між компонентами в трирівневої розподіленої системи