Backplane Gateway System

The Backplane Gateway System is the building block in charge of offering to all participants and marketplaces access to the Backplane system. The goal of the Backplane API is therefore twofold: on one hand, it serves an integrated API endpoint for all the i3-MARKET services offered by i3-MARKET and implemented in the respective building blocks. And on the other hand, it provides secure mechanisms for preventing not allowed accesses.

In term of public interfaces, the functionality integrated by the Backplane Gateway is exposed thought the Backplane API.

In terms of internal connexons with other i3-MARKET building block, Backplane Gateway system has secure communication with the rest of subsystems to integrate their services into the Backplane API. For this integration any service much have a complete specification following the OpenAPI Specification 3.0.

General description

The Backplane Gateway has two main purposes:

  • Single entrypoint: The Backplane offers a single set of endpoints, allowing clients to interact with all the services offered by the i3-MARKET project through a single API. This allows the whole system to have a modular and distributed architecture, while providing the ease of use of a single common interface.
  • Auth management: All authentication and authorization flows are centralized and managed by the Backplane Gateway so that the subsystems are protected without them needing to handle their own auth flows. The actual authentication/authorization is delegated to specialized subsystems. This centralization also allows the support of several auth flows (and the addition of new ones) transparent to the several subsystems.

Besides these main purposes, the presence of the Backplane Gateway provides several benefits:

  • Allows the subsystems to be isolated and not exposed publicly, so that they can only be accessed by the Backplane or other subsystems.
  • External connections are all handled by the Backplane, making connection security and encryption simpler and more straightforward.
  • The nature of the Backplane functionalities makes it easily scalable and replicable, making the addition of new Backplane instances transparent for both the subsystems and the clients.
Figure 1 – Backplane Gateway component diagram

Inner building blocks

The Backplane Gateway consists of 3 main components:

Backplane API

The Backplane API is the set of endpoints exposed by the Gateway. It comprises all the publicly available endpoints of the subsystems integrated with the Backplane, as well as a few other endpoints, belonging to the Backplane itself, used in the authentication/authorization flows.

The API follows the OpenApi Specification 3.0, and the endpoints corresponding to each subsystem are generated automatically based on the subsystem’s own OpenApi Specification.

Backplane Auth Manager

The Backplane auth manager is the responsible of handling the authentication and the authorization required for the endpoints of the different subsystems. The actual auth processes are delegated to the corresponding subsystem (User/Service centric authentication subsystem), depending on the requirements of the endpoint and client.

Backplane Router

The Backplane router is the component of the Backplane responsible for the forwarding of the incoming requests to the several subsystems. It also checks whether the endpoint requires authentication/authorization, invoking the Auth Manager if it does.

SDK Core Specification

General objectives

  • Backplane API SDK. The main goal of the SDK is boasting the Backplane API to create applications for the i3-MARKET platform. It will assist the data marketplaces and stakeholder developers with a set of tools, examples and documentation which will reduce the developing effort to be part of the i3-MARKET ecosystem. The Backplane API SDK content is divided into different logical modules which correspond to each of the i3-MARKET modules integrated in the Backplane API. Following, the different modules identified for the first version of the requirement specification can be seen:
    • User Centric Authentication SDK 
    • Cloud Wallet SDK module
    • Data Access SDK module
    • Standard Payments SDK module
    • Tokenization SDK module
  • Enhanced Backplane API SDK. For some cases, the SDK will complete the Backplane API services with its own logic to support the developers in the use of the i3-MARKET capabilities. These will be done through a set of workflows. 
  • Automatically-build Backplane API SDK. In addition to the inner SDK functionality, i3-MARKET will provide mechanisms to automatically build the SDK component and it will be offered in different programming languages.

Big picture

It is important to highlight that SDK-Core is supported as main pillar for the SDK-Generator.

The following picture shows the subsystem in charge of the SDK generation. Several components are involved in the process.

Some of the components depicted in Figure 2 are external to the SDK scope, such as:

  • Backplane API/Backplane API Gateway,
  • OpenAPI Generator, an open-source tool useful for the generator process.

On the other hand, following components will be provided in the context of the SDK Generation:

  • SDK Generator, the entry point to the Backplane API SDK creation and client of the OpenAPI Generator API.
  • Backplane SDK Enhancer. It will oversee extending the Backplane API functionality when required. It will use as input the result from the OpenAPI Generator and will give as result an augmented SDK which is able to complement the functionality exposed by the Backplane API. 
Diagram, schematic

Description automatically generated
Figure 2 – SDK Generation diagram components

SDK Core Implementation

The SDK Core implementation is based on the usage of SDK Generator and it is described in detail in next subsections.

Core Technology

The SDK Core is supported by means of a) the SDK Generator REST API and b) an ansible playbook in charge of generating:

  1. An SDK-Core Java artifact that contains client stub for Backplane API (semantic engine, notification manager and smart contract manager), OIDC (Open Id), VC (Verifiable credentials) and Data Access API.
  2. An SDK-Core JavaScript artifact contains client stub for Backplane API (semantic engine, notification manager and smart contract manager), OIDC, VC and Data Access API.

SDK Generator

The SDK Generator is the main pillar of the SDK Core. The SDK Generator is based on SDK as a service approach. SDK Generator aims to automatically generate the client stubs needed to interact and consume all the functionalities exposed in a REST API. The SDK as a service approach is shown in Figure 3.

Figure 3 – SDK Generator approach.

The workflow behind SDK Generator is based on the provision of a programming language specification next to an OAS file and making use of the OpenAPI generator server which is able to produce as output SDK client stubs next to associated documentation about how to use it.

The languages supported by the SDK Generator are shown in Figure 4:

Figure 4 – SDK Generator supported programming languages

Continuous Integration and Delivery

The SDK-Core artifact is automatically provided by means of an CI/CD pipeline based on Ansible AWX. A conceptual view of SDK-Core pipeline is shown in Figure 5.

Figure 5 – SDK-Core CI/CD pipeline

As initial step in the pipeline the SDK-Core artifact is triggering the compilation and deployment of a new version of the SDK-Generator once a commit into master branch of SDK-Generator project happens. As second step (represented as green area in Figure 10), the generation and publishing of a new version of the SDK-Core artifact it is triggering each one a new version of backplane API it is deployed. The CI/CD behind backplane API includes a triggering to SDK-Core pipeline. In this way, SDK-Core covers a set of tasks mainly in charge of generating SDK-Core artifacts for Java and JavaScript versions taking a set of relevant OAS files associated to the following artifacts:

  • Backplane API (including Semantic Engine, Notification Manager and Smart Contract Manager)
  • Verifiable Credentials API
  • Data Access API

Go to the beginning of the page