Protocol Mediation
Bridge legacy and modern systems without rewriting code.
Hexarch’s Protocol Mediation transforms requests between protocols at the gateway—REST to SOAP, MQTT to Kafka, JSON to XML—so your modern clients can talk to legacy backends, and vice versa.
How it works
- Inbound request arrives in one protocol (e.g., REST/JSON)
- Gateway transforms the request to the target protocol (e.g., SOAP/XML)
- Backend processes the transformed request
- Response transforms back to the original protocol
- Client receives a response in the format it expects
No code changes in the client. No code changes in the backend. The gateway handles translation.
Supported protocols
Inbound (client-facing)
- REST (JSON)
- GraphQL
- gRPC
- MQTT
- WebSocket
Outbound (backend-facing)
- SOAP (XML)
- HTTP (legacy REST)
- AMQP
- Kafka
- gRPC
Common mediation scenarios
REST-to-SOAP
Your modern frontend speaks REST. Your backend is a legacy SOAP service.
Without mediation:
- Frontend learns SOAP
- Or you build a translation service
- Either way, code changes and maintenance
With Hexarch:
- Gateway transforms JSON → XML
- Wraps in SOAP envelope
- Routes to backend
- Unwraps response, converts XML → JSON
- Client sees REST
MQTT-to-Kafka
IoT devices publish via MQTT. Your analytics pipeline consumes Kafka.
Without mediation:
- Build a broker bridge service
- Handle message format conversion
- Manage two messaging systems
With Hexarch:
- MQTT messages arrive at gateway
- Transform to Kafka-compatible format
- Publish to Kafka topic
- One governance layer for both
GraphQL-to-REST
Internal systems expose REST APIs. External partners want GraphQL.
With Hexarch:
- Accept GraphQL queries
- Decompose into REST calls
- Aggregate responses
- Return GraphQL response
AI-assisted transformation
Hexarch uses AI to generate mediation logic:
- Describe the scenario: “Bridge our legacy SOAP inventory system to a modern REST client”
- AI generates: Transformation logic, field mappings, envelope handling
- You review: Inspect the generated code, adjust if needed
- Deploy: Apply as a gateway filter
The AI handles the boilerplate. You verify the logic.
Transformation artifacts
Mediation generates deployable artifacts:
- Transformation strategy: High-level mapping documentation
- Java filter template: Gateway-native filter code
- Mapping configuration: Field-by-field transformation rules
Download, review, and deploy.
Field mapping
Mediation policies include explicit field mappings:
REST field → SOAP field
─────────────────────────────────
user.id → UserId
user.email → EmailAddress
order.items[] → OrderLines/OrderLine
order.total → TotalAmount
Mappings handle:
- Type conversions (string ↔ number)
- Nested structures (arrays ↔ repeated elements)
- Optional fields (null handling)
- Format transformations (dates, currencies)
Error handling
Mediation policies define how to handle transformation failures:
Fail Closed (default for critical systems)
- Transformation error → request rejected
- No partial data reaches backend
- Error logged with full context
Fail Open (for non-critical data)
- Transformation error → pass raw data
- Backend handles what it can
- Degraded but operational
Why this matters
Without Protocol Mediation:
- Legacy integration requires code changes
- Each protocol boundary is a custom project
- Translation logic is scattered across services
- Upgrades break integrations
With Hexarch:
- Protocol boundaries are gateway configuration
- AI generates transformation logic
- Centralized, audited mediation
- Change mappings without code deploys
Performance
Mediation adds latency—transformation isn’t free. Hexarch optimizations:
- Streaming transformation: Don’t buffer entire payloads
- Schema caching: Parse schemas once, reuse
- Hot-swap: Update mappings without gateway restart
Typical overhead: 2-10ms depending on payload size and transformation complexity.
Next steps
- AI Policy Generation — how transformation logic is generated
- Fleet Governance — how mediation filters deploy to nodes
- API Reference — endpoints for mediation policy management