AEDP-17 NATO standard ISR library interface

What it is

AEDP-17 is the Allied Publication that specifies the NATO Standard ISR Library Interface (NSILI): the interface an ISR product library server and the client applications that use it implement to publish, search, retrieve and keep in step with each other's holdings of intelligence, surveillance and reconnaissance (ISR) products. The document calls the server side of this a CSD-Server. It reads like a protocol or API specification rather than a management-system standard, and it names no certification against itself. AEDP-17 does not bind anyone by itself: its own Letter of Promulgation records that "the agreement of nations to use this publication is recorded in STANAG 4559," and a STANAG is what NATO nations ratify. For a supplier, that reaches them only once a national ISR programme or a NATO acquisition names STANAG 4559 / NSILI conformance as a contract requirement. It is written, in the document's own words, "to be used by application designers and software engineers," and a further audience sits above the builders: "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," describing the national operators who run these systems once fielded.

Two interface families, one mandatory

The interface comes in two families. The CORBA interface "is a mandatory NSIL interface," while "all NSIL Web Service Interfaces... are optional" (clause 2.3). A server has to support CORBA; the web-service interfaces are additional, and server-to-server synchronization uses the CORBA interface only. Which family (or both) a given deployment builds is a design decision driven by what it needs to interoperate with, not a choice the document makes for it.

What a compliant server has to do

A CSD-Server has to retain catalogue metadata at a defined precision and present one persisted state that stays consistent no matter which of its interfaces a client uses. If it lets its own metadata model be extended, that has to be configurable when the system is deployed, and newly added attributes can be marked as not searchable. Across every interface, an invalid request "MUST" be rejected in full, leaving anything already stored unchanged, and a valid one has to be carried out completely; the server also has to prevent two conflicting changes from landing on the same catalogue entry at once. Where a server offers the operations to publish, update or retire an entry, those calls cannot be sent blank, an update has to supply the complete set of metadata being changed (including a handful of attributes the server itself assigns and controls), and a call that does not follow the rules is rejected outright rather than partially applied. A compliant server always has to be able to supply any metadata attribute marked "Mandatory" on request, and a client ingesting a new entry always has to supply every one of them. A related, always-available mechanism lets a client retrieve the files linked to an entry, even where those files are also reachable through the entry's own metadata.

Security and searching

Every web-service operation "SHALL be protected from access" using a security mechanism the document describes as "agreed to be mandatory for all SOAP operations in all interfaces," and a service has to refuse a call that lacks sufficient credentials. Authentication overall is optional and, the document notes informatively, only practical on the web-service interfaces, because the CORBA and file-transfer interfaces carry forward an earlier edition's unauthenticated design. Where a server offers search, it has to cap how many results it returns per request to a maximum it declares itself and reject a request outside that range, keep results sorted consistently across repeated paged requests against the same catalogue version, return an empty result rather than an error for a query that matches nothing, and reject a malformed or oversized query.

Extending the model, forward and backward

A defined mechanism lets a deployment add new elements to its own metadata model without breaking interoperability with servers that lack them, with a recommended order for applying such changes. A small number of attributes the server itself assigns can never be extended, and extending anything security-related is technically possible but "strongly discouraged... because of potentially serious side-effects" (clause H-4). Handling catalogue entries that go beyond a server's own metadata model - forward compatibility - is mandatory; handling older model versions - backward compatibility - is optional, and where a server offers it, that is done through a separate set of transformation rules rather than built into the core interface.

Synchronizing servers

Taking on the role of a synchronizing server is itself optional: the document is explicit that this Annex "only enforces requirements on synchronizing servers," and a local, non-synchronizing server on the same network is out of scope of them (clause K-3). A server that does take on that role has to support the entire STANAG 4559 data model, act as a proxy so a client only ever reaches its own local server rather than a remote one, cache what it pulls from remote servers and serialize concurrent requests for the same file, filter so it can synchronize only part of a remote server's holdings, join an existing network of peers and catch up on their history, detect a peer going unreachable on its own and keep retrying the connection, and assign network-unique identifiers to what it originates. Where it also brokers products living on other servers, it has to collect them into a single delivery, coordinate simultaneous requests for the same product into one remote order, prefer ordering a reduced version from the remote server over fetching the whole item locally, and abort an entire order rather than deliver it partially if part of it cannot be retrieved.

Standards it references

AEDP-17 sits under STANAG 4559, the agreement NATO nations ratify, and the document text treats it as binding throughout - a synchronizing server, for instance, has to support the entire STANAG 4559 data model. It is written alongside two sibling publications covered by the same STANAG, AEDP-18 and AEDP-19, which share a base web-service interface with AEDP-17, and AEDP-05, named as source material for this edition. Several STANAGs govern the format of specific product types the interface catalogues, cited binding for that purpose: STANAG 4545 for an overview-image format, STANAG 4607 for ground moving-target-indicator files, STANAG 4609 for motion-imagery files, and STANAG 5516 for tactical-data-link products. ATP-45 and STANAG 2103 are cited together, binding, for how CBRN messages and reports are defined. STANAG 1059 is cited, background, as the source of country codes several attributes use, and STANAG 2433 for how the interface represents a small set of general entity types.

Standards it references

• STANAG 4607Binds
• STANAG 5516Binds
• AEDP-05Background
• STANAG 1059Background
• AEDP-19Background
• STANAG 4545Background
• STANAG 4609Background
• STANAG 2433Background
• AEDP-18Background
• STANAG 4238Background
• ATP-45Background
• STANAG 2103Background