Skip to content

Datalex airline-retailing modernization: EJB/Java 8 → Spring Boot/Java 21 via AWS EBA + agentic AI

Summary

Datalex — an airline-ecommerce platform that powers shopping, pricing, and booking for many of the world's leading airlines — needed to modernize a two-decades-old, mission-critical Java 8 / EJB2 n-tier system toward the industry's Modern Airline Retailing (offers-and-orders) model without disrupting airline operations running on it around the clock. In a three-day AWS Experience-Based Acceleration (EBA) workshop (Dublin, Dec 2025; 16 Datalex engineers + 6 AWS specialists), four parallel workstreams proved feasibility end-to-end on one slice (the Reservation component): extract it into a Spring Boot / Java 21 microservice, front the old and new implementations with a business service proxy so traffic can be routed per-service (Strangler Fig), wrap it in a shift-left DevSecOps pipeline, add observability, and layer an agentic-AI natural-language booking interface on top. The article's durable system-design content is the incremental monolith→ microservices migration mechanism (proxy-routed Strangler Fig over a tightly-coupled n-tier codebase), plus the measured runtime wins from the Java 8→21 / EJB→Spring jump. The surrounding EBA / "agentic AI accelerated it" framing is delivery-process narrative.

Key takeaways

  1. Strangler Fig via a business service proxy is the core migration mechanism. A business service proxy routes each incoming request to either the existing n-tier system or the new Spring Boot microservice based on migration status, so services move one at a time with no big-bang cutover and existing airline operations stay live. AWS advised implementing a gateway that could route to the old REST API or the modernized API "through a simple parameter change," enabling rapid non-regression testing within the 3-day window. (Source: sources/2026-10-01-aws-accelerating-airline-retailing-innovation-datalex-modernization)
  2. A compatibility runtime let existing code run on modern tech with minimal change. The Modernization Assessment (MODA) found that by building a compatible runtime environment, most of the existing code could run on modern technologies with minimal modification — evidence the foundations were sound and could be a stepping stone rather than a rewrite-from-scratch. Remaining code changes were automated with AI coding assistants (Amazon Q Developer, Kiro).
  3. Runtime modernization delivered measured wins. Java 8 → Java 21 (virtual threads for concurrency, optimized GC) + EJB2 → Spring Boot: 35% reduction in memory footprint vs the prior JBOSS deployment, 60% faster startup, and smaller locally-testable components. (Source: sources/2026-10-01-aws-accelerating-airline-retailing-innovation-datalex-modernization)
  4. Shift-left DevSecOps cut deployment from hours to <10 min. A CodeBuild-triggered pipeline embeds security at every stage: dependency + static analysis on commit, ECR image scanning, Terraform IaC security scanning, with findings aggregated in AWS Security Hub. Supports blue/green (zero-downtime), canary, and rolling deploys with native ECS rollback.
  5. Target runtime = containers on ECS/Fargate, decoupled by Kafka. Spring Boot microservices run as Docker containers on ECS Fargate (multi-AZ, CPU/memory auto scaling), avoiding JBOSS-on-EC2 operational overhead; Apache Kafka provides asynchronous, decoupled event-driven messaging between old and new components.
  6. Agentic AI layers onto — not into — the modernized system. A Bedrock AgentCore orchestrator coordinates three specialized agents (authentication, data retrieval, reporting — specialized-agent decomposition) that reach existing Datalex REST APIs through the AgentCore Gateway, with an MCP Gateway (MCP as integration proxy) mediating agent↔REST calls, secured by Cognito and Kong API Gateway. A conversational booking-retrieval interface translates natural language into API calls.
  7. Kong provides REST↔SOAP protocol translation during migration. The target architecture uses Kong API Gateway for protocol translation between REST and SOAP while supporting dynamic routing between existing and modernized services — a concrete instance of a gateway preserving existing interfaces while routing to new implementations (backward compatibility).
  8. Prove on one service before planning the full migration. The stated lessons: (1) prove it works end-to-end on one service first; (2) have the team in the room during migration (docs don't capture the decisions that matter); (3) add security + monitoring during the migration, not after. The established pattern now targets the remaining ~4 million lines of code.

Architecture

Request flow and components (Figure 1 in the post):

  • Demo app — Angular frontend demonstrating the modernized UX.
  • Business service proxy — request traffic controller; routes to the existing n-tier system or the new Spring Boot microservices based on per-service migration status. This is the Strangler Fig routing point.
  • Agent orchestrator — Amazon Bedrock / AgentCore coordinating authentication, data-retrieval, and reporting agents, calling both old and new services through the API Gateway + proxy.
  • Modernized services — Spring Boot (SOAP connector + core services) replacing EJB components, on ECS/Fargate.
  • Current n-tier architecture — existing services keep operating, incrementally replaced; each migrated service is tested before the next.
  • Event-driven messaging — Apache Kafka for async communication between decoupled components.
  • Observability stack — CloudWatch (Container Insights + Logs), Amazon Managed Grafana, AWS X-Ray, plus Datadog APM distributed tracing; CloudWatch Synthetics for proactive endpoint checks; an artificial booking generator to drive load without production-like data.
  • Security infrastructure — Secrets Manager (credentials for both old and new) + IAM.
  • Deployment sources — CI/CD from GitHub, ECR, and Terraform.

The migration pattern, now repeatable: identify bounded contexts → extract business logic with dependency analysis → refactor to Spring patterns → containerize with security hardening → deploy via automated pipeline, running in parallel with the existing system during transition.

Operational numbers

  • 35% reduction in memory footprint (Spring/Java 21 vs JBOSS).
  • 60% faster startup with Java 21 optimizations.
  • Deployment time: hours → under 10 minutes.
  • Migration done in the workshop: EJB/Java 8 → Spring Boot/Java 21 for the Reservation slice in 3 days (vs an estimated 8–12 weeks just to validate extractability independently).
  • Remaining codebase to migrate: ~4 million lines of code.
  • EBA workshop: 16 Datalex + 6 AWS; CSAT 4.9/5.0, 98% "extremely satisfied."

Caveats

  • This is an AWS EBA case study / reference architecture, not a production retrospective. The performance figures (35% memory, 60% startup, <10-min deploys) are workshop/prototype measurements on a single extracted component (Reservation), not steady-state production metrics at airline scale; no baseline methodology is disclosed.
  • CSAT (4.9/5.0) and "weeks → a day" productivity claims are engagement-satisfaction and anecdote, not system metrics.
  • The business service proxy is described functionally (routes old-vs-new by migration status, parameter-flipped) but no internal design, latency overhead, or SOAP↔REST translation cost is given.
  • The agentic-AI workstream is an explicit proof of concept (conversational booking retrieval), not deployed to airline customers.
  • Only Datalex-reported outcomes; no independent validation.

Source

Last updated · 766 distilled / 2,225 read