Design and Implementation of JD's TESB (Decare) Platform: Architecture, Challenges, and Solutions

To improve enterprise procurement experience and close the JD‑centric procurement loop, JD's large‑client department introduced TESB (Decare) as an evolution of traditional ESB, moving from EAI to service‑oriented architecture and adding service orchestration capabilities.

Evaluating three mainstream open‑source ESB projects (Celtix, ServiceMix, Mule) revealed shortcomings in integration efficiency and orchestration complexity, prompting the team to consider a BPM‑driven core model and execution engine for the ESB.

The goal is to build an ESB platform that requires little or no development effort, allowing non‑technical operations staff to operate it, while ensuring extensibility and ease of use. The platform’s domain model and visual operation architecture are illustrated in the accompanying diagrams.

Centralized architectures suffer from single‑point bottlenecks because they handle both routing and data transport, limiting scalability under high concurrency. A semi‑decentralized approach separates control flow from data flow, and a fully decentralized model lets each node act as both controller and data carrier.

Decare adopts a semi‑decentralized design: the client first obtains a routing address, then establishes a connection for the actual request, reducing the load on control nodes and supporting large‑scale concurrent access. Java and .NET agents are provided to lower client integration costs.

Performance considerations focus on increasing throughput and reducing per‑service response time while maintaining platform availability.

Key technical challenges include blocking HTTP request handling, long processing times of integrated services, limited web container resources, and the risk of blocking affecting overall service health.

Solutions implemented are: converting blocking I/O to non‑blocking using Tomcat’s Comet and asynchronous servlet support (with EventType.BEGIN, READ, END, ERROR); setting timeouts for integrated services; enlarging thread pool and queue sizes; and establishing virtual isolation to control CPU and JVM memory usage per service.

In summary, the Decare platform enhances traditional ESB by offering richer functionality for complex enterprise interactions, a visual low‑code development environment for faster integration, a semi‑decentralized architecture that mitigates bottlenecks, and asynchronous, event‑driven processing with virtual thread‑pool isolation to achieve high throughput and low latency.