Search
K

Bridge Architecture

Impel's R3 Corda | XDC Network Bridge Architected Design

Architected design style

Impel's bridge platform's architectural style is classified as a Service Oriented Architecture (SOA), to which there are two main services; a user interface service and a bridge service.
A strong advantage of having decoupled application components allows for readiness to easily connect with each new component or with other types of network systems.
Using The Twelve-Factor App principles make Impel's bridge scalable, robust, clean, and easy to incorporate additions.

Architecture diagram

Image 1
The main components of the architecture (Image 1) are denoted with digits from 1 to 6 and each one is explained as follows;
Components
Description
(1) Blockchain
Is the core technology where all types of XDC Network transactions are stored.
(2) Smart contract
Bridge pieces of code stored in the blockchain that helps the system to interact and manipulate data in the blockchain.
(3) UI service
A Angular 9 frontend application created for user interaction with the system functionalities.
(4) Bridge service
NodeJS backend application containing the business logic functionalities of the system.
(5) Cordite bridge node
Cordite application node instance where bridge account is stored.
(6) Cordite node
Simple Cordite node where other accounts can be stored.
The architecture has four core components:
Core Components
Description
(U)ser
The human user interface interactions
(S)end
Send flow system actions
(R)eceive
Receive flow system actions
(T)ransactions
Transactions query system actions
Other bridge actions;
Action
Description
U1. User interaction
The user can send or receive XDC asset value to or from Corda accounts and further this will trigger system actions like S1 or R1.
S1. Trigger send
Calls a smart contract method to send XDC tokens further to Corda account.
S2. Process teleports
Bridge service reads contract events and sends asset value teleports that will be processed further to be sent to the Corda network.
S3. Issue assets
Get teleports from the S2 action move this to Corda bridge account and further to the account used by the user using Corda API.
R1. Trigger settle
Calls REST API from the bridge account that initiates a settlement process, data that is passed to the API contains also the user and password credentials in order to connect to the Cordite account.
R2. Settle
Bridge service calls the Cordite API where it gets the XDC asset value and sends this to an XDC account.
T1. Query transactions
In order for the UI service to display transactions in real-time the system queries the blockchain for the last transactions that are not stored in the cache and displays this to the User Interface transactions component screen.

Architectural patterns

Both the UI and Bridge service uses a Layered Pattern that helps to organize project files and folders, simplifies the entire project structure. This pattern works real well with Angular 9 concepts like service and components to which Impel's bridge uses.

Design pattern

Most importantly, the Adapter pattern is the chosen methodology design used, assisting the bridge service, and allows to scale the system vertically. Depending on the teleport event or if the payload includes digital assets, the appropriate adapter class is chosen to complete a successful transaction.

Miscellaneous patterns

Other design patterns used by Impel's bridge for both UI and Bridge services include: