---

.На рисунку 16 прийнято такі познаки: bo — редактор зв'язків, ро — об’єкт протоколу, ео — інжи­ніринговий об’єкт, ESO — інжиніринговий об’єкт підтримки.

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

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

Для створювання єдиного керованого об’єкта виконують такі кроки (на рисунку 17 вжито такі познаки: Ьо — редактор зв’язків, ро — об'єкт протоколу, ео — інжиніринговий об’єкт, NM — вузол керування):

1. Керівний об’єкт одержує інформацію (наприклад, АЕ-заголовок-адресу) на бажаному інтер­фейсі (керованого об’єкта), можливо, за допомогою запиту інформації з довідника.

2. Трейдер видає керівний об’єкт з необхідною інформацією (посиланням інтерфейсу) Трей­дер розуміється у ODP-RM контексті.

3. Керівний об’єкт направляє запит створювання до відповідного АЕ.

4. Керування вузлом створює інтерфейс (керованого об'єкта).

Каталог може розташовуватися на іншому вузлі. У цьому випадку необхідний окремий канал зв’язку. ODP-керування вузлом відповідає за створювання і знищування інтерфейсу. Воно існує на кожному вузлі. Деталі див.: ITU-T Rec. X.903/ISO/IEC 10746-3 (12.1).

Керівна роль

Рисунок 17 — Приклад інжинірингового погляду

для підтримки створювання і знищування

Керований об’єкт надає операції на атрибутах (GET, REPLACE), діях і сповіщеннях. Частиною функціональності агентів є трансляція CMIS-примітивів у локальне подання цих операцій (сповіщень) на керованих об’єктах, наприклад, відображення M-GET у GET і відображення сповіщень у M-EVENT- REPORT. Природно, цю трансляцію потрібно виконувати з інжинірингового погляду.

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

Керівний об’єкт викликає обчислювальні операції керування. Ці виклики транслює stub-посе­редник з їхнього локального подання в CMIS-примітиви, а на іншому кінці каналу CMIS-примітиви транслюються в локальні подання операцій. Наприклад, об’єкт у керівній ролі викликає операцію GET, що його stub-посередник транслює з локального подання в CMIS M-GET. Stub-посередник на проти­лежному кінці транслює M-GET у GET, що і є результатом GET для об’єкта у керованій ролі.

Н

Рисунок 18 — Інжиніринговий об’єкт підтримки нав’язування політики зі сторони здійснення керування

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

Примітка. Контроль доступу є окремим випадком нав’язу­вання політики.

Це можливе рішення для підтримування ділянки дії крізь множину систем.

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

ODMA може підтримувати ділянку дії у поєднанні з каталогом. У цьому випадку каталог пови­нен порціями зберігати інформацію з дерева інформації керування, що доволі стабільно зберігаєть­ся у каталозі. Функцію керування знаннями надають об’єктам зі складу каталогу, щоб підтримувати таке збереження. Репозитарій повинен підтримувати ділянку дії і повертати список обраних керова­них об’єктів. Список керованих об’єктів (посилання на них) скеровується інжиніринговому об’єкту підтримки диспетчера операцій (рисунок 19, де ESO — об’єкт підтримки). Інжиніринговий об’єкт підтримки диспетчера операцій задає функціональність для розподілу операцій (виклику і відгуку) для всіх застосувань АЕ-заголовків і керованих об’єктів, які з’являються після АЕ-заголовка.

С

Рисунок 19 — Інжиніринговий об’єкт підтримування диспетчера операцій з керівної сторони

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

Примітка 1. Довідник можна використовувати як репозитарій для керівних знань. Приклад — об’єкт, що робить видимими керівні знання за допомогою інтерфейсу (керованих об’єктів).

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

Примітка. Фільтрацію вивчають далі.

Фільтрацію потрібно підтримувати керованим інтерфейсом (приклад на рисунку 12).

Тепер існує два підходи до розповсюдження сповіщень:

• як окрема служба (ODP-функція сповіщення подій), через яку об’єкти можуть підписатися або на відправлення сповіщень (у ролі ресурсу), або на прийом звітів подій у керівній ролі;

• як частина іжинірингового об’єкта, що відноситься до обчислювального об’єкта керування, тобто функція просування події є частиною цього об’єкта.

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

Таку службу надає об’єкт підтримування диспетчера сповіщень. Цей об'єкт використовують для просування і фільтрації подій, які генерують об’єкт, безпосередньо зареєстровані об’єктом підтрим­ки диспетчера сповіщень. Об’єкт, що генерує події, називають емітером, а об’єкт, що приймає спо­віщення про події, — реципієнтом. Зазначимо, що сповіщення від емітера варто розглядати як операції об’єкта підтримування диспетчера сповіщень. Після того, як емітер створений, він може інформувати об'єкт підтримування диспетчера сповіщень про бажання генерувати події визначено­го типу. Тоді об’єкт підтримування диспетчера сповіщень надає інтерфейс, здатний прийняти такі події.

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

Н

Рисунок 20 — Інжиніринговий погляд на об’єкт підтримування диспетчера сповіщень з керованої сторони

а рисунку 20 наведено іжиніринговий погляд на об’єкт підтримування диспетчера сповіщень щодо об’єктів у керованій ролі. Тут ЕО — проектний об’єкт, ESO — про­ектний об’єкт підтримування.

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

Примітка. Така функціональність може бути зайвою для різних середовищ (транспортних) протоколів.

Інтерфейс об’єкта підтримування диспетчера сповіщень розглядають як функцію звіту подій OSI- керування (ITU-T Rec. Х.734 I ISO/IEC 10164-5).

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

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

Об’єкт у керівній ролі позначається локальним ідентифікатором у ділянці дії його АЕ-заголовка. Ці локальні ідентифікатори адмініструє диспетчер і використовує для адресованих сповіщень і відгуків операцій керування для правильного керівного інтерфейсу. На рисунку 21 зображено інжиніринговий погляд, де ЕО — інжиніринговий об’єкт, ESO — інжиніринговий об’єкт підтримування.

Рисунок 21 — Інжиніринговий погляд на диспетчера керівної сторони

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

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

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

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

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

Прозорості транзакцій можна досягти в OSI-керуванні у разі використовування контексту за­стосування керування системами разом з оброблянням транзакцій (ITU-T Rec. Х.702 IISO/IEC 11587).

Примітка 1. Це можна використовувати для зберігання відношень між всіма об'єктами крізь множину систем. ODMA- функції для керування відношеннями вивчають далі.

Примітка 2. Не всі реалізації OSI-керування підтримують обробляння транзакцій.

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

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

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

8 CORBA-ПІДТРИМУВАННЯ ДЛЯ ODMA

Механізм реалізації ODMA-системи не унікальний і допускає багато підходів. Один з таких підходів є керування OSI-системами, розглянуте у розділі 7. У розділі 8 розглянуто інший підхід, який використовує OMG CORBA як інфраструктуру розподіленого обробляння. Розглянемо, як CORBA може використовуватися для підтримування ODMA.

Примітка. Всесвітньо відомий консорціум OMG здійснює величезний внесок у розвиток інформаційних технологій. ODP IDL згідно з ITU-T Rec. X 920 I ISO/IEC 14750 технічно зіставний з OMG IDL згідно з CORBA.