Інтерфейс федеративного управління сервісами та контролю ADatP-5656

Що це таке

Дев'ять томів, один федеративний інтерфейс

ADatP-5656 - це інтерфейс федеративного управління сервісами та контролю (Federated Service Management and Control, SMC) NATO: стандарт API на REST/JSON, який дозволяє системам зв'язку та інформаційним системам (CIS) різних учасників федеративної мережі (Federated Network Participants, FNP) обмінюватися даними управління сервісами в коаліційній мережі. Його опубліковано як дев'ять томів, а не як один документ. Том I - це основна специфікація інтерфейсу, описана у власних словах набору як спільна основа, яку розширює кожен інший том: загальні правила корисного навантаження, поводження з метаданими конфіденційності, ідентифікатори записів, фільтрування, публікація та підписка й оброблення помилок. Решта вісім томів стандартизують кожен по одному процесу управління ІТ-сервісами як федеративний інтерфейс: управління каталогом сервісів, управління інцидентами, виконання запитів, управління подіями, управління сервісними активами та конфігурацією, управління змінами, управління розташуваннями і управління каталогом сервісних запитів. Усі дев'ять томів мають позначення Edition A, Version 1, і кожен промульговано власним листом NATO про промульгацію від 8 грудня 2025 року.

Документ називає своєю основною аудиторією "engineers, system integrators, but also service designers involved in the solution and implementation of SMC systems in FNEs", а пункт про сферу застосування кожного тому зобов'язує "all Service Providers, and the Mission Commander" знати про взаємодії та залежності всередині федерації. Згоду держав використовувати цю публікацію зафіксовано в STANAG 5656. Як і з будь-якою союзною публікацією, охопленою STANAG, це угода між державами, а не правило, що доходить до постачальника напряму: системний інтегратор виконує ADatP-5656 тому, що коаліційна програма, мандат місії або контракт вимагає, щоб федеративна система управління сервісами (Federated Service Management System, FSMS) відкривала ці інтерфейси на межі федерації, а не тому, що документ існує.

Кожен із восьми процесних томів спирається безпосередньо на наявну специфікацію TM Forum Open API, тобто на ті REST API, які телекомунікаційна галузь використовує для власного управління сервісами, пристосовані федеративними розширеннями, властивими NATO. Кожен том зазначає, що специфікації, на які він посилається, хоч би де їх цитували в його тексті, "constitute provisions of this ADatP," тож це запозичення є обов'язковим, а не довідковим читанням.

Що стандартизує кожен том

Том II, Service Catalogue Management, ділить пропозиції постачальника на сервіси, звернені до замовника, до користувача і до ресурсу, та вимагає, щоб сервіси, звернені до замовника, публікувалися саме через Service Catalogue API, а замовні позиції лишалися в окремому каталозі сервісних запитів.

Том III, Incident Management, побудовано на TM Forum Trouble Ticket API, і він керує передаванням інциденту між учасником, який його порушує, і тим, хто володіє враженим сервісом. Писати в інцидент можуть лише ці двоє учасників; інцидент, яким уже обмінялися, "must not be forwarded or reassigned to another Service Provider to prevent record chaining," натомість створюють новий; а інцидент, залишений у розв'язаному стані, закривається автоматично після періоду очікування, якщо ініціатор не відповість.

Том IV, Request Fulfilment, розширює TM Forum Service Ordering Management API. Запит завжди стосується сервісу з каталогу, зверненого до замовника, несе єдину позицію замовлення, і постачальник може лише прийняти його або відмовити цілком. Позначити запит скасованим через API може лише постачальник, а не споживач, який його подав, і запити навмисно лишено поза механізмом публікації та підписки, бо вони "not considered critical information in federated environments."

Том V, Event Management, пристосовує TM Forum Alarm Management API для передавання подій між учасником-відправником і учасником-одержувачем. Суто національні події не можна поширювати у федерацію; від держав очікують, що вони фільтруватимуть і корелюватимуть їх перед поширенням. Будь-яка подія, що стосується федеративного сервісу CIS, сама вважається федеративною, і змінювати стан події може лише постачальник, який володіє враженим сервісом.

Том VI, Service Asset and Configuration Management, визначає дванадцять типів федеративних конфігураційних одиниць - від програмного забезпечення та баз даних до мережевих пристроїв і фізичних серверів. Постачальник, який поширює конфігураційну одиницю у федерацію, весь час зберігає володіння нею та відповідальність за неї.

Том VII, Change Management, розширює TM Forum Change Management API. Зміну, що впливає на федеративний сервіс, скеровують до органу управління сервісами (Service Management Authority, SMA) для координації, і її ніколи не можна передавати далі іншому учасникові; "only the two participants service owner (Service Provider) and change owner (SMA) have write-access to the Change," а споживач сервісу не може її ініціювати.

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

Том IX, Service Request Catalogue Management, керує каталогом замовних пропозицій, які постачальник відкриває федерації. Кожна пропозиція має відсилати до сервісу, що вже є в каталозі сервісів CIS, і від постачальника очікують, що він оновлюватиме опубліковане щонайменше щодня.

Що є спільним для кожного тому

Жменя правил повторюється в усьому наборі, а не належить якомусь одному процесові. Обов'язкові атрибути мають завжди нести значення; порожнє чи відсутнє обов'язкове поле не приймають. Запити до колекцій за замовчуванням виключають закриті, припинені чи виведені з ужитку записи, якщо той, хто звертається, окремо про них не попросить. За замовчуванням постачальник повертає лише ті дані, якими володіє сам, а не дані всієї федерації, окрім окремих обставин на кшталт формального передавання повноважень управління. Видалення підписки - єдина операція DELETE, яку цей інтерфейс десь дозволяє, і документ пов'язує це зі збереженням простежуваності та прозорості власної історії запису. А про полегшений режим участі у федерації, "Remote FNP Provider", том за томом зазначено, що його самого собою ніколи не досить, щоб учасник узяв на себе координаційну роль органу управління сервісами для цього процесу; для такої ролі потрібна вже побудована повнофункційна федеративна система управління сервісами з повною підтримкою відповідного тому.

Два моменти варто відзначити, бо вони окреслюють межі стандарту. Реалізаторам кажуть, що "crucial to ensure information security and protection of the REST API interfaces proposed," але документ прямо каже, що виконання цієї вимоги лишено на "governance and framework agreements in the area of operation" чи на національні настанови з упровадження, і відверто зазначає, що воно "is not part of this standard." А файли схем JSON, придатні до машинної перевірки, на момент промульгації цього видання ще не було випущено, і кілька томів зазначають, що вони з'являться в майбутньому додатку, тож наразі відповідність перевіряють за письмовими таблицями атрибутів і розібраними прикладами, а не автоматичним валідатором.

Як перевіряють відповідність

У жодному з дев'яти томів не з'являється ані орган сертифікації, ані випробувальна лабораторія, ані державний представник із забезпечення якості, ані схема акредитації. Кожен том зазначає, що його профіль відповідності "follows the TM Forum guidelines," а відповідність доводять, звіряючи власні корисні навантаження запитів і відповідей реалізації, операція за операцією, з таблицями атрибутів цього тому (де кожен атрибут позначено як обов'язковий, умовний, необов'язковий або незастосовний) і з розібраними прикладами REST/JSON у власному додатку тому. Організація підтверджує свою готовність до взаємодії через процедуру оперативної готовності до сумісності з тому I: вона будує власний реєстр сервісів, налаштовує вихідні з'єднання і формально стає "activated," зазвичай через сам процес управління змінами або виконання запитів. Це технічна та процедурна перевірка готовності між учасниками федерації, а не сертифікат, який видає третя сторона, і в жодному з дев'яти томів не сказано, що постачальник сервісу, виробник чи продукт може мати сертифікацію за ADatP-5656.

Стандарти, на які він посилається

ADatP-5656 охоплено STANAG 5656 - стандартизаційною угодою NATO, що фіксує згоду держав використовувати його. Метадані конфіденційності на даних SMC маркують і прив'язують за ADatP-4774 та ADatP-4778, і обидва цитовано як обов'язкові.

Поза власним каталогом NATO кожен том розширює названу специфікацію TM Forum Open API: Trouble Ticket API для управління інцидентами, Service Ordering Management API для виконання запитів, Alarm Management API для управління подіями, Resource Inventory API для управління сервісними активами та конфігурацією, Change Management API для управління змінами, Geographic Address, Site і Location Management API для управління розташуваннями та Service Catalog Management API для обох каталожних томів, і кожну з них профільовано за власними настановами TM Forum з проєктування REST API та з відповідності REST API. Інтерфейс також спирається на правила IETF щодо читання "shall/should/may," на JSON Merge Patch для запитів PATCH, на схему data URL для вбудованих вкладень і на реєстр IANA Media Types для типів MIME. Жодної з цих специфікацій TM Forum чи IETF немає в нашому каталозі.

Стандарти, на які він посилається

• AJP-6.1Довідково
• ADatP-4774Довідково
• ADatP-4778Довідково

Інші стандарти в темі «Системи зв'язку та інформації»

• AComP-5639AComP-5639 - специфікації Protected Core Networking для статичного середовища
• AComP-5640AComP-5640 - специфікації Protected Core Networking для розгортаного середовища
• ADatP-4774ADatP-4774 синтаксис міток конфіденційності в метаданих
• ADatP-4778Механізм прив'язки метаданих ADatP-4778
• ADatP-5636Специфікація базових метаданих NATO ADatP-5636
• ADatP-5644Профіль обміну повідомленнями через вебсервіси ADatP-5644