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:

• Singleton

• Data Transfer Object

• Data Access Object

• Factory