Extensible Framework

16 SPIs and 3 extension points. Your service implements only what differs.

Extensible Architecture

Build Once, Extend for Any Service

Service-specific logic is isolated into three consumer extension points (EP1, EP2, EP3), each delivered as an independent Maven module. Adding a dependency activates the extension; switching a transport requires only a dependency swap, with zero changes to business logic.

EP SPI Purpose Default Module
EP1 SwimInboxStore Persist received AMQP message to a durable inbox store swim-inbox-store-kafka
EP2 SwimInboxReader Read from inbox, deserialise envelope, dispatch to pipeline swim-inbox-reader-kafka
EP3 SwimOutboxRouter Route validated domain event to output destinations. Fan-out: multiple implementations run in parallel with independent timeouts. Failure in one router does not affect others. swim-outbox-kafka-dnotam / ed254
Extensible Architecture: Common Framework + Service-Specific Extensions CONSUMER Common Framework (Designed for Yellow Profile) Built-in Capabilities: Subscription Manager AMQP Consumer mTLS Security Inbox/Outbox Fault Tolerance Observability Health Checks 12-Factor / Cloud-Native Extension Points (EP1 → EP2 → EP3 + SPIs) • Inbox Store (EP1) • Inbox Reader (EP2) • Event Extractor • Payload Validator • Outbox Router (EP3) (SwimInboxStore) (AbstractKafkaInboxReader) (SwimEventExtractor) (SwimPayloadValidator) (SwimOutboxRouter) DNOTAM Module AIXM 5.1.1 schemas Scenario-based routing Event enrichment ED-254 Module FIXM schemas Airport-based routing Sequence enrichment MET Module IWXXM schemas Weather-based routing METAR/TAF enrichment PROVIDER Common Framework (Designed for Yellow Profile) Built-in Capabilities: Subscription CRUD Queue Manager mTLS + OIDC JWT Validation AMQP Publisher State Machine Observability 12-Factor / Cloud-Native Extension Points (5 Interfaces to Implement) • Event Ingress • Payload Validator • Event Extractor • Queue Provisioning • Outbox Router (SwimIngressHandler) (SwimPayloadValidator) (SwimEventExtractor) (QueueProvisioningStrategy) (SwimOutboxRouter) DNOTAM Module AIXM validation Scenario-based queues Event filtering ED-254 Module FIXM validation Airport-based queues Sequence filtering MET Module IWXXM validation Weather-based queues METAR/TAF filtering Resulting Container Images swim-dnotam-consumer Framework + DNOTAM ext. swim-ed254-consumer Framework + ED-254 ext. swim-met-consumer Framework + MET ext. swim-dnotam-provider Framework + DNOTAM ext. swim-ed254-provider Framework + ED-254 ext. swim-met-provider Framework + MET ext. Deployment Model: Same Image, Different Configurations Development Pulls: swim-dnotam-consumer AISP_URL=https://aisp.dev.local KAFKA_BROKERS=kafka.dev.local MONGO_URI=mongodb://db.dev.local UAT Pulls: swim-dnotam-consumer AISP_URL=https://aisp.uat.local KAFKA_BROKERS=kafka.uat.local MONGO_URI=mongodb://db.uat.local Pre-Production Pulls: swim-dnotam-consumer AISP_URL=https://aisp.preprod.local KAFKA_BROKERS=kafka.preprod.local MONGO_URI=mongodb://db.preprod.local Production Pulls: swim-dnotam-consumer AISP_URL=https://ead.eurocontrol.int KAFKA_BROKERS=kafka.prod.local MONGO_URI=mongodb://db.prod.local

Implement Once

Yellow Profile complexity (mTLS, AMQP, subscriptions, resilience) is implemented once in the framework. Services inherit it.

Fan-out Delivery (EP3)

Add any number of SwimOutboxRouter implementations. The framework delivers to all of them in parallel with independent timeouts.

Environment-Aware Provisioning

Dev uses Jolokia JMX for local Artemis. Prod uses Kubernetes Secrets + AMQ Operator. Same security model, different infrastructure.