---

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

Примітка. Операція зв'язного відгуку — спеціальна операція OSI-керування, що не має відображення в ODP-RM.

Для забезпечування такої можливості ODMA необхідно ввести два нових інтерфейси. У таб­лиці 5 описано асоціації інтерфейсу зв’язного відгуку з ODMA-ролями. За ODP-RM-принципами ці операції зв’язного відгуку можна промоделювати операціями, до яких потрібно виконати прив’язку. Інтерфейс зв’язного відгуку — це інтерфейс, у якому всі взаємодії є операціями, що відносяться до клієнтського інтерфейсу операцій.

Таблиця 5 — Типи обчислювального інтерфейсу, асоційовані з ролями

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

Зв’язний відгук специфікується у сигнатурі операцій виклику з ідентифікатором множинних операцій.

Примітка. Інтерфейс операції може підтримувати операцію для зупинки породження відгуку.

Для всіх операцій із сигнатури інтерфейсу зв’язного відгуку необхідний додатковий параметр для індикації зв'язку з необхідною операцією. На рисунку 3 показано, як працювати з декількома зв’язними відгуками, які використовують ODP-принципи.

Рисунок 3 — Приклад множинних зв'язних відгуків з єдиного об’єкта

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

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

Ь) Прив’язка до двох обчислювальних об'єктів у керованій ролі

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

d) Приклад об’єкта прив’язки диспетчера сповіщень

с) Прив’язка до двох обчислювальних об’єктів у керованій ролі

На рисунку 4 використано познаки: сі — керівний інтерфейс; Ьо — об'єкт прив’язки; eg — ке­рівний обчислювальний об’єкт; cd — керований обчислювальний об’єкт. Приклади таких ситуацій керування доступом одного чи декількох об’єктів керування:

• у керівній ролі до єдиного керівного об’єкта у керованій ролі (рисунок 4, Ь);

• у керованій ролі до єдиного об’єкта керування, у керівній ролі (рисунок 4, с).

Диспетчер сповіщень на рисунку 4, d є прикладом специфічного об’єкта прив’язки. Цей об’єкт прив’язки може керувати доступом одного чи декількох об’єктів керування в керівній ролі до одного чи кількох об’єктів керування у керованій ролі.

6

Рисунок 5 — Приклад композиції обчислювального об’єкта

.2.3.4 Композиція. Принципи ODP-композиції викори­стовують для групування ODMA обчислювальних об’єктів керування. Складений об’єкт має множинні інтерфейси ке­рування. Інтерфейс між об’єктами керування усередині складеного об'єкта невидимий зовні. Цей механізм проілю­стрований на рисунку 5. Показано три об’єкти керування, згруповані у складений обчислювальний об’єкт. Інтерфейс керування не може поєднуватися чи декомпозуватися з об­числювального погляду. Композиція об’єктів із множинним інтерфейсом може привести до об’єкта з множинними інтерфейсами, за винятком інтерфейсу, що існує між об’єктами в композиції (рису­нок 5).

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

.

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

Як приклад використання інжинірингового погляду, на рисун­ку 6 показана можлива специфікація зв’язування керування, рані­ше подана на рисунку 4а. Цей приклад акцентує увагу тільки на описі каналів (і не розглядає конфігурації кластерів і капсул) та не залежить від специфіки реалізаційного рішення. У розділі 7, де роз­глянуто OSI-SM-підтримку ODMA, показано, як можна використову­вати OSI-SM для специфікації такого зв’язування керування.

На рисунку 7 подано приклад складнішої системи, яка мож-

Р

Вузол на керованій стороні

Вузол на керівній стороні

Вузол на керованій стороні

исунок б-Приклад інжинірингової ^ливо- використовує різні технології. Елементи у пунктирних моделі зв’язування з рисунка 4а прямокутниках задають стек, що складається з stub-посередника, редактора зв’язків І об’єкта протоколу, що детальніше проілюстро­вано на рисунку 6.

Рисунок 7 — Складніший приклад інжинірингової моделі множинних прив'язок

Прозорість розміщування маскує місце інтерфейсу в просторі: прозорість розміщення інтер­фейсу вимагає приховувати ідентифікаторами інтерфейсу інформацію про місце розташування інтер­фейсу. Це також забезпечує прозорість розміщування об’єктів керування.

Інколи може знадобитися знання про розміщування (тобто конкретна адреса для доступу до ке­рованого об’єкта). Передбачено, що інформація про розміщення повинна бути доступною для інших об’єктів.

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

Прозорість міграції маскує від об’єкта здатність функції міграції до зміни місця розташування самого об’єкта. Міграцію об’єкта використовують, наприклад, для:

• мобільних мереж за оптимізації швидкості;

• балансування динамічного завантажування.

Відповідальність за дозвіл міграції лежить на базовій архітектурі.

Прозорість доступу маскує від об’єкта відмінності у механізмах подання даних і виклику. Це дає змогу інтегрувати гетерогенні середовища і використовувати різні технології. У ODP-RM прозорість доступу забезпечують stub-посередники.

Йдеться про те, що ODMA може надати механізми міжмережного обміну між OSI-керуванням і такими парадигмами, як IDL, SQL тощо. Однак повна прозорість доступу неможлива. Замість цього ідентифікація повинна складатися з невеликого набору наявних у конкретний момент видів прозо­рості доступу, наприклад, GDMO-IDL міжмережний обмін.

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

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

Прозорість відгуку приховує використання за підтримки інтерфейсу групи сумісних за пове­дінкою об’єктів.

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

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

ODMA надає керівні принципи для погодженості операторів специфікацій стандартів у ODMA і специфікацій систем, що відповідають ODMA.

Примітка. Погодженість ODMA розглянуто далі.

6.3 Багаторазове використовування ODMA-специфікацій

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

На рисунку 8 подано два stub-посередники, що можуть бути визначені двома ODMA-специ­фікаціями. Припустимо, що специфікація-1 була розроблена до написання специфікації-2. У цьому випадку та частина обчислювального погляду-2, що перекриває обчислювальний погляд-1, уже визначена в специфікації-1. Специфікація-2 може посилатися на специфікацію-1, а не повторюва­ти її. Отже, частину інформаційного погляду-1 використовують повторно.

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

погляд-1

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

Інформаційний

погляд-2

Рисунок 8 — Предметні області, що перекриваються

Інформаційний

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

Специфікація-2

Специфікація-1

7 ПІДТРИМУВАННЯ OSI-КЕРУВАННЯ ДЛЯ ODMA

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

Підтримка OSI-керування для ODMA є додатковою для архітектури (OSI Systems Management Architecture — SMA). Розглянуто, як SMA можна використовувати у розподіленому середовищі. Використання ODMA-середовища показує, як можна вбудовувати керування OSI-системами. У три­віальному випадку взаємодії між поодинокою системою, яка приводить до активності керування, й іншою поодинокою системою, в якій локалізовані керовані ресурси, можна застосовувати OSI-ке­рування згідно з ITU-T Rec. Х.701 IISO/IEC 10040. Якщо керівні або керовані застосування чи ре­сурси розподіляються, то треба використовувати ODMA-архітектуру. Описи подання предметної області й інформаційного погляду на підтримування OSI-керування для ODMA відповідають погля­ду на предметну область й інформаційному погляду з розділу 6.

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

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

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

Іншим важливим базовим елементом SMA є керований об’єкт, який видимий з обчислюваль­ного погляду. У ODMA керований об’єкт задає серверний інтерфейс операції керування і клієнтський інтерфейс сповіщень (або один з них). Інтерпретація керованого об’єкта, залишається тією самою, тобто об’єкт — це «погляд» менеджера на ресурс. Однак погляд на керований об’єкт є керований інтерфейс до об’єкту. Керований інтерфейс описується з використанням GDMO-шаблону.

Серверний інтерфейс операції керування і клієнтський інтерфейс сповіщень одного керованого об’єкта належать тій самій одиниці розподіляння.

Обчислювальний об’єкт керування може також мати керівний інтерфейс. Сучасна SMA не на­дає інструментарій для опису керівних інтерфейсів. Однак, оскільки керівний інтерфейс є протилеж­ністю до керованого інтерфейсу, то немає потреби у такому додатковому інструментарії. Для опису залежностей між інтерфейсом сервера і зв’язаного клієнта обчислювального об’єкта керування може використовуватися GRM. Приклад наведено у додатку D.