java ing serv ice description document tdes... · prepared in accordance with federal aviation...

U.S. Deof Tran

FederaAdmin

S

epartment sportation

al Aviation istration

JAVA

WIM T

To

Messag

Terminal

ower Dep

ging Serv

l Data D

parture

vice Des

Distribu

Event S

NAS

scription

tion Sys

Service

S-JMSDD-43Jan

n Docum

stem (ST

(TDES)

307-005 Rev Anuary 19, 201

ment

TDDS)

)

A17

NAS-JMSDD-4307-005 Rev A January 19, 2017

iii

JAVA Messaging Service Description Document STDDS Tower Departure Event Service

Revision Record

Revision Description Revision Date

Entered By

Updated baseline for R3.2 (CCD N35889) 11/30/2015 King A Updated for R3.3 1/19/2017 King


iv

Table of Contents 1� SCOPE ....................................................................................................................... 1�1.1� Background ........................................................................................................................................ 1�1.2� Intended�Use ...................................................................................................................................... 1�2� APPLICABLE�DOCUMENTS ............................................................................................ 2�2.1� Government�Documents ..................................................................................................................... 2�2.2� Non�Government�Standards�and�Other�Publications ............................................................................. 2�3� DEFINITIONS .............................................................................................................. 4�3.1� Terminology ....................................................................................................................................... 4�

3.1.1� Client............................................................................................................................................. 4�3.1.2� Service .......................................................................................................................................... 4�3.1.3� Service�Interface�Implementation .................................................................................................... 4�3.1.4� NEMS ............................................................................................................................................ 4�

3.2� Abbreviations�and�Acronyms ............................................................................................................... 5�4� SERVICE�PROFILE ........................................................................................................ 7�4.1� Service�Provider .................................................................................................................................. 7�

4.1.1� Point�of�Contact ............................................................................................................................. 7�4.2� Service�Consumers .............................................................................................................................. 7�4.3� Service�Functionality ........................................................................................................................... 7�4.4� Security .............................................................................................................................................. 8�4.5� Qualities�of�Service ............................................................................................................................. 8�4.6� Service�Policies ................................................................................................................................... 9�4.7� Environmental�Constraints .................................................................................................................. 9�5� SERVICE�INTERFACES ................................................................................................. 10�5.1� Interface .......................................................................................................................................... 10�5.2� Operations ....................................................................................................................................... 10�

5.2.1� Processing�Considerations ............................................................................................................. 10�5.3� Messages ......................................................................................................................................... 10�

5.3.1� TowerDepartureEventMessage�Data�Elements ............................................................................... 11�5.3.2� TowerDepartureEventReconstitutionStartMessage�Data�Elements .................................................. 12�5.3.3� TowerDepartureEventReconstitutionCompleteMessage�Data�Elements ........................................... 13�5.3.4� ReconstituteRequestStatusMessage�Data�Elements ........................................................................ 14�5.3.5� ReconstituteSubscriptionToDepartureDataMessage�Data�Elements ................................................. 15�

5.4� Exception�Handling ........................................................................................................................... 15�5.5� Data ................................................................................................................................................ 15�6� SERVICE�IMPLEMENTATION ....................................................................................... 16�6.1� Bindings ........................................................................................................................................... 16�

6.1.1� ActiveMQ�Binding......................................................................................................................... 16�6.1.1.1� Data�format ........................................................................................................................ 16�6.1.1.2� Message�Protocol ................................................................................................................ 16�6.1.1.3� Transport�Protocol ............................................................................................................... 16�

6.2� End�Points ........................................................................................................................................ 16�6.3� Subscribe�Flow ................................................................................................................................. 17�6.4� PublishReconRequest�Flow ................................................................................................................ 18�


v

List of Figures

Figure 1: Subscribe Flow ................................................................................................................................ 17�Figure 2: Reconstitution Sequence .................................................................................................................. 19�


vi

List of Tables

Table 1 : Quality of Services Parameters ............................................................................................................ 8�Table 2 : Environmental Constraints .................................................................................................................. 9�Table 3 : List of Published Messages ............................................................................................................... 11�Table 4 : Consumed Message .......................................................................................................................... 11�Table 5 : TowerDepartureEventMessage Header .............................................................................................. 11�Table 6 : TowerDepartureEventMessage Data Elements ................................................................................... 12�Table 7 : TowerDepartureEventReconstitutionStartMessage Header .................................................................. 13�Table 8 : TowerDepartureEventReconstitutionStartMessage Data Elements ....................................................... 13�Table 9 : TowerDepartureEventReconstitutionCompleteMessage Header ........................................................... 13�Table 10 : TowerDepartureEventReconstitutionCompleteMessage Data Elements .............................................. 14�Table 11 : ReconstituteRequestStatusMessage Header ...................................................................................... 14�Table 12 : ReconstituteRequestStatusMessage Data Elements ........................................................................... 14�Table 13 : ReconstituteSubscriptionToDepartureDataMessage Header ............................................................... 15�Table 14 : Simple Data Types ......................................................................................................................... 15�Table 15 : Complex Data Types ...................................................................................................................... 16�


1

1 SCOPEThis JAVA Messaging Service Description Document (JMSDD) describes the System Wide Information Management (SWIM) Terminal Data Distribution System (STDDS) Tower Departure Event Service (TDES) for SWIM. The TDES publishes controller entered departure events (e.g. taxi start, takeoff) received from the Electronic Flight Strip Transfer System (EFSTS) and clearance delivery information received from Tower Data Link Services (TDLS) to authorized SWIM service consumers via the National Airspace System (NAS) Enterprise Messaging Service (NEMS). In addition, the service provides a reconstitution mechanism for end-users interested in receiving historic departure events upon startup. This JMSDD was prepared in accordance with Federal Aviation Administration (FAA) Standard (STD) FAA-STD-073 and satisfies that the implementation of the STDDS TDES complies with the STDDS Web Services Requirements Document (WSRD), developed in accordance with FAA-STD-070.

1.1 BackgroundSTDDS provides Service Oriented Architecture (SOA) interfaces for tower and Terminal Radar Approach Control (TRACON) systems to send terminal events to the NEMS for subscription by NAS and non-NAS consumers using SWIM compliant infrastructure and interface standards.

The STDDS interfaces with Runway Visual Range (RVR) system, EFSTS, Airport Surface Detection Equipment Model X (ASDE-X) system, Airport Surface Surveillance Capability (ASSC) system, and TDLS system at airports to accept, derive and publish airport information.

The STDDS also interfaces with the STARS General NAS User Services (GeNUS) interface at TRACONs.

The Infrastructure, System Monitor and Control (ISMC) service publishes status information for all external links at an STDDS site. This service also publishes detailed information about the overall STDDS status.

1.2 Intended Use This JMSDD is intended to be used by clients of the STDDS TDES to facilitate the development and operation of service client applications. It may also be used by the FAA staff who may administer these services.


2

2 APPLICABLE DOCUMENTS

2.1 Government Documents [FAA-STD-063] XML Namespaces, 1 May 2009. http://www.tc.faa.gov/its/worldpac/standards/faa-std-063.pdf

[FAA-STD-064] Web Service Registration, 1 May 2009.http://www.tc.faa.gov/its/worldpac/standards/faa-std-064.pdf

[FAA-STD-073] Preparation of Java Message Service Description Document, W3C Working Draft, 29 January 2014.http://www.tc.faa.gov/its/worldpac/standards/faa-std-073.pdf

[FAA-STD-066] Web Service Taxonomies, 26 February 2010. http://www.tc.faa.gov/its/worldpac/standards/faa-std-066.pdf

[FAA-STD-068] Preparation of Standards, 4 December 2009. http://www.tc.faa.gov/its/worldpac/standards/faa-std-068.pdf

[NAS-WSRD-4307-001] SWIM Terminal Data Distribution System (STDDS) Web Services Requirements Document (WSRD), Rev A, 15 February 2017.

[NAS-IC-XXXXXXXXX] NAS Enterprise Messaging Service (NEMS) Asynchronous Messaging Interface Control Document (ICD), Rev 4 Draft, 17 June 2013.

[NAS-IR-22034307] Interface Requirements Document (IRD) STDDS to Tower Data Link Services (TDLS), Revision A, July 1, 2013.

[NAS-IR-82514307] IRD STDDS to Electronic Flight Strip Transfer System (EFSTS), Revision A, January 11, 2016.

[NAS-JMSDD-4307-002] JMSDD STDDS Infrastructure System Monitor and Control(ISMC), Revision A, 19 January 2017.

2.2 Non-Government Standards and Other Publications[W3C XML Recommendation] World Wide Web Consortium eXtensible Markup Language (XML) Version 1.9, Fifth edition, 26 Nov 2008. http://www.w3.org/TR/2008/REC-xml-20081126/

[IEE 802.3] Information Technology – Telecommunication & Information Exchange between Systems – LAN/MAN – Specific Requirements – Part 3: Carrier Sense Multiple Access with


3

Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, 2002.

[WSDR] Web Services Description Requirements, W3C Working Draft, 28 October 2002. http://www.w3.org/TR/2002/WD-ws-desc-reqs-20021028/

[RFC 2119] Key words for Use in RFCs to Indicate Requirement Levels, Network Working Group, March 1997. http://www.rfc-editor.org/rfc/rfc2119.txt

[ISO/IEC 11179-1] Information Technology – Metadata Registries (MDR) – Part 1: Framework, 15 September 2004. http://metadata-standards.org/11179/

[WS Glossary] Web Services Glossary, W3C Working Draft, 14 November 2002. http://www.w3.org/TR/2002/WD-ws-gloss-20021114/

[WSA] Web Services Architecture, W3C Working Group Note, 11 February 2004. http://www.w3.org/TR/ws-arch


4

3 DEFINITIONS

3.1 TerminologyWithin the SWIM service-oriented architecture (SOA) environment, there are key elements that must be defined to properly identify boundaries, functionality, and components. The key high-level entities are identified in the list below:

� Client� Service� Service Interface Implementation � NAS Enterprise Messaging Service (NEMS)

3.1.1 Client A client is an external entity that interacts with a service. A client makes a request of a service and receives a response from the service. The client may also request a subscription and receive messages when a service publishes information. A client may be a software system, software application, or another service. A client may be a NAS client or a non-NAS client. It should be noted that the terms “consumer” and “end-user” can be and are used interchangeably with “client”.

3.1.2 ServiceIn the most general sense, a service is a set of functionality that is performed upon demand based upon a defined interface. A defined request must be provided by the client that invokes the service, and the service returns a defined response to the client. For the STDDS environment, a service is a combination of software components running on the STDDS Application Server and the NEMS. At a minimum, the service requires an XML message that is transported over TCP/IP. In this context, "service" refers to all of the implementation components including the service interface implementation and the service logic.

3.1.3 Service Interface Implementation The service interface implementation is the hardware and software that handles the interaction between the client and the rest of the service. The definition and the implementation are independent of each other. It is possible to maintain the same service interface definition and replace the implementation. The Publish/Subscribe service interface implementation is based on the software in the NEMS.

3.1.4 NEMS NEMS contains the consumer topics used to provide the appropriate information to a consumer of the Publish/Subscribe service. STDDS will publish data onto queues on the NEMS. Consumers will connect to NEMS to retrieve data from their subscribed topic(s).


5

3.2 Abbreviations and Acronyms

AIG

APDS

API

ARTCC

Application Interface Gateway

Airport Data Service

Application Programming Interface

Air Route Traffic Control Center

ASCII American Standard Code for Information Interchange

ASDE-X

ASSC

Airport Surface Detection Equipment Model X

Airport Surface Surveillance Capability

CID Computer Identification Number

EFSTS Electronic Flight Strip Transfer System

FAA

FNTB

FTI

Federal Aviation Administration

FTI National Test Bed

FAA Telecommunications Infrastructure

ICAO

ICD

International Civil Aviation Organization

Interface Control Document

IP Internet Protocol

IRD Interface Requirements Document

ISMC Infrastructure System Monitor and Control

ISO International Standards Organization

JMS

JMSDD

MEP

MTBF

NA

NA

Java Messaging Service

Java Messaging Service Description Document

Message Exchange Pattern

Mean Time Between Failures

Not Applicable

Not Adapted (airport)

NAS National Airspace System

NDRB NAS Data Release Board

NEMS

NSRR

NAS Enterprise Messaging Service

NAS Service Registry Repository

PM

R&D

Program Manager

Research and Development


6

RVR

SOA

Runway Visual Range

Service Oriented Architecture

SSD

SSI

STD

System Specification Document

Sensitive Security Information

Standard

STARS

STDDS

SUI

Standard Terminal Automation Replacement System

SWIM Terminal Data Distribution System

Sensitive Unclassified Information

SWIM System-Wide Information Management

TCP Transmission Control Protocol

TDES

TDLS

Tower Departure Event Service

Tower Data Link Service

TRACON

URL

Terminal Radar Approach Control facility

Uniform Resource Locator

UTC Universal Time Coordinated/ Coordinated Universal Time

WJHTC

WSRD

William J. Hughes Technical Center

Web Services Requirements Document

XML eXtensible Markup Language


7

4 Service Profile This section provides the information needed to discover and use the STDDS TDES.

Service Profile Name STDDS Tower Departure Event Service Description The Tower Departure Event Service sends departure events for all

flights from select towers associated with a TRACON. In addition, the service provides a reconstitution mechanism for end-users interested in receiving historic departure events upon startup.

Namespace urn:us:gov:dot:faa:atm:terminal:entities:v3-0:tdes Version 3.0Service category FAA-STD-066 category 1.3.1.2.1, Air Traffic Command and

Control Information Exchange Service Lifecycle stage ProductionService criticality Essential

4.1 Service Provider The STDDS TDES is provided by FAA Air Traffic Organization (ATO), Enterprise Programs.

4.1.1 Point of Contact

Point of Contact Name Melissa MatthewsOrganization Federal Aviation Administration

Enterprise ProgramsTitle SWIM Capabilities ManagerPhone 202-267-0764Email [email protected]

4.2 Service Consumers The STDDS TDES is currently only available to authorized NAS end-users. STDDS will provide sample client applications as reference models, however clients are responsible for implementing their own applications to consume TDES data.

4.3 Service Functionality STDDS TDES publishes the data listed below. For more information about individual message types see section 5.3.

o Publishes clearance delivery time, start taxi time and takeoff time (TowerDepartureEventMessage)

o Receives Reconstitution Request message (ReconstituteSubscriptionToDepartureDataMessage)


8

o Publishes Reconstitution Request Response message (ReconstitutionRequestStatusMessage)

o Publishes Reconstitution Start message (TowerDepartureEventReconstitutionStartMessage)

o Publishes Reconstitution complete message (TowerDepartureEventReconstitutionCompleteMessage)

4.4 Security NEMS manages all security features for Publish/Subscribe services for authorized NAS and non-NAS consumers and NAS producers.

Access controls are supported through the use of username and password credentials supplied when establishing connections to NEMS interfaces. Username and password credentials are unique to each NEMS client and established during on-ramping.

The STDDS TDES does not filter sensitive data and is only available for subscription by consumers who are authorized to receive sensitive data.

4.5 Qualities of Service STDDS TDES Quality of Service parameters are listed in the following table.

Table 1 : Quality of Services Parameters

QoSParameter

Value Unit Definition Calculation

Availability 0.999 ratio The probability that a system or constituent piece may be operational during any randomly selected instant of time. (Definition from NAS-RD-2012)

MTBF/(MTBF + MDT)

Data Latency 1 second (mean) and 5 seconds(95th

percentile)

seconds Time interval from the time an input message is received and a corresponding message is published to NEMS.

Note: Some EFSTS messages do not result in a corresponding published message, however some of the data in that message may be utilized in a subsequent published message.

Continuousmeasurement


9

QoSParameter

Value Unit Definition Calculation

Reconstitute ResponseTime

2 Minutes Time interval from the time a reconstitution request message is received and when a reconstitution complete message is sent


NEMS Re-connectionTime

3 Minutes Maximum time interval from the time a connection failure to NEMS occurs to the time that the STDDS has reconnected to NEMS.


4.6 Service Policies No specific service policies are applied to the STDDS TDES.

4.7 Environmental Constraints This service covers three NEMS operating environments:

1) Research & Development (R&D) NEMS at Melbourne, Florida 2) FAA Telecommunications Infrastructure (FTI) National Test Bed (FNTB) NEMS at

WJHTC 3) NAS-OPS NEMS deployed to ARTCCs.

Table 2 : Environmental Constraints

Service Constraints FTI environmentDeployed NEMS Environment R&D, FNTB and NAS-OPSMessage Producer Type NAS application Record Type Live


10

5 Service Interfaces The following sections provide detailed information about the types and content of messages that the STDDS TDES publishes. The service is also described in terms of the interfaces that it communicates with.

5.1 InterfaceThe STDDS TDES follows the “point to point” messaging model and employs a single queue interface to NEMS, through which all published data can be subscribed to and received. Each client interested in subscribing to STDDS TDES data establishes a connection to a custom data topic provided by NEMS and defined during on-ramping.

In addition, the STDDS TDES supports the “PublishReconRequest” message flow, which allows end-users to send a data reconstitution request via NEMS. STDDS TDES then publishes at most 30 minutes worth of the most recent TDES data along with new updates.

5.2 OperationsSTDDS TDES publishes departure events derived from TDLS and EFSTS for all flights from towers associated with an STDDS TRACON. In addition, the service provides a reconstitution mechanism for end-users interested in receiving historic departure events upon startup.

5.2.1 Processing Considerations STDDS TDES provides a reconstitution mechanism for end-users to request for a reconstitution of departure events for a particular airport. This should be done by the end-user upon the start of a subscription or detection that a message in a sequence is lost. NEMS provides a specific reconstitution topic for the reconstitution request message. To start the process, an end-user must request data reconstitution by sending a reconstitution request message to the reconstitution topic. NEMS validates the airport in the request and publishes it to STDDS TDES. STDDS TDES validates the request and sends a response to the end-user indicating success or failure of the request. STDDS TDES will reject a reconstitution request sent by an end-user for an airport if a reconstitution for that airport to the same end-user is currently in process. Each valid request contains data identifying the end-user and an airport code. This data is included in the published reconstituted messages and is used by NEMS to route the messages to the requesting end-user. Reconstituted data is published in the same message flow as current TDES messages.

5.3 MessagesThe foundation for the external message format for STDDS TDES is based upon the W3C XML standard. Publish/Subscribe services deliver messages using an asynchronous message exchange pattern. The reconstitution request message is consumed by the STDDS TDES using an In Only Message Exchange Pattern (MEP).

The following messages are published by STDDS TDES via NEMS. Each message has a header and a payload. The header contains routing data used by NEMS to deliver messages to the


11

correct subscriber. Note that the MsgType column defines the two character abbreviation that is used in the JMS header to delineate the message type.

Table 3 : List of Published Messages

Name Definition MsgTypeTowerDepartureEventMessage Sent upon the receipt of a corresponding

event from EFSTS and/or TDLS. The MsgType indicates if this event is new (DE) or reconstituted (DR).

DE, DR

TowerDepartureEventReconstitutionStartMessage

Indicates the beginning of a set of reconstituted messages

RS

TowerDepartureEventReconstitutionCompleteMessage

Indicates the end of a set of reconstituted messages

RC

ReconstitutionRequestStatusMessage

Response to a reconstitution request. The MsgType indicates if the reconstitution request has been accepted (RA), or rejected (RF).

RA, RF

The following message is consumed by the STDDS TDES.

Table 4 : Consumed Message

Name Definition MsgTypeReconstitutionSubscriptionToDepartureDataMessage

End-user request for a reconstitution of tower departure events

TR

5.3.1 TowerDepartureEventMessage Data Elements The following table lists the header for a TowerDepartureEventMessage.

Table 5 : TowerDepartureEventMessage Header

Data Element Description Cardinality TypemsgType Defines the type of message 1 string version Version number of STDDS schema 1 string timestamp UTC date and time of message generation 1 dateTime tracon FAA location identifier (three alphanumeric

characters) of the producer STDDS installation

1 string

airport ICAO code of the source airport 1 string clientID End-recipient username, present only as part

of a reconstitution (msgType is set to “DR”). 0…1 string

sendTo Authorization flag; permissible value: authorized.

1 string


12

The following table lists the data elements in the payload of a TowerDepartureEventMessage.

Table 6 : TowerDepartureEventMessage Data Elements

Data Element Description Cardinality

Type

messageSequenceID

Message sequence identifier 1 long

reconMessageSequenceID

Reconstitution message sequence identifier. This field will not be included if the msgType is set to “DE”.

0..1 long

flightID Global unique flight identifier 0..1 string aircraftID Aircraft callsign 1 AircraftIdentifier computerID NAS computer identification number

(CID)/ERAM ID. May contain Alpha in position 3. In the future the CID may also take the form of NAA, as well as NNA.

1 string

departureAirport ICAO departure airport code 1 string destinationAirport ICAO destination airport code 0..1 string clearanceDeliveryTime

UTC date and time at which a departure clearance was issued as reported by TDLS.

Note: TDLS sends a Clearance Delivery message after the Airlines Operations Center acknowledged receiving the clearance.

0..1 dateTime

parkingGate Aircraft parking gate information. 0..1 string taxiStartTime UTC date and time at which taxi start

event was detected by STDDS TDES.0..1 dateTime

takeoffTime UTC date and time at which takeoff event was detected by STDDS TDES.

0..1 dateTime

takeoffRunway Runway identifier 0..1 RunwayIdentifier

5.3.2 TowerDepartureEventReconstitutionStartMessage Data Elements

The following table lists the header for a TowerDepartureEventReconstitutionStartMessage.


13

Table 7 : TowerDepartureEventReconstitutionStartMessage Header



1 string

airport ICAO code of the source airport 1 string clientID End-recipient username 1 string sendTo Authorization flag; permissible value:

authorized. 1 string

The following table lists the data elements in the payload of a TowerDepartureEventReconstitutionStartMessage.

Table 8 : TowerDepartureEventReconstitutionStartMessage Data Elements


Type

airportID Airport for which a reconstitution is being started

1 string

5.3.3 TowerDepartureEventReconstitutionCompleteMessage Data Elements

The following table lists the header for a TowerDepartureEventReconstitutionCompleteMessage.

Table 9 : TowerDepartureEventReconstitutionCompleteMessage Header



1 string

airport ICAO code of the source airport 1 string clientID End-recipient username 1 string sendTo Authorization flag; permissible value:


The following table lists the data elements in the payload of a TowerDepartureEventReconstitutionCompleteMessage.


14

Table 10 : TowerDepartureEventReconstitutionCompleteMessage Data Elements


Type

airportID Airport for which reconstitution has completed

1 string

numberOfReconMessages

Total number of reconstitution messages sent

1 int

5.3.4 ReconstituteRequestStatusMessage Data Elements

The following table lists the header for a ReconstituteRequestStatusMessage.

Table 11 : ReconstituteRequestStatusMessage Header



1 string

clientID End-recipient username. 1 string sendTo Authorization flag; permissible value:


The following table lists the data elements in the payload of a ReconstituteRequestStatusMessage.

Table 12 : ReconstituteRequestStatusMessage Data Elements


Type

airportID Airport for which a reconstitution status is being sent.

1 string

reasonForFailure The reason if for a reconstitution request failure. Sent if msgType is set to “RF”.

0..1 ReconstitutionRequestFailureReason


15

5.3.5 ReconstituteSubscriptionToDepartureDataMessage Data Elements

The following table lists the header for a ReconstituteSubscriptionToDepartureDataMessage.

Table 13 : ReconstituteSubscriptionToDepartureDataMessage Header

Data Element Description Cardinality TypemsgType Defines the type of message 1 string timestamp UTC date and time of message generation 1 dateTime airport ICAO code of the source airport 1 string clientID Identification of the end-user requesting a

reconstitution. 1 string

The payload of the ReconstituteSubscriptionToDepartureDataMessage consists of a root element with no contents or attributes.

5.4 Exception Handling The TowerDepartureEventServiceStatus message described in the ISMC JMSDD contains status information for each external TDLS and/or EFSTS link at an STDDS site. A degraded or failed external link may result in loss of data.

5.5 DataThe following tables describe the data types defined in the STDDS TDES messages.

Specific formats required for any data types will be included in the types’ definition text. The detail for the obligation and maximum occurrences of the data types and elements is included in the schema definitions within the NSRR.

A type listed as complex means that the entity consists of one or more sub-entities, which are detailed in the entity’s definition.

Table 14 : Simple Data Types Name Definition Permissible Values Data

TypeFormat

dateTime This type defines the date and time. It is a primitive data type.

Valid date and time primitive

yyyy-mm-ddThh:mm:ss.sssZ

AircraftIdentifier This type defines an aircraft identifier

NA string .{1,8}


16

Name Definition Permissible Values DataType

Format

ReconstitutionRequestFailureReason

This provides the reason for reconstitutionrequest failure. NA (Not adapted airport), CR (client already receiving reconstitution)

NA CR

string NA

Table 15 : Complex Data Types Name Definition Permissible

Values Data Type Format Obligation

RunwayIdentifier This type defines a runway identifier

NA Complex NA NA

RunwayIdentifier.numericRunwayID

The numeric value of the runway

NA Integer NA Required

RunwayIdentifier.runwaySubID

The orientation of the runway

NA string NA Required

6 Service Implementation The STDDS TDES is implemented as a JMS Publish service. All access points to the service are wholly contained within NEMS. STDDS TDES publishes data to NEMS via a JMS queue and receives reconstitution requests via another JMS queue. Clients connect to a topic established by NEMS in order to receive STDDS TDES data. Clients connect to a different topic established by NEMS in order to send reconstitution requests.

6.1 Bindings

6.1.1 ActiveMQ Binding All STDDS TDES messages are bound to the NEMS JMS interface through ActiveMQ.

6.1.1.1 Data format All STDDS TDES data is published to NEMS in XML format.

6.1.1.2 Message Protocol The message protocol for the STDDS TDES is JMS.

6.1.1.3 Transport Protocol The transport protocol is Transmission Control Protocol (TCP).

6.2 End Points The TCP/IP addresses are not included in this document for security reasons. Please refer to NEMS On-Ramping forms and section 4.1.1 Point of Contact for more details.


17

6.3 Subscribe Flow An STDDS TDES client may subscribe to a NEMS specified topic to obtain distributed departure events. Individual subscriber topics will be identified as part of a client’s on-ramping process.

The message flow to publish a message is asynchronous and starts with the client requesting a connection and a subscription from NEMS. As data becomes available from the STDDS TDES, it is published to the NEMS. The NEMS stores the messages on each client’s registered topic. If the client is connected to its topic, the messages will be delivered from the client’s topic to the client. If the client is not connected to its topic, the message is purged from the queue after its time-to-live has expired. The subscription request (steps 1 and 2 below) is performed once for each desired subscription, and the messages are published to the client until the subscription is cancelled.

A detailed message flow for receiving a message is shown below:

1. The client connects to the NEMS and requests a subscription. 2. The NEMS accepts the connection, validates the client’s security, and replies with the

status of the subscription.3. STDDS TDES transforms legacy external data to XML messages. 4. STDDS TDES publishes the messages to the assigned queue on the NEMS. 5. The NEMS publishes the message to each of the topics associated with clients that have

registered for the message. 6. Each client connected to the NEMS pulls the message out of its topic.

Figure 1: Subscribe Flow

Client

STDDSNEMS

Input�System1.�The�Client�connects�to�NEMS

2.�NEMS�accepts�the�connection

6.�The�Client�consumes�the�message�from�the�topic�

5.�NEMS�publishes�the�message�on�the�topic 3.�Data�is�received�

from�an�external�input�source.

4.�An�XML�message�is�published�on�the�queue�to�NEMS.

Client�connection�flow

Data�flow


18

6.4 PublishReconRequest Flow

The PublishReconRequest flow includes the creation and publication of a reconstitution start (TowerDepartureEventReconstitutionStart) message, publication of the retained tower departure event (TowerDepartureEvent) message, and then creation and publication of a reconstitution complete (TowerDepartureEventReconstitutionComplete) message. Messages published during a reconstitution process are interleaved in the steady state publication stream of tower departure event messages.

In the event that a client does not receive a response or an incomplete reconstitution is received, a client will need to re-request a reconstitution. Incomplete or missing responses may be the result of a given STDDS TDES site failure or a NEMS node failover that is currently occurring.Detection of a NEMS connection failure and recovery by STDDS TDES can take up to 3 minutes; during that time, a response to a reconstitution request cannot be guaranteed. A client should wait the maximum failure detection time (3 minutes) before re-requesting a reconstitution for a given airport.

An example of the reconstitution flow is as follows:

1. A consumer is already connected to NEMS using the Subscribe flow 2. The consumer sends a ReconstituteSubscriptionToDepartureData on the

PublishReconRequest endpoint to NEMS 3. NEMS checks the validity of the user and the requested airport

a. If the request is invalid, a ReconstituteRequestStatusMessage indicating failure is returned via the Subscribe flow

b. If the request is valid, it is forwarded to all attached STDDS TDES instances 4. The STDDS TDES associated with the requested airport receives the reconstitution

request and checks its validity a. If a reconstitution is currently occurring for this client for the airport requested a

ReconstituteRequestStatusMessage indicating failure is returned via the Subscribe flow

b. Otherwise the STDDS TDES will publish ReconstituteRequestStatusMessage indicating the request was accepted and begin a reconstitution using the supplied clientID to mark messages

5. The consumer listens on the Subscribe endpoint for in this sequence: a. A TowerDepartureEventReconstitutionStart message b. One or more TowerDepartureEvent with the reconstitution identifier c. A TowerDepartureEventReconstitutionComplete message


19

Figure 2: Reconstitution Sequence