Large Language Models are no longer just consumers of public APIs. With the Model Context Protocol (MCP), they become first-class clients of enterprise systems. This creates a new architectural challenge for the enterprise:
How do we expose MCP servers from legacy Jakarta EE applications without breaking the systems we rely on today?
This isn't about greenfield projects. This is about WildFly, Payara, WebLogic, SOAP endpoints, EJBs, and shared databases.
The key insight: MCP is not “just another API.” It changes traffic patterns, trust boundaries, and scaling behavior. Treating it like standard REST leads to failure modes you already know too well.
MCP Changes the Shape of Integration
Traditional integrations assume human-driven request rates and predictable shapes. MCP breaks these assumptions. An AI client can:
- Invoke many tools in rapid succession.
- Call internal operations humans never touch.
- Generate load patterns that look like accidental DDoS.
Pattern 1: The MCP Gateway
The safest starting point is a dedicated MCP gateway implemented with a modern runtime like Quarkus.
The gateway terminates the MCP protocol and translates tool calls into legacy-friendly interactions (REST, SOAP, or even JCA).
Why this works:
- Buffer Zone: AI traffic is isolated from fragile legacy logic.
- Independent Scaling: You can scale the gateway without touching the WebLogic cluster.
- Security: Policies are enforced before requests hit the core.
Integration Styles Inside the Gateway
1. Direct Adapter
A thin MCP tool mapped directly to an existing API.
Warning: This exposes legacy design mistakes to the LLM, leading to "token waste" and expensive prompts.
2. Semantic Aggregation Layer
Reshape legacy data into AI-friendly structures.
One MCP call produces a single semantic object. This hides complexity and provides a clean place for caching.
Pattern 2: Event-Driven MCP for Writes
Reads and writes behave differently under AI load. Writes deserve an asynchronous safety net.
This decouples AI timing from legacy processing. The trade-off? AI systems must accept eventual consistency.
Pattern 3: The In-Process MCP Server
Can you expose MCP directly from Jakarta EE? Yes, using LangChain4j-CDI.
When to use it:
- The app is relatively modern.
- You need direct access to internal EJBs not exposed via REST.
- Time-to-market outweighs long-term architectural flexibility.
Pattern 4: The MCP Sidecar
A pragmatic compromise. The sidecar hosts the MCP endpoints and calls the legacy app locally.
This keeps MCP dependencies out of your 10-year-old pom.xml while keeping latency low.
Choosing Your Pattern
| Pattern | Best For | Trade-off |
|---|---|---|
| Gateway | Security & Scale | Architectural Duplication |
| In-Process | Speed & Simplicity | High Coupling |
| Sidecar | Pragmatic Evolution | Infrastructure Complexity |
| Event-Driven | Resilience | Eventual Consistency |
Summary
MCP turns legacy systems into conversational backends. That is powerful, but unforgiving. Success won't come to those who wire endpoints the fastest; it will come to those who treat AI traffic as a new class of integration with its own scaling and security modes.
This post was originally published on The Main Thread.
Top comments (0)