AEDP-17 - стандартний інтерфейс бібліотеки ISR NATO

Що це таке

AEDP-17 - Allied Publication, що специфікує NATO Standard ISR Library Interface (NSILI): інтерфейс, який сервер бібліотеки продуктів ISR і клієнтські застосунки впроваджують, щоб публікувати, шукати, отримувати та синхронізувати holdings продуктів intelligence, surveillance and reconnaissance (ISR). Документ називає серверну сторону CSD-Server. Це читається як специфікація протоколу або API, а не стандарт системи менеджменту, і не називає сертифікації за собою. AEDP-17 сам по собі нікого не зобов'язує: власний Letter of Promulgation фіксує, що «the agreement of nations to use this publication is recorded in STANAG 4559», а STANAG ратифікують країни NATO. Для постачальника це доходить лише коли національна програма ISR або закупівля NATO називає відповідність STANAG 4559 / NSILI вимогою контракту. Написано, на власні слова документа, «to be used by application designers and software engineers», а аудиторія вище будівельників - «members of the JISR community may use the CSD-Server to initialize national system JISR libraries and complement their internal information from other coalition members' systems», описуючи національних операторів, які керують системами після розгортання.

Два сімейства інтерфейсів, одне обов'язкове

Інтерфейс має два сімейства. CORBA interface «is a mandatory NSIL interface», тоді як «all NSIL Web Service Interfaces... are optional» (clause 2.3). Сервер має підтримувати CORBA; web-service interfaces - додаткові, а синхронізація server-to-server використовує лише CORBA interface. Яке сімейство (або обидва) будує конкретне розгортання - рішення проєктування від того, з чим потрібна взаємодія, а не вибір, який документ робить за вас.

Що має робити сумісний сервер

CSD-Server має зберігати метадані каталогу з визначеною точністю і показувати один збережений стан, узгоджений незалежно від інтерфейсу, яким користується клієнт. Якщо дозволяє розширення власної моделі метаданих, це має налаштовуватися під час розгортання системи, а новододані атрибути можна позначити як такі, що не підлягають пошуку. На кожному інтерфейсі недійсний запит «MUST» відхиляється повністю, не змінюючи вже збереженого, а дійсний має бути виконаний повністю; сервер також має запобігати двом суперечливим змінам на той самий запис каталогу одночасно. Де сервер пропонує операції публікації, оновлення або виведення запису з обігу, ці виклики не можна надсилати порожніми, оновлення має передати повний набір метаданих, що змінюються (зокрема кілька атрибутів, які сервер сам призначає і контролює), а виклик, що не дотримується правил, відхиляється повністю, а не частково. Сумісний сервер завжди має надати будь-який атрибут метаданих, позначений «Mandatory», на запит, а клієнт, що приймає новий запис, завжди має передати кожен з них. Пов'язаний, завжди доступний механізм дозволяє клієнту отримати файли, пов'язані з записом, навіть коли до них також можна дістатися через власні метадані запису.

Безпека та пошук

Кожна web-service operation «SHALL be protected from access» механізмом безпеки, який документ описує як «agreed to be mandatory for all SOAP operations in all interfaces», а сервіс має відмовити у виклику без достатніх облікових даних. Аутентифікація загалом необов'язкова і, як інформативно зазначає документ, практична лише на web-service interfaces, бо CORBA і file-transfer interfaces успадковують неаутентифікований дизайн попереднього видання. Де сервер пропонує пошук, він має обмежити кількість результатів на запит до максимуму, який оголошує сам, і відхилити запит поза діапазоном, тримати результати відсортованими однаково між повторними посторінковими запитами проти тієї самої версії каталогу, повернути порожній результат замість помилки для запиту без збігів і відхилити некоректний або занадто великий запит.

Розширення моделі вперед і назад

Визначений механізм дозволяє розгортанню додавати нові елементи до власної моделі метаданих, не ламати взаємодію з серверами, яким їх бракує, з рекомендованим порядком застосування таких змін. Невелика кількість атрибутів, які сервер сам призначає, ніколи не розширюють, а розширення чогось пов'язаного з безпекою технічно можливе, але «strongly discouraged... because of potentially serious side-effects» (clause H-4). Обробка записів каталогу, що виходять за межі власної моделі метаданих сервера, - forward compatibility - обов'язкова; обробка старіших версій моделі - backward compatibility - необов'язкова, і де сервер це пропонує, це через окремий набір правил трансформації, а не вбудовано в core interface.

Синхронізація серверів

Роль synchronizing server сама по собі необов'язкова: документ прямо зазначає, що Annex «only enforces requirements on synchronizing servers», а локальний, non-synchronizing server у тій самій мережі out of scope of them (clause K-3). Сервер, що бере цю роль, має підтримувати всю модель даних STANAG 4559, діяти як proxy, щоб клієнт звертався лише до власного локального сервера, а не до віддаленого, кешувати те, що отримує з віддалених серверів, і серіалізувати одночасні запити на той самий файл, фільтрувати, щоб синхронізувати лише частину holdings віддаленого сервера, приєднатися до наявної мережі peers і наздогнати їхню історію, самостійно виявляти недоступного peer і продовжувати повторні спроби з'єднання, і призначати унікальні в мережі ідентифікатори тому, що він створює. Якщо він також брокерує продукти на інших серверах, має зібрати їх в одну доставку, координувати одночасні запити на той самий продукт в одне віддалене замовлення, віддавати перевагу замовленню скороченої версії з віддаленого сервера замість завантаження цілого елемента локально, і переривати все замовлення, а не доставляти частково, якщо частину не вдалося отримати.

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

AEDP-17 стоїть під STANAG 4559, угодою, яку ратифікують країни NATO, і текст документа трактує її як обов'язкову скрізь - synchronizing server, наприклад, має підтримувати всю модель даних STANAG 4559. Написано поруч із двома sibling publications під тим самим STANAG, AEDP-18 і AEDP-19, які ділять base web-service interface з AEDP-17, і AEDP-05, named as source material для цього видання. Кілька STANAG регулюють формат конкретних типів продуктів, які каталогує інтерфейс, cited binding for that purpose: STANAG 4545 для overview-image format, STANAG 4607 для ground moving-target-indicator files, STANAG 4609 для motion-imagery files і STANAG 5516 для tactical-data-link products. ATP-45 і STANAG 2103 cited together, binding, for how CBRN messages and reports defined. STANAG 1059 cited, background, as source country codes кілька attributes use, і STANAG 2433 for how the interface represents a small set of general entity types.

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

• STANAG 4607Обов'язкове
• STANAG 5516Обов'язкове
• AEDP-05Довідково
• STANAG 1059Довідково
• AEDP-19Довідково
• STANAG 4545Довідково
• STANAG 4609Довідково
• STANAG 2433Довідково
• AEDP-18Довідково
• STANAG 4238Довідково
• ATP-45Довідково
• STANAG 2103Довідково

Інші стандарти в темі «Авіаційні озброєння»

• AEDP-02AEDP-02 - архітектура взаємодії ISR NATO
• AEDP-03AEDP-03 - керівні матеріали з санітарної обробки пам'яті розширених систем зберігання даних
• AEDP-05AEDP-05 - посібник з впровадження інтерфейсу бібліотеки ISR NATO
• AEDP-06AEDP-06 - інтерфейс розширеного зберігання даних NATO (NADSI)
• AEDP-12AEDP-12 стандарт NATO на дані супроводу цілей для ISR
• AEDP-18AEDP-18 стандартні служби потокової передачі ISR для NATO