KCBP/KCXP vs AS/AR: The Architectural Divide Behind China’s Securities Middleware Twins

#

Around 2001, China’s securities industry entered the era of centralized trading platforms.

Brokerages were moving away from fragmented branch-based systems toward centralized architectures capable of supporting:

• massive transaction volumes
• nationwide branch networks
• heterogeneous infrastructure
• high availability requirements
• real-time financial processing

At that time, global middleware products such as IBM CICS, IBM MQ, and BEA Tuxedo dominated large-scale financial systems.

However, Chinese securities firms faced unique challenges:

• multiple operating systems
• multiple database platforms
• legacy hardware environments
• rapid business changes
• strict transaction reliability requirements

Against this background, two Chinese financial technology companies developed their own middleware platforms almost simultaneously:

Kingstar:

• KCBP (Kingstar Core Business Platform)
• KCXP (Kingstar Communication Exchange Platform)

Hundsun:

• AS (Application Server)
• AR (Application Router)

Functionally, they solved similar problems.

Architecturally, they chose very different paths.

1. Similar Mission, Different Philosophy

#

At a functional level:

Both platforms provided:

• transaction processing
• communication abstraction
• distributed deployment
• business component execution

However, their core philosophies were fundamentally different.

Kingstar’s philosophy:

#

Decouple systems through messaging.

Hundsun’s philosophy:

#

Organize services through intelligent routing.

This difference shaped every later architectural decision.

2. KCXP vs AR: Message Queue vs Application Routing

#

2.1 KCXP: A Message-Centric Architecture

#

KCXP was designed around the message queue paradigm.

The simplified architecture:

Application
|
v
KCXP Queue
|
v
Business Processing Node

The responsibility of KCXP was:

• message persistence
• message delivery
• network abstraction
• asynchronous communication

KCXP did not manage:

• business rules
• transaction semantics
• business state

Its philosophy was:

Messages should be independent from applications.

This approach provided:

• loose coupling
• high reliability
• asynchronous scalability

Similar concepts can be found in:

• IBM MQ
• enterprise message brokers
• event-driven architectures

2.2 AR: A Routing-Centric Architecture

#

Hundsun AR followed a different model.

Instead of storing messages, AR focused on request routing.

Architecture:

Client

|
v

Access AR

|
v

Bus AR

|
v

Application Server

AR was responsible for:

• service location
• request forwarding
• load balancing

When a request arrived:

AR determined:

• which service should handle it
• which node was available
• how traffic should be distributed

The philosophy was:

Applications should be accessed through intelligent routing.

3. LBM vs DLL: Two Business Component Philosophies

#

The most interesting difference between the two platforms lies in how business logic was packaged.

3.1 Kingstar KCBP: Loadable Business Modules

#

KCBP introduced:

LBM (Loadable Business Module)

Business logic existed as independent modules.

Architecture:

Client Application

|
v

KCBP API

|
v

KCXP

|
v

KCBP Server

|
v

LBM

|
v

Database

Characteristics:

• dynamic loading
• dynamic unloading
• modular deployment
• platform abstraction

The design idea:

The middleware platform manages execution; business logic becomes a replaceable module.

Advantages:

• stronger isolation
• easier extension
• long lifecycle support

3.2 Hundsun AS: DLL-Based Business Components

#

Hundsun AS used another approach:

• business components
• dynamic libraries
• multi-threaded execution

Architecture:

AR

|

AS

|

DLL Business Components

|

Database

Characteristics:

• high execution efficiency
• component-based design
• tight integration with application server runtime

The philosophy:

The application server is the container of business capabilities.

4. Cluster Architecture: Queue-Driven vs Route-Driven

#

This is perhaps the biggest architectural difference.

4.1 KCBP/KCXP: Resource Pool Model

#

Kingstar used a queue-driven cluster model.

      KCXP

        |

---

|              |              |

KCBP1          KCBP2          KCBP3

Requests entered the queue.

Available workers consumed tasks.

This resembles:

• worker pools
• compute grids
• pull-based distributed processing

Characteristics:

• implicit load balancing
• dynamic node scaling
• resource sharing

The system decides:

Which worker is available?

4.2 AS/AR: Service Routing Model

#

Hundsun used explicit routing.

     Client

        |

        v

       AR

        |

| | |

AS1 AS2 AS3

AS nodes reported:

• current load
• availability
• processing status

AR selected the destination.

Characteristics:

• explicit service discovery
• routing-based balancing
• service-oriented architecture

The system decides:

Which service should receive this request?

5. Reliability and Transaction Management

#

KCBP

#

Public technical materials describe KCBP as providing:

• transaction integrity management
• XA resource support
• crash recovery
• automatic reconnection
• primary/backup communication paths

The goal:

Provide mainframe-level reliability for securities trading systems.

AS/AR

#

Early AS/AR materials focused more on:

• three-tier architecture
• network separation
• request routing
• service distribution

Later generations such as:

• CRES
• Light-JRES

inherited and expanded these capabilities.

6. Cross-Platform Capability

#

KCBP/KCXP

#

From the beginning, Kingstar emphasized heterogeneous environments.

Supported environments included:

Operating systems:

• Windows
• Unix
• Linux
• AIX
• OS/400

Databases:

• Oracle
• IBM DB2
• SQL Server
• Sybase
• MySQL

The objective:

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

This allowed securities systems to run across very diverse infrastructure.

AS/AR

#

Hundsun’s early focus was more concentrated on:

• securities concentration systems
• three-tier architecture
• network isolation

Later evolution through:

AR/AS

↓

CRES

↓

Light-JRES

moved toward:

• distributed computing
• microservices
• Java-based middleware platforms

7. Two Completely Different Evolution Strategies

#

7.1 Kingstar: Long-Lifecycle Evolution

#

Evolution path:

KCBP/KCXP

|

v

HARE

|

v

KOCA Platform

Characteristics:

• preserve existing investment
• continuous improvement
• backward compatibility

KCBP/KCXP became a foundation layer.

Like:

A database kernel that continues operating for decades.

7.2 Hundsun: Generational Replacement

#

Evolution path:

AR/AS

|

v

CRES

|

v

Light-JRES

Characteristics:

• major architectural upgrades
• technology transitions
• rapid modernization

The strategy resembles:

Operating system version evolution.

Each generation replaced the previous one.

8. Summary Comparison

#

9. Final Thoughts: Two Chinese Financial IT Philosophies

#

KCBP/KCXP and AS/AR were not simply competing products.

They represented two different engineering philosophies.

Kingstar:

#

Build a powerful platform so applications become simpler.

Priorities:

• reliability
• compatibility
• long lifecycle
• infrastructure stability

Hundsun:

#

Build a cleaner architecture that evolves quickly with business needs.

Priorities:

• layering
• service orientation
• modernization
• architectural transformation

If we compare financial IT systems to cities:

Kingstar built a historic city:

• strong foundation
• continuous renovation
• decades of operation

Hundsun built a modern district:

• new architecture
• rapid expansion
• constant rebuilding

Neither approach is universally superior.

They represent two different solutions to the same challenge:

How can financial systems survive decades of technological change?

The story of KCBP/KCXP and AS/AR is therefore not only about middleware.

It is about two different paths taken by China’s financial technology industry.