ADatP-5644 web services messaging profile

What it is

A specification for developers, not a contract clause

ADatP-5644, the Web Services Messaging Profile (WSMP), is a NATO Allied Data Publication: a technical interface specification, not a document a contracting officer or a national quality assurance representative reads. NATO says so directly in its own scope clause: "the target audience for this specification is the community of software developers who are" implementers of WSMP Service Providers and implementers of WSMP Service Consumers. It is covered by STANAG 5644, the agreement by which nations commit to it; the STANAG binds a nation, and a supplier meets WSMP because a contract or a Community of Interest (COI) profile built on it says so, not because the specification exists. This is Edition A, Version 1, promulgated October 2023, the first edition, built on an NCI Agency working paper.

WSMP replaces an earlier ad-hoc protocol, the Service Interoperability Profile 3 (SIP3), that the Friendly Force Tracking community used to exchange NATO Friendly Force Information messages. WSMP generalises that idea for any interested community: "WSMP is extensible and MAY be used by any Community of Interest (COI)." It standardises how two systems exchange messages with each other, not what the messages themselves contain.

Two message-exchange patterns

WSMP defines two ways systems can talk to each other. WSMP-RR is a Request/Response protocol NATO wrote itself, because generic request/response messaging had no strong existing standard to reuse: "the Request/Response MEP is not strongly regulated like the Publish/Subscribe MEP where standards are available for almost all the messaging protocols." It exposes Create, Read, Update and Delete operations, plus two discovery operations a client can use to ask a service what it supports. WSMP-PS instead reuses the OASIS WS-Notification standard for Publish/Subscribe messaging, wrapping the notification payload in WSMP's own message envelope.

Every message, in either pattern, travels inside a single WSMPMsg wrapper element that can carry several Create, Update, Delete and Response elements at once, each with its own optional metadata binding, mandatory data payload, optional filter and optional delivery policy.

Filtering, faults, and what WSMP leaves open

A Filter narrows which data objects an operation applies to. Where one is present, the operation "SHALL only be applied to the data objects for which the application of ALL the indicated filter expressions evaluate to TRUE"; omit it, and the operation applies to every data object the service manages. WSMP standardises one content filter language at the generic level, XPath 1.0, and is candid that its own metadata filter language "is currently not defined so this filtering method is unavailable at a COI generic layer" - a gap the specification names rather than glosses over.

Every WSMP-RR error condition returns one of a small set of standard fault messages, built on the OASIS Web Services Base Faults model: a generic fault, an operation-not-implemented fault, an unsupported-message fault, and matched pairs of dialect and policy faults for anything a service does not recognise or cannot honour. Even an operation a service chooses not to implement still has to be exposed and still has to fail with the correct fault, rather than simply not existing.

WSMP does not define the format of the data it carries, how a service decides to publish something, how services discover each other, or message and protocol security. All four are left to the Community of Interest's own profile and to the underlying transport layer. In practice, that means WSMP alone is never enough to build an interoperable system: a WSMP Message Exchange Profile has to name the actual transport standard, and a WSMP COI Profile has to define the payload, filters and business rules a specific community needs. WSMP ships with one Message Exchange Profile ready to use, for SOAP 1.2, in its Annex B; a developer targeting REST, JMS, AMQP or WebSocket has no equivalent profile in this edition and would need the Community of Interest to write one.

What nations have already found in practice

The record of reservations at the front of the document shows how much of WSMP's surface a real implementation can leave out. One nation recorded that it "did not implement REST, JMS, AMQP and WebSocket", that it "only supports SOAP and Read operations", that it "does not implement data compression", and that instead of verifying delivery it implemented "the transaction as fire and forget". A profile this flexible is meant to be tailored, and nations tailor it.

How you would be checked

ADatP-5644 describes no certification, audit or inspection regime. It is a technical interface specification, and the closest thing it defines to an evaluation mechanism runs between systems rather than between an organisation and an assessor: a WSMP Service Provider "SHALL return in the WSMPProfiles element with all the supported profiles" it accepts, so a client can check a service's declared capabilities before relying on them. That is a machine checking a machine, not a third party checking a supplier.

Standards it references

• ADatP-36Background
• STANAG 4778Background
• STANAG 4774Background
• ADatP-03Background