На рисунку 9 показано приклад чотирьох обчислювальних об’єктів керування, задіяних у сис­темі керування. Об’єкт Ланцюг активізований у трьох відношеннях. У відношенні з об’єктом у керів­ній ропі об’єкт Ланцюг виступає у керованій ропі. У відношенні з двома об'єктами Гілка об’єкт Лан­цюг виконує керівну роль. Обчислювальну поведінку об’єкта керування Ланцюг можна визначити тим, як операції, прийняті керованим інтерфейсом, впливатимуть на операції, що передаються керівним інтерфейсом.

Рисунок 9 —Приклад обчислювального погляду для ODMA

Тут для опису інтерфейсу і поведінки обчислювальних об’єктів керування Ланцюг і Гілка мож­на використовувати визначання класів GRM-відношень (GRM Relationship Class — RC). Інтерфейс обчислювального об’єкта керування відповідає ролі класу відношень. Так, клас відношень Ланцюг виконує дві ролі, наприклад, сервер операції Ланцюг і клієнт операції Гілка. Клас керованого відно­шення Гілка виконує одну роль, наприклад, сервер операції Гілка. Поведінка класу відношень опи­сує взаємодію між інтерфейсами (ролями) обчислювальних об’єктів керування (класу відношень), що показано на рисунку 10, причому поведінка RC Ланцюг описує взаємодію між двома інтерфей­сами (ролями).


Роль клієнта


Р

Роль клієнта

операції

Ланцюг

операції

Гілка

оль сервера

операції f rc;

1 Ланцюг

Гілка

Рисунок 10 — Опис класу відносин обчислювальних об’єктів керування

Отже, інтерфейс обчислювальних об’єктів керування відповідає GRM-ролям. Оскільки ролі треба визначати термінами сумісних класів керованих об'єктів, то інтерфейс обчислювальних об’єктів керування описується термінами класів керованих об’єктів. Визначення керованих класу об’єктів (Managed Object Class — МОС), описує характеристики серверного інтерфейсу операцій керування і клієнтського інтерфейсу сповіщень. Крім того, клас керованих об'єктів можна також використову­вати для опису клієнтського інтерфейсу операцій керування і серверного інтерфейсу сповіщень для екземпляра класу іншого об’єкта. У цьому методі класи керованих об’єктів використовують для опису керівної сторони інтерфейсу за допомогою дзеркального відображення серверного інтерфейсу опе­рацій керування і клієнтського інтерфейсу сповіщень. Останній принцип є суттєвим для методів, що використовують GRM разом з GDMO.

Поведінка класу керованих об’єктів усе ще описує тільки поведінку керованої сторони. Нехай є клас керованого об’єкта Інтерфейс Гілки, який використовують для характеризацїї обох інтерфейсів — сервера і клієнта операції Гілка. Тоді поведінка Інтерфейсу Гілки застосовуватиметься лише до ролі сервера операції Гілка. Асоційована поведінка ролі клієнта операції Гілка описується поведін­кою класу відношень Ланцюг, що показано на рисунку 11.

RC ) Ланцюг)


Роль клієнта
операції


Роль сервера
операції'


Гілка


Поведінка RC
Ланцюг описує
використовування


Характеризує
інтерфейс
операції



МОС
інтерфейсу
Гілка


Поведінка МОС
інтерфейсу Гілка
і RC Гілка описує
підтримку МОС


Гілка

RC

Гілка


Рисунок 11 —Характеризація класом керованого об'єкта інтерфейсу операцій

Зазначимо, що поведінка МОС Інтерфейсу Гілка, аналогічна поведінці RC Гілка, може описати виконання операцій одержання атрибутів керованого об’єкта Інтерфейс Гілка. Однак поведінка RC Ланцюг може специфікувати лише виклик операції одержання атрибута. Причина в тому, що від подання обчислювального об’єкта керування Ланцюг операція реально виконується на віддаленій стороні інтерфейсу обчислювального об’єкта керування Гілка.

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

Існує два способи вирішування цієї проблеми: або розширення GDMO з CMIS параметрами (на­приклад, для ділянки дії і фільтрації), або поповнення сигнатури інтерфейсу операцій обчислюваль­ного інтерфейсу керування, заснованого на GDMO-специфікації (частини) стандартизованою сигна­турою CMIS-операцій.

Примітка 1. Обидві можливості вивчено далі. Рішення особливо важливе для міжмережного обміну з наявними системами OSI-керування.

Отже, GDMO, GRM і CMISE можна використовувати разом для формування повної обчислю­вальної реалізації. Така реалізація буде оптимізована для роботи з СМІР, що підтримує сферу ко­мунікації.

Примітка 2. Щоб розробити стандартизовану обчислювальну модель, засновану на CMISE, важливо використо­вувати GDMO і GRM для специфікації обчислювального інтерфейсу. Не йдеться про використання СМІР як протоколу щодо інжинірингового погляду.

Примітка 3. GDMO, GRM і CMISE-специфікаціі можуть бути успадковані з більш абстрактної обчислювальної нотації, як показано в 6.2 З

  1. Зв’язні відгуки

В OSI-керуванні зв’язні відгуки використовують СМІР.

  1. Рівні обчислювальної абстракції

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

  • ділянки дії і фільтрації;

  • просування подій.

Ці параметри можуть візуалізуватися щодо обчислювального погляду, якщо:

  • існує необхідність підтримування цих параметрів певним узагальненим способом. Наприк­лад, на рисунку 12 є специфічний об’єкт NW, що розподіляє операцію встановлювання часу на множині адресатів — керованих об’єктів Е1, Е2 і ЕЗ. У цьому випадку немає потреби у обчислю­вальній візуалізації ділянки дії і фільтрації;

  • система може надавати необхідні механізми для підтримування цих параметрів, наприклад, підтримування узагальненої фільтрації й ділянки дії. На рисунку 13 подано обчислювальний аспект ділянки дії і фільтрації за підтримки узагальненого перегляду.

інжиніринговий погляд




Рисунок 12 — Ділянка дії і фільтрація як інжинірингова оптимізація (без обчислювальної візуалізації)

На рисунках 12 і 13 вжито наступні познаки: F — фільтр; filter stub — заглушка фільтра; binder — редактор зв’язків; ро — об'єкт протоколу; scope — контекст.

У верхній частині рисунка 12 показана обчислювальна реалізація, яка задовольняє специфічну предметну область встановлювання часу в мережі. У цій обчислювальній реалізації керівний об’єкт в лівій частині рисунка 12 також передає інтерфейс іншому керівному об’єкту (не показаний на ри­сунку). До того ж у цій реалізації не відображені параметри ділянки дії і фільтрації, оскільки об'єкти El, Е2, ЕЗ приховані об’єктом NW з обчислювального погляду.

Діаграма обчислювального погляду, розташована у верхній частині рисунка 12, показує мережний об’єкт NW (Network Object), що розподіляє операцію встановлювання часу на множину об’єктів ЕІ, Е2 і ЕЗ. Цей об'єкт NW є абстрактною нотацією «параметрів ділянки дії і фільтрації». Зазначимо, що ділянка дії і фільтрація — дві різні функції, змодельовані двома інжиніринговими об’єктами: контексту scope (для керівного об’єкта) і фільтра (для керованого об’єкта).

Примітка. Для об’єднання фільтрації і керованих об’єктів можна використовувати композицію.

ІНЖИНІРИНГОВИЙ ПОГЛЯД




Рисунок 13 — Візуалізована ділянка дії і фільтрація



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

Оскільки не існує стандартного CMIS-API, то для ділянки дії і фільтрації можна визначити множину сигнатур.

Обчислювальна реалізація, показана на рисунку 12, є прикладом того, як можна специфікува­ти стандартне рішення ODMA-компонента для однієї предметної області, тоді як на рисунку 13 на­

ведено приклад того, як можна специфікувати стандартне рішення ODMA-компонента для іншої пред­метної області. Обидві обчислювальні реалізації мають різних кандидатів на розподіляння, тому від них не можна очікувати інтрооперабельності.

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


Т

Дискримінатор просування подій

сповіщення

Рисунок 14 — Обчислювальна візуалізація просування подій

акого роду рисунки викликають припущення, покладені в основу реалізації. У цьому стандарті використано тільки просту сигнатуру, описувану класом керованих об’єктів. Крім того, ODMA створює таку саму абстракцію з керівної сторони. Потрібно абстра­гувати від деталей реалізації обчислювального об’єкта керуван­ня, зв’язаної за допомогою композиції з кількома механізмами підтримки.

Для стандартизації сигнатур інтерфейсу необхідно розроби­ти додаткові стандарти в рамках ODMA. Наприклад, сигнатури функцій просування подій необхідно визначити для ділянки дії, фільтрації тощо.

7.2 Інжиніринговий погляд

У цьому підрозділі обговорюються, як різні форми прозорості розподіляння підтримуються ме­ханізмами OSI-керування.

Спочатку показано, яким чином сучасна архітектура керування системами забезпечує потреби інжинірингу. На рисунку 15 наведено приклад інжинірингу MIS-користувача в ролях менеджера й агента. У цьому випадку два інтерфейси об’єкта інжинірингу з агентної сторони відповідають класу керо­ваного об’єкта. На рисунку 15 показано, що обидва — клієнтський і серверний інтерфейси керування — прив’язані в єдиній асоціації керування до об’єкта протоколу.

Та частина керування OSI-системами, яку необхідно розглядати з позицій відкритого розподі­леного керування, є роллю MIS-користувача. Агент завжди ідентифікується у відкритій системі. Іден­тифікацію виконують за допомогою АЕ-заголовка. На рисунку 15 показано, що обидва інтерфейси зв’язуються в єдину асоціацію керування. Для цілей відкритого розподіленого керування агент по­винен бути розділений на (керовані) складові. У випадку відкритого розподіленого керування немає єдиного об’єкта агент. Як показано на рисунку 15, за функціональні складові агента можна розгля­дати об’єкти протоколу, stub-посередника і редактора прив’язки. На рисунку 15 прийняті наступні познаки: Ьо — редактор зв’язків, ро — об’єкт протоколу, ео — інжиніринговий об’єкт, eso — інжині­ринговий об’єкт підтримки, mg — керівний, md — керований, МОС — клас керованого об’єкта.

Інжинірингові об’єкти можна визначати, виходячи з багатьох причин, наприклад:

  • контроль за сесією керування (ініціалізацією і завершенням);

  • створення і знищення керованих об’єктів;

  • обробляння операцій, що вимагають контролювання доступу, синхронізації, ділянки дії і фільтрації;

  • координація між об’єктами керування;

  • поширення повідомлень.

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

Об’єкт протоколу задає стек протоколів, наприклад, 7-рівневий стек OSI-протоколів, що надає обслуговування прикладного рівня.

З редакторами зв'язків асоціюється більшість проблем, пов’язаних з розподілянням. Вони відпо­відають за наскрізне підтримування цілісності каналу і мають справу зі збоями об’єктів. Тому ре­дактори зв’язків зобов’язані підтримувати зміни конфігурації і комунікацій. Редактор зв'язків пови-



нен встановити прив’язку, якщо канал створений, і простежити кінцевий пункт під час руху об’єкта, заміни об’єкта чи збою. Об’єкт редактора зв’язків задіяний у процесі переміщування об’єкта і забез­печенні більшості з видів прозорості розподіляння, описаних раніше.


Рисунок 15 — Модель керування OSI-системами (1991) з інжинірингового погляду


Рисунок 16 — Приклад ODMA базових інжинірингових об'єктів


Керований об’єкт, що має як клієнтський інтерфейс спові­щень, так і серверний інтерфейс операцій керування, повинен у деяких випадках мати можливість відобразити усі взаємодії в єдиній СМІР-асоціації. Таким чином, редактор зв’язків повинен мати змогу відобразити множинні інжинірингові інтерфейси в єдину асоціацію об’єкта протоколу.

Об’єкт stub забезпечує функції адаптації для підтримування взаємодії між інтерфейсами на різних вузлах. Така адаптація може означати трансляцію операцій у кодування, зрозумілу інжинірин­говим об’єктам (так зване упорядкування/розупорядкування — marshaling/ unmarshalling).

На рисунку 16 наведено складені інжинірингові об’єкти, вико­ристані далі в рисунках. Інжиніринговий об’єкт керування є спро­щеним варіантом взаємодії між базовим інжиніринговим об’єктом і stub'oM та допустимим варіантом інженерії у випадку, якщо не потрібно прозорості доступу з інжинірингового погляду на обчис­лювальний об’єкт керування. Об'єкт асоціації керування поєднує функціональність об’єктів протоколу і редактора зв’язків у єдиний інжиніринговий об’єкт, що відноситься до наявної асоціації керу­вання. Це допустимий варіант інжинірингу, якщо немає потреби використовувати множинні протоколи в інжиніринговому погляді на обчислювальний об'єкт керування. Нарешті, інжинірингові об’єкти підтримки надають такі додаткові функції системного керування, як, наприклад, сервер повідомлення