Обзор технології 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 в мови З, З++ і 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), служби автоматизации

(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

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

ПоказатьСвернуть
Заполнить форму текущей работой