DSX Engine Community Edition

Truly decentralized dataspace connector based on Eclipse Dataspace Components (EDC).

This project currently has three runtimes which are working together to represent a Connector:

• controlplane
  • core component of a connector;
  • through it assets, policies, contract definitions,... are managed;
  • facilitates Federated Catalog component with Crawlers;
  • facilitates Contract Negotiations and other functionalities.
• dataplane
  • used as a data proxy;
  • can be horizontally scaled by deploying multiple instances;
  • used only for data serving.
• identity
  • used as an identity wallet;
  • it holds DID Documents, VCs, VPs, keypairs,...

There is also issuer runtime which issues and signs credentials. It acts as a trust anchor for the dataspace. One dataspace can have multiple trusted issuers.

---

Quick start

Using Docker:

./gradlew dockerize # on x86/64 platforms
./gradlew dockerize -Dplatform="linux/amd64" # on arm platforms, e.g. Apple M1

This creates a Docker Image for each runtime. Default tag is latest and projectVersion (if exists).

It generates the following images:

• controlplane
• dataplane
• identity
• issuer

In both cases configuration must be supplied, either using Docker environment variables, or using Java application properties.

Directory structure

• config: contains the configuration file for the Checkstyle plugin
• extensions: this is where your extension modules should be implemented
• gradle: contains the Gradle Wrapper and the Version Catalog
• runtimes: contains executable modules for the controlplane and data plane
• environments: contains environment files (.env) for the Demo project

When developing only an extension

This is for developers who want to create custom extensions to implement new features and thereby extend the EDC functionality. For example, implementing support for a new database technology could be implemented in one (or several) extensions.

If this is you, then you should focus mainly on the extensions/ directory.

When developing a custom runtime

This is for developers who want to package several existing extensions into a new runtime. A runtime in EDC-speak is a runnable application. We achieve this by packaging all class files into a fat JAR using the Shadow Plugin, but naturally other approaches exist (but are not covered here).

If this is you, then you should focus mainly on the runtimes/ directory.

Configuration

For latest ENVs please check environments directory.

Extension configuration and information

Some extensions have their own README.md files with documentation on purpose, ENVs and other useful information on how to get started.

Additional information

This project can be set up in a way that's very similar to Eclipse Minimum Viable Dataspace.