EDC Connector

Documentation

Base documentation can be found on the documentation website. \ Developer documentation can be found under docs/developer, \ where the main concepts and decisions are captured as decision records.

Directory structure

spi

This is the primary extension point for the connector. It contains all necessary interfaces that need to be implemented as well as essential model classes and enums. Basically, the spi modules defines the extent to what users can customize and extend the code.

core

Contains all absolutely essential building that is necessary to run a connector such as TransferProcessManager, ProvisionManager, DataFlowManager, various model classes, the protocol engine and the policy piece. While it is possible to build a connector with just the code from the core module, it will have very limited capabilities to communicate and to interact with a data space.

extensions

This contains code that extends the connector's core functionality with technology- or cloud-provider-specific code. For example a transfer process store based on Azure CosmosDB, a secure vault based on Azure KeyVault, etc. This is where technology- and cloud-specific implementations should go.

If someone were to create a configuration service based on Postgres, then the implementation should go into the extensions/database/configuration-postgres module.

launchers

Launchers are essentially connector packages that are runnable. What modules get included in the build (and thus: what capabilities a connector has) is defined by the build.gradle.kts file inside the launcher subdirectory. That's also where a Java class containing a main method should go. We will call that class a "runtime" and in order for the connector to become operational the runtime needs to perform several important tasks (="bootstrapping"). For an example take a look at this runtime.

data-protocols

Contains implementations for communication protocols a connector might use, such as DSP.

Contributing

See how to contribute.