Spring AI Alibaba MCP Client Source Code Analysis

Deep-dive into the distributed capability integration layer that connects enterprise agents to a network of remote tools and data sources

Introduction

Tool Calling gave language models the ability to invoke local functions—but only within the boundary of a single application. In an enterprise landscape, capabilities are distributed across microservices, SaaS platforms, legacy mainframes, and cloud APIs. Hardwiring each of these as a local @Tool creates a brittle, tightly coupled architecture that cannot scale across teams, languages, or deployment environments.

The Model Context Protocol (MCP) addresses this fragmentation by defining an open, standardized protocol for exposing tools, resources, and prompts from any system. An MCP server advertises its capabilities; an MCP client discovers and invokes them dynamically, at runtime. This transforms AI integration from a point-to-point wiring exercise into a pluggable, network-native capability fabric.

Spring AI Alibaba’s MCP Client implementation embodies this vision. It is not a simple HTTP wrapper but a carefully layered subsystem that handles capability negotiation, remote invocation, serialization, session management, error recovery, and seamless integration with the existing Tool Calling and Agent Runtime. This article dissects the internal architecture of that client—the source-level design, protocol handling, discovery flows, and the enterprise patterns that make it a cornerstone of future AI ecosystems.

Where MCP Fits in Spring AI Alibaba Architecture

The MCP Client sits between the agent’s reasoning layer and remote capabilities, acting as a proxy that makes external tools appear local.

Agent Runtime decides to invoke a tool. The Executor queries the ToolRegistry.
ToolRegistry now includes both statically registered @Tool beans and tools dynamically provided by the McpClient.
McpClient manages connections to one or more MCP servers. It discovers their capabilities, translates local tool calls into remote JSON-RPC requests, and maps responses back.
McpServer runs externally—possibly written in Python, Node.js, or any language—exposing tools that wrap real enterprise services.

This design means the agent never knows whether a tool executes locally or remotely. The MCP Client abstracts location and protocol.

What is MCP in Spring AI Alibaba Context

In Spring AI Alibaba, MCP is both a protocol and an integration module. The MCP Client plays several roles:

Capability Gateway: It connects to MCP servers and fetches their list of tools, resources, and prompts.
Dynamic Tool Provider: It implements ToolProvider so that discovered MCP tools are automatically registered in the Spring AI ToolRegistry.
Remote Invocation Proxy: When a tool call targets an MCP tool, the client serializes the call, sends it over the wire, and deserializes the response.
Protocol Abstraction Layer: It hides the transport (stdio, WebSocket, HTTP) and the JSON-RPC message format behind clean Java interfaces.
Session Manager: It handles the MCP session lifecycle: initialize, negotiate capabilities, heartbeat, and graceful shutdown.

The MCP Server is the counter-party, but its implementation is not part of the client analysis. The client focuses solely on consuming MCP capabilities.

MCP Architecture Overview

The MCP Client is composed of several internal modules:

McpClient – Public API for listing tools, calling tools, reading resources.
Transport Layer – Abstracts the communication channel (stdio, WebSocket). Uses JSON-RPC 2.0 messages.
CapabilityRegistry – Caches tool and resource definitions fetched from the server. Provides a unified view to the ToolRegistry.
InvocationHandler – Converts ToolCall requests into MCP JSON-RPC calls, handles responses and errors.
SessionManager – Manages the MCP session: initialization, heartbeat, reconnection.

This internal decomposition follows the single-responsibility principle and allows swapping transports or changing the capability storage independently.

MCP vs Tool Calling

MCP fundamentally extends the scope of tool calling from local in-process to distributed out-of-process.

Aspect	Local Tool Calling (`@Tool`)	MCP-based Tool Calling
Location	Same JVM, Spring beans	Remote process, any language
Discovery	Startup-only (bean scanning)	Dynamic, runtime negotiation
Coupling	Tight (direct method call)	Loose (protocol + schema)
Scalability	Single app boundary	Distributed, independently scalable
Ecosystem	Closed to app's classpath	Open, any MCP server can contribute
Latency	Microseconds	Milliseconds (network)
Security	Spring Security on beans	Transport authentication + tool-level permissions
Standardization	Framework-specific annotations	Open standard (MCP specification)

Local tool calling is ideal for fast, internal operations. MCP is essential when capabilities live in separate systems or need to be shared across multiple AI applications. Spring AI Alibaba treats both uniformly: the ToolRegistry holds both types, and the Executor invokes them through the same interface.

MCP Client Source Code Structure

The Spring AI Alibaba MCP module is organized as follows (conceptual):

com.alibaba.cloud.ai.mcp
├── client
│   ├── McpClient.java
│   ├── DefaultMcpClient.java
│   └── McpClientFactory.java
├── transport
│   ├── McpTransport.java
│   ├── StdioTransport.java
│   ├── WebSocketTransport.java
│   └── HttpTransport.java
├── registry
│   ├── McpCapabilityRegistry.java
│   └── McpToolProvider.java
├── invoke
│   ├── McpInvocationHandler.java
│   └── McpResponseMapper.java
├── session
│   └── McpSessionManager.java
├── config
│   └── McpAutoConfiguration.java

McpClient: The main entry point; provides listTools(), callTool(name, args), listResources(), etc.
Transport: Abstracts the wire protocol. StdioTransport launches a server subprocess; WebSocketTransport connects to a remote endpoint.
Capability Registry: In-memory store of tools and resources retrieved from the server.
Invocation Handler: Takes a local ToolCall, converts it to an MCP request, sends it via transport, and maps the response.
Session Manager: Manages the lifecycle of an MCP session, including the initialization handshake.
Auto Configuration: Creates McpClient beans based on properties and classpath conditions.

Capability Discovery Mechanism

Discovery is at the heart of MCP. Unlike static @Tool scanning, MCP tools are fetched dynamically when the client connects or when a change is signaled.

Flow:

After the transport connection is established, the client sends an initialize request with its protocol version and capabilities.
The server responds with its own capabilities, including the list of available tools (name, description, input schema).
The McpCapabilityRegistry stores these as ToolDefinition objects, each with a flag indicating it’s remote.
The McpToolProvider (implementing ToolProvider) returns these definitions to the ToolRegistry.
If the server supports notifications/tools/list_changed, the client subscribes and refreshes its registry when tools are added or removed.

Code snippet (conceptual):

public class McpCapabilityRegistry {
    private final Map<String, ToolDefinition> tools = new ConcurrentHashMap<>();

    public void syncFromServer(McpClient client) {
        List<Tool> serverTools = client.listTools();
        serverTools.forEach(t -> {
            ToolDefinition def = ToolDefinition.builder()
                .name(t.getName())
                .description(t.getDescription())
                .inputSchema(t.getInputSchema())
                .source(ToolSource.MCP)
                .build();
            tools.put(t.getName(), def);
        });
    }
}

Analysis: The registry decouples network discovery from the consumer. The ToolRegistry doesn’t need to know how tools arrived—only that they are available.

Dynamic updates: When a server notifies of changes, the CapabilityRegistry can emit an event, which the McpToolProvider uses to refresh the ToolRegistry. This allows runtime addition of tools without restarting the application.

Schema negotiation: MCP tools include a JSON Schema for input parameters. The client maps this to Spring AI’s ToolParameterMetadata, enabling the same schema generation used for local @Tool methods. This ensures the LLM sees a uniform interface.

MCP Connection Lifecycle

A robust connection lifecycle is critical for distributed tooling.

Initialize: Version and capability negotiation happens here. If versions mismatch, the client can fall back or reject the connection.
Capability sync: After initialization, the client requests the current tool and resource lists.
Heartbeat: A periodic ping/pong keeps the connection alive and detects dead servers early.
Reconnection: The SessionManager can implement exponential backoff reconnection if the connection drops. During reconnection, capability refresh is triggered again.

Remote Tool Invocation Flow

When an agent decides to use an MCP-discovered tool, the invocation traverses the network.

Key points:

The ToolExecutor uses the same execute method, regardless of tool source. The ToolDefinition indicates MCP source, and the executor delegates to the McpClient instead of reflective invocation.
The InvocationHandler constructs a JSON-RPC request with method: "tools/call" and serialized parameters.
The response is mapped back into a Spring AI ToolResponseMessage, handling both success and error cases.

Unified invocation: This design means that from the executor’s perspective, all tools look identical. Adding a new MCP server adds new capabilities with zero code changes in the business logic.

Serialization & Protocol Design

MCP uses JSON-RPC 2.0 for message exchange. The client must handle serialization carefully to ensure interoperability.

Request: {"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_weather","arguments":{"location":"Paris"}}}
Response: {"jsonrpc":"2.0","id":1,"result":{"content":[{"type":"text","text":"22°C sunny"}]}}

The McpInvocationHandler uses Jackson to serialize/deserialize. It maps Java Map<String,Object> arguments to the arguments field.

Schema validation: Before sending, the client can validate the arguments against the tool’s input schema (obtained during discovery). This prevents malformed requests from reaching the server. If validation fails, a ToolInvocationException is thrown locally without a network call.

Cross-system compatibility: The client adheres to the standard MCP message structure, ensuring interoperability with any MCP-compliant server, regardless of its language or framework.

Tradeoffs: JSON-RPC adds a slight overhead compared to a custom binary protocol, but the benefits of standardization and debuggability far outweigh it for enterprise AI integration.

Error Handling & Resilience

Network calls are inherently unreliable. The MCP client includes several resilience features.

Timeouts: Each tools/call request has a configurable timeout. If the server does not respond in time, a TimeoutException is thrown and caught by the executor, which feeds it back to the agent as an error observation.
Retries: The InvocationHandler can be wrapped with a retry template (via Spring Retry). Transient network errors are retried with exponential backoff, up to a limit.
Circuit Breaker: Using Resilience4j, repeated failures to a particular server can trip a circuit, failing fast and allowing the agent to use alternative tools or servers.
Partial server failures: If a server responds with an error (e.g., tool execution exception), the error content is packaged as a ToolResponse with status error. The agent can then replan.
Graceful degradation: If the MCP connection is lost and cannot be re-established, the McpToolProvider can remove the server’s tools from the ToolRegistry, preventing further calls.

These patterns ensure that the distributed tool layer is as reliable as possible while maintaining transparency.

MCP + Tool Calling Integration

The integration between MCP and the existing Tool Calling infrastructure is seamless.

Dynamic tool registration: The McpToolProvider bean is automatically created when an McpClient is present. It implements ToolProvider, and its getTools() method returns the tools from the McpCapabilityRegistry. The ToolRegistry eagerly or lazily fetches these and merges them with local @Tool beans.

Unified invocation interface: The ToolExecutor checks the source field of the ToolDefinition. If MCP, it calls mcpClient.callTool(...). If LOCAL, it uses reflective invocation. The callers are completely unaware.

Hybrid execution model: An agent can mix local and remote tools in a single plan. For example: call a local validateOrder tool, then an MCP tool createShippingLabel hosted in the logistics microservice.

Code snippet:

public class HybridToolExecutor implements ToolExecutor {
    private final Map<String, ToolDefinition> registry;
    private final McpClient mcpClient;

    @Override
    public ToolResponse execute(ToolCall call) {
        ToolDefinition def = registry.get(call.getName());
        if (def.getSource() == ToolSource.MCP) {
            return mcpClient.callTool(call.getName(), call.getArguments());
        } else {
            return localInvoke(def, call);
        }
    }
}

Analysis: This strategy pattern keeps the execution logic clean and extensible.

MCP + Agent Runtime Integration

The agent runtime benefits from MCP by having access to a virtually unlimited set of tools, without redeployment.

MCP as external execution layer: The agent’s planner includes all MCP tools in the prompt, just like local tools. The model selects them based on name and description.
Agent decision → MCP routing: The agent emits a ToolCallRequest; the executor routes it to the MCP client if needed. The agent doesn’t distinguish.
Multi-step MCP interactions: The agent can chain MCP tools from different servers. For instance, get customer info from CRM (MCP server A), then check inventory (MCP server B), then create order (local tool).
State propagation: The AgentContext is local. However, any relevant state (like session ID or user identity) can be passed as tool arguments if the MCP server requires them.

This design makes the agent an orchestrator of a distributed tool ecosystem.

Performance Considerations

Distributing tool execution introduces latency, which must be managed.

Network latency: Each MCP call adds RTT (round-trip time). For internal services, this is typically 1-10ms. For cloud services, 10-100ms.
Serialization overhead: JSON serialization/deserialization adds microseconds. For large payloads, consider streaming or chunking (MCP supports content streams).
Batch invocation: If the agent needs to call multiple independent MCP tools, the client can parallelize these calls using a CompletableFuture and a thread pool, reducing total wait time.
Connection pooling: The transport layer maintains a pool of persistent connections to each MCP server, avoiding TCP handshake per request.
Caching capabilities: The tool list is cached after initial discovery, and only refreshed upon notification, saving discovery overhead.

Comparison with local tools: A local @Tool call is in the microsecond range. An MCP call is in the millisecond range. For most enterprise tasks, where the tool itself involves a database query or API call taking tens of milliseconds, the network overhead is negligible.

Security Model

Allowing an AI to invoke remote tools requires a robust security model.

Authentication: Transport layer can use mTLS (for WebSocket) or secure stdio channels. The McpClient configuration includes credentials (API keys, OAuth2 tokens) that are sent during initialization.
Capability permission control: Not all agents should have access to all MCP tools. The McpClient can filter the discovered tools based on the agent’s role, presenting only a subset to the ToolRegistry.
Safe execution boundaries: The MCP server runs in its own process, providing a natural boundary. Even if a tool is maliciously invoked, it cannot directly affect the JVM or Spring context of the client.
Trust model: The client trusts the MCP server to correctly execute tools. In the future, tool attestations or signatures could enhance trust.

Design Patterns Used

The MCP client implementation exemplifies several classic patterns.

Proxy Pattern: The McpClient acts as a remote proxy for tools. Local code calls mcpClient.callTool(...) without knowing the server’s location or implementation.
Adapter Pattern: The transport layer adapts different communication protocols (stdio, WebSocket) to a common McpTransport interface.
Registry Pattern: The McpCapabilityRegistry maintains a central catalog of remote tools, decoupling discovery from invocation.
Command Pattern: Each tool call is encapsulated as a ToolCall command; the InvocationHandler executes it remotely.
Facade Pattern: The McpClient interface provides a simplified, high-level API that hides JSON-RPC, session management, and transport details.

Benefits: These patterns yield a modular, testable client that can evolve independently of the server protocol. Tradeoffs: The additional layers introduce a slight complexity, but they are essential for a clean, maintainable architecture.

Source Code Walkthrough

We'll walk through key classes and their architectural intent.

McpClient interface and DefaultMcpClient:

public interface McpClient {
    List<ToolDefinition> listTools();
    ToolResponse callTool(String name, Map<String, Object> arguments);
    // resource and prompt methods...
}

public class DefaultMcpClient implements McpClient {
    private final McpTransport transport;
    private final McpSessionManager sessionManager;
    private final McpInvocationHandler invocationHandler;
    private final McpCapabilityRegistry capabilityRegistry;

    // constructor with injection

    @Override
    public List<ToolDefinition> listTools() {
        return capabilityRegistry.getAllTools();
    }

    @Override
    public ToolResponse callTool(String name, Map<String, Object> arguments) {
        return invocationHandler.invoke(name, arguments);
    }
}

Analysis: The client delegates to specialized components. listTools is a passive call to the registry; the actual network fetch happens in syncCapabilities(), called during session setup.

McpTransport interface and WebSocketTransport:

public interface McpTransport {
    CompletableFuture<String> send(String message);
    void onMessage(Consumer<String> handler);
    void connect();
    void close();
}

public class WebSocketTransport implements McpTransport {
    // uses Spring WebSocket client to connect to ws://server/mcp
    // manages reconnection, heartbeat
}

Analysis: The transport abstraction allows the client to work with stdio for local servers and WebSocket for remote servers. Auto-configuration selects the transport based on properties.

McpInvocationHandler:

public class McpInvocationHandler {
    private final McpTransport transport;
    private final ObjectMapper mapper;

    public ToolResponse invoke(String toolName, Map<String, Object> arguments) {
        String requestJson = buildRequest(toolName, arguments);
        String responseJson = transport.send(requestJson).get(timeout, MILLISECONDS);
        return parseResponse(responseJson);
    }

    private String buildRequest(String name, Map<String,Object> args) {
        return mapper.writeValueAsString(Map.of(
            "jsonrpc", "2.0",
            "method", "tools/call",
            "params", Map.of("name", name, "arguments", args)
        ));
    }
    // parsing...
}

Analysis: The handler constructs a standard JSON-RPC request and synchronously waits for the response. For async, a CompletableFuture is returned.

McpToolProvider:

@Component
public class McpToolProvider implements ToolProvider {
    private final McpClient mcpClient;

    @Override
    public List<ToolDefinition> getTools() {
        return mcpClient.listTools();
    }
}

Analysis: This is the bridge to Spring AI’s ToolRegistry. Every time the registry asks for tools, the provider returns the current MCP tools. This can be cached with a TTL to avoid frequent network calls.

Auto-configuration:

@AutoConfiguration
@ConditionalOnClass(McpClient.class)
public class McpAutoConfiguration {
    @Bean
    @ConditionalOnMissingBean
    public McpClient mcpClient(McpTransport transport, McpSessionManager sessionManager, ...) {
        return new DefaultMcpClient(transport, sessionManager, ...);
    }
    // other beans...
}

Analysis: Spring Boot’s auto-configuration makes MCP client setup effortless. Developers just add properties like spring.ai.alibaba.mcp.client.url=ws://....

Enterprise Use Cases

Enterprise system integration: An AI assistant for employee services connects to HR, IT, and facilities via separate MCP servers, each exposing relevant tools (book room, reset password, submit ticket).
Database + AI hybrid systems: An MCP server wraps a SQL database, exposing parameterized query tools. The AI agent can ask the user’s question, the MCP tool executes a safe query, and the agent summarizes results.
DevOps automation ecosystems: CI/CD tools, monitoring systems, and deployment pipelines expose MCP tools. An incident agent can diagnose by querying logs (MCP tool), then trigger a rollback (MCP tool) or open a Jira ticket (MCP tool).
SaaS AI orchestration platforms: Multiple SaaS products expose MCP servers. A sales agent can lookup CRM data, create a quote in CPQ, and schedule a follow-up in the calendar—all through MCP, no custom integration.
Multi-system workflow orchestration: Complex business processes that span 5 different internal services become AI-orchestrated, with MCP providing the uniform tool interface.

Design Tradeoffs

Local vs remote execution: Local tools are faster but limit reuse. MCP enables reuse at the cost of network latency. The framework allows choosing the right tool location.
Latency vs extensibility: Adding network hops increases latency; but the ability to add new capabilities without redeploying the application is a massive agility win.
Complexity vs standardization: MCP adds a protocol layer, but its standardization reduces the N×M integration problem to 1×M.
Debugging distributed flows: A tool call now spans multiple processes; distributed tracing (Micrometer + Zipkin) is necessary to correlate logs. Spring AI Alibaba integrates this automatically.
Security overhead: Mutual TLS, token exchange, and capability filtering add operational complexity but are required for enterprise security.

Comparison with Other Systems

Feature	Spring AI Alibaba MCP Client	LangChain Tool APIs	OpenAI Function Calling	Semantic Kernel Connectors	Custom Microservice Tool Layer
Protocol	MCP (JSON-RPC 2.0)	Custom REST or direct	OpenAI proprietary JSON	Custom REST/gRPC	Custom (often REST)
Discovery	Dynamic, runtime	Manual registration	Manual	Manual	Manual or service mesh
Tool source	Any MCP server	Python functions	Only OpenAI’s endpoint	.NET services	In-house services
Interoperability	High (standard)	Low (framework-specific)	Very low	Low	Depends on API design
Latency	Network overhead	Local or network	API call	Network	Network
Security	Transport + tool-level	User-implemented	API key	Middleware	Custom
Spring integration	Native, auto-config	No	No	No	Manual
Agent integration	Yes, via ToolRegistry	Yes, via AgentExecutor	Only via API	Yes, via Planner	Custom wiring

Spring AI Alibaba’s MCP Client uniquely combines an open protocol with deep Spring integration, enabling a true ecosystem of tools rather than ad-hoc integrations.

Lessons for Framework Designers

Standardize capability protocols. Point-to-point integrations are not scalable. Design a protocol that allows any system to expose tools, and any client to consume them.
Separate execution from location. The tool registry and executor should be location-agnostic, enabling a mix of local and remote tools without changing client code.
Treat tools as distributed services. Plan for network failures, latency, and version mismatches. Build resilience into the client.
Design for dynamic discovery. Static registries hinder evolution. The client should be able to pick up new capabilities at runtime.
Embrace network-aware AI systems. AI agents will increasingly span multiple services and clouds. The framework must treat network communication as a first-class concern.

Future Evolution

MCP-based AI ecosystems: A public marketplace of MCP servers providing domain tools (legal, medical, logistics) that any Spring AI agent can instantly use.
Autonomous distributed agent networks: Agents that discover and negotiate with each other via MCP, forming temporary coalitions to solve complex tasks.
Multi-cloud tool orchestration: MCP clients connecting to servers across AWS, Azure, Alibaba Cloud, and on-premise, providing a unified tool surface.
Enterprise AI capability marketplaces: Companies expose internal capabilities as MCP servers; AI agents “shop” for the best tool to accomplish a task.
Self-discovering tools: Using semantic descriptions, agents can discover tools that match a sub-goal without explicit programming.

FAQ

What is the MCP Client in Spring AI Alibaba?
It’s a component that connects to MCP servers, discovers their tools, and makes them available to the agent runtime as if they were local @Tool beans.
How does capability discovery work?
After initial connection, the client requests the server’s tool list via JSON-RPC. The tools are stored in a registry and provided to the ToolRegistry.
How are remote tools invoked?
The ToolExecutor detects a tool’s MCP source and delegates to the McpClient, which sends a JSON-RPC tools/call request to the server.
What is the difference between MCP and local Tool Calling?
Local tool calling invokes Java methods directly; MCP invokes tools over the network using a standard protocol, enabling cross-language and cross-service capabilities.
How is reliability ensured in distributed execution?
Through retries, circuit breakers, timeouts, and dynamic capability removal on disconnection.
Can MCP tools be mixed with local tools?
Yes, the ToolRegistry merges both, and the agent can use them interchangeably.
How is the MCP client configured?
Via application.properties and auto-configuration. Simply providing the server URL creates the client bean.
What transports are supported?
Stdio (for subprocess-based servers) and WebSocket (for remote servers). HTTP may also be supported.
How does the client handle server version mismatches?
During initialization, version negotiation occurs. The client can reject incompatible servers or adapt its behavior.
Is tool schema validation performed client-side?
Optionally, yes. The InvocationHandler can validate arguments against the schema before sending.
Can the client connect to multiple MCP servers?
Yes, multiple McpClient beans can be configured, each with its own transport, and their tools are aggregated.
What observability features are built-in?
Distributed tracing spans for each MCP call, Micrometer metrics for latency and error rates.
How does security work?
Transport-level encryption and authentication (mTLS, API keys) can be configured; tool-level access control is planned.
What happens if an MCP server goes down?
Its tools are removed from the registry, and calls to them will fail with an error that the agent can handle.
How does MCP fit with Spring AI’s existing Advisor chain?
An McpAdvisor could be used to inject MCP context (resources) into the prompt, similar to the RAG advisor.

Conclusion

The MCP Client in Spring AI Alibaba is more than a network library—it is the architectural foundation for distributed AI capability ecosystems. By implementing the open Model Context Protocol, it allows enterprise agents to break free from the confines of a single application and dynamically discover and invoke tools across languages, clouds, and organizational boundaries. The client’s layered design—transport abstraction, capability registry, remote invocation handler—demonstrates a mature approach to integrating network-native capabilities into the Spring ecosystem.

As AI systems evolve from isolated assistants to interconnected, autonomous agents, the principles embodied in the MCP Client—standardized protocols, dynamic discovery, location transparency, and resilience—will become mandatory. Spring AI Alibaba’s implementation not only provides a practical tool today but also serves as a blueprint for the next generation of enterprise AI platforms.

This article was written for SpringDevPro.com as part of the Spring AI Alibaba Source Code Analysis series, providing deep architectural insights for senior Java architects and platform engineers.

Introduction​

Where MCP Fits in Spring AI Alibaba Architecture​

What is MCP in Spring AI Alibaba Context​

MCP Architecture Overview​

MCP vs Tool Calling​

MCP Client Source Code Structure​

Capability Discovery Mechanism​

MCP Connection Lifecycle​

Remote Tool Invocation Flow​

Serialization & Protocol Design​

Error Handling & Resilience​

MCP + Tool Calling Integration​

MCP + Agent Runtime Integration​

Performance Considerations​

Security Model​

Design Patterns Used​

Source Code Walkthrough​

Enterprise Use Cases​

Design Tradeoffs​

Comparison with Other Systems​

Lessons for Framework Designers​

Future Evolution​

FAQ​

Conclusion​