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.
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.
Inner building blocks
The Backplane Gateway consists of 3 main components:
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.
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
- 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.
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.
SDK Core Implementation
The SDK Core implementation is based on the usage of SDK Generator and it is described in detail in next subsections.
The SDK Core is supported by means of a) the SDK Generator REST API and b) an ansible playbook in charge of generating:
- 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.
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.
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:
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.
- Backplane API (including Semantic Engine, Notification Manager and Smart Contract Manager)
- OIDC API
- Verifiable Credentials API
- Data Access API