Reference Architecture

Deployment patterns, modular design, and infrastructure overview

Power of Community

Collaborative Development

SWIM adoption accelerates when ATM entities collaborate. Our modular architecture enables different organizations to develop independent components that integrate seamlessly into a unified solution. The framework supports any SWIM service—current implementations include DNOTAM and ED-254, with the same architecture applicable to MET, Flight Data, and other services.

Modular Architecture

Demo Environment — This diagram shows all components deployed together for validation and testing. In production, Consumer and Provider are deployed independently by different organizations.

Demo Environment (single cluster deployment for validation) Internal to organization - NOT external SWIM communication Provider Validator Test Client Manage Subscriptions Event Streaming SWIM Provider SWIM API Subscription Manager WFS GetFeature Event Publisher Outbox Business Component Event Bus (Apache Kafka) SWIM Consumer Manage Subscriptions Event Processor XSD + Pluggable Rules Inbox/Outbox Consumer Validator Simulates AISP Subscription API Event Generator Provider Infrastructure AMQP Broker (Artemis) PostgreSQL Consumer Infrastructure Document Store (MongoDB) Consumer Validator Infra AMQP Broker (Artemis)

Understanding the Deployment Scenarios

ANSP (Consumer Only)

Air Navigation Service Providers deploy only the Consumer module. It connects to an external AISP (like EUROCONTROL EAD) via AMQP to receive DNOTAM events. Kafka distributes events to internal ATM systems.

AISP (Provider Only)

Aeronautical Information Service Providers deploy only the Provider module. It receives events from internal systems via Kafka and exposes SWIM-compliant APIs (AMQP pub/sub + REST) to external consumers.

Demo Environment (Both)

For validation and testing, all components deploy together in a single cluster. Consumer Validator simulates an AISP provider for testing consumers. Provider Validator tests provider implementations. This enables end-to-end testing without real infrastructure.

Consumer + Provider Together: Real-World Scenarios

While Consumer and Provider are typically deployed by different organizations, there are valid operational scenarios where the same organization deploys both:

  • National AIS Hub: A national authority receives events from EUROCONTROL EAD (Consumer) and redistributes to local ANSPs and airports (Provider).
  • Regional Aggregator: A regional entity consolidates events from multiple national AISPs and provides unified access to regional consumers.
  • Enterprise Integration: A large airline receives DNOTAM events (Consumer) and redistributes to internal dispatch centers and crew systems (Provider).
  • Data Enrichment: An organization receives raw events, enriches them with local data, and republishes enhanced events.

Note: This project focuses on demonstrating technical capabilities for SWIM compliance. The operational validity of specific scenarios should be verified with domain experts and relevant aviation authorities.

Modular by Design

Each component is an independent, containerized module. One organization can focus on the Provider implementation—exposing SWIM-compliant interfaces and managing subscriptions—while another develops the Consumer module for receiving and processing events.

Both teams contribute to the same ecosystem: source code is shared on GitHub, and container images are published to a common registry. The result? A complete SWIM solution built through distributed collaboration.

Open Source Collaboration

All source code is available under the BSD 3-Clause License. Organizations are free to use, modify, and redistribute the code. Each member chooses their preferred technology stack—as long as the container interfaces remain compatible, the modules integrate seamlessly.

Secure Container Registry

All container images are published to Quay.io, an enterprise-grade registry with built-in security features:

Vulnerability Scanning

Automatic security analysis using Clair, detecting CVEs in base images and dependencies

Image Signing

Cryptographic signatures ensure image integrity and provenance verification

Health Indicators

Visual security status for each image—green, yellow, or red based on vulnerability severity

Immutable Tags

Version control with immutable digests prevents accidental overwrites

Automated Builds

CI/CD integration triggers rebuilds when base images are updated

Source Code

All modules are open source. Fork, contribute, or use as reference for your implementation.

github.com/swim-developer

Container Images

Pre-built, scanned, and signed images ready to deploy on any Kubernetes cluster.

quay.io/swim-developer

Join the Effort

ANSPs, vendors, and developers can contribute modules, tests, or documentation.

See how to contribute
How It Works

Reference Architecture

SWIM Reference Architecture — Independent Modules ROLE 1: Your Organization as a CONSUMER CONSUMER (Independent production module) INPUT (from any AISP/EAD) • REST client for subscriptions • AMQP consumer for events OUTPUT (to internal systems) • Kafka topics by business intent • GraphQL API for queries • REST API for management PROCESSING • Inbox pattern (AMQP → MongoDB) • XSD + business rules (pluggable) • Fault tolerance (retry, DLQ) PERSISTENCE • MongoDB (subscriptions, events) • Outbox pattern (MongoDB → Kafka) Connects to & consumes from EXTERNAL AISP / EAD Production: EUROCONTROL EAD, National AIS, or other certified AISP or simulate with VALIDATOR (Simulates an AISP/EAD for dev/testing) • Subscription Manager API (REST) • Integrated Artemis AMQP broker • Event generator (configurable) • 82 sample AIXM events included • Scenario simulator • Lightweight container (~50MB) Optional ROLE 2: Your Organization as a PROVIDER PROVIDER (Independent production module) EXTERNAL API (SWIM Compliant) • Subscription Manager API • WFS GetFeature (OGC) • HTTPS + mTLS + OIDC/JWT INTERNAL INPUT • Kafka consumer (internal topics) • REST API (direct publish) QUEUE MANAGEMENT • Auto queue creation via AMQ Operator • Security roles per subscriber • Durable/non-durable support SECURITY • mTLS (client certificates) • OIDC/JWT (any OIDC provider) • Role-based queue access PERSISTENCE • PostgreSQL (subscriptions) • Subscription state machine DISTRIBUTION • AMQP 1.0 via AMQ Broker • Per-subscriber queues Distributes events to EXTERNAL CONSUMERS ANSPs, Airport Operators, Airlines, or any authorized subscriber or test with MOCKCLIENT (Simulates an External Consumer connecting to Provider) • Subscription CRUD operations • Real-time event streaming (SSE) • Interactive web UI + mTLS proxy • Load and contract testing Optional ℹ️ Consumer and Provider are independent modules with no direct coupling. Integration happens through Kafka topics: Consumer publishes to business topics, Provider reads from delivery-ready topics. Configure Provider to read from Consumer's topics for end-to-end integration without intermediaries. Deploy Consumer only, Provider only, or both. INFRASTRUCTURE (Shared across all modules) Cert-Manager (Automated PKI for all components) • Auto-generation of certificates • Auto-renewal before expiration • mTLS everywhere • EACP-ready PKI Observability Stack Prometheus Tempo Loki Grafana OpenTelemetry OpenShift

mTLS Everywhere

All service-to-service communication secured with mutual TLS via cert-manager; PKI ready for EACP integration.

Event-Driven

AMQP for external SWIM network communication; Kafka for internal event streaming and module integration.

Full Observability

Metrics, traces, and logs correlated for complete operational visibility.

Ready to Deploy?

Start with our getting started guide or explore the framework architecture

Getting Started Framework Overview