nato standard aedp-19 nato standard isr workflow … eda v1 e... · 2018. 8. 24. · soa...

NATO STANDARD

AEDP-19

NATO STANDARD ISR WORKFLOW ARCHITECTURE

Edition A Version 1

MARCH 2018

NORTH ATLANTIC TREATY ORGANIZATION

ALLIED ENGINEERING DOCUMENTATION PUBLICATION

Published by the NATO STANDARDIZATION OFFICE (NSO)

© NATO/OTAN

INTENTIONALLY BLANK

NORTH ATLANTIC TREATY ORGANIZATION (NATO)

NATO STANDARDIZATION OFFICE (NSO)

NATO LETTER OF PROMULGATION

28 March 2018

1. The enclosed Allied Engineering Documentation Publication AEDP-19, Edition A, Version 1, NATO STANDARD ISR WORKFLOW ARCHITECTURE, which has been approved by the Nations in the NATO AIR FORCE ARMAMENTS GROUP, is promulgated herewith. The agreement of nations to use this publication is recorded in STANAG 4559.

2. AEDP-19, Edition A, Version 1, is effective upon receipt.

3. No part of this publication may be reproduced, stored in a retrieval system, used commercially, adapted, or transmitted in any form or by any means, electronic, mechanical, photo-copying, recording or otherwise, without the prior permission of the publisher. With the exception of commercial sales, this does not apply to member nations or NATO commands and bodies.

4. This publication shall be handled in accordance with C-M(2002)60.

~_I I(~ 40oltan t:{YAS ( 1--..

/Sriga i7rG~neral, HUNAF Director, NATO Standardization Office

INTENTIONALLY BLANK

AEDP-19

I Edition A Version 1

RESERVED FOR NATIONAL LETTER OF PROMULGATION

AEDP-19

II Edition A Version 1

INTENTIONALLY BLANK

AEDP-19

III Edition A Version 1

RECORD OF RESERVATIONS

CHAPTER RECORD OF RESERVATION BY NATIONS

Note: The reservations listed on this page include only those that were recorded at time of promulgation and may not be complete. Refer to the NATO Standardization Document Database for the complete list of existing reservations.

AEDP-19

IV Edition A Version 1

INTENTIONALLY BLANK

AEDP-19

V Edition A Version 1

RECORD OF SPECIFIC RESERVATIONS [nation] [detail of reservation]

Note: The reservations listed on this page include only those that were recorded at time of promulgation and may not be complete. Refer to the NATO Standardization Document Database for the complete list of existing reservations.

AEDP-19

VI Edition A Version 1

INTENTIONALLY BLANK

AEDP-19

VII Edition A Version 1

TABLE OF CONTENTS

This table of contents provides the structure and content for AEDP-19. AEDP-17, NATO Standard ISR Library Interface, and AEDP-18, NATO Standard ISR Streaming Services, complement AEDP-19 in these related respects.

CHAPTER 1 INTRODUCTION ............................................................................ 1-1

1.1 BACKGROUND ........................................................................................ 1-1

1.2 AIM ..................................................................................................... 1-2

1.3 DESCRIPTION ......................................................................................... 1-2

1.4 RFC 2119 COMPLIANCE ......................................................................... 1-2

1.5 REFERENCES AND RELATION TO OTHER STANDARDS ................... 1-3 1.5.1 Referenced Documents ............................................................................ 1-3 1.5.2 Related Documents .................................................................................. 1-4

1.6 ABBREVIATIONS ..................................................................................... 1-5

CHAPTER 2 STANAG 4559 Service STACK ...................................................... 2-1

2.1 INTRODUCTION ...................................................................................... 2-1

2.2 SERVICE RELATIONSHIPS .................................................................... 2-2

2.3 CORE SERVICES .................................................................................... 2-3

2.4 JISR COI-SPECIFIC SERVICES .............................................................. 2-3

2.5 SERVICE STACK BASIC REQUIREMENTS ............................................ 2-3

2.6 SECURITY CONSIDERATIONS .............................................................. 2-4

2.7 AEDP-19 XML SCHEMA and WSDL DEFINITIONS ................................ 2-4

AEDP-19

VIII Edition A Version 1

Tables

Table 2-1 XML Schemas for Workflow Artifacts ...................................................... 2-4

Table 2-2 XSDs und WSDLs for Workflow Services (services) ............................... 2-5

Figures

Figure 2-1 AEDP-19 (red) in the overall STANAG 4559 Service Stack ................... 2-1

Figure 2-2 Abstract, three tier workflow architecture (dynamic data) ....................... 2-2

ANNEXES

Annex A CORE SERVICES INTERFACES ........................................................ A-1

Annex B ORGANIZATION SERVICE INTERFACE ............................................ B-1

Annex C REQUIREMENT SERVICE INTERFACE ............................................. C-1

Annex D PRIORITY SERVICE INTERFACE ....................................................... D-1

Annex E TASKING SERVICE INTERFACE ........................................................ E-1

Annex F REQUEST SERVICE INTERFACE ...................................................... F-1

Annex G GEOGRAPHIC AREA OF INTEREST SERVICE INTERFACE ........... G-1

Annex H WORKFLOW SERVICES BUSINESS RULES ..................................... H-1

AEDP-19

1-1 Edition A Version 1

CHAPTER 1 INTRODUCTION

1.1 BACKGROUND

1. This document sets forth AEDP-19, NATO Standard ISR Workflow Architecture, proposed for agreement under STANAG 4559 Edition 4. 2. AEDP-19 complements AEDP-17, NATO Standard ISR Library Interface, and AEDP-18, NATO Standard ISR Streaming Services, proposed for agreement under STANAG 4559 Edition 4, with a Joint ISR Workflow Architecture.

3. Sources for AEDP-19 are

a) MAJIIC2 Baseline Bravo.1

(1) DOP-MAJIIC2-081, MAJIIC2 Enterprise Event Relay Service (E2RS) Specification Documentation, Document Version 2.0

(2) DOP-MAJIIC2-082, MAJIIC2 Organization Service Specification, Service Version 4.4, Document Version 3.0

(3) DOP-MAJIIC2-083, MAJIIC2 Request Service Specification, Document Version 4.0

(4) DOP-MAJIIC2-084, MAJIIC2 Simple Persistence as a Service (SPS++) Documentation, Document Version 4.0

(5) DOP-MAJIIC2-085, MAJIIC2 Tasking Service Specification, Document Version 4.0

(6) DOP-MAJIIC2-093, MAJIIC2 WS-Notification Implementation Guide, Document Version 2.0

(7) DOP-MAJIIC2-107, MAJIIC2 Geographical Area of Interest Service Specification, Document Version 2.0

(8) DOP-MAJIIC2-109, MAJIIC2 Priority Service Specification, Document Version 1.0

(9) DOP-MAJIIC2-110, MAJIIC2 Requirement Service Specification, Document Version 2.0

(10) DOP-MAJIIC2-096, MAJIIC2 SOA Services Profile, Document Version 2.0

AEDP-19


(11) DOP-MAJIIC2-101, MAJIIC2 Core Interface Documentation, Document Version 2.0

(12) DOP-MAJIIC2-026, MAJIIC2 Business Rules and Use Cases, Document Version 6.0 (BRUC)

1.2 AIM

The aim of this standard is to promote interoperability for the exchange of

NATO Intelligence, Surveillance and Reconnaissance (ISR) process elements. The NATO Standard ISR Workflow Architecture provides standard interfaces for enabling Joint ISR processes and exchanging JISR workflow elements through suitable applications maintained by NATO and NATO Nations.

1.3 DESCRIPTION

1. The workflow architecture covered by this AEDP-19 covers the ISR enterprise wide sharing and management of:

Intelligence Collection Plans through the Requirements, Priority and GAOI Services.

Requests for information and ISR requests through the request service.

Taskings of organic ISR assets through the tasking service.

Linkage of collected and exploited products to requests, tasks and intelligence requirements.

ISR ORBAT including configuration information through the organisation service.

2. The operational processes facilitated by the ISR workflow architecture are described in detail in AIntP-16 (IRM&CM procedures) and AIntP-14 (JISR procedures).

1.4 RFC 2119 COMPLIANCE

1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [IETF, RFC 2119, 1997] 2. The key word “INFORMATIVE” is used to denote strictly informative content of the document.

AEDP-19


1.5 REFERENCES AND RELATION TO OTHER STANDARDS

1.5.1 Referenced Documents

1. The following STANAGS, Allied Publications, Specifications and Standards contain provisions contain provisions, which through references in this text constitute provisions of this AEDP:

OASIS WS-Topics 1.3, 2006

OASIS Standard Specification, “Web services Topics”, Version 1.3, 1 October 2006

OASIS WS-BaseNotification 1.3, 2006

OASIS Standard Specification, “Web services Base Notification”, Version 1.3, 1 October 2006

OASIS WS-BrokeredNotification 1.3, 2006

OASIS Standard Specification, “Web Services Brokered Notification”, Version 1.3, 1 October 2006

OASIS WS-Security UsernameToken 1.1, 2006

OASIS Standard Specification, “Web Services Security UsernameToken Profile“, Version 1.1, Web Service Security, February 2006

W3C WS transfer 1.0, 2011

W3C Standard Specification, “Web Services Transfer”, Version 1.0, December 2011.

AEDP-17 Annex D NATO Standard ISR Library Interface, NSIL WEB SERVICE CORE INTERFACE

2. At the time of publication, the editions indicated were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this AEDP are encouraged to investigate the possibility of applying the most recent editions of the STANAG, Recommendations and Standards listed above. NATO maintains registers of currently valid STANAGs.

AEDP-19


1.5.2 Related Documents

1. The following STANAGS, Allied Publications, Specifications and Standards relate to this AEDP:

AJP-2 Allied Joint Doctrine for Intelligence, Counter-Intelligence and Security, Edition A Version 2, Februray 2016.

AJP-2.1 Allied Joint Doctrine for Intelligence Procedures, Edition B Version 1, June 2016.

AJP-2.7 Allied Joint Doctrine for Joint Intelligence, Surveillance and Reconnaissance, Edition A Version 1, July 2016.

AIntP-14 Joint Intelligence, Surveillance and Reconnaissance (JISR) Procedures in Support of NATO Operations, Edition A Version 1, October 2016

AIntP-16 Intelligence Requirements Management and Collection Management (IRM&CM) Procedures, Edition A, Study Draft 1 (SD2) (STANAG 6524)

RFC 2119 Key words for use in RFCs to Indicate Requirement Levels, IETF 1997

NATO C3 Classification Taxonomy, 2015

C3 Taxonomy, at https://tide.act.nato.int/em/index.php?title=C3_Taxonomy, viewed 12 October 2015

ADatP-34(H) NATO Interoperability Standards and Profiles, Edition H

DOP-MAJIIC2-026 BRUC

MAJIIC2 Business Rules and Use Cases, Document Version 6.0

2. The MAJIIC2 Business Rules and Use Cases [DOP-MAJIIC2-026 BRUC] of the former MAJIIC2 program provide conditions for enhancing service integration and interoperability. The application of business rules and use cases offers a more integrated package of services that are interoperating with each other and enriching the value and content of each other.

3. Relevant portions of the MAJIIC2 BRUC will be included in the forthcoming STANAG 4559 Edition 4 Standard Related Documentation. Until then the MAJIIC2 BRUC should be considered an informative resource for AEDP-19. A copy of the MAJIIC2 BRUC can be requested from the STANAG 4559 Custodian.

AEDP-19


1.6 ABBREVIATIONS

AEDP Allied Engineering Documentation Publication AOI area of interest BPMN Business Process Model and Notation BQS Boolean Query Syntax BRUC Business Rules and Use Cases COI community of interest CRL Collection Request List CSD Coalition Shared Data CSL Core Services Layer CTL collection task list CXP Collection and Exploitation Plan E2RS Enterprise Event Relay Service EOB electronic order of battle EO/IR electro-optical/infra-red FMN Federated Mission Networking FMV full motion video FQN fully qualified name GAOI geographic area of interest GIS geographic information system GMTI ground moving target indicator HTML HyperText Markup Language HUMINT human intelligence ICP intelligence collection plan IRM&CM Information Requirement Management and Collection Management ISR intelligence, surveillance and reconnaissance JCSL JISR COI-Specific Services Layer JISR Joint Intelligence Surveillance and Reconnaissance KML Keyhole Markup Language LAN local area network

AEDP-19


MAJIIC2 Multi Intelligence All Source Joint Intelligence Surveillance and

Reconnaissance Interoperability Coalition 2 MARD MAJIIC 2 Architecture Requirements Document MDA model-driven architecture MoD Ministry of Defence NATO North Atlantic Treaty Organization NIIA NATO ISR Interoperability Architecture NSILI NATO Standard ISR Library Interface OASIS Organization for the Advancement of Structured Information

Standards OGC Open Geospatial Consortium ORBAT order of battle OUR operational user requirement PED processing, exploitation, and dissemination PIM Platform Independent Model PSM Platform Specific Model RFI request for information SIGINT signals intelligence SOA service-oriented architecture SOF special operations forces SPS++ Simple Persistence as a Service STANAG NATO Standardization Agreement TTP tactics, techniques and procedure UAV unmanned aerial vehicle UML Unified Modelling Language W3C World Wide Web Consortium WAN wide-area network WKT well-known text WSDL Web Services Description Language XML Extensible Markup Language XSD XML Schema Definition

AEDP-19


CHAPTER 2 STANAG 4559 SERVICE STACK

2.1 INTRODUCTION

1. The overall STANAG 4559 Service Stack is shown in Figure 2-1, highlighting in red those services that are applicable to this AEDP-19.

2. Its various layers are based on NATO C3 Classification Taxonomy.

Figure 2-1 AEDP-19 (red) in the overall STANAG 4559 Service Stack

3. The generic domain independent services reside in the Core Services Layer. For this AEDP-19 these include: SPS++, E2RS and Pub Sub.

4. Certain services are distinguished by the fact that they provide logic specific for the JISR Community of Interest (COI) serving the JISR user-facing applications. These services are too COI-specific to be considered to be Core Services at the utility end of the service spectrum, and therefore find themselves in the JISR COI-Specific Services Layer (JCSL). For this AEDP-19 these include: Request, Organization, Tasking, Requirement, GAOI, and Priority.

AEDP-19


2.2 SERVICE RELATIONSHIPS

Figure 2-2 Abstract, three tier workflow architecture (dynamic data)

A number of aspects, independent of the number of layers, are important to understanding Figure 2-2:

There are two nodes (or echelons) depicted because the intent is to demonstrate both the intra and inter node interactions

Arrows show: o Interactions between specific services – for example the replication

arrow going from the SPS++ in one node to the SPS++ in the other node

o Interactions between classes of services, e.g. the JISR COI-Specific service call can be from any JISR user-facing capability to any JISR COI-Specific service

The interactions can be read as an abstract linear narrative of interactions which supports many specific JISR COI use cases, e.g. “Create new RFI”, “Add new product to ISR request”, “Accept tasking”, etc.

According to the rules of dependency and responsibility it can be seen that:

o All top-down interactions are initiated by the topmost layer and are of a request-response pattern

AEDP-19


o All bottom-up interactions are event based; they are initiated by the lower layer, follow a one-way pattern and are triggered in response to subscriptions expressed earlier by the upper layer;

2.3 CORE SERVICES

The following Core Services apply to the Standard ISR Workflow Architecture and are detailed in Annex A:

Simple Persistence as a Service (SPS++) Service

Pub-Sub Service (WS Notification)

Enterprise Event Relay Service (E2RS) Service

2.4 JISR COI-SPECIFIC SERVICES

The following COI Specific Services apply to the Standard ISR Workflow Architecture and are detailed in corresponding Annexes:

Requirement Service (ICP management)

Priority Service

Request (RFI/ISRR) Service

Tasking Service

Geographic Area of Interest (GAOI) Service

Organization Service

2.5 SERVICE STACK BASIC REQUIREMENTS

1. The NSIL web-service Core Interface shall be implemented by all STANAG 4559 SOA services. The Core Interface is described in AEDP-17 Annex D NSIL WEB SERVICE CORE INTERFACE.

2. The SOA Services Profile describes specific aspects all services shall conform to and is described in A-5 SOA SERVICES PROFILE.

3. All business service operations (including underlying service operations) from service call to service response SHALL be atomic.

AEDP-19


2.6 SECURITY CONSIDERATIONS

Access to the functionality provided by the service interfaces described in this document SHALL be controlled using the “Username Token Profile 1.1” [OASIS WS-Security UsernameToken 1.1, 2006] that has been agreed to be mandatory for all SOAP operations in all interfaces. Further details on the profile and how it is to be used depends on the operational environment. A service SHALL throw an “AccessDenied” exception if it does not receive sufficient credentials.

2.7 AEDP-19 XML SCHEMA and WSDL DEFINITIONS

The data model underlying the workflow architecture is established by the following schema and service definitions, which are maintained and managed (versioning) in a NATO Metadata Registry and Repository under a “NATO/NIIA/STANAG 4559 Edition 4” namespace:

Table 2-1 XML Schemas for Workflow Artifacts

Name XSD Version

CCIRM Common Types Schema (ccirm)

ccirmcommontypes.xsd 4.4

Country Code Schema (common) CountryCode1059.xsd 4.4

Collection and Exploitation Plan Schema (ccirm)

cxp.xsd 4.4

ISR Asset Status Schema (ccirm) israssetstatus.xsd 4.4

ISR Common Schema (common) isrcommon.xsd 4.4

ORBAT Schema (organization) orbat.xsd 4.4

Organization Common Types Schema (organization)

organizationcommontypes.xsd 4.4

Request Schema (ccirm) request.xsd 4.4

System Status Update Schema (ccirm)

SysStatusUpdate.xsd 4.4

System Specifications Schema (organization)

systemspecifications.xsd 4.4

AEDP-19


Table 2-2 XSDs und WSDLs for Workflow Services (services)

Name WSDL Version

Common Messages Schema (CommonMessages)

CommonMessages.xsd 4.4

Geographic Area of Interest Web-service Definition Language (WSDL) File (GeographicAreaOfInterest)

GeographicAreaOfInterest.wsdl 4.4

Geographic Area of Interest Messages Schema (GeographicAreaOfInterest)

GeographicAreaOfInterestMessages.xsd 4.4

Geographic Area of Interest Service Web-service Definition Language (WSDL) File (GeographicAreaOfInterest)

GeographicAreaOfInterestService.wsdl 4.4

Local ConsistencyMessages Schema (LocalConsistencyInterface)

LocalConsistencyMessages.xsd 4.4

ISR Request Messages Schema (Request)

ISRRMessages.xsd 4.4

MAJIIC Notification Schema MAJIICNotification.xsd 4.4

MAJIIC2 Services Replication Web-service Definition Language (WSDL) File (SPSReplication)

majiic-services-replication.wsdl 4.4

MAJIIC2 Services Replication Schema (SPSReplication)

majiic-services-replication.xsd 4.4

Organization Web-service Definition Language (WSDL) File (Organization)

Organization.wsdl 4.4

Organization Messages Schema (Organization)

OrganizationMessages.xsd 4.4

Organization Service Web-service Definition Language (WSDL) File (Organization)

OrganizationService.wsdl 4.4

Priority Web-service Definition Language (WSDL) File (Priority)

Priority.wsdl 4.4

Priority Message Schema (Priority) PriorityMessages.xsd 4.4

Priority Service Web-service Definition Language (WSDL) File (Priority)

PriorityService.wsdl 4.4

AEDP-19


Request Web-service Definition Language (WSDL) File (Request)

Request.wsdl 4.4

Request Messages Schema (Request) RequestMessages.xsd 4.4

Request Service Web-service Definition Language (WSDL) File (Request)

RequestService.wsdl 4.4

Requirement Web-service Definition Language (WSDL) File (Requirement)

Requirement.wsdl 4.4

Requirement Messages Schema (Requirement)

RequirementMessages.xsd 4.4

Requirement Service Service Web-service Definition Language (WSDL) File (Requirement)

RequirementService.wsdl 4.4

Core Service Web-service Definition Language (WSDL) File

services.wsdl 4.4

Request for Information Messages Schema (Request)

RFIMessages.xsd 4.4

Structured Product Service SPS++ Web-service Definition Language (WSDL) File (SPSPlusPlus)

SPSPlusPlus.wsdl 4.4

Structured Product Service SPS++ Messages Schema (SPSPlusPlus)

SPSPlusPlusMessages.xsd 4.4

Structured Product Service SPS++ Service Web-service Definition Language (WSDL) File (SPSPlusPlus)

SPSPlusPlusService.wsdl 4.4

Structured Product Service SPS ++ Replication Service Web-service Definition Language (WSDL) File (SPSReplication)

SPSReplicationService.wsdl 4.4

Synchronization Schema Sync.xsd 4.4

Tasking Web-service Definition Language (WSDL) file (Tasking)

Tasking.wsdl 4.4

Tasking Messages Schema (Tasking) TaskingMessages.xsd 4.4

Tasking Service Web-service Definition Language (WSDL) file (Tasking)

TaskingService.wsdl 4.4

ANNEX A TO

AEDP-19

A-1 Edition A Version 1

A

ANNEX A CORE SERVICES INTERFACES

TABLE OF CONTENT

Annex A CORE SERVICES INTERFACES ........................................................ A-1

A-1 PURPOSE ................................................................................................ A-7

A-2 PUB-SUB SERVICE (WS-Notification) ..................................................... A-7

A-3 SIMPLE PERSISTANCE AS A SERVICE (SPS++) SERVICE ................. A-9

A-3.1 Terminology ........................................................................................ A-9

A-3.2 SPS++ Service Overview ................................................................. A-11

A-3.3 SPS++ Service Description .............................................................. A-11

A-3.4 SPS++ Service Interactions .............................................................. A-11

A-3.5 SPS++ Service provider profiles ....................................................... A-12

A-3.6 SPS++ Service Implementation Requirements ................................ A-13

A-3.7 SPS++ Service Contract ................................................................... A-13

A-3.7.1 SPS++ Service Contract Overview ................................................... A-13

A-3.7.2 Service Operations ........................................................................... A-15

A-3.7.3 Core Interface ................................................................................... A-16

A-3.7.3.1 getCapabilities .................................................................................. A-16

A-3.7.4 SPSPlusPlusDomain Interface ......................................................... A-17

A-3.7.4.1 Get ................................................................................................... A-17

A-3.7.4.2 Put ................................................................................................... A-18

A-3.7.4.3 markVersionAsDead ......................................................................... A-20

A-3.7.4.4 getCurrentVersions........................................................................... A-22

A-3.7.4.5 getVersionTree ................................................................................. A-23

A-3.7.5 SPSPlusPlusDomain Interface Constraints ...................................... A-24

A-3.7.6 LocalConsistency Interface .............................................................. A-24

A-3.7.6.1 getStartingDate ................................................................................ A-24

ANNEX A TO

AEDP-19


A-3.7.6.2 getCurrentState ................................................................................ A-25

A-3.7.6.3 getEventsBetween............................................................................ A-26

A-3.7.7 LocalConsistency Interface Constraints ........................................... A-28

A-3.7.8 Service Behaviour Model .................................................................. A-28

A-3.7.8.1 Notification Broker Interface ............................................................. A-28

A-3.7.8.1.1 Topic ................................................................................................. A-29

A-3.7.8.1.2 Notification for new content .............................................................. A-29

A-3.7.8.1.3 Notification for concurrent modification ............................................. A-29

A-3.7.8.2 Replication Service Interface ............................................................ A-29

A-3.7.8.2.1 Service Namespace ......................................................................... A-30

A-3.7.8.2.2 Service Interface............................................................................... A-30

A-3.7.8.2.3 Replication Entity Payload Body ....................................................... A-31

A-3.7.8.2.4 Replication Entity Payload Metadata ................................................ A-31

A-3.7.8.2.5 WS transfer wrapper ......................................................................... A-32

A-3.7.8.2.6 Exceptions ........................................................................................ A-32

A-3.7.8.2.7 Non-functional Requirements ........................................................... A-33

A-3.7.8.3 Inbound And Outbound Queues ....................................................... A-33

A-3.7.8.3.1 Local Write Actions ........................................................................... A-34

A-3.7.8.3.2 Replication amongst SPS++ Instances ............................................ A-35

A-3.7.8.3.3 Handling Inbound Replication queue messages .............................. A-36

A-3.7.8.3.4 Handling outbound replication queue messages .............................. A-37

A-3.7.8.3.5 Handling outbound notification queue messages ............................. A-38

A-3.7.9 Non-functional Requirements ........................................................... A-38

A-3.8 Service XML Artefacts ...................................................................... A-39

A-3.8.1 Message Types ................................................................................ A-39

A-3.8.1.1 SPSPlusPlusDomain Interface ......................................................... A-39

A-3.8.1.1.1 Tree Node ........................................................................................ A-41

A-3.8.1.1.2 Security Type ................................................................................... A-41

A-3.8.1.2 Notification Broker Interface ............................................................. A-41

A-3.8.1.3 SPSPlusPlus replication service interface ........................................ A-44

A-3.8.1.3.1 MAJIICReplicationEntityPayload ...................................................... A-44

ANNEX A TO

AEDP-19


A-3.8.2 Service Interface............................................................................... A-45

A-3.8.2.1 SPSPlusPlusDomain Interface Service WSDL ................................. A-45

A-3.8.2.2 Notification Broker Interface Service WSDL ..................................... A-45

A-3.8.2.3 SPSPlusPlusReplication Interface Service WSDL ........................... A-45

A-3.8.3 Entity Version and Version Trees ..................................................... A-45

A-3.8.4 “Dead” branches ............................................................................... A-46

A-3.8.5 Version tree set of an entityID .......................................................... A-46

A-3.8.6 Current versions of an entity ............................................................. A-47

A-3.8.7 Conflict occurrence and conflict resolution ....................................... A-47

A-3.8.8 Special cases to consider ................................................................. A-48

A-3.9 Joining SPS ...................................................................................... A-51

A-3.9.1 Background ...................................................................................... A-51

A-3.9.1.1 Synchronisation ................................................................................ A-51

A-3.9.1.2 Initial Assumptions and Restrictions ................................................. A-51

A-3.9.2 Requirements to Support the Joining SPS++ Scenario .................... A-52

A-3.9.2.1 Creation of Synchronisation Data File .............................................. A-52

A-3.9.2.2 Ingestion of Synchronisation Data File ............................................. A-53

A-3.9.3 Joiners Process ................................................................................ A-53

A-3.9.4 Replication Topology ........................................................................ A-54

A-3.9.4.1 MOM Routing Background ............................................................... A-55

A-3.9.4.2 SPS++ Replication Routing .............................................................. A-56

A-3.9.4.2.1 Receive Side .................................................................................... A-56

A-3.9.4.2.2 Send Side ......................................................................................... A-56

A-3.9.4.2.3 Routings ........................................................................................... A-57

A-3.9.4.2.4 Replication Modes ............................................................................ A-57

A-4 ENTERPRISE EVENT RELAY SERVICE (E2RS) SERVICE ................. A-58

A-4.1 Core Definitions ................................................................................ A-58

A-4.1.1 Enterprise event ............................................................................... A-58

A-4.1.2 Node ................................................................................................. A-58

A-4.1.3 Notification Broker ............................................................................ A-58

A-4.2 Interface Description ......................................................................... A-59

ANNEX A TO

AEDP-19


A-4.2.1 Interfaces .......................................................................................... A-59

A-4.2.2 NotificationConsumer Interface ........................................................ A-60

A-4.2.3 NotificationProducer Interface .......................................................... A-60

A-4.2.4 SubscriptionManager Interface ......................................................... A-60

A-4.3 Non-Functional Requirements .......................................................... A-61

A-4.3.1 Volume [INFORMATIVE] .................................................................. A-61

A-4.4 Service Behaviour ............................................................................ A-61

A-4.4.1 Persistence ....................................................................................... A-61

A-4.4.2 Queueing .......................................................................................... A-61

A-4.4.3 Subscription ...................................................................................... A-61

A-4.4.4 Relay ................................................................................................ A-61

A-4.5 Client Behaviour ............................................................................... A-62

A-4.5.1 Enterprise Event Interactions ........................................................... A-62

A-4.5.1.1 Full Dialect for Subscriptions ............................................................ A-63

A-4.5.1.2 Full Dialect for Notifications .............................................................. A-64

A-5 SOA SERVICES PROFILE ..................................................................... A-66

A-5.1 CES Specification Profiles in Use ..................................................... A-66

A-5.2 Non-Security specific CES Specifications in Use ............................. A-66

A-5.2.1 Document/Literal Wrapped Pattern .................................................. A-67

A-5.3 Security Specific Profile in Use ......................................................... A-68

A-5.3.1 Username Token Policy for STANAG 4559 ...................................... A-68

A-5.3.1.1 Username Tokens ............................................................................ A-68

A-5.3.1.2 WS-Policy ......................................................................................... A-68

A-5.4 Specifications outside the CES Specification in Use ........................ A-69

ANNEX A TO

AEDP-19


Tables

Table A-1 SPS++ Terminology ........................................................................... A-9

Table A-2 SPS++ Service Overview ................................................................. A-14

Table A-3 Specific Returns from getCapabilities ............................................... A-16

Table A-4 Compliance level mapping ............................................................... A-43

Table A-5 Non-Security Specific Standards specified by ADatP-34(H) ............. A-66

Table A-6 Security Specific Standards specified by ADatP-34(H) .................... A-68

Table A-7 Standards not specified by ADatP-34(H) .......................................... A-69

Figures

Figure A-1 Architectural components interaction with the SPS++ ...................... A-12

Figure A-2 SPS++ Service Interface .................................................................. A-14

Figure A-3 Core Interface ................................................................................... A-15

Figure A-4 SPSPlusPlusDomain Interface ......................................................... A-15

Figure A-5 LocalConsistency Interface .............................................................. A-15

Figure A-6 MOM Interface to SPS++ ................................................................. A-30

Figure A-7 Inbound and outbound queues ......................................................... A-34

Figure A-8 Local write actions ............................................................................ A-35

Figure A-9 Replication amongst SPS++ instances ............................................. A-36

Figure A-10 Handling inbound replication queue messages ................................ A-37

Figure A-11 Handling outbound replication queue messages .............................. A-37

Figure A-12 Handling outbound notification queue messages ............................. A-38

Figure A-13 SPS++ service interface messages .................................................. A-40

ANNEX A TO

AEDP-19


Figure A-14 SecurityType .................................................................................... A-41

Figure A-15 MAJIICNotificationEnvelopeType ..................................................... A-42

Figure A-16 SPS++ event types ........................................................................... A-43

Figure A-17 Example SOAP replication payload of a CXP .................................. A-44

Figure A-18 Example of Object Entity Versioning ................................................ A-45

Figure A-19 Example of replacedVersionID ......................................................... A-46

Figure A-20 Example of conflicting versions ........................................................ A-47

Figure A-21 Example of conflict resolution ........................................................... A-48

Figure A-22 Special case scenario 1 .................................................................... A-49



Figure A-25 SPS replication within a COI / security domain ................................ A-54

Figure A-26 SPS replication across COI / Security domain ................................. A-55

Figure A-27 SPS replication across COI / security domain .................................. A-56

Figure A-28 E2RS component diagram ............................................................... A-59

Figure A-29 E2RS WS-Notification interfaces ...................................................... A-60

ANNEX A TO

AEDP-19


A-1 PURPOSE

1. The purpose of this Annex A is to specify the AEDP-19 Core Services.

2. The following services are specified:

Pub-Sub Service (WS-Notification)

Simple Persistence as a Service (SPS++) Service

Enterprise Event Relay Service (E2RS) Service.

3. This Annex provides also the specification for the underlying service-oriented architecture (SOA) services profile.

A-2 PUB-SUB SERVICE (WS-Notification)

1. The Pub-Sub Service SHALL provide a brokered publish and subscribe infrastructure for management of bottom up web service interactions. The Pub-Sub Service SHALL implement a web service notification broker in accordance with:

a) WS-BaseNotification 1.3 [OASIS WS-BaseNotification 1.3, 2006] b) WS-BrokeredNotification 1.3 [OASIS WS-BrokeredNotification 1.3,

2006] c) WS-Topics 1.3 [OASIS WS-Topics 1.3, 2006].

2. The NotificationConsumer SHALL receive the Notification data as a Notify message, i.e. the non-raw, notification form. This provides a well specified mechanism by which the NotificationProducer can supply additional information defined by WS-BaseNotification (such as the Topic) in addition to the application-specific Notification content. It also allows the NotificationConsumer to receive a wide range of Notifications without having to explicitly provide support for each one in its WSDL. This form of Notification also allows a batch of several Notifications to be combined into a single physical message.

3. Service implementers SHALL use the Full Topic Dialect [OASIS WS-Topics 1.3, 2006].

a) INFORMATIVE: The key enablers provided by this grammar include: (1) This dialect allows TopicExpressions that identify more than one

Topic (possibly from multiple Topic Namespaces); (2) This dialect supports the use of Topic Trees and the organization

of topics into Topic; (3) It permits the building of inter-broker subscription meshes because

local and remote traffic can be differentiated.

ANNEX A TO

AEDP-19


b) INFORMATIVE: Slashes in the Topic Expression (1) ‘//’ has a specific meaning and as [OASIS WS-Topics 1.3, 2006]

indicates: the Full Topic Dialect is a subset of XPATH which means that ‘//’ is a wild card meaning include all descendents. When this is used with further topics after the ‘//’ it has no effect other than being a matter of syntactic style.

(2) ‘//’ has no meaning when publishing a notification – it is only permitted to publish to one, and only one, full topic. Of course, using wildcards, one can subscribe to more than one topic.

4. The MAJIICNotificationEnvelope SHALL be used for all event notifications sent by providers. Its schema is defined as MAJIICNotification.xsd.

ANNEX A TO

AEDP-19


A-3 SIMPLE PERSISTANCE AS A SERVICE (SPS++) SERVICE

The purpose of this section is to specify the Simple Persistence as a Service (SPS++) Interface with regard to:

the provided and required interfaces, describing the functional capabilities of each and including inputs, outputs, pre-conditions, post-conditions and any exception behaviours;

any other behaviours exhibited by the service, knowledge of which will be required by consumers;

the protocols needed to interact with the service;

the constraints imposed by the service;

qualities and other non-functional requirement aspects of the service and policies for using the service.

A-3.1 Terminology

Table A-1 SPS++ Terminology

Terminology Description

Entity From [Vaughn Vernon, Implementing Domain-Driven Design, 2013]: “We design a domain concept as an Entity when we care about its individuality, when distinguishing it from all other objects in a system is a mandatory constraint. An Entity is a unique thing and is capable of being changed continuously over a long period of time. Changes may be so extensive that the object might seem much different from what it once was. Yet, it is the same object by identity.”

Service Provider

A service that produces data for other services.

Service Consumer

A service or application that calls other services in order to retrieve data.

Node A Node is defined as being any entity which is separated from other entities by the need to replicate. Typically a node might, but does not have to, map to a local area network (LAN). Similarly, replication will typically be conducted across a WAN (wide-area network).

Notification A one-way message sent to indicate that an event has occurred.

It is represented as an XML fragment with a namespace qualified QName

ANNEX A TO

AEDP-19


Terminology Description

and a type defined using a schema.

It contains the application specific payload.

Topic Categorization that can be attached to a notification. Topics are used to determine which of the subscribed consumers should receive the notification.

Storage State Storage State in this context can be described by combining wikipedia on persistence1, “In computer science, persistence refers to the characteristic of state that outlives the process that created it.” and wikipedia on state2, “In computer science and automata theory, the state of a digital logic circuit or computer program is a technical term for all the stored information, at a given instant in time, to which the circuit or program has access”

Concurrent Modification

Concurrent modification refers to a write-write-conflict where two or more independent processes attempt to write, at the same time (concurrently) to the same version of an entity.

Core Services From [NATO C3 Classification Taxonomy, 2015] “The Core Services provide generic, Community of Interest (COI)-independent, technical functionality to implement service-based environments using infrastructure, architectural and enabling building blocks. Core Services provide these building blocks so that these generic, common capabilities do not have to be implemented by individual applications or other services.”

1 https://en.wikipedia.org/wiki/Persistence_(computer_science)

2 https://en.wikipedia.org/wiki/State_(computer_science)

ANNEX A TO

AEDP-19


A-3.2 SPS++ Service Overview

The SPS++ service resides in the Core Services Layer, see Figure 2-1.

A-3.3 SPS++ Service Description

1. The purpose of the SPS++ is the storage and dissemination of the business entities produced and consumed within workflows. The business entities are XML artefacts with a defined schema. The SPS++ itself is defined to be content agnostic so it can be used for arbitrary business entities and a range of workflows. Examples of types of business entities are the request for information (RFI), order of battle (ORBAT), task, intelligence requests (IR) etc.

2. Through the application of choreographies, the interactions of the local service consumers should prevent concurrent modifications on the same business entity and keep the complete set of business entities in a common perception of business entity state across the entire enterprise. As different scenarios (such as network failure, communication latency, etc.) can lead to choreography participants perceiving different states of the business entities, each of them could follow a different path in the choreography. To resolve these issues, the SPS++ also provides means to correct this branching in the choreography. The responsibility of resolving these cases lies with the SPS++ service consumer, as the SPS++ has no understanding of the stored content and is unable to take the necessary actions.

3. A business entity is identified by a universally unique identifier that is generated by the service consumer. Each version of the business entity is then identified by another universally unique identifier which differentiates the versions of a business entity from each other.

A-3.4 SPS++ Service Interactions

1. Figure A-1 depicts the dependencies of the different architectural components.

2. The SPS++ service interface is used by an arbitrary number of services from the next higher layer (the component in the diagram is a placeholder for a service from the next higher layer).

3. The SPS++ uses the notification broker to send events about new content to the services in the next higher layer; it is thus decoupled from both the number of receivers and the specific instances. These events are then provided.

4. The simplification (“WS-Notification Reception Interface”) made in Figure A-1 is for the sake of easier reading of the diagram. WS notification defines a registration interface for reception endpoints hosted by the higher layer services, a detail which is not shown here.

ANNEX A TO

AEDP-19


Figure A-1 Architectural components interaction with the SPS++

5. Dissemination of business entities across all the SPS++ instances is done through a message oriented middleware (MOM) ensuring that every SPS++ instance contains the same set of business entity versions. As the design of the concurrency mechanism favors availability and partition tolerance, there is no guarantee of global consistency. However, there is still a guarantee of consistency over time and the event based interaction with the higher layer services renders the delays introduced by replication invisible / indistinguishable from local interaction.

A-3.5 SPS++ Service provider profiles

1. This SPS++ specification defines three possible levels of compliance for service providers:

a) Full compliance with the entire specification except the LocalConsistencyInterface (refer to A-3.7.6) is not supported (called “compliance level 1”)

b) Full compliance with the entire specification except the getEventsBetween operation of the LocalConsistencyInterface not being supported (called “compliance level 2”)

c) Full compliance with the entire specification (called “compliance level 3”)

2. As the compliance levels in the specification build upon each other, a service provider being rated with “compliance level 3” provides all available operational

ANNEX A TO

AEDP-19


capabilities as defined for “compliance level 2”. The same is true for “compliance level 2” with regards to “compliance level 1”.

3. A SPS++ service provider SHOULD provide “compliance level 3”, however lower levels of compliance could still be operationally sufficient in a specific deployment.

4. Unless otherwise specified for specific sections of A-3, a SPS++ service provider SHALL at least provide “compliance level 1”.

A-3.6 SPS++ Service Implementation Requirements

1. All interfaces provided by the SPS++ service interface MUST be bound with the SOAP over HTTP binding using the document/literal-wrapped style, as described in A-5 SOA SERVICES PROFILE.

2. All security aspects of the SPS++ are expressed in accordance with 2.6 SECURITY CONSIDERATIONS. SPS++ implementations SHALL provide a username in the SOAP header.

A-3.7 SPS++ Service Contract

A-3.7.1 SPS++ Service Contract Overview

1. The SPS++ service provides and consumes a set of interfaces.

2. Firstly, there are two service interfaces consumed and/or provided by the SPS++ defined by external open standards based communities:

a) One being the WS transfer [W3C WS transfer 1.0, 2011] that is both provided and consumed. It is used for replication between SPS++.

b) The other being WS notification [OASIS WS-BaseNotification 1.3, 2006] that is consumed by the SPS++. It is used to inform higher layer services about content stored to the SPS++ instance (see A-3.7.8.1).

3. Secondly, the SPS++ service interface provides a SOAP-based web services interface (see A-3.8.2.1 and A-3.8.2.3).

4. The SPS++ service interface is derived from the following three interfaces:

a) The CoreInterface – as provided by all STANAG 4559 service interfaces and described in AEDP-17 Annex D NSIL WEB SERVICE CORE INTERFACE.

b) The SPSPlusPlusDomainInterface – used by the next higher layer services for SPS++ domain-specific interaction (refer to A-3.7.4).

ANNEX A TO

AEDP-19


c) The LocalConsistencyInterface – used by the next higher layer services to achieve consistency of their perceived business (processing) state (refer to A-3.7.6).

Table A-2 SPS++ Service Overview

Service Name SPSPlusPlus Service

Service Layer Core Services Layer

Service Namespace http://srvc/nato/majiic/services/SPSPlusPlus/SPSPlusPlusService/

Service Version 4.4

5. Figure A-2 below illustrates the SPS++ interfaces (defined by this AEDP-19 and not the externally defined interfaces mentioned above) offered by the SPS++ Web Services Description Language (WSDL) service contract.

Figure A-2 SPS++ Service Interface

ANNEX A TO

AEDP-19


A-3.7.2 Service Operations

1. The following tables include: all the operations for each interface of the service interface; compliance level (see A-3.5); and a reference to the appropriate chapter in the document.

2. Please note that a field being greyed out does not mean that the service provider has not implemented the operation at all. All operations can be invoked from the service consumer side, however the result of the invocation depends on the compliance level of the service provider.

Interface Operation Compliance Level Reference

1 2 3

Core getCapabilities X X X A-3.7.3.1

Figure A-3 Core Interface


1 2 3

SPSPlusPlusDomain

get X X X A-3.7.4.1

put X X X A-3.7.4.2

markVersionAsDead X X X A-3.7.4.3

getCurrentVersions X X X A-3.7.4.4

getVersionTrees X X X A-3.7.4.5

Figure A-4 SPSPlusPlusDomain Interface


1 2 3

LocalConsistency

getStartingDate X X A-3.7.6.1

getCurrentState X X A-3.7.6.2

getEventsBetween X A-3.7.6.3

Figure A-5 LocalConsistency Interface

ANNEX A TO

AEDP-19


A-3.7.3 Core Interface

1. The Core interface provides the common operations for all STANAG 4559 SOA services.

2. Available operations are described in the sections below.

3. All operations in this interface are secured by the mechanism described in 2.6 SECURITY CONSIDERATIONS. As a consequence, a service SHALL throw an “AccessDenied” exception if it does not receive sufficient credentials.

4. All other exceptions MUST result in a “ReadFailed” exception to be sent to the consumer.

A-3.7.3.1 getCapabilities

This operation inherits from Core Interface, see AEDP-17 Annex D NSIL WEB SERVICE CORE INTERFACE. Table A-3 below defines the return values specific to the SPS++ Service.

Table A-3 Specific Returns from getCapabilities

Name GenericValue Class Meaning

notification.topic NotificationTopicValue This value SHALL state the topic on which the accessed service sends notifications.

notification.broker.endpoint TextualValue This value SHALL state the WSDL address used by the service for emitting/subscribing notifications. The value is case sensitive and SHALL be provided in the right case.

Example: ‘http://messageBrokerHost:12345/some/service/path?WSDL’

a) Constraints (1) The list of GenericValues that is returned by the service provider MUST be limited to the values defined in AEDP-17 Annex D NSIL WEB SERVICE CORE INTERFACE combined with the ones defined in Table A-3.

ANNEX A TO

AEDP-19


(2) The entries in Table A-3 MUST be returned in every invocation of the getCapabilities operation. (3) The returned GenericValue MUST use the class and name defined in Table A-3. (4) The returned GenericValue MUST comply with the described usage and MUST NOT add or remove additional information.

b) Exceptions The service provider MUST respond with the ReadFailed

exception (see A-3.7.2) if an internal error prevented retrieval, e.g. through database access issues).

A-3.7.4 SPSPlusPlusDomain Interface

1. The SPS++ Domain interface allows the next higher layer to persist, share and access business entities. In addition the interface allows retrieval of versioning information for business entities that is necessary to resolve concurrent modifications that can occur within workflows or collaborative modification of business entities.

2. The data structures used for communication between service provider and service consumer, which illustrate the variety of messages defined for the SPS++ service interface, are described in A-3.8.1.1.

3. The SPSPlusPlusInterface provides a set of operations for the higher layer services in the local node to persist choreography data.


A-3.7.4.1 Get

This operation consists of a single request/response that is used to retrieve persisted XML artefacts from the SPS++. The entityId and versionId are the values that were previously provided by the SPS++ in notifications.

a) Input

Parameter Type Obligation Description

EntityReference ::entityId

xsd:string Mandatory A universally unique identifier provided by the caller to identify the entity that shall be retrieved.

EntityReference ::versionId

xsd:string Mandatory A universally unique identifier provided by the caller to identify the entity version that shall be retrieved.

ANNEX A TO

AEDP-19


b) Output


get xsd:string Mandatory XML artefact identified by the entityId and versionId passed over in the request.

c) Constraints (1) The EntityReference object which encapsulates both the entityId and the versionId as input for the Get operation request MUST NOT be null. (2) The combination of entityId and versionId MUST be known to the service provider, (3) The entityId provided value (as input to the Get operation request) MUST NOT be null or an empty string. (4) The versionId provided value (as input to the Get operation request) MUST NOT be null or an empty string.

d) Exceptions (1) If the constraints on the content provided by the service consumer stated in c) are not met the service provider MUST send a ReadFailed exception to the service consumer. (2) The service provider MUST also respond with the ReadFailed exception if an internal error prevented retrieval – e.g. database access issues.

A-3.7.4.2 Put

This operation consists of a single request/response that is used to store an XML artefact in the SPS++. The XML artefact is uniquely identified by an entityId and a versionId.

ANNEX A TO

AEDP-19


a) Input






replacedVersion xsd:string Optional The version that the provided XML is based on.

xmlPayload xsd:string Optional The XML artefact to be stored.

security SecurityType Mandatory Indicates the security policy, classification and releasability of the entity to be persisted. The security information covers all parameters of this operation, not just the XML content.

b) Output

None.

c) Constraints

(1) If a Put operation request provides an entityId / versionId combination that is already persisted, the operation invocation MUST return without persisting the provided XML / generating events / replication impacts. (2) The EntityReference object which encapsulates both the entityId and the versionId as input for the Put operation request MUST NOT be null. (3) The entityId provided value (as input to the Put operation request) MUST NOT be null or an empty string. (4) The versionId provided value (as input to the Put operation request) MUST NOT be null or an empty string. (5) For the initial Put operation request for a new entity the replacedVersion MUST be null.

ANNEX A TO

AEDP-19


(6) If a Put operation is used to store a newer version of an entity, the replacedVersionId MUST be a known versionId for the given entityId to the service provider. (7) The XML content (passed as a string in the xmlPayload of the Put operation request) is assumed to be valid according to the schemas defined by higher level services and therefore MUST NOT be validated. (8) The xmlPayload of the Put operation request value MAY be null or an empty string. (9) For the initial Put operation request for a new entity the xmlPayload value SHOULD NOT be null. (10) The security type SHALL NOT be null – as in “no value”. The security type SHALL according to the requirements stated in A-3.8.1.1.2. Further validation such as checking it against the project security instructions (PSI) of the event the service is deployed at SHALL NOT be performed.

d) Exceptions

(1) If the constraints on the content provided by the service consumer stated in c) are not met the service provider MUST send a writeFailed exception to the service consumer. (2) The service provider MUST send a writeFailed exception if the SPS++ cannot persist the XML artefact version. (3) The service provider MUST send a writeFailed exception if an internal error prevented storage, e.g. database access issues.

A-3.7.4.3 markVersionAsDead

1. This operation consists of a single request/response that is a convenience operation that simply puts a new version for an entity that has null – as in “no value” – as XML payload.

2. The value provided as entityId is mapped to the entityId of the corresponding put. The value provided as versionId is mapped to the replacedVersionId. A random ID is generated by the service and mapped to the versionId of the corresponding put operation.

3. The result is that the branch of the entity identified by the versionId is considered ‘dead’ by the service and the versionId no longer shows up in the getCurrentVersions method.

ANNEX A TO

AEDP-19


a) Input






security SecurityType Mandatory Indicates the security policy, classification and releasability of the entity to be persisted. The security information covers all parameters of this operation, not just the XML content.

b) Output

None.

c) Constraints

(1) The constraints from A-3.7.4.1 c) apply to this operation as well. (2) The EntityReference object which encapsulates both the entityID and the versionID as input for the markVersionAsDead operation request MUST NOT be null. (3) The entityId provided value (as input to the markVersionAsDead operation request) MUST NOT be null or an empty string. (4) The versionId provided value (as input to the markVersionAsDead operation request) MUST NOT be null or an empty string. (5) The security type SHALL NOT be null – as in “no value”. The security type SHALL be given according to the requirements stated in A-3.8.1.1.2. Further validation such as checking it against the project security instructions (PSI) of the event the service is deployed at SHALL NOT be performed.

ANNEX A TO

AEDP-19


d) Exceptions

(1) If the constraints on the content provided by the service consumer stated in c) are not met the service provider MUST send a writeFailed exception to the service consumer. (2) The service provider MUST send a writeFailed exception if the SPS++ cannot persist the XML artefact version. (3) The service provider MUST send a writeFailed exception if an internal error prevented storage, e.g. database access issues.

A-3.7.4.4 getCurrentVersions

This operation consists of a single request/response that is used to retrieve all those versionIds that are considered “current” for the provided entityId. For a definition of “current”, see A-3.8.6.

a) Input


entityId xsd:string Mandatory A universally unique identifier provided by the caller to identify the entity that shall be retrieved.

b) Output


currentVersions xsd:string array

Mandatory An unordered array of versionIds that are considered “current” by the service

c) Constraints

(1) The entityId MUST be known to the service provider. (2) The entityId provided value (as input to the getCurrentVersions operation request) MUST NOT be null or an empty string.

ANNEX A TO

AEDP-19


d) Exceptions

(1) If the constraints on the content provided by the service consumer stated in c) are not met the service provider MUST send a ReadFailed exception to the service consumer. (2) The service provider MUST send a ReadFailed exception if an internal error prevented retrieval, e.g. database access issues.

A-3.7.4.5 getVersionTree

This operation consists of a single request/response that is used to retrieve all the versions known to the SPS++ service in the form of a set of trees. See A-3.8.3 for more information on versioning.

a) Input


entityId xsd:string Mandatory A universally unique identifier provided by the caller to identify the entity that shall be retrieved.

b) Output


versionTrees TreeNode array

Mandatory An unordered array of trees formed by the versionIds and replacedVersionIds stored by the SPS++ service

c) Constraints

(1) The entityId MUST be known to the service provider. (2) The entityId provided value (as input to the getCurrentVersions operation request) MUST NOT be null or an empty string.

d) Exceptions

(1) If the constraints stated in c) are not met the service provider MUST send a ReadFailed exception to the service consumer. (2) The service provider MUST send a ReadFailed exception if an internal error prevented retrieval, e.g. database access issues.

ANNEX A TO

AEDP-19


A-3.7.5 SPSPlusPlusDomain Interface Constraints

Parameters of operations where IDs can be passed SHALL NOT permit the usage of any wildcards. All characters SHALL be interpreted as actual text that is part of the ID.

A-3.7.6 LocalConsistency Interface

1. Due to the unreliable nature of the WS notification implementation configuration several scenarios can result in the next higher layer services receiving only a subset of the events. The LocalConsistency interface is intended to overcome this issue by allowing higher layer services to retrieve the events / event ranges identified as missing.

2. The approach taken to resolve the local consistency issue is by labeling all events emitted by the SPS++ with a storage state label before the message was queued for transmission and a storage state label that was reached through queueing the message. This labeling allows the identification of missed events / event ranges and is described further in A-3.7.6.3.

3. The LocalConsistency interface provides a set of operations for the next higher layer to retrieve missed events.


5. All other exceptions MUST result in a “ReadFailed” exception to be sent to the consumer.

A-3.7.6.1 getStartingDate

1. This operation consists of a single request/response that returns the storage state label of the SPS++ when it was initially deployed and had no content stored.

2. When a service consumer from the next higher layer requires to retrieve the events since the SPS++ was deployed using the getEventsBetween operation (see A-3.7.6.3), this label value is used as the fromState parameter value in the getEventsBetween operation request.

a) Input

None.

ANNEX A TO

AEDP-19


b) Output


state xsd:string Mandatory The storage state label of the SPS++ when it was initially deployed and had no content stored.

c) Constraints

None.

d) Exceptions

The service provider MUST send a “ReadFailed” exception if an internal error occurs.

A-3.7.6.2 getCurrentState

1. This operation consists of a single request/response that returns the storage state label that the SPS++ currently has.

2. Note that the current state value that the SPS++ has does not change when messages are actually transmitted, the only event that causes a change in the value returned is the queuing of messages for the next higher service layer.

a) Input

As the interface is designed for later usage by services that emit messages on multiple topics, it takes the notification topic as an input parameter. For the SPS++ the topic parameter value in the operation request will be the same value in all invocation due to the constraints of its usage described below.


topic notificationTopicValue Mandatory The notification topic returned by the CoreInterface::getCapabilities (see A-3.7.3.1) operation.

ANNEX A TO

AEDP-19


b) Output


state xsd:string Mandatory The storage state the SPS++ currently has.

c) Constraints

The topic parameter value in the operation request SHALL be equal to the notification topic returned by the CoreInterface::getCapabilities (see A-3.7.3.1) operation.

d) Exceptions

If the constraints on the content provided by the service consumer stated in c) are not met, the service provider MUST send a “ReadFailed” exception to the service consumer.

A-3.7.6.3 getEventsBetween

1. This operation consists of a single request/ response that returns a sequence of events as they had been queued for transmission to the next higher layer services.

2. If the last message “afterState” is different from the to parameter value, the service consumer knows more events than the returned ones have been missed3. Therefore the service consumer can perform more invocations of this operation with new requested ranges until the complete range of missed messages has been retrieved.

a) Input


topic notificationTopicValue Mandatory The notification topic returned by the CoreInterface::getCapabilities (see A-3.7.3.1) operation.

from xsd:string Mandatory This value indicates the storage state the SPS++ was in before the message that was missed by the next higher layer service.

3 This can occur if the service consumer specifies a maxCount that is less than the number of missed messages.

ANNEX A TO

AEDP-19


to xsd:string Mandatory This value indicates the storage state the SPS++ was in with the last message that was missed by the next higher layer service.

maxCount xsd:long Mandatory This value indicates the maximum amount of messages the service consumer will receive as the result of a valid operation invocation.

The value MUST be larger than 0. If the value is less, the SPS++ SHALL raise a ReadFailed exception to the service consumer.

The service consumer may receive less messages if there are less messages for the storage state range requested or if the service provider limits the number of returned messages to prevent “denial of service” like requests.

b) Output


event Sequence of MAJIICNotificationEnvelopeType

Optional Sequence of messages.

c) Constraints

(1) The from parameter value in the operation request MUST be one of the storage states the SPS++ was in throughout its deployment time. (2) The to parameter value in the operation request MUST be one of the storage states the SPS++ was in throughout its deployment time. (3) The from parameter value SHALL be a storage state before or equal to the to parameter value. (4) The maxCount parameter value of the operation request MUST be larger than 0. (5) The event result value of the operation response MUST be empty if the from and to parameter values are the same.

ANNEX A TO

AEDP-19


(6) In all other cases where the from and to parameter values are not the same, the event parameter value MUST contain an ordered sequence of messages that MUST contain at least one message. (7) In the case that more than one event is returned the first message MUST have the “beforeState” equal to the from parameter value. All following messages will have the “beforeState” equal to the “afterState” of the preceding messages. (8) In the case the returned sequence of messages contains the full range of messages described by the from and to parameter values, the last message MUST have the “afterState” equal to the to parameter value.

d) Exceptions

If the constraints on the content provided by the service consumer stated in c) are not met the service provider MUST send a ReadFailed exception to the service consumer.

A-3.7.7 LocalConsistency Interface Constraints

1. Parameters of operations where IDs can be passed SHALL NOT permit the usage of any wildcards. All characters SHALL be interpreted as actual text that is part of the ID.

2. A Compliance Level 3 service provider SHALL implement all operations of the LocalConsistency interface.

3. A Compliance Level 2 service provider SHALL implement the getStartingDate and getCurrentState operations of the LocalConsistency interface. The service provider SHALL send a ReadFailed exception to the service consumer when the getEventsBetween operation is invoked.

4. A Compliance Level 1 service provider SHALL send a ReadFailed exception to the service consumer when any LocalConsistency interface operation is invoked.

A-3.7.8 Service Behaviour Model

A-3.7.8.1 Notification Broker Interface

1. The SPS++ service provider consumes the [OASIS WS-BrokeredNotification 1.3, 2006 ] Notify method of the NotificationBroker interface to communicate with the local notification broker. The intent of this usage is to inform the higher layer services (with the use of notifications) about new content that has become available in the SPS++ service. These notifications (see A-3.8.1.2) will be raised through the Pub-Sub Service (WS-Notification), which is implemented through [OASIS WS-

ANNEX A TO

AEDP-19


BaseNotification 1.3, 2006], [OASIS WS-BrokeredNotification 1.3, 2006 ] and [OASIS WS-Topics 1.3, 2006].

2. Whenever the service provider stored new content, a notification SHALL be emitted to the notification broker. Regarding the special cases of the Put operation of the SPS++ interface and the replication interface for already known combinations of entityID and versionID, no notification is emitted in these cases – as no new content is stored (there is no change to the internal storage state of the SPS++).

3. Whenever the service provider stored new content, it SHALL check if there is another versionID for the given entityID that replaces the same versionID as the storage operation it just performed. If this is the case, the service provider SHALL emit a notification about this incident. This case is also known as concurrent modification.

4. The service implementation SHALL employ a persisted queue towards the notification broker for all messages generated by the service.

A-3.7.8.1.1 Topic

Under [OASIS WS-BaseNotification 1.3, 2006] notifications are posted to topics, see [OASIS WS-Topics 1.3, 2006]. The topic on which the service publishes events SHALL be communicated to the service consumer by the value from the parameter named notification.topic returned by the getCapabilities operation of the SPS++ Core interface, see A-3.7.2).

A-3.7.8.1.2 Notification for new content

The service provider SHALL use the SPSStorageEvent data structure (see A-3.8.1.2). The entityID, versionID and replacedVersionID SHALL be filled according to the values of the version of the persisted business entity.

A-3.7.8.1.3 Notification for concurrent modification

The service provider SHALL use the SPSConcurrentModificationEvent data structure (see A-3.8.1.2). The entityID SHALL be filled with the entityID of the persisted content. The “parentID” shall be filled according to the values of the version of the persisted business entity.

A-3.7.8.2 Replication Service Interface

Whenever an artefact is stored into the SPS++ via the SPSPlusPlusDomain interface Put operation, a set of messages are generated by the SPS++ and sent to the local Pub-Sub instance. As for the Pub-Sub interface, the SPS++ instance shall queue the messages for later transmission if the local Pub-Sub instance is currently not accessible.

ANNEX A TO

AEDP-19


Figure A-6 MOM Interface to SPS++

A-3.7.8.2.1 Service Namespace

http://srvc/nato/majiic/services/SPSReplication/SPSReplicationService/

A-3.7.8.2.2 Service Interface

1. All of the web service specific specification is captured in a replication Web Service Description Language (WSDL) file and the attendant WSDLs and XSDs that it references, see 2.7 AEDP-19 .

2. The SPS++ shall provide an incoming interface compliant with the following specifications:

a) Replication Entity Payload (see A-3.8.1.3.1) b) WS-Transfer c) SOAP 1.1 d) WSDL 1.1 e) HTTP 1.1.

3. Whilst WS transfer [W3C WS transfer 1.0, 2011] defines other verbs (GET and DELETE) the replication requirement is for implementation of the PUT verb only. The input for the Put operation is specified in A-3.7.8.2.3 and A-3.7.8.2.4, respectively, and A-3.7.8.2.5.

4. Nearly all of the SPS++ replication requirements fall in to the WS transfer and interface specifications detailed in this section. However a few others remain:

a) SPS++ implementations SHALL be able to dispatch messages to zero, one or more other remote SPS++ instances;

b) SPS++ implementations SHALL provide runtime dynamic configurability of the remote SPS++ endpoints receiving outgoing messages;

c) SPS++ implementations SHALL be able to receive messages from zero, one or more other remote SPS++ instances.

ANNEX A TO

AEDP-19


5. Note that adding a remote endpoint when the local SPS++ already has some business entities stored implies that all these business entities SHALL be queued for replication as if they were stored after the remote endpoint is added.

A-3.7.8.2.3 Replication Entity Payload Body

The following referenced types are defined in the namespace http://srvc/nato/majiic/services/SPSReplication/SPSReplicationMessages/:

a) The payload of the replication message shall be captured in the content of a single XML entity element of type Entity.

b) The content of this entity shall be plain text and shall be identical to the entity received through the PUT client interface.

c) For encoding purposes the content shall be wrapped in an XML CDATA section or it shall be XML escaped text.

d) SPS++ implementations shall place the Entity element in the SOAP body as shown in the sample PUT request above.

A-3.7.8.2.4 Replication Entity Payload Metadata

1. There are four additional metadata attributes attendant to each payload:

a) EntityID: the identifier of the entity received through the client interface PUT method;

b) VersionID: the versionIdentifier of the entity received through the client interface PUT method;

c) ReplacedVersionID: the replaced versionIdentifier of the entity received through the client interface PUT method;

d) SecurityType: the security information of the entity received through the client interface PUT method.

2. The following referenced types are defined in the namespace http://srvc/nato/majiic/services/SPSReplication/SPSReplicationMessages/:

a) SPS++ implementations shall place the entityId received through the client interface PUT method in the SOAP header of type EntityID;

b) SPS++ implementations shall place the versionId received through the client interface PUT method in the SOAP header of type VersionID;

ANNEX A TO

AEDP-19


c) SPS++ implementations shall place the replacedVersionId received through the client interface PUT method in the SOAP header of type ReplacedVersionID.

A-3.7.8.2.5 WS transfer wrapper

WS transfer is a minimal specification with a number of requirements in scope here:

a) the request-response MEP (Message Exchange Pattern); the WS addressing requirements outlined below are consistent with the usage of the request-response MEP;

b) the usage of WS addressing in the PUT request message:

urn:#Put

soap://majiic.mnb.replication/sender

uuid:192031b1-22da-4b74-8d30-

d88292f93334

soap://majiic.acc.replication/sender

c) the usage of WS addressing in the PUT response message:

urn:#Put

uuid:192031b1-22da-4b74-8d30-

d88292f93334

soap://majiic.mnb.replication/sender

uuid:936fa6c4-68bd-4df2-bffe-

88f491a95a28

d) Regarding the use of optional return message types in the SOAP body. These are not required at this time for the replication PUT.

A-3.7.8.2.6 Exceptions

1. In addition to the WS addressing exceptions utilized by the WS transfer specification this specification reuses the writeFailed exception from the “urn:nato:majiic:common:isrcommon” namespace.

2. If an SPS++ implementation is unable to persist the incoming Entity it MUST respond with the writeFailed exception.

ANNEX A TO

AEDP-19


A-3.7.8.2.7 Non-functional Requirements

1. With respect to MOM replication a number of non-functional requirements (NFR) behaviours are considered to be mandatory and SHALL be implemented by SPS++ service providers:

a) SPS++ implementations SHALL be able to provide a throughput of up to 64,850 messages per day;

b) SPS++ implementations SHALL use an outgoing asynchronous pattern, i.e. loosely coupled dispatch of the entity messages outgoing to other SPS++ instances;

c) SPS++ implementations SHALL use an incoming asynchronous pattern, i.e. loosely coupled ingestion of the entity messages incoming from other SPS++ instances.

2. The last two items are described in more detail in A-3.7.8.3.

A-3.7.8.3 Inbound And Outbound Queues

1. The SPS++ features a set of queues that serve as decoupling points with other systems. The first queue is the inbound replication queue. This queue holds replicated business entities received from other SPS++ instances until they have been stored and thus made available in the local service stack. The second queue is the notification queue that holds notifications until they could be sent to the notification broker in the local service stack. The last type of queues is the outbound replication queues. They keep business entities until they have been successfully replicated to the respective remote SPS++ instance. Together, the inbound and outbound replication queues build the foundation through which the “consistency over time” is achieved by the SPS++.

2. The replication inbound queue is permitted to be limited in size (it is permitted to reject replication messages from a remote SPS++ instance when the queue runs full. To prevent stalling of replication due to small queue size, it is RECOMMENDED to support “a few thousand” elements in this queue.

3. The outbound replication queues and the notification queue MUST be unlimited in size. This means that it must be ensured that they can hold the entire number of elements that is accessible by the higher layer service layer in the local service stack.

ANNEX A TO

AEDP-19


Figure A-7 Inbound and outbound queues

4. Putting an element into one of those queues MUST be a durable write. Queue entries MUST NOT be taken out of the queues unless the conditions described in the chapters below are met.

5. Please note the definitions in previous chapters regarding the property values from events when they are put in the notification queue.

6. All inbound and outbound queues shall be FIFO.

A-3.7.8.3.1 Local Write Actions

1. Upon an invocation of the “put” or “markVersionAsDead” operation on the SPS++ domain interface, the SPS++ SHALL put the business entity into all the applicable outbound replication queues and the respective notifications into the notification queue. In addition it SHALL store the business entity into the local storage for business entities so they are accessible in the local service stack.

2. All these storage actions MUST be guaranteed to be performed. The storage into the local storage MUST be done synchronously with the invocation from the business layer, the outbound queues MAY be filled asynchronously under the condition that it is impossible that the respective messages are not put into the queues.

3. If any of these internal write operations cannot be performed, the SPS++ SHALL respond with an exception to the invocation from the higher layer service interface.

ANNEX A TO

AEDP-19


Figure A-8 Local write actions

A-3.7.8.3.2 Replication amongst SPS++ Instances

When a remote SPS++ instance replicates data to the local instance, a successful replication call MUST result in the business entity being stored in the inbound replication queue. If that is not possible, the replication call MUST be answered with an exception. Under no conditions may the local SPS++ instance respond with a successful response method to the remote SPS++ if the business entity has not been stored durably in the inbound replication q