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

SMA (Systems Management Architecture) — архітектура керування системами

SMASE (Systems Management Application Service Element) — сервісний елемент застосування керування системами

SNC (Subnetwork Connection) — підмережне з’єднання

SNMP (Simple Network Management Protocol) — простий мережний протокол керування

TP (Transaction Processing) — обробляння транзакцій

4. ВИМОГИ

У цьому розділі визначений набір вимог, які потрібно виконувати для забезпечування відкри­того розподіленого керування. ODMA повинна підтримувати:

• керування ресурсами, зокрема ресурсами, необхідними для самого керування;

• модульність з ідентифікацією частин, які можуть розподілятися;

• делегування обов’язків від одного менеджера до іншого для вихідних операцій керування;

• координацію активності розподіленого керування;

• керування системами будь-якого масштабу;

• моделювання відкритих систем з розподіленим керуванням, з огляду на прозорість розпо­діляння;

• інструментарій для обраного виду прозорості розподіляння;

• специфічну нотаційну техніку керування для об’єктно-орієнтованого моделювання;

• передачу обов’язків керування від однієї системи до іншої;

• механізми визначання обов’язків керування відповідно до компонентів керованої системи;

• деякі форми прозорості розподіляння, визначені ODP-RM. Не всіх їх використовують для застосувань керування чи базових систем, але всі види прозорості потрібно забезпечувати цими системами;

• прозорість доступу (наприклад, заснована на СМІР чи RPC), що допускає декілька реалізацій специфічних частин одного й того самого застосування у певному застосуванні для міжмережного обміну, реалізованого різними шляхами (які розрізняються АРІ і протоколами взаємодії);

• гарантований міжмережний обмін з наявними OSI-SM-застосуваннями та системами з вка­зуванням, як саме принципи і нотації OSI-SM можна використовувати для специфікації ODMA-сис- тем і застосувань;

• міжмережний обмін застосувань керування та некерування (наприклад, мережного керуван­ня і застосувань інтелектуальних мереж);

• мобільність застосувань керування;

• використовування в ODMA з мінімальною адаптацією наявних інформаційних моделей ке­рування;

• керівні вказівки щодо розробляння нових інформаційних моделей керування, заснованих на ODMA.

Застосування керування, заснованого на ODMA, повинні бути здатними адаптуватися до змін середовища. До них належать, але не обов’язково обмежуються ними:

• внутрішня адміністративна організація: різні адміністративні організації предметних облас­тей мають різні статичні конфігурації функціональності керування. Адміністративні рішення можуть призвести до реконфігурації функціональності керування. За ODMA варто подавати стабільні спе­цифікації застосування керування незалежно від варіантів допустимих організацій керування;

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

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

• еволюція служб керування: ODMA повинна підтримувати еволюцію наявних служб керуван­ня. Специфікації нових служб, якщо це можливо, не повинні посилатися на розміщення наявних служб;

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

6 ЗАГАЛЬНЕ СЕРЕДОВИЩЕ

Еталонна модель відкритого розподіленого обробляння є об’єднаним стандартом ISO/ITU, який надає середовище (framework) для масштабних специфікацій гетерогенних розподілених систем. Він визначає архітектуру як набір з п’яти поглядів (уявлень), концентруючись на різних аспектах про­блеми розподіленості, і як множину функцій і механізмів прозорості, що підтримують розподіленість. Підсумкове середовище (framework) наповнюється деталізованими стандартами специфічних ас­пектів конструкцій та операцій розподілених систем. ODMA задає еталонну модель спеціалізованої архітектури для розподіленого керування розподіленими ресурсами, системами і застосуваннями. Наступний опис ODMA фокусується на специфічних особливостях або вимогах керування, які вже не відображаються в ODP-RM. Якщо немає додаткових уточнень, то термін «об’єкт» відноситься до абстракції ODMA-об’єктів, що узгоджуються з ODP-поданням у цьому розділі. Якщо не обумовлене інше, то принципи з цього розділу відповідають зазначеним у ODP-RM принципам.

Загальне середовище ODMA ґрунтується на такому базисі:

• обчислювальний об’єкт керування;

• інжиніринговий об'єкт керування;

• керівна роль;

• керована роль;

• серверний інтерфейс операцій керування;

• клієнтський інтерфейс операцій керування;

• клієнтський інтерфейс сповіщень;

• серверний інтерфейс сповіщень.

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

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

ODMA-опис цього погляду не відрізняється від аналогічних описів інших ODP-RM-застосувань. Однак, оскільки особливо цікавими для ODMA є варіанти керованих і керівних ролей, то підвищені вимоги накладаються на збирання даних у реальному масштабі часу.

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

Зараз ODMA не приписує використання конкретної нотаційної техніки для специфікації подання предметної області (тобто нотації предметної області). Однак опис повинен однозначно ідентифіку­вати (іменувати) різні складові, наприклад, як проілюстровано у додатку F. Такими складовими є:

• контракт;

• роль предметної області;

• спільність;

• політика;

• Дія;

• діяльність.

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

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

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

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

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

Приклад специфікації статичної схеми з використанням ОМТ-бази² (Object Modeling Technique — техніка об’єктного моделювання) і поліпшеної об’єктної моделі наведено у додатку С.

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

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

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

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

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

• наявність у об’єкта максимальної імовірності збою (обмеження надійності).

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

• операції керування;

• сповіщення;

• зв'язні відгуки.

Примітка. Якщо термін операція не уточнено додатково, то його використовують у контексті визначання ODP-RM.Обчислювальний інтерфейс керування — це інтерфейс операцій, що може мати одну з таких ролей:

• керівного клієнта: ініціює операції клієнтського інтерфейсу операцій керування;

• керованого сервера: приймає операції від серверного інтерфейсу операцій керування;

• клієнта: ініціює повідомлення на клієнтському інтерфейсі повідомлення;

• керівного сервера: приймає повідомлення від серверного інтерфейсу повідомлень;

• керованого клієнта: ініціює операції над клієнтським інтерфейсом зв’язного відгуку;

• керівного сервера: приймає операції від серверного інтерфейсу зв’язного відгуку.

З метою керування, операції (наприклад, одержати, замінити, операції дії, визначені в GDMO) можуть бути оголошеннями або запитами. Операції, породжені клієнтським інтерфейсом операцій керування, приймає серверний інтерфейс операцій керування. Сповіщення, породжені клієнтським інтерфейсом сповіщень, приймає серверний інтерфейс сповіщень.

З обчислювального погляду інтерфейс специфікує сигнатура інтерфейсу ODP-операцій, яка складається з:

• вказівки ролі інтерфейсу керування;

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

Примітка. У цьому стандарті параметр використано в ODP-контексті і він не суперечить термінології GDMO.

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

Обчислювальний об’єкт керування може мати множинні інтерфейси, які керують і якими керу­ють (таблиця 4 і рисунок 2). Для підтримування OSI-керування придатне використання наявних описів класів об’єктів керування для відображення різноцільового інтерфейсу керування; наприклад, один для керування конфігурацією (згідно ITU-T Rec. М.3100) та один для керування збоями (згідно ITU- Т Rec. Q.821). Можливість визначати множинні інтерфейси керування спрощує опис взаємозв’язків між різним інтерфейсом об’єкта керування. Отже, для керованої системи існують альтернативи моделювання різноцільової інформації керування за допомогою множинних інтерфейсів керування об’єкта керування, або введення для різних цілей різних об’єктів керування.

Таблиця 4 — Типи обчислювальних інтерфейсів, асоційовані з ODMA-ролями

Рисунок 2 — Приклад залежностей між ролями і типами операцій та сповіщень

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

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