The formal, signed copy of this document is available in PDF format.
This document specifies the policies, rules, and standards for identifying, designing, implementing, deploying, and managing the resources, assets, and processes that are enabled and/or supported by the Federal Aviation Administration (FAA) System Wide Information Management (SWIM) program.
The National Airspace System (NAS) is in the process of evolving from the traditional modes of information exchange (including system-to-system interaction) to a paradigm of service-oriented architecture (SOA).
To facilitate delivery of SOA-based services , the FAA established the SWIM program. The goal of the SWIM program is to support information sharing among NAS stakeholders by providing a communications infrastructure and architectural solutions for identifying, developing, provisioning, and operating shareable and reusable services. SWIM leverages the FAA Telecommunications Infrastructure (FTI) that provides network-level connectivity, security and communication capability. SWIM presents a model for a next-generation computing infrastructure with a special emphasis on fielding SOA services that permits integration and consolidation of information systems.
The most challenging aspect of establishing a mature SOA-based enterprise framework of reusable business services is an effective governance model. SOA Governance ensures that all of the independent SOA-based efforts (whether in the design, development, deployment, or operation of a service) come together to meet enterprise requirements.
This document establishes SOA Governance policies, processes, and standards for managing the lifecycle of services, service acquisitions, service components and registries, service providers, and service consumers.
The policies specified in this document apply to all current and prospective SWIM-enabled programs responsible for identifying, acquiring, designing, implementing, consuming and deploying services supported and/or enabled by the SWIM program.
|||SWIM Controlled Vocabulary, March 2013.|
|||FAA-STD-065A, Web Service Description Document, 1 July 2013.|
|||FAA-STD-070, Preparation of Web Service Requirements Documents, 12 July 2012.|
|||FAA-STD-073, Preparation of JAVA Message Service Description Documents, 30 September 2013.|
|||FAA-STD-063, XML Namespaces, 1 May 2009.|
|||1370.113 - FAA Web Security Policy, Federal Aviation Administration, 16 April 2012.|
|||FIPS PUB 199, Standards for Security Categorization of Federal Information and Information Systems, National Institute of Standards and Technology, February 2004.|
|||FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems, National Institute of Standards and Technology, March 2006.|
|||FAA Order 1370.98, ATO Information Technology Infrastructure Requirements for Non-FAA Connectivity, 17 April 2007. |
|||NIST Special Publication 800-95, Guide to Secure Web Services, National Institute of Standards and Technology, August 2007.|
|||RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, Network Working Group, August 2008.|
|||Web Services Security: SOAP Message Security 1.1 (WS-Security 2004), OASIS Standard Specification, 1 February 2006.|
|||RFC 2119, Key words for Use in RFCs to Indicate Requirement Levels, Network Working Group, March 1997.|
|||Web Services Architecture, W3C Working Group Note, 11 February 2004.|
|||Java 2 Platform, Enterprise Edition, v 1.3 API Specification|
|||Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Recommendation, 26 June 2007.|
|||XML Schema Definition Language (XSD) 1.1 Part 1: Structures, W3C Recommendation, 5 April 2012.|
|||XML Schema Part 1: Structures Second Edition, W3C Recommendation, 28 October 2004.|
|||Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, 26 November 2008.|
|||SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), W3C Recommendation, 27 April 2007.|
|||DCMI Metadata Terms, Dublin Core Metadata Initiative, 14 June 2012.|
|||OWS-9 CCI Semantic Mediation Engineering Report, Open Geospatial Consortium, 2013.|
|||Aeronautical Information Exchange Model (AIXM) Release 5.1, EUROCONTROL/FAA, 1 February 2010. |
|||Weather Information Exchange Model (WXXM) Version 1.1.1, EUROCONTROL/FAA, 19 March 2010.|
|||Flight Information Exchange Model (FIXM) Version 2.0, EUROCONTROL/FAA, 22 August 2013.|
In the event of a conflict between the text of this document and the references cited herein, the text of this document takes precedence. Nothing in this document, however, supersedes applicable laws and regulations unless a specific exemption has been obtained.
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 RFC 2119 .
These key words are capitalized when used to unambiguously specify requirements. When these words are not capitalized, they are meant in their natural-language sense.
Note: terms labeled "CV" may be found in the SWIM Controlled Vocabularyalong with information about terms' sources and relationships to other terms.
|On-Ramping||The process of configuring and enabling a connection between a service or consumer agent and the NAS Enterprise Messaging Service (NEMS).|
|Semantic Interoperability||The aspect of interoperability that assures that the content of the data being transferred across two systems is understood in the same way in both systems, including by those humans interacting with the systems in a given context. |
|SOA Governance||The application of policies, rules, and standards needed to ensure that all of the independent SOA-based efforts (whether in the design, development, deployment, or operations of a service) come together to meet enterprise requirements.|
|SOA-Based||Something that is designed, developed, or operated according to principles of Service-Oriented Architecture.|
|SWIM-Enabled Program||A program that provides or consumes, or intends to provide or consume, NAS SOA-based services and which uses SWIM common computing and infrastructure assets.|
|Taxonomy||A controlled list of well-defined concepts organized into a hierarchical structure.|
|FAA||Federal Aviation Administration|
|FID||Final Investment Decision|
|FIXM||Flight Information Exchange Model|
|FNTB||FTI National Test Bed|
|FPRD||Final Program Requirements Document|
|FTI||FAA Telecommunications Infrastructure|
|HTTP||Hypertext Transfer Protocol|
|IARD||Investment Analysis Readiness Decision|
|IID||Initial Investment Decision|
|IPR||Initial Program Requirements|
|ISD||In Service Decision|
|ISPD||Implementation Strategy and Planning Document|
|JMS||Java Message Service|
|JRC||Joint Resources Council|
|JMSDD||Java Messaging Service Description Document|
|MOA||Memorandum of Agreement|
|NAS||National Airspace System|
|NEMS||NAS Enterprise Messaging Service|
|NSRR||NAS Service Registry/Repository|
|OGC||Open Geospatial Consortium|
|PRD||Program Requirements Document|
|SLMP||Service Lifecycle Management Process|
|SOAP||Originally "Simple Object Access Protocol"; the full spelling is no longer used|
|URI||Uniform Resource Identifier|
|WSDD||Web Service Description Document|
|WSDL||Web Service Description Language|
|WSRD||Web Service Requirements Document|
|W3C||World Wide Web Consortium|
|WXXM||Weather Information Exchange Model|
|XML||eXtensible Markup Language|
|XSD||XML Schema Definition|
This section describes the general policies for instituting governance mechanisms of SOA-based implementations in the context of SWIM. These policies are further elaborated in section 5 of this document.
The goal of the SOA suitability assessment process is to discover SOA-suitable program initiatives early in their analysis phase. This early discovery is critical for the program's architecture and requirements development and ensures appropriate integration of SWIM infrastructure in the program solution architecture.
Additional information on SOA suitability assessment is available at the SWIM Governance Website .
The ability to effectively manage all stages of the service lifecycle is fundamental to the success of governing SOA services. This document asserts the Service Lifecycle Management Process (SLMP) to contain a set of controlled and well-defined activities performed at each stage of a service's lifecycle for any and all versions of any given service.
Table 1 lists the sequential service provider lifecycle stages. Policies relevant to each stage are described in corresponding subsections following Table 1.
|Proposed||The stage during which the business needs for the proposed service are identified and assessed as to whether needs can be met through the use of SOA.|
|Definition||The stage during which the service's business requirements are gathered and the service design is produced based on these requirements.|
|Development||The stage during which the service specifications are developed and the service is built.|
|Verification||The stage during which the service is being inspected and/or tested to confirm that the service is of sufficient quality, complies with the prescribed set of standards and regulations, and is approved for use.|
|Production||The stage during which the service is available for use by its intended consumers.|
|Deprecated||The stage during which the service can no longer be used by new consumers.|
|Retired||The stage during which the service is disposed of and is no longer used.|
For information about service registration policies, see section 5.1.5 of this document.
For a comprehensive Service Provider checklist, see Appendix A.
This section specifies policies for organizations or programs that intend to consume services provided in the context of SWIM implementations. This document asserts two types of Service Consumers: internal (FAA organizations), and external (FAA business partners).
In addition to the policies listed in section 5.1.3, internal Service Consumers shall also comply with the following policies:
In addition to the policies listed in section 5.1.3, internal Service Consumers shall also comply with the following policies:
This document asserts NSRR registration to be a formal process of storing, cataloging and managing of SOA services metadata and relevant artifacts in the NSRR. Use of the NSRR is mandated for the development and acquisition of all new or modified SWIM-enabled programs.
NAS SOA implementations are based on two technological solutions: Web Services and JMS-based services. In the Web Service, a requester of a service accesses a remote system hosting the service (usually via HTTP) and invokes methods offered through a public interface (described in a XML-based file, usually WSDL). In the JMS, messages (specifically formatted sets of data) are exchanged through a messaging server, which acts as a message exchange service for client programs that produce or receive data.>
This section addresses the policies that promote and facilitate semantic interoperability among SWIM-enabled programs. Semantic interoperability ensures that the content of information is understood in the same way between interacting systems, including by those humans interacting with the systems in a given context. In the context of SWIM SOA Governance, semantic interoperability is achieved through the consistent use of description standards (e.g., Dublin Core , FAA-STD-065A ), shared vocabularies, common sets of taxonomies, and ontologies.
|Proposed||Deliverable||SOA Suitability Scorecard||SOA suitability memo and score is developed as part of the SOA Suitability Assessment. The SOA Suitability Assessment is conducted by EES for ARB. Submit to NSRR.|
|Deliverable||Organization Entity Request Form||A form completed by the Program to provide SWIM Governance with necessary information to create an Organizational entity for the Program in NSRR. Submit to SWIM Governance.|
|Checkpoint||Organization URI||An Organization URI registered by an FAA registration authority. Refer to FAA-STD-063 .|
|Checkpoint||IARD and/or IID||Service Provider passed AMS Investment Analysis Readiness Decision (IARD) and Initial Investment Decision (IID). Applicable only to Service Providers in the AMS Deliverable Concept of OperationsSolution CONOPS is an AMS deliverable. Submit to NSRR.|
|Deliverable||Concept of Operations||Solution CONOPS is an AMS deliverable. Submit to NSRR.|
|Definition||Checkpoint||FID||Service Provider passed AMS Final Investment Decision. Applicable only to Service Providers in the AMS|
|Deliverable||Web Service Requirements Document (WSRD)||Provides a series of requirements for the Program's Service interface. Refer to FAA-STD-70. Submit to NSRR.|
|Development||Deliverable||Web Services Description Document (WSDD) or Java Messaging Service Description Document (JMSDD)||Provides technical specification regarding interface specifics of the SOA Service. Refer to FAA-STD-065A or FAA-STD-073. Submit to NSRR.|
|Deliverable||XML Schema Definitions for Types||A description of constraints, structure, and content of the data products of the SOA Service. Refer to FAA-STD-065A. Submit to NSRR.|
|Deliverable||Web Services Description Language (WSDL) document(s)||An XML description for defining the functionality offered by the Web Service. Not applicable to JMS Services. Submit to NSRR.|
|Deliverable||Enterprise Engineering Service and Cost Agreement (EESCA)||Program Level agreement between EES and program inclusive of SWIM service requirements and costing. (formerly known as TPP). Submit to EES|
|Verification||Checkpoint||Test Plan/ Producer Review||SWIM T&E Team will review and approve test plans and procedures specifically related to SWIM requirements.|
|Production||Checkpoint||ISD Action Plan||Submit to NSRR. ISD Action Plan describes deployment activities such as product installation and certification for operational use. ISD Action Plan supports ISD in the AMS.|
|Deliverable||Memorandum of Agreement (MOA)||MOA for each non FAA consumer, submit to NSRR for each external Service Consumer|
|Deprecation||Deliverable||Deprecation Impact Analysis||Submit to NSRR.|
|Retired||Deliverable||Retirement Impact Analysis||Submit to NSRR.|
Note: this example is non-normative.
|SWIM Governance Policies Waiver Request|
|FOR USE BY REQUESTER|
|Date of Request: August 21, 2013|
|Requester’s Organization: En Route Services Modernization Group (ESMG)|
|Requester’s Name: John D. Doe, ATO-X ESMG Manager|
|Requester’s Telephone Number: (609) 444-5555|
|Requester’s Email: firstname.lastname@example.org|
|Short description of request, including specific policy or policies to be waived, together with a justification of the request and alternative policies to be followed or actions to be taken:|
ESMG requests a waiver from using the Flight Information Exchange Model (FIXM) as the data exchange format for the Flight Plan Service (FPS), as prescribed by SWIM Governance Policies version 2.0, for the following reason:
During design of FPS version 1.0, the FIXM wasn't mature and ESMG decided to use a custom-built XML-based model to describe flight plan data provided by the service. Although FIXM has since achieved a sufficient level of maturity, the transition to FIXM will significantly affect the cost of implementing FPS version 1.0 and will make it impossible to meet its release date. The transition to FIXM will be implemented in the next release of FPS, currently scheduled for March 1, 2015.
Date or condition upon which this waiver can be expected to expire: March 1, 2015
|FOR USE BY SWIM GOVERNANCE|
|Resolution of Request:|
Given the information and analysis referenced above, it is considered that the use of a custom-built model instead of FIXM does not constitute a material defect in the Flight Plan Service implementation. The SWIM Governance Policies requirement to demonstrate compliance with canonical models, specifically FIXM, is hereby waived. The FPS may proceed to the Service Lifecycle Production stage.
|Waiver Granted (X) / Disapproved ( ) on: September 4, 2013
|Signed: Mark Kaplun, SWIM Governance Lead (email@example.com)|