The consumer part of the TSG Playground consists out of two types of interactions:
Consuming artifacts
Consuming API endpoints
Since for the consumption of resources it is not required for the consuming connector to be available on the internet, there are three different deployment variants of the connector. Either via Kubernetes, preferred since this allows to easily migrate to a deployment that is reachable by others, or via Docker-compose.
Consuming artifacts
The consumption of artifacts is the default IDS way of interaction between two connectors. Following the general process of:
retrieving the metadata of the connector and artifact,
negotiating a contract for the artifact,
retrieving the artifact.
The test connector deployed at https://test-connector.playground.dataspac.es/ui/ provides a single artifact with a simple policy offer attached to it that allows for READ and USE rights if a consumer requests a contract with a validity in 2022 and 2023.
The following deployment strategies can be chosen for consuming artifacts:
Local Kubernetes: For Kubernetes clusters on local hardware, e.g. via Docker Desktop, Minikube, MicroK8s.
Public Kubernetes: For Kubernetes clusters on cloud infrastructure or on self-managed servers that are reachable from the internet.
Docker Compose: If you don’t have any experience with Kubernetes and no intention to use it in the future. Configuration will be harder for Docker deployments, especially when moving towards a publicly available connector.
Consuming API endpoints
The consumption of API endpoints is an addition to the default IDS interaction that allows to exchange API endpoints. This allows for existing HTTP services to work over IDS. For this the OpenAPI Data App is used.
The process of consuming an API is as follows:
retrieve metadata of the connector and OpenAPI data app resources,
send the HTTP request to the OpenAPI data app connected to your own connector
The following deployment strategies can be chosen for consuming API endpoints:
Local Kubernetes: For Kubernetes clusters on local hardware, e.g. via Docker Desktop, Minikube, MicroK8s.
Public Kubernetes: For Kubernetes clusters on cloud infrastructure or on self-managed servers that are reachable from the internet.
Docker Compose: If you don’t have any experience with Kubernetes and no intention to use it in the future. Configuration will be harder for Docker deployments, especially when moving towards a publicly available connector.