Засновані на CORBA технології мають такі ділянки потенційного розвитку.

  • Під час проектування CORBA усуває відмінності операційних систем і мов.

  • Розвиток систем керування може суттєво підсилити використовування CORBA-служб і CORBA- засобів.

  • Поліпшується сумісність систем керування. Як стандартний компонент проміжного забезпе­чення (middleware), CORBA підтримує мови програмування незалежно від визначення інтерфейсу, стандартні відображення мов і підтримку багатьох постачальників. Публікація інтерфейсу для при­кладних функцій, підтримуваних системами керування, в ODP IDL повинна сприяти забезпеченню міжмережного обміну між такими системами керування.

  • Заснована на CORBA інфраструктура сприяє розвиткові систем керування зі стандартними компонентами, заснованими винятково на CORBA.

Передбачено (там, де це необхідно) використовувати знання і специфікації, сформовані в ме­жах традиційного керування OSI-системами. Крім того, використано узагальнену реалізацію, яка для більшості переваг, наданих розподіленим обчисленням об’єктів загалом і CORBA зокрема, буде розвивати і поліпшувати характеристики систем, розроблених у конкретному контексті.

Опис CORBA-підтримки ODMA з поглядом на предметну область й інформаційний погляд відпо­відають описові у розділі 6.

  1. Обчислювальний погляд

Функції, введені ODMA, повинні доповнити більш загальні CORBA-служби і CORBA-засоби. Повний набір специфікацій служб складає фундамент для побудови середовища (framework) роз­робляння розподілених систем керування телекомунікаціями.

  1. 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-керованого об'єкта.

  1. Обробляння сповіщень

Сповіщення 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-керованого об’єкта до об’єкта розпо­ділу події, або від об'єкта розподілу події до адресата).

Примітка. Модель доставляння з виштовхуванням робить підтвердження доставляння надлишковим з позицій приймача.

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

  1. Обробляння зв’язних відгуків

У CORBA зв'язкові відгуки реалізуються клієнтом вихідної операції (тобто обчислювальним об’єктом у керівній ролі), що забезпечує вхідні параметри операції з сигнатури, яка дає посилання на lrs-інтерфейс, який далі вживають для виклику зв'язного відгуку.

Примітка. Цей принцип іноді називається зворотним викликом (callback).

  1. Підтримування ділянки дії

Множинний доступ до об’єктів через ділянку дії може оброблятися або безпосередньо CORBA- керованим об’єктом (через операції одного зі своїх серверних інтерфейсів операцій керування), або механізмом ділянки дії (наявний в іншого об’єкта, поза CORBA-керованим об’єктом), який є узагаль­неним інтерфейсом керування, що підтримує параметри ділянки дії.

  1. Підтримування фільтрації

Обробляння фільтрації підтримується безпосередньо CORBA-керованим об’єктом (через пара­метри операцій одного зі своїх серверних інтерфейсів операції керування), або використовуючи спе­ціальні об’єкти фільтрів, розміщені між обчислювальним об’єктом у керівній ролі і CORBA-керова­ним об’єктом.8.2 Інжиніринговий погляд

  1. Підтримування прозорості доступу

У ODMA інтелектуальність застосувань керування розподіляється між керівною і керованою системами. Керівна система забезпечує функції керування за допомогою використання об’єктів у керівній ролі, що ініціюють операції, які зрештою впливають на об’єкти у керованій ролі і локалі­зовані в системах керування. Якщо керівна система спирається на відповідне використання stub- посередників і динамічний інтерфейс викликів (Dynamic Invocation Interface — Dll) у разі доступу до служб керованих систем, то немає потреби в нових версіях керівної системи у випадку модифі­кації мережі.

Щоб уникнути модифікацій керівної системи у разі введення нового інтерфейсу до керованої си­стеми, керівній системі слід використовувати CORBA-репозитарій інтерфейсу (CORBA Interface Repository — IR) для дослідження визначень інтерфейсу і CORBA DII для виклику нових або роз­ширених служб.

  1. Підтримування прозорості розміщення


Н

Рисунок 22 — CORBA інжиніринг, забезпечений ORB

Вузол Вузол

а рисунку 22 показано, як CORBA підтримує про­зорість розміщення, забезпечувану ORB (тут mg — кері­вний, md — керований):
  • stub у керівній ролі для клієнтського інтерфейсу операцій керування, серверного інтерфейсу зв’язного відгуку і серверного інтерфейсу сповіщень;

  • stub у керованій ролі для серверного інтерфейсу операцій керування, клієнтського інтерфейсу зв’язного відгуку і клієнтського інтерфейсу сповіщень;

  • брокер об'єктних запитів (Object Request Broker — ORB), що забезпечує прозорість.

Це означає, що CORBA-керовані об’єкти можуть розміщуватися в різних адресних просторах (або лише в одному).

  1. Підтримування CORBA-реалізації

Реалізацію керівної системи іноді можна розглядати як специфічний випадок реалізації більш загальної інформаційної системи.

Природним є припущення проектувальників об’єктно-орієнтованих систем керування про існу­вання сучасних середовищ розробляння застосувань (мов, кодів, баз даних, GUI тощо). CORBA є інфраструктурою, яка підтримує розробляння застосувань у таких середовищах.

CORBA-системам керування можуть знадобитися шлюзи (gateway) для взаємодії із система­ми, що використовують відмінні парадигми комунікації. Дискусія про підходи до взаємодії шлюзів, що забезпечують міжмережний обмін між різними інфраструктурами комунікацій, подана у додатку Н.

  1. 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-значенні.