---

³⁾ Термін «система» означає інформаційну систему.

Інтерфейс простого SNC-виконавця необхідний для задоволення вимог предметної області, встановлених у:

<"Rec. G.852.1", COMMUNITY:sscc, ACTION:scccl > ,

<"Rec. G.852.1", COMMUNITYzsscc. ACTION:sccc2 > .

COMPUTATIONAL-INTERFACE simpleSncPerformerlfce {

OPERATIONS <setupSubnetworkConnection>;

<releaseSubnetworkConnection>;

BEHAVIOUR «Обчислювальний об’єкт, що підтримує цей інтерфейс, як сервер, повинен задо­вольняти вимоги, встановлені у директиві BEHAVIOUR шаблонів OPERATION для кожної операції інтерфейсу»;

}

setupSubnetworkConnection operation

OPERATION setupSubnetworkConnection {

INPUT-PARAMETERS

subnetwork : Subnetworkid ::= REF(snQuerylfce);

snpa : SnTPId ::= REF(snTPQuerylfce);

snpz : SnTPId ::= REF(snTPQuerylfce);

dir : Directionality;

suppliedUserLabel: UserLabel;

-- рядки нульової довжини не підтримують servicecharacteristics: Characteristicsld ::= REF(serviceCharacteristicsQue- rylfce);

- посилання можна використовувати для визначання Qo або харак­теристик процедур);

OUTPUT_PARAMETERS

newSNC : SNCId ::= REF(sncQuerylfce) ;

agreedUserLabel: UserLabel;

RAISED EXCEPTIONS

incorrectSubnetworkTerminationPoints : SnTPId; subnetworkTerminationPointDisabled : SnTPId;

subnetworkDisabled : NULL;

subnetworkTerminationPointConnected : SnTPId;

operation Fails : NULL;

wrongDirectionality : Directionality;

userLabellnUse : UserLabel;

BEHAVIOUR

PARAMETERMATCHING

subnetwork: < ssccNotConnected , ROLE:involvedSubnetwork > AND < ssccConnected , ROLEiinvolvedSubnetwork > ;

snpa : < ssccNotConnected , ROLE:potentialAEnd > AND

• scmConnected , ROLE:connectedAEnd > ;

snpz : < ssccNotConnected , ROLE. potentialZEnd > AND

• ssccConnected , ROLE:connectedZEnd > ;

dir : < ssccConnected, ROLE: involvedSubnetwork , ATTRIBUTE: directionality > ; newSNC : <ssccConnected, ROLE: involvedSubnetwork> ;

suppliedUserLabel: <ssccConnected, ROLEiinvolvedSubnetwork, ATTRIBUTE: userLabel >

OR <>; -Користувач не повинен підтримувати користувацьке значення мітки agreedUserLabel: <ssccConnected, ROLEiinvolvedSubnetwork, ATTRIBUTE: userLabel > ;

serviceCharacteristics:<ssccConnected,ROLE: involvedServiceCharacteristics >;

PRE-CONDITIONS < ssccNotConnected> ;

• - і scmNotConnecled схема визначає тип схеми з двома незв’язними інформаційними

• - networkTP об’єктами — кандидатами на з’єднання типу «точка-точка»

• - служби керування.

POST CONDITIONS < ssccConnected> ;

• і Схема scmConnected визначає тип схеми з двома зв’язковими networkTP

• інформаційними об’єктами — кандидатами на з’єднання типу «точка-точка»

• - служби керування.

EXCEPTIONS

IF PRECONDITION <inv 1> NOT.VERIFIED RAISE_EXCEPTION IncorrectSubnetworkTerinination Points ;

IF PRECONDITION <inv_2> NOT.VERIFIED RAISE_EXCEPTION subnetworkTerminationPointConnected ;

IF PRE CONDITION <inv_3> NOT.VERIFIED RAISE_EXCEPTION subnetworkTerminationPointConnected ;

IF POST_CONDITION <inv_l> NOT.VERIFIED RAISE EXCEPTION operationFails ;

IF POST.CONDIT10N <inv 2>NOT.VERIFIED RAISE EXCEPTION operationFails ;

IF POST.CONDITION <inv_3> NOT.VERIFIED RAISE EXCEPTION operationFails ;

IF POST CONDITION <inv_4> NOT.VERIFIED RAISE_EXCEPTION userLabellnllse ;

INFORMAL

«Ця операція встановлює підмережне з’єднання між заданими а-кінцевою точкою snip і z-кінцевою точкою sntp»;

ДОДАТОК F
(довідковий)

ПРИКЛАД СПЕЦИФІКАЦІЇ СПІЛЬНОСТІ ПРЕДМЕТНИХ ОБЛАСТЕЙ

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

F.1 ODP-принципи погляду предметної області

цей додаток повторює ODP-RM визначення для полегшення розуміння шаблонів у F.2.

контракт

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

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

• атрибути якісних характеристик служб;

• ознаки чи тривалості періодів ймовірності;

• ознаки поведінки, що робить контракт недійсним;

• умови життя і безпеки.

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

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

Ролі спільності предметних областей забезпечують приватні функції цілей сукупності.

Ролі предметної області специфічних ODMA-інтересів є різними варіантами керованої і керів­ної ролей.

спільність

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

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

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

політика

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

• Політика: набір правил, який відноситься до приватної мети. Правило може виражатися як дозволи, зобов’язання або заборони.

• Дозвіл: розпорядження про дозвіл на особливу поведінку.

• Зобов’язання: розпорядження про вимогу особливої поведінки.

— Заборона: розпорядження про заборону на особливу поведінку.

Дія

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

діяльність

ODP-RM дає таке визначення діяльності:

Діяльність — однокореневий ациклічний граф (single-headed acyclic graph) дій, де входження кожної дії в граф означає входження всіх безпосередніх попередніх дій.

F.2 Приклад специфікації спільності предметної області

F.2.1 Спільність керування простим підмережним з’єднанням

цілі спільності

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

ролі спільності

Роль ініціатор відображає клієнта служби керування простим підмережним з’єднанням.

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

Роль порт відображає два G.805 порти, включених у спільність керування простим підмереж­ним з’єднанням.

Роль sn відображає G.805 підмережу, для якої визначена служба керування простим підмереж­ним з’єднанням.

Роль snc відображає G.805 підмережне з’єднання, що входить у спільність керування простим підмережним з’єднанням.

політика спільності

Не визначена.

F.2.2 Опис дій спільності

Установка SNC типу «точка-точка»

Ця дія встановлює підмережне з’єднання типу «точка-точка» між двома портами однієї підме­режі. Нижче специфікована політика дії.

Зобов’язання 1

Ініціатор повинен ідентифікувати два порти, що є частиною підмережного домена.

Зобов’язання 2

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

Зобов’язання З

У випадку відхилу запиту на послугу провайдер повинен дозволити ініціаторові довідатися, яка політика була порушена.

Зобов’язання 4

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

• унікальний ідентифікатор підмережного з’єднання,

• про одно- чи двоспрямованість з’єднання,

• про порти, що виступають як кінцеві точки підмережного з'єднання.

Дозвіл 1

Ініціатор може специфікувати, яке саме підмережне з’єднання запитується: дво— чи односпря- моване.

Дозвіл 2

Ініціатор може специфікувати обмеження маршрутизації, засноване на ідентифікаторі каналу (Link ID) чи ідентифікаторі підмережі (Subnetwork(Matrix) ID).

Дозвіл З

Ініціатор може задати ступінь готовності послуги.

Дозвіл 4

Ініціатор може задати ідентифікатор якісних характеристик послуги (Quality of Service — QOS).

Дозвіл 5

Ініціатор може задати смугу частот.

Заборона 1

Провайдер не може задовольнити запит, якщо використовують один з портів.

зміна SNC типу «точка-точка»

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

Зобов’язання 1

З’єднання повинно бути частиною підмережного домену.

Зобов’язання 2

Ініціатор повинен ідентифікувати з'єднання як частину запиту.

Допущення 1

Ініціатор може задати нову смугу частот.

звільнення з’єднання

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

Зобов’язання 1

З'єднання повинне бути частиною підмережного домену.

Зобов’язання 2

Ініціатор повинен ідентифікувати з’єднання як частину запиту.

Зобов’язання З

Провайдер повинен відновити доступність усіх ресурсів після очищування з’єднання.

Зобов’язання 4

Провайдер повинен вказати причину на випадок відмови дії.

Зобов’язання 5

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

ДОДАТОК G

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

ТЕРМІНОЛОГІЯ CORBA

Далі наведено ODMA-термінологію, використовувану для опису принципів CORBA. У правому стовпчику подані українська й англійська назви термінів CORBA, а в лівому — тлумачення термінів

• м

  ODMA (ODP).

  Динамічний інтерфейс виклику (Dynamic Invocation Interface) Динамічний інтерфейс каркаса (Dynamic Skeleton Interface) Подія (Event)

  Канал події — Event channel Виключення (Exception)

  Протокол взаємодії (Interoperability protocol) (наприклад, GIOP) Об’єкт (Object)

  ORB

  Каркас (Skeleton)

  Посередник, заглушка (Stub) Репозитарій інтерфейсу (Interface Repository)

  еханізм виклику на інжиніринговому рівні операції об’єкта з боку клієнта

• механізм прийому на інжиніринговому рівні операції об’єкта з боку сервера

• сигнал

• спеціальний тип каналу

• припинення взаємодії, що виражає помилку виконування операції

• проектний протокол

• інтерфейс обчислювального об’єкта

• набір інженірингових об'єктів

• заглушка з боку сервера

• заглушка з боку клієнта

• та частина ODP-репозитарію типів, яка збері­гає визначення інтерфейсу

ДОДАТОК Н

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

ЗАБЕЗПЕЧЕННЯ МІЖМЕРЕЖНОГО ОБМІНУ CORBA
З ІНШИМИ СТАНДАРТНИМИ ПРОТОКОЛАМИ КЕРУВАННЯ

Існує два основних стандарти інтерфейсу мережного керування: інформаційні CMIS/CMIP та GDMO/ASN.1 моделі й керування Інтернет³. Важливо забезпечити цілісний погляд на цей інтерфейс у CORBA-середовищі.

На рисунку Н.1 показано, як CORBA-керована система може забезпечувати міжмережний обмін з різними протоколами керування (наприклад, СМІР чи SNMP) через шлюзи чи за допомогою CORBA протоколів взаємодії (наприклад, GIOP). Трансляцію між взаємодіями (передбачається, що транс­ляції існують між GDMO/ASN.1 та ODP IDL або між SNMP МІВ-стислим визначенням та ODP IDL) виконують в шлюзах, а не безпосередньо у системі керування.

ITU-T Рекомендації І міжнародні стандарти таких трансляцій підпорядковують міжгалузевим ODMA-функціям.

Примітка. У JIDM-документі трансляції специфікацій⁴) визначено алгоритми трансляції специфікацій між:

• GDMO/ASN. 1 і ODP IDL,

• ODP IDL і GDMO/ASN. 1,

— SNMP МІВ-стислим визначенням і ODP IDL.

Н.1 Міжмережний обмін між GDMO/ASN. 1 і ODP IDL

Використовуючи ODP IDL, необхідно так описати GDMO керовані об’єкти, щоб CORBA систе­ми керування могли здійснити доступ до GDMO керованих об’єктів. Для досягнення цього необхід­на трансляція специфікацій, визначених у GDMO/ASN.1, у специфікації, визначені в ODP IDL. Така трансляція називається трансляцією специфікацій.

Базові принципи об’єктів, спадковування, атрибутів, операцій, станів, поведінки, ікапсульовані в GDMO/ASN.1 та ODP IDL, є подібними. Отже, досяжна двостороння трансляція специфікацій GDMO у ODP IDL та двостороння динамічна трансляція взаємодій (тобто шлюз) СМІР у CORBA протоколи взаємодії.

Н.2 Міжмережний обмін між SNMP і ODP IDL

Внаслідок спрощеної природи SNMP немає придатних засобів подання звичайного ODP IDL інтерфейсу, що використовує SNMP МІВ визначення. Проте доволі легко відобразити SNMP МІВ визначення в ODP IDL визначенні інтерфейсу.

Оскільки SNMP МІВ визначення відображаються у відповідному наборі ODP IDL за допомогою механізму трансляції специфікацій, то досяжна двостороння динамічна трансляція взаємодій між SNMP та CORBA протоколами взаємодії.

35.080

Ключові слова: відкрита система, розподілене керування, брокер об'єктних запитів, об’єкт, інтерфейс, контракт, клієнт, сервер, упорядкування/розупорядкування.