Platform
Modules
By sector
By sector
By standard
Blog
News
Events
ADatP-5644
Software developers implementing WSMP Service Providers and Service Consumers for a NATO Community of Interest
NATO's technical profile for exchanging XML messages between software systems over web services, covering request/response and publish/subscribe message patterns.
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.
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.
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.
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.
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.
ADatP-5644 is a technical interface specification. The work it demands - implementing the WSMPMsg wrapper, the CRUD operations, the fault messages and the resource-property discovery interface, and writing the Community of Interest profile a community needs before any of it is usable - is software engineering work, done in code. ComplyTrain does not write, test or operate a WSMP Service Provider or Consumer, and does not implement the SOAP profile in Annex B on anyone's behalf.
What ComplyTrain can hold is the documentation trail around that work: the COI Profile itself as a controlled, versioned document with a review history; a record of which optional elements - transport protocol, compression, particular filter dialects - a given implementation supports or has recorded a reservation against, the way NATO nations record their own reservations at promulgation; and the interface-control and validation evidence a programme's own quality process expects an integrator to produce.
Which messaging profile a programme actually needs, and what else sits alongside ADatP-5644 in its NATO CIS architecture, is set by the contract and the customer's quality clause. See what else is in the catalogue in the standards explorer, and talk to us about the documentation trail behind an interoperability requirement like this one.
Tell us how you need to work with ADatP-5644 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
Not by itself. ADatP-5644 is covered by STANAG 5644, and a nation's ratification of that STANAG, together with a contract or tender that names WSMP or a Community of Interest profile built on it, is what brings it to bear on a given programme or supplier. The specification's own text sets no obligation.
WSMP is the overall profile. WSMP-RR is one of the two message-exchange patterns it defines: the Request/Response protocol NATO wrote because no adequate public standard existed for it. The other pattern, WSMP-PS, reuses the existing OASIS WS-Notification standard for Publish/Subscribe messaging.
No. The document describes no certification, audit or accreditation scheme. A WSMP Service Provider only self-reports which dialects, policies and profiles it supports to a client application, not to any assessing authority.
WSMP is designed to be transport-independent, but the only Message Exchange Profile it ships with in this edition is for SOAP 1.2. Using WSMP over REST, JMS, AMQP or WebSocket would need a Community of Interest to write an equivalent profile first.
No. ADatP-36 defines the earlier Service Interoperability Profile 3 (SIP3), which WSMP generalises and evolves from, to the point that NATO's own text notes WSMP "MAY also be known as SIP3 v2". NATO has also prepared a WSMP profile for ADatP-36 as a worked example for other communities.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.