Reference Architecture

Each component deploys independently. An ANSP uses the consumer. An AISP uses the provider. Both share the same framework.

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, ED-254, and FF-ICE, with the same architecture applicable to MET 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 SWIM 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.

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 container images. Deploy on Kubernetes, Podman, Docker, or run as standalone Java services.

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 PROVIDER VALIDATOR (Simulates an external consumer connecting to the 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.

Tech Stack

Technologies Used

All components were developed and tested using enterprise-grade downstream versions. The upstream (community) versions are fully compatible and can be used without vendor dependency.

Category Upstream (Community) Downstream (Enterprise)
Application Framework Quarkus Red Hat Build of Quarkus
Message Broker (AMQP) Apache ActiveMQ Artemis Red Hat AMQ Broker
Event Streaming Apache Kafka Red Hat AMQ Streams
Identity & Access Keycloak Red Hat Build of Keycloak
Document Database MongoDB MongoDB (UBI Container)
Relational Database PostgreSQL PostgreSQL (UBI Container)
Certificate Management cert-manager cert-manager Operator for Red Hat OpenShift
Container Registry Quay.io Red Hat Quay
Container Platform Kubernetes Red Hat OpenShift
Observability OpenTelemetry, Prometheus, Loki, Tempo, Grafana OpenShift Logging, OpenShift Observability

No Vendor Lock-in: While components were validated using Red Hat downstream versions, upstream community versions are fully compatible. No vendor dependency is required.