5. Entity Relationships

5.1 Persistent Logical Structure

The logic of the Mobius HTTP Gateway stack follows this strict hierarchical relationship:

Key Rules:

• Every HttpLink must reference both a destinationID and a serverID.
• Each HttpServer must have a unique serviceName within its Destination.
• Each HttpDestination must have a unique destinationName.

5.2 Runtime Operational Mapping

At runtime, HttpStandaloneServer constructs in-memory mappings based on the persisted entities, using HttpServerData containers per local port.

Request flow at runtime:

• Incoming HTTP request matches a HttpLink by URL and remoteHost.
• The HttpLink leads to a HttpServer via serverID.
• The HttpServer provides the serviceName needed to lookup a registered callback.
• If mapping is successful, request payload is delivered to the correct callback asynchronously.

If any step fails (e.g., missing Link, missing Server, missing Callback), the Gateway responds with an appropriate HTTP error (e.g., 404 or 500).

5.3 Design Rationale

All structural components — Destinations, Servers, and Links — are stored persistently in the database. This allows configuration to be safely versioned, backed up, and programmatically updated without affecting active traffic. 
At runtime, these components are loaded into a lightweight container called HttpServerData, which maintains: 

• activeLinks – runtime-resolved links by URI and host.
• serversMap – map of serverID → HttpServer.
• registeredCallbacks – dynamic lookup of (destinationID, serviceName) → HttpCallbackInterface.

These allow the Gateway to make routing decisions in constant time, avoiding database lookups during live traffic handling.

Mobius HTTP Gateway follows the stateless HTTP model: each incoming request is processed independently without relying on server-side session state. Request routing is determined by matching the URL path and remote host to a registered HttpLink, followed by mapping that link to a HttpServer (based on serviceName) and then to an application callback.

Since routing depends only on the in-memory structures and request contents — not on persistent state — multiple Mobius HTTP Gateway instances can run in parallel. These instances can share the same database configuration backend and safely load-balance traffic, be horizontally scaled up or down, be restarted or updated independently without impacting others.

New configurations — such as enabling a new Destination, adding a new Server, or creating a new inbound/outbound Link — can be applied at runtime. This is achieved by persisting changes via the management API/UI and reloading only the affected runtime structures in-memory (HttpServerData), without restarting the entire JVM or disrupting active connections.

Developers can register and deregister HttpCallbackInterface implementations at runtime using the registerCallbackInterface(destinationID, serviceName, callback) method. This allows application logic to evolve dynamically (e.g., enabling/disabling specific service handlers) without touching core routing.