Designing an Enterprise ESB: Practical SOA Blueprint and Component Platform

Enterprise SOA Design (1) – ESB Design

Recently we completed an ESB design for the company; the following briefly explains the specific design scheme.

Enterprise SOA Overall Scheme

SOA is a service‑oriented architecture whose core idea is to componentize business and expose component capabilities as services.

Our SOA design has two layers: inter‑system SOA, realized by an ESB that connects business systems, and intra‑system SOA, which builds a component‑based technical platform allowing development as business components that are combined and interconnected via the platform.

Typically SOA design focuses on inter‑system connectivity (e.g., ESB design), but the intra‑system componentization is even more important because it yields low‑coupling, high‑reuse product designs and better supports inter‑system SOA.

This article mainly explains how to implement the ESB design; the intra‑system component platform will be covered in the next article.

ESB Target Functions

The previous article listed a fairly complete set of ESB functions. SOA should include not only simple inter‑system communication but also advanced BPM workflow orchestration.

Below is the functional hierarchy we defined for our ESB. Functions are prioritized; the first phase implements the red‑marked minimal set, while service orchestration is deferred to later phases. We chose a request/response interaction mode for its simplicity, avoiding dependencies such as MSMQ.

ESB Main Design

The main design references another online ESB design, illustrated in the following diagrams.

ESB Detailed Design

First, we plan all internal components of the ESB.

Key components include:

Web Portal – external website for service providers and consumers.

Adapter – protocol adapters.

Service Invoker – synchronous service caller.

Async Invoker – asynchronous caller.

Service Mocker – exposes services via WS, etc.

ESB Message – internal message structure.

Service Registry – service registration repository.

Service Router – routing component.

Service Router Cache Notification – cache update notifier.

Logger – logging component.

Exception Handler – error handling.

Performance Counter – performance statistics.

Further detailed call designs are shown below.

ESB website:

Mock service:

Service invocation:

Pipeline module design during service calls:

Routing table and updates:

Adapter component:

The most important persistent domain entity is shown below:

Thus, our SOA design consists of two layers: inter‑system SOA via ESB, and intra‑system componentized design, which will be detailed in the next article.

Enterprise SOA Design (2) – Componentized Product Development Platform

Platform Overall Structure

To achieve large‑grain reuse at the business level, we split business vertically into components, develop them as business components, and combine multiple completed components into the final software product.

The component‑based product is built on a common development platform that provides all underlying facilities. The platform includes a technical layer (libraries, frameworks, tools, and support for componentization) and a business layer (a library of packaged business components and controls, plus tools, designers, and management interfaces).

Overall structure diagram:

The diagram lists most key parts; details are omitted here.

Component Integration Platform

Each independent business can be packaged as a business component and placed in a component library. Components interact via services or events. To support this, the technical platform provides a plugin framework, service container, and event bus.

Component integration architecture diagram:

The technical platform offers an event bus and lightweight service bus.

Components are developed using domain‑driven design, with domain entity framework as the base.

Components expose events and services; external components can only call services or listen to events.

Reusable UI and distributed services are also provided.

After assembling multiple business components, developers add specific UI or functionality to complete a full system.

Product Composition

Complete product component composition diagram:

Our platform must support 721 customizations; thus a single business component can have different commonality levels: "Organization Common" (most generic), "Org Part1" (optional package), and "Customization" (deep customization without modifying the original component).

By referencing components from the library, the product gains core functionality. The "Customer App Component" adds extra features and customizations via platform interfaces.

Component Internal Architecture

Each business component follows a domain‑driven layered architecture:

The classic layers are Distribution (DTO interface), Application (application/domain logic), Repository, and Domain (domain entities). The Domain layer also contains component events and service interfaces, forming the core of the component.

The underlying technical platform provides support such as IOC/AOP, attribute extension framework, domain entity framework, 721 customization framework, and database generation framework.

Conclusion

The most complex part of componentized architecture design is identifying a well‑encapsulated component, its intended users, and their requirements, then ensuring the architecture meets those needs—covering component evolution, extensibility, interaction, system integration, team customization, external system interaction, and usability.

Feel free to discuss with interested peers.