Засновані на CORBA технології мають такі ділянки потенційного розвитку.
Під час проектування CORBA усуває відмінності операційних систем і мов.
Розвиток систем керування може суттєво підсилити використовування CORBA-служб і CORBA- засобів.
Поліпшується сумісність систем керування. Як стандартний компонент проміжного забезпечення (middleware), CORBA підтримує мови програмування незалежно від визначення інтерфейсу, стандартні відображення мов і підтримку багатьох постачальників. Публікація інтерфейсу для прикладних функцій, підтримуваних системами керування, в ODP IDL повинна сприяти забезпеченню міжмережного обміну між такими системами керування.
Заснована на CORBA інфраструктура сприяє розвиткові систем керування зі стандартними компонентами, заснованими винятково на CORBA.
Передбачено (там, де це необхідно) використовувати знання і специфікації, сформовані в межах традиційного керування OSI-системами. Крім того, використано узагальнену реалізацію, яка для більшості переваг, наданих розподіленим обчисленням об’єктів загалом і CORBA зокрема, буде розвивати і поліпшувати характеристики систем, розроблених у конкретному контексті.
Опис CORBA-підтримки ODMA з поглядом на предметну область й інформаційний погляд відповідають описові у розділі 6.
Обчислювальний погляд
Функції, введені ODMA, повинні доповнити більш загальні CORBA-служби і CORBA-засоби. Повний набір специфікацій служб складає фундамент для побудови середовища (framework) розробляння розподілених систем керування телекомунікаціями.
CORBA-керовані об’єкти
Тут термін «CORBA-керований об’єкт» позначає обчислювальний об’єкт у керованій ролі, реалізований CORBA-середовищем.
Також необхідно визначити тип погодженого базового серверного інтерфейсу операцій керування (commonly agreed base management-operation server interface type — bmos), який буде підтримувати CORBA-керовані об'єкти. Глобальна підтримка bmos типу інтерфейсу CORBA-керованими об’єктами забезпечує спільність для різних груп служб, визначених для CORBA-відкритого розподіленого керування.
Примітка. Термін «базовий інтерфейс» використовують для позначення того, що інші типи інтерфейсу можуть бути його похідним інтерфейсом, отриманим як результат успадкування або від інших форм типізації.
Кожен CORBA-керований об’єкт має хоча б один інтерфейс, визначений у ODP IDL, для підтримуваних атрибутів і операцій. У цьому контексті тип інтерфейсу bmos повинен містити всі загальні базові характеристики, асоційовані з довільним CORBA-керованим об’єктом. Він уміє включати інформацію про тип інтерфейсу, підтримуваному CORBA-керованим об’єктом, і ідентифікатор екземпляра CORBA-керованого об’єкта. Такий тип інтерфейсу bmos потім повинен адаптуватися до конкретних типів CORBA-керованих об’єктів системи.
ODP IDL пропонує засоби визначення інтерфейсу. Для клієнта і сервера використовують однакові визначення інтерфейсу.Важливо спланувати розподілені системи керування таким чином, щоб нові типи CORBA-керо- ваних об’єктів (з відповідними новими типами інтерфейсу) могли інсталюватися у систему під час виконання, без перекомпонування системного програмного забезпечування для роботи з новими визначеннями. Динамічний інтерфейс каркасів (The Dynamic Skeleton Interface), що забезпечує подібну гнучкість систем, можна використовувати як такий механізм, але допустимі й інші механізми.
Використовуючи інтерфейс типу bmos CORBA-керованого об’єкта система керування може викликати лише обмежене число операцій без додаткових знань про специфічні характеристики спеціального типу CORBA-керованого об'єкта.
Обробляння сповіщень
Сповіщення ODMA обробляють як операційні виклики з сутностей керування у механізм розподілу подій [який засновано на розширенні CORBA-служби подій (CORBA-служби)]. Кожне конкретне ODMA-сповіщення приводить до специфікації множини операцій у серверному інтерфейсі сповіщень. Цей серверний інтерфейс сповіщень може підтримуватися об’єктами прив’язки диспетчера сповіщень (наприклад, CORBA-канал події) чи об’єктами адресатів.
Обробляння ODMA-сповіщень у CORBA-середовищі (як визначено у специфікації CORBA-служби) можна виконувати з використанням як типізованих або нетипізованих у CORBA подій, так і моделей доставляння звітів подій з проштовхуванням або виштовхуванням.
У CORBA-службі подій за моделлю:
з проштовхуванням (push model) відправник звіту події викликає операцію об’єкта-приймача (з контекстом звіту події, що міститься у виклику);
за моделлю з виштовхуванням (pull model) приймач звіту події викликає операцію об’єкта- відправника (з контекстом звіту події в кінцевому сповіщенні).
Визначення ODMA-повідомлень і всі рисунки цього стандарту допускають використовування під час доставляння сповіщень моделі з проштовхуванням. Якщо використовують модель з виштовхуванням, ролі сервера і клієнта сповіщення міняються місцями; цей принцип не знайшов явного відображення у цьому стандарті.
Необхідний CORBA-механізм розподілу подій (наприклад, ITU-T Rec. Х.770 I ISO/IEC 15427-1), що забезпечить доставляння сповіщень від одиничного CORBA-керованого об’єкта до множинних обчислювальних об’єктів-адресатів, що підписалися на конкретний тип сповіщень.
Визначання ODMA-сповіщень, що допускає розподіл на множинах адресатах, не передбачає іншої інформації, крім підтвердження доставляння, що повертається у відгуку до операції доставляння сповіщення, у випадку моделі з проштовхуванням (або від CORBA-керованого об’єкта до об’єкта розподілу події, або від об'єкта розподілу події до адресата).
Примітка. Модель доставляння з виштовхуванням робить підтвердження доставляння надлишковим з позицій приймача.
Необхідним є механізм розподілу подій, який можна сконфігурувати для різних рівнів якісних характеристик послуг, зокрема можливість обчислювального об'єкта щодо розподіляння подій відкладати у чергу сповіщення для наступного доставляння, коли адресат стане доступний.
Обробляння зв’язних відгуків
У CORBA зв'язкові відгуки реалізуються клієнтом вихідної операції (тобто обчислювальним об’єктом у керівній ролі), що забезпечує вхідні параметри операції з сигнатури, яка дає посилання на lrs-інтерфейс, який далі вживають для виклику зв'язного відгуку.
Примітка. Цей принцип іноді називається зворотним викликом (callback).
Підтримування ділянки дії
Множинний доступ до об’єктів через ділянку дії може оброблятися або безпосередньо CORBA- керованим об’єктом (через операції одного зі своїх серверних інтерфейсів операцій керування), або механізмом ділянки дії (наявний в іншого об’єкта, поза CORBA-керованим об’єктом), який є узагальненим інтерфейсом керування, що підтримує параметри ділянки дії.
Підтримування фільтрації
Обробляння фільтрації підтримується безпосередньо CORBA-керованим об’єктом (через параметри операцій одного зі своїх серверних інтерфейсів операції керування), або використовуючи спеціальні об’єкти фільтрів, розміщені між обчислювальним об’єктом у керівній ролі і CORBA-керованим об’єктом.8.2 Інжиніринговий погляд
Підтримування прозорості доступу
У ODMA інтелектуальність застосувань керування розподіляється між керівною і керованою системами. Керівна система забезпечує функції керування за допомогою використання об’єктів у керівній ролі, що ініціюють операції, які зрештою впливають на об’єкти у керованій ролі і локалізовані в системах керування. Якщо керівна система спирається на відповідне використання stub- посередників і динамічний інтерфейс викликів (Dynamic Invocation Interface — Dll) у разі доступу до служб керованих систем, то немає потреби в нових версіях керівної системи у випадку модифікації мережі.
Щоб уникнути модифікацій керівної системи у разі введення нового інтерфейсу до керованої системи, керівній системі слід використовувати CORBA-репозитарій інтерфейсу (CORBA Interface Repository — IR) для дослідження визначень інтерфейсу і CORBA DII для виклику нових або розширених служб.
Підтримування прозорості розміщення
Н
Рисунок 22 — CORBA інжиніринг, забезпечений ORB
Вузол Вузол
а рисунку 22 показано, як CORBA підтримує прозорість розміщення, забезпечувану ORB (тут mg — керівний, md — керований):stub у керівній ролі для клієнтського інтерфейсу операцій керування, серверного інтерфейсу зв’язного відгуку і серверного інтерфейсу сповіщень;
stub у керованій ролі для серверного інтерфейсу операцій керування, клієнтського інтерфейсу зв’язного відгуку і клієнтського інтерфейсу сповіщень;
брокер об'єктних запитів (Object Request Broker — ORB), що забезпечує прозорість.
Це означає, що CORBA-керовані об’єкти можуть розміщуватися в різних адресних просторах (або лише в одному).
Підтримування CORBA-реалізації
Реалізацію керівної системи іноді можна розглядати як специфічний випадок реалізації більш загальної інформаційної системи.
Природним є припущення проектувальників об’єктно-орієнтованих систем керування про існування сучасних середовищ розробляння застосувань (мов, кодів, баз даних, GUI тощо). CORBA є інфраструктурою, яка підтримує розробляння застосувань у таких середовищах.
CORBA-системам керування можуть знадобитися шлюзи (gateway) для взаємодії із системами, що використовують відмінні парадигми комунікації. Дискусія про підходи до взаємодії шлюзів, що забезпечують міжмережний обмін між різними інфраструктурами комунікацій, подана у додатку Н.
CORBA-керовані об’єкти з гетерогенними агентами
Розглянемо, яким чином CORBA-керовані системи забезпечують різний інтерфейс комунікації до систем керування.
Стандарти керування OSI-системами задають інтерфейс між керівною і керованою системами, використовуючи в керованій системі процес Агент, що діє в інтересах керованих об’єктів. На рисунку 23 показаний СМІ-доступ до CORBA-керованих об’єктів і об’єктів підтримки з використанням OSI-агента.
На рисунку 23 показана відкрита CORBA-керована система, яка підтримує множинні протоколи керування. Керовані об’єкти, визначені з використанням GDMO і доступні СМІР, можна реалізувати як CORBA-об’єкти. У цьому випадку до таких реалізацій CORBA-керованих об’єктів можливий доступ з використанням CORBA-протоколів взаємодії. Механізми оригінальної інфраструктури можуть аналогічно забезпечити множинну взаємодію з CORBA-об’єктами.
Рисунок 23 — Відкрита CORBA-керована система
|
ДОДАТОК А (довідковий) |
ТЕРМІНОЛОГІЯ OSI-КЕРУВАННЯ
Подана нижче таблиця використовує термінологію ODMA для опису принципів OSI-керування.
Термін OSI-керування системами |
Термінологія ODMA |
|
Керований об’єкт — Managed object |
Комбінація серверного інтерфейсу операцій і клієнтського інтерфейсу сповіщень обчислювального об’єкта керування. |
|
Клас керованого об’єкта — Managed object class |
Опис серверного інтерфейсу операцій керування і клієнтського інтерфейсу сповіщень, що містить сигнатуру і поведінку. |
|
Агент — Agent |
Сукупність інжинірингових об’єктів підтримування, що забезпечують комунікацію з об’єктами в керованій ролі. |
|
Менеджер — Manager |
Сукупність інжинірингових об’єктів підтримування, що забезпечують зв’язок з об’єктами в керівній ролі. |
|
Керована система — Managed system |
Вузол, що містить інжинірингові об'єкти в керованій ролі. |
|
Керівна система — Managing system |
Вузол, що містить інжинірингові об'єкти у керівній ролі. |
|
Сповіщення — Notification |
Взаємодія, коли контракт між об’єктом-ініціатором (клієнтом) і об’єктом-приймачем (сервером) обмежується можливістю прийому сервером інформації, відправленої клієнтом. |
|
Операція керування системами — Systems management operation |
Операція, виконувана об’єктом у керівній ролі, над об’єктами у керованій ролі. |
|
Атрибут — Attribute |
Частина сигнатури інтерфейсу операцій керування (скорочена нотація для всіх операцій доступу до значень атрибутів). |
|
Функція керування системами — Systems management function |
Один чи кілька інжинірингових об’єктів підтримування і множина типів обчислювального інтерфейсу керування, які задовольняють вимоги, що логічно відносяться до користувачів |
|
Термін OSI-керування системами |
Термінологія ODMA. |
|
Сутність СМІР протоколу — СМІР protocol entity Дерево імен — Naming tree Ділянка дії — Scoping Фільтрація — Filtering |
Частина інжинірингового об’єкта протоколу. Дерево ідентифікаторів інтерфейсу операцій, використовуваних для цілей ділянки дії Ділянка дії є функцією інжинірингового об’єкта, що дає змогу за допомогою одиничного виклику об’єкта з ділянки дії ідентифікувати серверний інтерфейс операцій керування, які поширюють виклик. Фільтрація є функцією інжинірингового об’єкта, що застосовує до серверного інтерфейсу операцій тестування на допустимість виконання виклику операції над даним інтерфейсом. |
|
Приміткаї. У правому стовпчикові термін «операція» використовується з ODP-значенням, що не слід плутати з поняттям операція керування системами. Примітка 2. Якщо термін «об'єкт» явно не уточнений, то його застосовують як до обчислювального, так і до інжинірингового об'єктів і використовують у ODP-значенні. |