KCBP/KCXP vs AS/AR: Two Chinese Securities Middleware Platforms That Shaped the Centralized Trading Era

#

Introduction: The Rise of Centralized Securities Trading Systems in China

#

Around 2001, China’s securities industry experienced a fundamental architectural transformation.

The previous generation of systems was based on:

Local brokerage branch systems

*

Local databases

*

Independent deployments

which gradually evolved into:

Centralized trading

*

Data concentration

*

Unified transaction processing

*

Enterprise-level access platforms

Large securities firms needed to support:

• Thousands of trading terminals
• Hundreds of branches
• Massive concurrent transactions
• High availability requirements
• Multi-platform deployment environments

Traditional client/server architectures were no longer sufficient.

Therefore, Chinese securities software vendors began building their own middleware platforms.

Two representative systems emerged:

These platforms became the core infrastructure behind China’s centralized securities trading systems.

1. Overall Positioning: KCBP/KCXP vs AS/AR

#

Kingdom Architecture

#

The basic architecture of KCBP/KCXP can be represented as:

Client Application

|

KCBP Client API

|

KCXP Messaging Layer

|

KCBP Server

|

LBM Business Modules

|

Database

The design philosophy:

Message-driven transaction processing with dynamically loadable business modules.

Hundsun Architecture

#

The AS/AR architecture:

Client Application

|

Application Router (AR)

|

Application Server (AS)

|

Business Components

|

Database

The design philosophy:

Request routing and service-oriented transaction processing.

2. Fundamental Design Philosophy Differences

#

Kingdom: Message Queue Driven Architecture

#

KCBP/KCXP was closer to traditional transaction middleware such as:

• IBM CICS
• IBM MQ

The core concept:

Convert requests into messages and let backend services process them.

Model:

Request

|

Message Queue

|

Business Service

|

Database

Advantages:

• Loose communication dependency
• High reliability
• Asynchronous processing
• Flexible scaling

Hundsun: Application Routing Architecture

#

AS/AR focused on service routing.

The core concept:

Requests enter the middleware layer, and the routing layer decides which service node handles the request.

Model:

Request

|

AR Router

|

AS Server Cluster

|

Business Logic

|

Database

Advantages:

• Clear service boundaries
• Active load balancing
• Layered architecture

3. Communication Model Comparison

#

3.1 KCXP: Message Queue Model

#

KCXP’s primary responsibility:

Reliable message delivery.

Core capabilities:

• Message queues
• Point-to-point communication
• Publish/subscribe communication
• Asynchronous messaging

Abstract model:

Producer

|

Message Queue

|

Consumer

KCXP itself does not handle:

• Trading rules
• Business validation
• Transaction semantics

Its responsibility is:

Store and forward messages reliably.

3.2 AR: Application Routing Model

#

AR focuses on:

• Request entry
• Service discovery
• Request forwarding
• Load balancing

Model:

Client

|

AR

|

AS1
AS2
AS3

AR determines the target AS node based on:

• Service availability
• Server status
• Routing configuration

4. Business Module Implementation Differences

#

This is one of the most important architectural differences.

Kingdom: LBM (Loadable Business Module)

#

KCBP introduced:

LBM — Loadable Business Module

Architecture:

KCBP Platform

|

LBM Trading Module

LBM Customer Module

LBM Account Module

LBM Query Module

Characteristics:

Dynamic Loading

#

LBM modules could be:

• Loaded
• Unloaded
• Updated

without stopping the entire transaction platform.

The philosophy:

The middleware platform provides the runtime environment, while business capabilities are delivered as independent modules.

Hundsun: AS + DLL Components

#

AS used a component-based model:

AS Server

|

DLL Business Components

|

Transaction Logic

Characteristics:

• Business functions packaged as DLL modules
• Multi-threaded request processing
• Dynamic loading/unloading support

The philosophy:

Build a high-performance application server containing reusable business components.

5. Clustering and Load Balancing Models

#

Kingdom: Queue-Based Cluster Model

#

Architecture:

      KCXP

  /     |     \

KCBP KCBP KCBP

Requests enter the queue.

Available KCBP nodes pull and process tasks.

This is essentially:

Pull-based workload distribution.

Advantages:

• Transparent scaling
• Simple cluster expansion
• Strong fault tolerance

Hundsun: Router-Based Cluster Model

#

Architecture:

      AR

/      |      \

AS1 AS2 AS3

AR actively selects the appropriate AS node.

This is:

Push-based routing.

Advantages:

• Explicit service location
• Intelligent routing
• Better service governance

6. Reliability and Transaction Handling

#

KCBP/KCXP Reliability Design

#

KCBP focused heavily on transaction integrity.

Capabilities included:

• XA transaction support
• Resource reconnect
• Failure recovery
• Primary/backup communication paths

Design philosophy:

Financial transactions must never lose consistency.

AS/AR Reliability Design

#

AS/AR focused on:

• Service isolation
• Request forwarding
• Distributed deployment
• Centralized architecture

Design philosophy:

Reliability comes from architectural separation and service management.

7. Cross-Platform Capability

#

KCBP/KCXP

#

KCBP was designed for heterogeneous environments.

Supported environments included:

Operating systems:

Unix

Linux

Windows

AIX

OS/400

Databases:

Oracle

DB2

SQL Server

Sybase

MySQL

The goal:

Hide differences between hardware platforms, operating systems, databases, and networks.

AS/AR

#

AS/AR primarily focused on:

• Large securities firms
• Centralized trading environments
• High concurrency transaction processing

Its evolution later moved toward:

AS/AR

|

CRES

|

JRES

|

Light-JRES

8. Twenty-Year Evolution Paths

#

Kingdom Evolution Path

#

KCBP/KCXP

|

A6 Investment Trading Platform

|

KOCA Platform

|

A8 Investment Trading Platform

Characteristics:

Long lifecycle evolution.

Instead of replacing the old middleware completely, Kingdom continued integrating KCBP/KCXP into newer platforms as a stable transaction foundation.

Hundsun Evolution Path

#

AS/AR

|

CRES

|

JRES

|

Light-JRES

|

O45 / UF3

Characteristics:

Generational architectural transformation.

The evolution moved from:

• Native C/C++ middleware

towards:

• Java distributed middleware
• Microservices architecture
• Cloud-native platforms

9. Overall Comparison

#

10. The Deeper Meaning Behind Two Technical Philosophies

#

These two middleware platforms represent two different engineering philosophies.

Kingdom Philosophy

#

Transaction Core

*

Reliable Messaging

*

Long-Term Stability

The priority:

Build a financial infrastructure platform that can run for decades.

Hundsun Philosophy

#

Service Architecture

*

Componentization

*

Continuous Evolution

The priority:

Build a flexible financial technology platform that evolves with business requirements.

Conclusion

#

KCBP/KCXP and AS/AR were not merely middleware products.

They represented two different paths in China’s financial IT evolution.

Kingdom chose:

Evolutionary stability.

Hundsun chose:

Architectural transformation.

Their influence continues today.

Modern financial platforms still rely on the same fundamental ideas:

• Message-driven architecture
• Service routing
• Distributed transaction processing
• Middleware abstraction
• High availability design

The technologies have changed:

Middleware

↓

Distributed Platform

↓

Cloud Native Architecture

But the original challenge remains unchanged:

How can complex financial businesses process millions of transactions safely, reliably, and efficiently?

KCBP/KCXP and AS/AR were among the earliest Chinese answers to that question.