Страница 10: ДСТУ 4071-2001. Інформаційні технології. Архітектура відкритого розподіленого керування та підтримка загальної архітектури брокера об’єктних запитів (CORBA) (61988)

ДОДАТОК В

(довідковий)

ФУНКЦІЇ ODMA

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

Примітка. Розглянуто лише схеми ODMA-функцій. Вони можуть відрізнятися від реальних ODMA-функцій.

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

Розглянемо такі інформаційні об’єкти:

1. запит операції; складається з імені операції, набору параметрів і запитаного набору інтер­фейсу адресатів;

2. ім’я операції; є іменем операції, що диспетчеризується;

3. запитуваний набір інтерфейсу адресатів; визначає, які з адресатів можуть прийняти опера­цію;

4. узагальнена ділянка дії; визначає список посилань керованих ресурсів, який може динаміч­но змінюватися;

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

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

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

Статичну і динамічну схеми можна уточнювати для спеціальних парадигм (наприклад, OSI-SM).

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

• інтерфейс запиту операції;

• інтерфейс контролю диспетчера операцій.

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

Інтерфейс запиту операції дозволяє клієнтським ODMA-об’єктам «проштовхувати» операції до інших ODMA-об’єктів. Цей інтерфейс містить одну операцію, яка зветься запитом операції. Ця операція має, принаймні, три параметри: перші два відповідно включають ім’я операції та інфор­мацію, що буде передана з операцією. Третій параметр — необов’язковий і містить список адре­сатів операції.

Рисунок В.1 — Обчислювальний погляд операції диспетчеризації

Інтерфейс контролю диспетчера операцій дозволяє іншим об’єктам динамічно маніпулювати набором зв’язаного інтерфейсу операцій керування, який приймають диспетчеризован! операції. Цей інтерфейс повинен також надавати критерії добору імен операцій. Такий інтерфейс містить щонай­менше дві операції. Перша операція зміни набору адресатів дає змогу ODMA-об’єкту змінити спи­сок адресатів і має єдиний параметр, який подає набір інтерфейсу операцій керування або безпо­середньо як список, або опосредковано через селектор. Друга операція зміни інформації про дозво­лені операції використовується для зміни критерію добору операцій, а новий критерій передається як параметр

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

Примітка. Розглянута лише спрощена схема, що не дозволяє визначати адресатів, виходячи зі значень параметрів сповіщення. Для простоти, визначання адресата базується на імені сповіщення.

Необхідно описати наступні інформаційні об’єкти:

1. запит сповіщення; складається з імені сповіщення і списку параметрів;

2. ім’я повідомлення, яке будуть диспетчеризувати;

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

4. максимальний набір інтерфейсу адресатів; становить підмножину узагальнених адресатів і може змінюватися динамічно. Кожен член підмножини асоційований з набором відібраних імен спо­віщень;

5. посилання серверного інтерфейсу сповіщень; є потенційною метою функції диспетчеризації й асоціюється з одним іменем сповіщення;

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

Статична і динамічна схеми можуть деталізуватися для спеціальних парадигм (наприклад, OSI-SM).

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

Рисунок В.2 — Обчислювальний погляд диспетчеризації сповіщень

• інтерфейс контролю диспетчера сповіщень;

• інтерфейс запиту сповіщення.

Обчислювальний об’єкт Диспетчер сповіщень як клієнт також повинен підтримувати такий тип інтерфейсу — інтерфейс доставляння сповіщення.

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

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

Інтерфейс контролю диспетчера сповіщень дозволяє іншим ODMA-об’єктам динамічно маніпу­лювати багатьма зв’язаними інтерфейсами доставляння сповіщень, які можуть приймати диспет­черизован! сповіщення. Цей інтерфейс також повинен забезпечувати критерій добору імен сповіщень. Такий інтерфейс містить щонайменше дві операції. Перша операція зміни набору адресатів дозво­ляє ODMA-об’єктам змінювати список адресатів і має єдиний параметр, який подає набір інтерфейсу доставляння сповіщення або, безпосередньо використовуючи список, або опосередковано через се­лектор. Другу операцію зміни інформації про дозволене сповіщення, використовують для зміни кри­терію добору сповіщень, новий критерій передають як параметр.

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

Диспетчер сповіщень повинен підтримувати паралельний доступ. Отже, диспетчер сповіщень повинен пропонувати атомарні операції для свого серверного інтерфейсу.

Функція нав’язування політики забезпечує системну політику керування і її використовують для фіксації її порушень. Політику керування розглядають в ITU-T Rec. Х.701 | ISO/IEC 10040 і ITU-T Rec. Х.749 I ISO/IEC 10164-19.

Необхідно визначити такі інформаційні об’єкти:

1. специфікацію політики; визначає застосовувану політику;

2. звіти про порушення; породжуються за спроби порушити політику.

Крім того, необхідно задати операції і сповіщення, які нав’язує політика.

Нижче проілюстровано дві можливі обчислювальні реалізації:

• у першій (рисунок В.З) взаємодія між об’єктами в керівній ролі й об’єктами в керованій ролі перехоплюється єдиним обчислювальним об’єктом прив’язки Нав'язування політики;

• у другій (рисунок В.4, де ре — нав’язування політики) кожен об’єкт у керованій ролі зв’язується через окремий обчислювальний об’єкт прив’язки Нав’язування політики.

Звіт
порушень

Контроль ПОЛІТИКИ

Нав'я­зування політики

Рисунок В.З — Обчислювальна реалізація нав’язування політики
з єдиним об’єктом Нав’язування політики

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

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

• інтерфейс контролю політики, використовуваний для контролю застосовуваної політики;

• сповіщення про порушення (клієнтський інтерфейс сповіщень) використовують для сповіщення про порушення політики.

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

• Рішення 1 (рисунок В.З). Об’єкт Нав’язування політики використовує у разі перехоплювання взаємодії між об’єктами в керівній ролі і керованій ролі за допомогою єдиного обчислювального об'єкта прив’язки. Таким чином, цей об’єкт прив'язки повинен допускати встановлювання політики і забез­печувати сповіщення про спроби порушення політики. Об’єкт Нав’язування політики повинен допус­кати перехоплення взаємодії керування з всіма об’єктами — суб’єктами політики.

• Рішення 2 (рисунок В.4). Об’єкт Нав'язування політики використовують у разі перехоплювання взаємодій між об’єктами в керівній ролі й об’єктами в керованій ролі за допомогою набору обчис­лювальних об’єктів прив’язки, де кожен об’єкт Нав’язування політики прив’язують до єдиного об’єкта в керованій ролі і єдиного об’єкта в керівній ролі.

• Рішення 1 (рисунок В.З). Необхідно забезпечити захист доступу до об’єкта Нав’язування полі­тики.

Рішення 2 (рисунок В.4). Повинні існувати засоби, які забезпечують погоджене встановлювання політики на усі об’єкти, задіяні до нав'язування цієї політики. Необхідний захист доступу до об’єктів Нав’язування політики.ДОДАТОК С
(обов’язковий)

ПРИКЛАД OSI-КЕРУВАННЯ, ЩО ВИКОРИСТОВУЄ ODP-RM

У додатку поданий ODP-погляд на опис застосування відкритого розподіленого керування. На прикладі розглядається функція керування системами для контролю журналу реєстрації (опис див. у ССІТТ Rec.X.735|ISO/IEC 10164-6).

Примітка. Метод, розглянутий у додатку, не є єдиним, що може використовуватися ODMA.

С.1 Погляд предметної області

Текст з погляду предметної області копіює текст з ССІТТ Rec. Х.735|ISO/IEC 10164-6, функції контролю журналу реєстрації.

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