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
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) Corda bridge node | Corda application node instance where bridge account is stored. |
(6) Corda node | Simple Corda 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:
Last updated
