![](media/image1.wmf){width="3.0166666666666666in"
height="2.995138888888889in"}

**System Wide Information Management (SWIM)**

**Service Container Requirements**

**December 2007**

Federal Aviation Administration

800 Independence Avenue SW

Washington, DC 20591

TABLE OF CONTENTS

**1.0** **BACKGROUND [1](#background)**

2.0 OPERATIONAL CONCEPT [2](#operational-concept)

2.1 Operations [2](#operations)

2.1.1 Core Capability Descriptions [4](#core-capability-descriptions)

2.1.2 SWIM Service Lifecycle Descriptions
[5](#swim-service-lifecycle-descriptions)

3.0 TECHNICAL REQUIREMENTS [8](#technical-requirements)

Appendix A -- Acronyms [1](#appendix-a-acronyms)

> List of Figures

[Figure 2-1. Point-to-Point Interfaces Transformed by SWIM
3](#__RefHeading___Toc186193996)

[Figure 2-2. Development of Services 6](#__RefHeading___Toc186193998)

[Figure 2‑3. Registration of Services 7](#__RefHeading___Toc186193999)

# BACKGROUND

Today's National Airspace System (NAS) comprises systems that have been
developed over time for specific purposes. In general, they are
connected discretely to support specific data and information exchange
needs. Each of these interfaces is custom designed, developed, managed,
and maintained individually at a significant cost to the Federal
Aviation Administration (FAA). The Next Generation Air Transportation
System (NextGen) relies upon a new decision construct that will bring
more data, systems, customers, and service providers into the process.
Data will be needed at more places, for more purposes, in a timely
manner, and in common formats and structures to ensure consistent use.
The resulting decisions must be distributed to the affected parties
efficiently and reliably to support timely execution.

The mission of the System Wide Information Management (SWIM) Program is
to provide the means for greater information sharing among NAS
stakeholders, both FAA and non-FAA users, to support the NextGen
operations. This includes, but is not limited to, aeronautical
information, flight data, traffic flow management data, surveillance,
and weather information. To achieve this mission, SWIM's strategy is to
migrate NAS applications toward a loosely coupled, open, distributed
processing environment focused on information sharing (where loosely
coupled systems tend to be highly scalable, robust and agile). These
open architecture principles will provide value by reducing costs,
reducing risks, enabling new services, and extending and therefore
adding value to existing services.

Specifically, SWIM will use Service Oriented Architecture (SOA)
principles in designing and specifying NAS Air Traffic Management (ATM)
services. Key functional elements of the SWIM SOA are the SWIM Core
Capabilities and SWIM Business services. The SWIM Program Office is
responsible for definition of the Core Services, whereas the FAA NAS
Programs will define the business services in SWIM Segment 1.

The planned Segment 1 SWIM Core Capabilities are: Interface Management
(Interface Specification, Interface Discovery, Schema Management,
Service Invocation, SWIM Basic Profile), Messaging (reliable messaging),
Security (authentication and authorization), and Enterprise Service
Management (service monitoring and configuration). The SWIM Program
Office will specify standards for all SWIM Core Capabilities; however,
product standardization will be focused on the Service Container.

The SWIM Service Container is an infrastructure component that will
provide many of the needed support (hosting) capabilities. It will
relieve the SWIM Implementing Program (SIP) implementers of some of the
housekeeping tasks required in service delivery. It should provide
connections to data, to messaging services, and to
authentication/authorization services (i.e., the SWIM Core
Capabilities), as well as provide logging, error handling, and other
support functions.

The SWIM service container is one software component of the SWIM
infrastructure that provides support and hosting capabilities for NAS
applications. SWIM will use the Service Container as a means for
achieving consistency and interoperability among diverse NAS programs
and operating elements, in the absence of a centralized service
infrastructure. The Service Container will be comprised of an existing
product (commercial off-the-shelf (COTS) or open source software) with
components configured to support SWIM specific goals such as
interoperability, extensibility, and portability. The Service Container
is a logical component of the SWIM architecture that provides support
for the SWIM Core Service functionality. It does so in a manner
consistent with non-functional requirements for enterprise Service
Oriented Architecture (SOA) and the federated approach to
implementation. The Service Container serves as the point of enforcement
for enterprise-wide SWIM policies and accelerates service implementation
by providing standard, reusable common infrastructure elements. It
provides access to enterprise resources and simplifies the service
design and development process.

Use of the Service Container will encourage consistent use of common
capabilities across the SWIM SIPs. It will provides flexibility,
manageability, and reduce risk in achieving the SWIM vision by
decoupling supporting enterprise Information Technology (IT) elements
from each other while providing a lightweight enterprise management
capability to help manage the SWIM environment across the NAS.

This document specifies the requirements for the SWIM Service Container
software. The Service Container is a SWIM standardized architecture
component that SWIM Implementing Programs (SIPs) will implement on
servers that host SWIM-provided Service Container software. NAS Programs
will own and manage the Business Services and will determine where and
how Service Containers are deployed with guidance and support from the
SWIM program.

The following sections provide background information on the SWIM Core
Capabilities and Segment 1 Air Traffic Management (business)
capabilities.

# OPERATIONAL CONCEPT

## Operations

SWIM will be developed incrementally based upon the needs of various
data communities, maturity of concepts of use, and segments that are
sized to fit reasonable cost, schedule, and risk thresholds. To define
Segment 1, SWIM system engineers collaborated with stakeholders (called
Communities of Interest (COIs)) who possess the expertise to accurately
describe how information is currently being used in the NAS, predict
future NAS information needs, and discern how to best fulfill those
needs using a net-centric solution. COIs currently include Aeronautical
Information Management (AIM), Flight and Flow Management (F&FM), and
Weather; others (e.g., Surveillance) will form as needed over time.

Rather than developing a separate infrastructure, the SWIM program will
provide Core Capabilities standards and Service Container software to
the NAS SIPs that will implement the capabilities that comprise
Segment 1. These SIPs include En Route Automation Modernization (ERAM),
Traffic Flow Management System (TFMS), Aeronautical Information
Management (AIM), Corridor Integrated Weather System (CIWS), Weather
Message Switching Center Replacement (WMSCR), and Integrated Terminal
Weather System (ITWS). The SIPs will acquire software for the Core
Capabilities (that meet SWIM defined standards) and use that with the
SWIM Program Office provided Service Container software to support their
SWIM developed applications programs. New SWIM software will be hosted
on existing hardware, if available, or SIPs will procure new hardware to
support Segment 1 capabilities. The implementing programs will provide
configuration management, life cycle support, safety, and security for
Segment 1 functional capabilities.

The SWIM concept includes the ability to transform NAS application
interfaces from a tightly coupled, point-to-point model into a Service
Oriented Architecture (SOA) supporting loosely coupled (or minimally
interdependent) services. This transformation is depicted in Figure 2-1.
SWIM provides the flexibility to develop interfaces consistent with
needs; it does not mandate a one-size-fits-all approach. The
characteristics of each interface are determined based on the
requirements and associated business case.

[]{#__RefHeading___Toc186193996 .anchor}**Figure 2-1. Point-to-Point
Interfaces Transformed by SWIM**

SWIM provides a set of Core Capabilities (described in Section 2.1.1)
that facilitate development and execution of services on SWIM-enabled
systems and the migration of NAS systems to a SOA-based application.
SWIM exposes a Service (Information or Application Service) for Service
Providers and makes information about that Service available to known
and potential users through SWIM Core Capabilities during Service
development time. Service Consumers in turn use the Core Capabilities to
locate and download information about the exposed services to generate
and compile into appropriate interface codes to consume and reuse the
desired Service. The stated concept is the cornerstone of SOA-based
integration. In the SOA environment, one method of service
provision/consumption is the publish/subscribe model. Request/Reply is
another SOA method; SWIM will support both approaches.

When development of a SWIM Service is completed, the service will be
deployed and monitored on a NAS System platform in the run-time
environment by the SIPs. During service execution, the approved platform
will provide service monitoring in accordance with SWIM standards.

### Core Capability Descriptions

The following provides a top-level description of the SWIM Core
Capabilities. The use of specific Core Capabilities is dependent on the
business needs for each service. Every SIP developed NAS service will
not necessarily require every Core Capability or the same capability
level. Consequently, Core Capabilities will be subject to incremental
implementation as requirements and programmatic priorities dictate.

Four types of Core Capabilities are described below. Core Capabilities
isolate IT concerns from business concerns, allowing developers to focus
on applying service oriented principles to developing services without
being distracted by IT issues. It also promotes re-use of existing
services and the encapsulated infrastructure (Core Capabilities). This
generates cost savings, mitigates much of the integration technology
risk, and provides a point of control for implementing enterprise
guidance and integration patterns.

**Interface Management** includes capabilities (Service Design-Time
Environment) that enable Service Providers to expose services and
Service Consumers to find services. It includes supporting capabilities
such as descriptions of the services performed (typically, in a service
registry) and data exchange requirements to assist in interface
development. It also provides support for managing metadata such as the
schemas that define the format and semantics of interface data elements.

**Messaging** includes mechanisms (Service Run-Time Environment)
supporting a variety of service invocation styles (e.g.,
publish/subscribe, request/reply) and data exchange protocols. It
enables message routing including the structures and metadata supporting
routing and policy. Messaging capabilities can include delivery allowing
service consumers to receive queued messages after reconnecting to the
network. It provides Quality of Service (QoS) including priority and
response time.

**Security** includes mechanisms (Service Design-Time and Run-Time
Environments) to enforce security policies at the service and message
level including providing authorization-based access to data and
services. It ensures both Service Consumers and Service Providers can
verify identities, authenticate themselves and assert access privileges
via authorization; and ensures confidentiality of information exchanged
while invoking and consuming services. It also protects information
integrity, that is, guards against unauthorized modification of data and
services. SWIM security is focused on application-level interfaces and
messages consistent with enterprise SOA principles.

**Enterprise Service Management** (Service Design-Time and Run-Time
Environments) includes Governance and Monitoring. Governance manages
services across all service lifecycle phases based on conformance to
SWIM Policies and Guidelines in Service Design-Time. Monitoring is how
NAS system ensures the key requirements are met including the ability to
capture, view, and report on service performance and usage. QoS and
other performance metrics are defined and measured consistent with
system and service requirements and address items such as throughput,
reliability, availability, latency, response time, and fault data (e.g.,
for isolation and repair).

### SWIM Service Lifecycle Descriptions

The nature of how SWIM Core Capabilities are used depends on the mode of
operation. As mentioned above, Core Capabilities play a role in both
development and execution of services. To clarify the discussion, two
service lifecycle phases are defined: design-time and run-time.
Design-time refers to the development activities preceding operational
implementation of a service. Run-time refers to the activities during
routine service operations.

The following provides a description of each service lifecycle phase,
highlighting SWIM capabilities to help users create, expose, discover,
manage, invoke and consume services. Distinctions between design-time
and run-time capabilities are highlighted as appropriate.

#### Design-Time (Development of Services)

The development of services begins when an operational need is
identified and requirements are defined. Requirements are elaborated and
design decisions are made that shape the service delivery approach. In
particular, services can be developed independently but often will
leverage existing services to provide a composite capability. That is,
the service being developed can itself be a consumer of other services.

A service developer begins by using SWIM to discover available services.
For example, a developer who wants to create a service that can forecast
the arrival time of a flight at its destination airport may want to know
what services are available that model flight trajectories. The
developer will use SWIM discovery to learn about the relevant services
(e.g., through the service registry). Service descriptions are available
that detail the input, output and performance characteristics. When an
appropriate reusable service is discovered, the developer can download a
description of the service interface to enable it to be invoked by the
new service. Security policies applicable to the service are used to
ensure security-compliant service requirements are met. Similarly,
service development is required to be performed consistent with
applicable Governance policies and rules. Figure 2-2 provides an
illustration of service development.

[]{#__RefHeading___Toc186193998 .anchor}**Figure 2-2. Development of
Services**

In the design-time phase, the service description and service interface
specification are reviewed. Figure 2-3 provides an illustration of
service development, review and registration. Review and registration
are elements of design-time phase. Non-compliant services are rejected
and returned to the developers for correction. The Service reviewer is a
notional role within the COI or NAS domain that evaluates services for
compliance with applicable SWIM guidelines and policies.

[]{#__RefHeading___Toc186193999 .anchor}**Figure 2‑3. Registration of
Services**

![](media/image2.wmf){width="5.995833333333334in"
height="4.204861111111111in"}

#### 2.1.2.2 Run-Time (Deployment of Services) {#run-time-deployment-of-services .unnumbered}

Once a service is developed, approved, and registered it is placed at
the appropriate resource (e.g., computers, portals or server platforms)
for operational use. This defines the beginning of the run-time phase of
a SWIM-enabled Service. The SWIM Enterprise Service Management and the
Security Core Capabilities in each NAS platform, developed by SIPs in
accordance with SWIM standards, will monitor the latency, availability,
and performance characteristics.

Service exposure in the run-time phase occurs after the service has
satisfied all testing and review requirements in its native domain and
it is placed into operations. The location of run-time service access
point for the operational service is exposed for run-time service
execution.

# TECHNICAL REQUIREMENTS

The requirements for the SWIM Service Container (SC) are provided in the
table, below.

+-------------------------------------------------------+---+--------------+
| **Requirement Text**                                  |   | **M-Must     |
|                                                       |   | Have;**      |
|                                                       |   |              |
|                                                       |   | **D          |
|                                                       |   | -Desirable** |
+=======================================================+===+==============+
| **Portability**                                       |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  The Service Container (SC) shall operate on       |   |              |
|     heterogeneous software platforms, including the   |   |              |
|     following:                                        |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  on J2EE: servlet 2.x, EJB 2.x and 3               |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  on JVM: J2SE 1.4, J2SE 1.5, J2SE 1.6              |   | M            |
+-------------------------------------------------------+---+--------------+
| 3.  on .NET                                           |   | D            |
+-------------------------------------------------------+---+--------------+
| 2.  The SC shall be capable of hosting applications   |   |              |
|     written in the following languages:               |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  Java                                              |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  C#                                                |   | D            |
+-------------------------------------------------------+---+--------------+
| 3.  C++                                               |   | D            |
+-------------------------------------------------------+---+--------------+
| 4.  Other                                             |   | D            |
+-------------------------------------------------------+---+--------------+
| 3.  The SC shall be capable of the following:         |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  being deployed within application components      |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  being deployed within stand-alone applications    |   | M            |
+-------------------------------------------------------+---+--------------+
| 3.  being deployed within heavyweight application     |   | M            |
|     servers                                           |   |              |
+-------------------------------------------------------+---+--------------+
| 4.  being deployed within application appliances      |   | D            |
+-------------------------------------------------------+---+--------------+
| 4.  The SC shall provide a non-invasive Application   |   | D            |
|     Program Interface (API).\                         |   |              |
|     \                                                 |   |              |
|     Note: Non-invasive means the ability to make      |   |              |
|     configuration modifications or to extend          |   |              |
|     functionality with no additional coding required  |   |              |
|     for connectivity to the supporting                |   |              |
|     infrastructure.                                   |   |              |
+-------------------------------------------------------+---+--------------+
| 5.  The SC shall operate on the following Operating   |   |              |
|     Systems (OS):                                     |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  Red Hat Linux                                     |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  IBM AIX                                           |   | D            |
+-------------------------------------------------------+---+--------------+
| 3.  Sun Solaris                                       |   | D            |
+-------------------------------------------------------+---+--------------+
| 4.  Windows 2K3 Server                                |   | D            |
+-------------------------------------------------------+---+--------------+
| 5.  Other                                             |   | D            |
+-------------------------------------------------------+---+--------------+
| 6.  The SC shall not require proprietary APIs when    |   | D            |
|     interacting with internal components for          |   |              |
|     integration or extension of existing              |   |              |
|     capabilities.\                                    |   |              |
|     \                                                 |   |              |
|     Note: Partial support of the Java Business        |   |              |
|     Integration (JBI) specification for binding       |   |              |
|     components is an example of internal standards    |   |              |
|     based APIs for extension. The JBI Normalized      |   |              |
|     Message Router (NMR) is not required.             |   |              |
+-------------------------------------------------------+---+--------------+
| 7.  The SC shall support business logic, implemented  |   | M            |
|     as a simple class/object (.NET, Java, C++, C#),   |   |              |
|     to assure loose coupling of the business service  |   |              |
|     from the IT infrastructure.                       |   |              |
+-------------------------------------------------------+---+--------------+
| **Flexibility**                                       |   |              |
+-------------------------------------------------------+---+--------------+
| 8.  The SC shall be lightweight with respect to CPU,  |   | M            |
|     RAM, and bandwidth requirements. For example, it  |   |              |
|     must run within any of the specified deployment   |   |              |
|     options in Requirement 3, above, without          |   |              |
|     increasing the endpoint server CPU, RAM, and      |   |              |
|     bandwidth requirements by more than 10%.          |   |              |
+-------------------------------------------------------+---+--------------+
| **Distributed**                                       |   |              |
+-------------------------------------------------------+---+--------------+
| 9.  The SC shall provide a highly distributed service |   | M            |
|     infrastructure across both geography and network  |   |              |
|     topology.                                         |   |              |
+-------------------------------------------------------+---+--------------+
| 10. The SC shall be capable of being deployed as a    |   | M            |
|     managed proxy on a server separate from the       |   |              |
|     endpoint implementation server.                   |   |              |
+-------------------------------------------------------+---+--------------+
| **Pervasive**                                         |   |              |
+-------------------------------------------------------+---+--------------+
| 11. The SC shall directly enable service endpoints at |   | M            |
|     the point of implementation by supporting         |   |              |
|     distribution to every node that hosts one or more |   |              |
|     endpoints throughout the enterprise.              |   |              |
+-------------------------------------------------------+---+--------------+
| **Policy-centric**                                    |   |              |
+-------------------------------------------------------+---+--------------+
| 12. The SC shall have the ability for each SC         |   | M            |
|     instance to enforce enterprise policies at        |   |              |
|     endpoints.                                        |   |              |
+-------------------------------------------------------+---+--------------+
| **Modularity**                                        |   |              |
+-------------------------------------------------------+---+--------------+
| 13. The SC shall be modular in order to allow         |   |              |
|     selective deployment of the following Core        |   |              |
|     Services:                                         |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  Messaging: JMS v1.x, HTTP, ftp, SOAP              |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  Connectivity: JCA v1.x,                           |   | M            |
+-------------------------------------------------------+---+--------------+
| 3.  Enterprise Service Management (ESM): JMX v1.2     |   | M            |
+-------------------------------------------------------+---+--------------+
| 4.  Security: HTTP/S 1 & 1.1, TLS 1.0, PKCS #1, #5,   |   | D            |
|     #7, #10, #12, PKIX IETF RFC 2459, SSL 3.0, SAML   |   |              |
|     1.0 & 1.1, X.509, Kerberos 5.0, LDAP              |   |              |
+-------------------------------------------------------+---+--------------+
| 5.  Registry: UDDI v3                                 |   | M            |
+-------------------------------------------------------+---+--------------+
| 6.  WSDL v1.1                                         |   | M            |
+-------------------------------------------------------+---+--------------+
| **Scalability**                                       |   |              |
+-------------------------------------------------------+---+--------------+
| 14. The SC shall not prevent server clustering.       |   | M            |
+-------------------------------------------------------+---+--------------+
| **Security**                                          |   |              |
+-------------------------------------------------------+---+--------------+
| 15. The SC shall enable integration with the security |   | M            |
|     framework of the software platform (reference     |   |              |
|     Requirement 3, above) on which it is running.     |   |              |
+-------------------------------------------------------+---+--------------+
| 16. The SC shall provide role-based access control    |   | M            |
|     (RBAC) enforcement at the endpoint level, at the  |   |              |
|     operational level, and at the message level.      |   |              |
+-------------------------------------------------------+---+--------------+
| 17. The SC shall support message level security in    |   |              |
|     accordance with the following standards:          |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  OASIS WS-Security 1.1                             |   | D            |
+-------------------------------------------------------+---+--------------+
| 2.  W3C XML Signature                                 |   | D            |
+-------------------------------------------------------+---+--------------+
| 3.  W3C XML Encryption                                |   | D            |
+-------------------------------------------------------+---+--------------+
| 4.  OASIS Security Assertion Markup Language (SAML)   |   | D            |
+-------------------------------------------------------+---+--------------+
| 5.  Secure Sockets Layer v3 (SSLv3)                   |   | D            |
+-------------------------------------------------------+---+--------------+
| 6.  IETF RFC 2246 Transport Layer Security v1 (TLSv1) |   | D            |
+-------------------------------------------------------+---+--------------+
| 7.  WS-I Basic Security Profile version 1.1           |   | D            |
+-------------------------------------------------------+---+--------------+
| 8.  OASIS Extensible Access control Markup Language   |   | D            |
|     (XACML)                                           |   |              |
+-------------------------------------------------------+---+--------------+
| 18. The SC shall support the following transport      |   |              |
|     level security:                                   |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  RFC 2818: HTTP over TLS                           |   | D            |
+-------------------------------------------------------+---+--------------+
| 2.  RFC 2246: The TLS protocol Version 1.0            |   | D            |
+-------------------------------------------------------+---+--------------+
| 3.  The SSL Protocol Version 3.0                      |   | D            |
+-------------------------------------------------------+---+--------------+
| **Manageability**                                     |   |              |
+-------------------------------------------------------+---+--------------+
| 19. The SC shall be capable of integrating with       |   |              |
|     runtime Enterprise Service Management tools for   |   |              |
|     monitor and control, including the following:     |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  Tivoli                                            |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  HP Openview                                       |   | M            |
+-------------------------------------------------------+---+--------------+
| 3.  Amberpoint                                        |   | D            |
+-------------------------------------------------------+---+--------------+
| 4.  Actional                                          |   | D            |
+-------------------------------------------------------+---+--------------+
| 5.  SOA Operations                                    |   | D            |
+-------------------------------------------------------+---+--------------+
| 6.  Others                                            |   | D            |
+-------------------------------------------------------+---+--------------+
| 20. The SC shall support JMX 1.2 for java endpoints   |   | M            |
|     mechanism for providing Enterprise Service        |   |              |
|     Management (ESM) capabilities.                    |   |              |
+-------------------------------------------------------+---+--------------+
| 21. The SC shall support the simple network           |   | D            |
|     management protocol (SNMP).                       |   |              |
+-------------------------------------------------------+---+--------------+
| 22. The SC shall provide the capability to manage     |   | D            |
|     multiple Business service versions.               |   |              |
+-------------------------------------------------------+---+--------------+
| 23. The SC shall distinguish between exception types  |   | D            |
|     and provide the means for applying exception      |   |              |
|     handling actions.                                 |   |              |
|                                                       |   |              |
| Note: Exception handling actions include route, log,  |   |              |
| and process.                                          |   |              |
+-------------------------------------------------------+---+--------------+
| **Monitoring**                                        |   |              |
+-------------------------------------------------------+---+--------------+
| 24. The SC shall expose information necessary for     |   | M            |
|     calculating Quality of Service (QoS) metrics for  |   |              |
|     assuring Service Level Agreement (SLA)            |   |              |
|     compliance.\                                      |   |              |
|     \                                                 |   |              |
|     Note: Exposing information does not include       |   |              |
|     aggregation of data or calculations necessary for |   |              |
|     SLA compliance assessment.                        |   |              |
+-------------------------------------------------------+---+--------------+
| 25. The SC shall provide information to monitor the   |   |              |
|     load on the service provider for SLA reporting    |   |              |
|     purposes. Specifically, the SC shall be able to   |   |              |
|     measure the following:                            |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  number of consumers on an individual endpoint     |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  number of messages (inbound/outbound) on an       |   | M            |
|     individual endpoint                               |   |              |
+-------------------------------------------------------+---+--------------+
| 3.  Response time (not end-to-end, but service        |   | M            |
|     execution time, only).                            |   |              |
+-------------------------------------------------------+---+--------------+
| **Control**                                           |   |              |
+-------------------------------------------------------+---+--------------+
| 26. The SC shall accommodate implementation of QoS    |   |              |
|     through control of endpoint policies for:         |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  Security policy                                   |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  Transport Policy                                  |   | D            |
+-------------------------------------------------------+---+--------------+
| 3.  Business Policy                                   |   | D            |
+-------------------------------------------------------+---+--------------+
| 27. The SC shall provide throttling as a means to     |   | D            |
|     control the load on services.                     |   |              |
+-------------------------------------------------------+---+--------------+
| **Federation**                                        |   |              |
+-------------------------------------------------------+---+--------------+
| 28. The SC shall encapsulate IT infrastructure to     | M |              |
|     enable an integrated, federated, and consistent   |   |              |
|     environment for messaging, security and           |   |              |
|     enterprise management.                            |   |              |
+-------------------------------------------------------+---+--------------+
| **Integration**                                       |   |              |
+-------------------------------------------------------+---+--------------+
| 29. The SC shall enable event driven integration in   |   | M            |
|     order to minimize coupling between Systems and    |   |              |
|     Software components.                              |   |              |
+-------------------------------------------------------+---+--------------+
| 30. Users shall be able to implement RESTful web      |   | M            |
|     service architectures with the SC.                |   |              |
+-------------------------------------------------------+---+--------------+
| 31. The SC shall be capable of hosting long running   |   | D            |
|     business process orchestration, including batch   |   |              |
|     processes.\                                       |   |              |
|     \                                                 |   |              |
|     Note: A long running business process is any      |   |              |
|     process that may have an indefinite delay because |   |              |
|     of external dependencies.                         |   |              |
+-------------------------------------------------------+---+--------------+
| 32. The SC shall provide enterprise integration       |   | D            |
|     patterns (Hohpe) for building services from       |   |              |
|     software components and other services.           |   |              |
|                                                       |   |              |
| Refer to                                              |   |              |
| <htt                                                  |   |              |
| p://www.enterpriseintegrationpatterns.com/index.html> |   |              |
| for additional information on the integration         |   |              |
| patterns.                                             |   |              |
+-------------------------------------------------------+---+--------------+
| 33. Web services implemented with the SC shall be     |   | M            |
|     compliant with the WS-I Basic Profile 1.2.        |   |              |
+-------------------------------------------------------+---+--------------+
| **SOA Orchestration**                                 |   |              |
+-------------------------------------------------------+---+--------------+
| 34. The SC shall support Business Process Execution   |   | D            |
|     Language (BPEL) for service level orchestration.  |   |              |
+-------------------------------------------------------+---+--------------+
| **Invocation**                                        |   |              |
+-------------------------------------------------------+---+--------------+
| 35. The SC shall encapsulate how a consumer binds to  |   | M            |
|     the service endpoint to enable location           |   |              |
|     independent service invocation (discovery and     |   |              |
|     binding to other services).                       |   |              |
+-------------------------------------------------------+---+--------------+
| 36. The SC shall be compatible with the WS-Addressing |   | M            |
|     Specification.                                    |   |              |
+-------------------------------------------------------+---+--------------+
| 37. The SC shall perform conversion between           |   | M            |
|     synchronous and asynchronous invocations.         |   |              |
+-------------------------------------------------------+---+--------------+
| **Decoupling**                                        |   |              |
+-------------------------------------------------------+---+--------------+
| 38. The SC shall encapsulate the supporting           |   | M            |
|     enterprise IT infrastructure making the IT        |   |              |
|     infrastructure pluggable, to support decoupling   |   |              |
|     of ATM services from Core Services.               |   |              |
+-------------------------------------------------------+---+--------------+
| 39. The SC shall encapsulate the IT technologies      |   | M            |
|     within the IT infrastructure to support           |   |              |
|     modularity of IT infrastructure technology.       |   |              |
+-------------------------------------------------------+---+--------------+
| **Transformation**                                    |   |              |
+-------------------------------------------------------+---+--------------+
| 40. The SC shall support transformation of one        |   | M            |
|     message format to another message format (e.g.,   |   |              |
|     data mapper or transformation) for the purpose of |   |              |
|     providing data mediation.                         |   |              |
+-------------------------------------------------------+---+--------------+
| **Virtualization**                                    |   |              |
+-------------------------------------------------------+---+--------------+
| 41. The SC shall encapsulate concerns regarding       |   | M            |
|     location, versioning, configuration management,   |   |              |
|     deployment, configuration and availability of     |   |              |
|     services.                                         |   |              |
+-------------------------------------------------------+---+--------------+
| **Availability**                                      |   |              |
+-------------------------------------------------------+---+--------------+
| 42. The SC shall enable active failover to a          |   | D            |
|     different service endpoint implementation.\       |   |              |
|     \                                                 |   |              |
|     Note: This means that a failed service invocation |   |              |
|     can automatically invoke another endpoint         |   |              |
|     instance of the same service to satisfy the       |   |              |
|     request.                                          |   |              |
+-------------------------------------------------------+---+--------------+
| **Messaging**                                         |   |              |
+-------------------------------------------------------+---+--------------+
| 43. Web services implemented with the SC shall be     |   | M            |
|     capable of complying with the SOAP 1.1 standard.  |   |              |
+-------------------------------------------------------+---+--------------+
| **Transport**                                         |   |              |
+-------------------------------------------------------+---+--------------+
| 44. The SC shall have the ability to route messages   |   | M            |
|     between each SC instance.                         |   |              |
+-------------------------------------------------------+---+--------------+
| 45. The SC shall support multiple application         |   |              |
|     transport protocols declaratively.\               |   |              |
|     \                                                 |   |              |
|     Note: Support means that a service implemented    |   |              |
|     with the SC will be able to accept requests on    |   |              |
|     any supported protocol.                           |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  PoX/HTTP(S)                                       |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  PoX/JMS                                           |   | M            |
+-------------------------------------------------------+---+--------------+
| 3.  SOAP/HTTP(S)                                      |   | M            |
+-------------------------------------------------------+---+--------------+
| 4.  SOAP/JMS                                          |   | M            |
+-------------------------------------------------------+---+--------------+
| 5.  ftp                                               |   | M            |
+-------------------------------------------------------+---+--------------+
| 6.  RMI (for java endpoints)                          |   | D            |
+-------------------------------------------------------+---+--------------+
| 7.  IIOP                                              |   | D            |
+-------------------------------------------------------+---+--------------+
| 46. The SC shall support application transport        |   | M            |
|     extension and customization.\                     |   |              |
|     \                                                 |   |              |
|     Note: The goal is to be able to add new protocols |   |              |
|     as they emerge, or to add standardized features   |   |              |
|     for how supported protocols are handled.          |   |              |
+-------------------------------------------------------+---+--------------+
| 47. The SC shall provide transport conversion between |   | M            |
|     supported protocols declaratively; e.g.,          |   |              |
|     SOAP/HTTP to SOAP/JMS.\                           |   |              |
|     \                                                 |   |              |
|     Note: WS-Addressing to be used for different      |   |              |
|     transports for request and reply.                 |   |              |
+-------------------------------------------------------+---+--------------+
| 48. The SC shall be able to use multiple              |   |              |
|     message-oriented middleware for transport,        |   |              |
|     including the following:\                         |   |              |
|     \                                                 |   |              |
|     Note: This is use of the middleware by the SC for |   |              |
|     external transport to another endpoint.           |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  IBM MQ                                            |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  ActiveMQ                                          |   | M            |
+-------------------------------------------------------+---+--------------+
| 3.  JMS                                               |   | M            |
+-------------------------------------------------------+---+--------------+
| 49. The SC shall support WS-Reliable Messaging over   |   | D            |
|     SOAP/HTTP.                                        |   |              |
+-------------------------------------------------------+---+--------------+
| 50. The SC shall work with push/pull, pub/sub,        |   | M            |
|     request/reply, and synchronous /asynchronous      |   |              |
|     invocation styles.                                |   |              |
+-------------------------------------------------------+---+--------------+
| 51. The SC shall provide a library of technology      |   | D            |
|     adapters, including the following:                |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  CORBA                                             |   | D            |
+-------------------------------------------------------+---+--------------+
| 2.  Other                                             |   | D            |
+-------------------------------------------------------+---+--------------+
| 52. The SC shall support WS-Notification.             |   | D            |
+-------------------------------------------------------+---+--------------+
| 53. The SC shall support at least one of the          |   | M for the    |
|     following two SOAP message attachment protocols:  |   | first, D for |
|                                                       |   | the second   |
|     1.  either Message Transmission Optimization      |   |              |
|         Mechanism (MTOM), or                          |   |              |
|                                                       |   |              |
|     2.  SOAP with Attachments.                        |   |              |
|                                                       |   |              |
| > Note: Either MTOM or SOAP with Attachments is       |   |              |
| > required. If either one is supported, then the      |   |              |
| > other is only desired.                              |   |              |
+-------------------------------------------------------+---+--------------+
| 54. The SC shall provide support for content based    |   | M            |
|     routing.                                          |   |              |
+-------------------------------------------------------+---+--------------+
| **Integrated Development Environment (IDE)**          |   |              |
+-------------------------------------------------------+---+--------------+
| 55. SC development components shall integrate with    |   |              |
|     other IDEs, including:                            |   |              |
+-------------------------------------------------------+---+--------------+
| 1.  Eclipse                                           |   | M            |
+-------------------------------------------------------+---+--------------+
| 2.  JDeveloper                                        |   | D            |
+-------------------------------------------------------+---+--------------+
| 3.  Others                                            |   | D            |
+-------------------------------------------------------+---+--------------+

# Appendix A -- Acronyms {#appendix-a-acronyms .unnumbered}

#  {#section .unnumbered}

AIM Aeronautical Information Management

AOP Aspect Oriented Programming

API Application Program Interface

ATC Air Traffic Control

ATM Air Traffic Management

BPEL Business Process Execution Language

CIWS Corridor Integrated Weather System

CM Configuration Management

COI Community of Interest

CORBA Common Object Request Broker Architecture

COTS Commercial off the Shelf

CPU Central Processing Unit

DOT Department of Transportation

ERAM En Route Automation Modernization

ESM Enterprise Service Management

FAA Federal Aviation Administration

F&FM Flight and Flow Management

HP Hewlett Packard

HTTP Hypertext Transfer Protocol

IBM MQ IBM Message Queue

iCMM FAA-Integrated Capability Maturity Model

IDE Integrated Development Environment

IEEE Institute of Electrical and Electronics Engineers

IT Information Technology

ITWS Integrated Terminal Weather System

JBI NMR Java Business Integration Normalized Message Router

JMS Java Message Service

JMX Java Management Extensions

MTOM Message Transmission Optimization Mechanism

NAS National Airspace System

NextGen Next Generation Air Transportation System

OS Operating System

PoX Plain Old XML

QoS Quality of Service

RAM Random Access Memory

RFC Request for Comments

RMI Remote Method Invocation

SAML Security Assertion Markup Language

SC Service Container

SIP SWIM Implementing Program

SLA Service Level Agreement

SNMP Simple Network Management Protocol

SOA Service-Oriented Architecture

SOAP Simple Object Access Protocol

SSL Secure Sockets Layer

SWIM System Wide Information Management

TBD To Be Determined

TFMS Traffic Flow Management System

TLS Transport Layer Security

URL Uniform Resource Locator

WMSCR Weather Message Switching Center Replacement

WS Web Service

WSDL Web Services Description Language

XACML Extensible Access Control Markup Language

XML Extensible Markup Language