Eclipse Dataspace Connector (EDC): Hands On

Sogenannte „Data Spaces“ (oder Datenräume) sind das Schlüsselkonzept für eine groß angelegte, länderübergreifende Datenökonomie. So sieht das auch die Gaia-X Initiative für eine Dateninfrastruktur in Europa vor. Die „International Data Space Association“ (IDSA) liefert dafür mit einem großen Anteil das Architekturmodell, Schnittstellen und Standards. Ein Beispiel dafür ist das unter dem Projektnamen „Catena-X“ eingeführte Data Space, das die die Datenökonomie der Automobilindustrie vertreten soll. Datenräume kommunizieren über standardisierte Konnektoren. Der Eclipse Data Space Connector (EDC) ist ein standard- und richtliniengemäßer Konnektor der im Rahmen von Catena-X, aber auch allgemein als Konnektor für Data Spaces eingesetzt werden kann.

In diesem Blogbeitrag schauen wir uns EDC genauer an. Dabei ist das Ziel ein besseres Verständnis über den Konnektor zu erlangen und eine Kommunikation mit diesem aufzubauen.

Informationsquellen zum Eclipse Data Space Connector

Eine gute Übersicht zum EDC Projekt ist auf der Eclipse Foundation zu finden (https://projects.eclipse.org/projects/technology.dataspaceconnector). Auf dieser Seite ist eine Projektübersicht zu finden. Grundsätzliche Fragen über das EDC Projekt können hierdurch beantwortet werden.

Das technische Konzept des Eclipse Data Space Connectors wird vom Catena-X Projekt übersichtlich in einer Seite festgehalten und bietet übersichtliche Darstellungen zum Aufbau und der Funktion des EDC-Konnektors: https://catena-x.net/en/angebote/edc-die-zentrale-komponente-fuer-die

Als Open Source Software ist der Quellcode des EDC öffentlich abgelegt. In Form eines Projekts ist dieser auf Github einsehbar: [https://github.com/eclipse-dataspaceconnector/DataSpaceConnector]. Innerhalb des Projektverzeichnisses befinden sich mehrere Anleitungsdateien, die den Leser über die technischen Komponenten, Funktionsweise und Anwendung informieren soll.

Zusätzlich gibt es eine hilfreiche Webseite (https://eclipse-dataspaceconnector.github.io/docs/#/) die alle Komponenten des EDC erläutert, dazugehörige Dokumente (bspw. Veröffentlichungen) und eine „Erste Schritte“ -Anleitung beinhaltet. Wer das EDC verstehen und damit entwickeln möchte, sollte unbedingt die „Hands-On“-Beispiele durchgehen.

Hands-On – Klonen, Bauen, Ausführen des Eclipse Data Space Connector auf der lokalen Maschine

Um die Hands-On Beispiele durchzugehen wird der Quellcode des EDC-Projekts [https://github.com/eclipse-dataspaceconnector/DataSpaceConnector] von Github in die eigene lokale Entwicklungsumgebung geklont:

git clone https://github.com/eclipse-dataspaceconnector/DataSpaceConnector.git

Sollte das Projekt nicht vollständig in das lokale Projekt geklont werden, liegt es sehr wahrscheinlich daran, dass eine Konfiguration in git das Klonen von Projektdateien mit einem längeren Dateinamen ablehnt. Die Beschränkung kann mit folgendem Konsolenbefehl aufgehoben werden:

git config –system.core.longpaths true

Das Projekt lässt sich mit dem Befehl „./gradlew clean build“ bauen. Dieser Prozess dauert einige Minuten und es ist möglich, dass dabei in den letzten Bauschritten noch Fehler auftreten (Tests schlagen fehl). Der Eclipse Data Space Connector befindet sich noch in Entwicklung. Zu Testzwecken setzen wir den Bauprozess mit dem Befehl „./gradlew –continue“ fort. Der Build Prozess sollte erfolgreich abgeschlossen sein.

Um die Funktion des Konnektors zu verifizieren, starten wir diesen mit folgendem Befehl:

java -jar launchers/ids-connector/build/libs/dataspace-connector.jar

Sobald in der Konsole „Datspace Connector ready“ steht, kann davon ausgegangen werden, dass der Konnektor korrekt installiert wurde. Dieser Konnektor ist noch funktionslos. Über Erweiterungen wird der EDC in diesem Hands-On mit einer Schnittstelle versehen. Dazu wird zuerst ein Blick auf die Ordnerstruktur geworfen. So kann ein Überblick über das Projekt verschafft werden.

EDC – Ordnerstruktur

Das Projekt wird in mehreren Unterverzeichnissen aufgeteilt. Im Folgenden werden die wichtigsten Verzeichnisse erläutert:

spi

Dies ist der primäre Erweiterungspunkt für den Konnektor. Es enthält alle notwendigen Schnittstellen, die implementiert werden müssen, sowie wesentliche Modellklassen und Enums. Grundsätzlich definieren die spi-Module das Maß, in dem Anwender den Code anpassen und erweitern können.

core

In diesem Verzeichnis befinden sich alle absolut essentiellen Bausteine, die zum Betrieb eines Konnektors notwendig sind, wie TransferProcessManager, ProvisionManager, DataFlowManager, verschiedene Modellklassen, die Protokoll-Engine und den Policy-Teil. Es ist zwar möglich, einen Konnektor nur mit dem Code des Kernmoduls zu erstellen. Die Möglichkeiten bei der Kommunikation mit Data Spaces sind dadurch jedoch beschränkt.

Extensions

Dieses Unterverzeichnis enthält Code, der die Kernfunktionalität des Konnektors um technologie- oder cloud-provider-spezifischen Code erweitert. Zum Beispiel ein Transferprozess-Speicher auf Basis von Azure CosmosDB, ein sicherer Tresor auf Basis von Azure KeyVault, etc. Hier sollten technologie- und cloud-spezifische Implementierungen stattfinden.

launchers

Launchers sind im Wesentlichen Connector-Pakete, die lauffähig sind. Welche Module in den Build eingeschlossen werden (und damit: welche Fähigkeiten ein Konnektor hat), wird durch die Datei build.gradle.kts im Unterverzeichnis launcher definiert.

data-protocols

Enthält Implementierungen für Kommunikationsprotokolle, die ein Konnektor verwenden könnte, wie z. B. IDS.

samples

Enthält Code, der demonstriert, wie der Konnektor in verschiedenen Szenarien verwendet werden kann. Es wird beispielsweise gezeigt, wie ein Konnektor aus einem Unit-Test heraus ausgeführt wird, um die Funktionalität schnell zu testen, oder wie eine nach außen gerichtete REST-API für einen Konnektor implementiert wird. [https://github.com/eclipse-dataspaceconnector/DataSpaceConnector]

EDC Erweiterung um eine Schnittstelle mit einer Extension

In diesem Beispiel wird der Konnektor um eine REST-Schnittstelle erweitert. Diese antwortet bei eingehenden Requests mit einer benutzerdefinierten Antwortnachricht (bpsw. „Hello World!“).

Der EDC wurde mit großer Rücksicht auf Erweiterbarkeit entwickelt. So ergibt sich die Möglichkeit im Unterverzeichnis Extension ein Java Unterprojekt anzulegen und mit dem Konnektor ausführen zu lassen. Damit können Verbindungen zu jeglichen Datenbanken aufgebaut werden.

Zuerst wird ein Modul im Pfad „../extensions/common/“ angelegt:

Das Modul wird in diesem Beispiel „myrest“ genannt. Dabei wird Gradle als Build-management Tool ausgewählt und in der Sprache Kotlin festgelegt. EDC setzt mindestens die Version 11 für Java voraus.

Das erstellte Verzeichnis muss überarbeitet werden, sodass es als Extension vom überliegenden Konnektor Projekt erkannt wird.

Zuerst wird die build.gradle.kts eingerichtet. Notwendige Abhängigkeiten zum Konnektor werden hier aufgenommen. Zusätzlich wird Jakarta hinzugefügt, um den REST-Controller aufzubauen. In der letzten Zeile wird der Name für den ausführbaren Konnektor festgelegt. Die build.gradle.kts Datei sollte wie folgt aussehen:

build.gradle.kts

plugins {
    `java-library`
    id("application")
    id("com.github.johnrengelman.shadow") version "7.1.2"
}

val rsApi: String by project

dependencies {
    implementation(project(":core:control-plane:control-plane-core"))

    implementation(project(":extensions:common:http"))

    implementation("jakarta.ws.rs:jakarta.ws.rs-api:${rsApi}")
}

application {
    mainClass.set(

        "org.eclipse.dataspaceconnector.boot.system.runtime.BaseRuntime")
}

tasks.withType<com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar> {
    exclude("**/pom.properties", "**/pom.xm")
    mergeServiceFiles()
    archiveFileName.set("connector-myrest.jar")
}

Anstatt der automatisch erstellten Main.java Klasse werden zwei neue angelegt. Die erste Klasse ist bei der Erstellung eines Extensions für EDC notwendig. In diesem Beispiel nennen wir diese „MyrestEndpointExtension“. Diese muss das Interface „ServiceExtension“ des EDC implementieren, sodass die Extension vom Konnektor einbezogen wird. Diese injiziert einen Webservice in den Konnektor. Der Webservice wird später mit der zweiten Klasse „MyrestApiController“ definiert. Die Klasse MyrestEndpointExtension sieht wie folgt aus:

MyrestEndpointExtension.java

package org.eclipse.dataspaceconnector.extensions.myrest;

import org.eclipse.dataspaceconnector.runtime.metamodel.annotation.Inject;
import org.eclipse.dataspaceconnector.spi.WebService;
import org.eclipse.dataspaceconnector.spi.system.ServiceExtension;
import org.eclipse.dataspaceconnector.spi.system.ServiceExtensionContext;

public class MyrestEndpointExtension implements ServiceExtension {

    @Inject
    WebService webService;

    @Override
    public void initialize(ServiceExtensionContext context) {
        webService.registerResource(

               new org.eclipse.dataspaceconnector.extensions.myrest

                       .MyrestApiController(context.getMonitor()));
    }
}

Die zweite Klasse MyrestApiController definiert die Funktionen der REST-Schnittstelle. Mit Jakarta erstellen wir eine simple Schnittstelle um den Anfrager zu grüßen. Der EDC-seitige Logger wird dabei genutzt um eine eingegangene Anfrage zu signalisieren. Die Klasse sieht wie folgt aus:

MyrestApiController.java

package org.eclipse.dataspaceconnector.extensions.myrest;

import jakarta.ws.rs.Consumes;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import org.eclipse.dataspaceconnector.spi.monitor.Monitor;


@Consumes({MediaType.APPLICATION_JSON})
@Produces({MediaType.APPLICATION_JSON})
@Path("/")
public class MyrestApiController {
    private final Monitor monitor;

    public MyrestApiController(Monitor monitor) {
        this.monitor = monitor;
    }

    @GET
    @Path("doubleslash")
    public String checkHealth() {
        monitor.info("Received GET Request");
        return "{\"response\":\"Welcome, I'm alive at doubleSlash!\"}";
    }
}

Nach der Erstellung muss die Extension in einer von EDC vorgeschrieben Form registriert werden. Dies wird durch Anlegen der folgenden Struktur unter dem Package „main“ erreicht. Wichtig zu beachten ist, dass die Struktur genau wie im folgenden Bildausschnitt angelegt und benannt werden muss (resources/META_INF/services/…):

Innerhalb des „services“ Ordners muss eine Datei mit dem Namen aus dem Ausschnitt angelegt (org.eclipse…) werden. Der Inhalt besteht aus einer Textzeile. Dabei handelt es sich um den Pfad zur „MyrestEndpointExtension“-Klasse:

Nun wurde die Extension erstellt und beim Konnektor registriert.

Testen der entwickelten Schnittstelle am Konnektor

Nun kann das gesamte DataSpace-Projekt gebaut werden. Zusätzlich wird die hinzugefügte Extension gebaut. Dazu öffnen wir das Gradlefenster, navigieren zur „dataspaceconnector/extensions/myrest/common/myres/Tasks/build/“ und führen einen Doppelklick auf „clean“ aus, um die Extension erstmal von bereits bestehenden Builddateien zu bereinigen. Danach kann im gleichen Verzeichnis der „build“ Befehl ausgeführt werden. Innerhalb des „myrest“ Extension-Ordners erscheint nun ein Build Ordner:

In diesem befindet sich das Endprodukt der Extension. Nun können wir den Konnektor mit folgendem Befehl ausführen:

Standardmäßig wird der Server lokal auf dem Port 8181 ausgeführt. Diesen können wir nun im Browser ansprechen:

Das Beispiel für die REST-Schnittstelle zeigt auf, wie auch bspw. eine Datenquelle mit dem Konnektor verbunden werden kann. Hierzu bietet der Konnektor bereits mehrere Funktionen, die dies erleichtern. Beispielsweise kann mit einem integrierten SQL Package gearbeitet werden und so SQL-Datenbanken verbunden werden. Noch einfacher ist es mit einer passenden Erweiterung. Innerhalb des Projekts gibt es bereits eine PostgresQL-Extension, mit der die Verbindung eingerichtet werden kann. Aber auch Cloud Lösungen werden schon unterstützt. Die Cloud Anbieter Azure und AWS sind ebenso in den bereits bestehenden Erweiterungen zu finden. Innerhalb der Erweiterung sind immer wieder README Anleitungen zu finden, die eine Verbindung zur Cloud erleichtern.

Fazit

Wichtig zu erwähnen ist, dass sich der EDC noch in der Entwicklung befindet. Daher kam es bei der Erstellung der REST-Schnittstelle vereinzelt zu Fehlern, die teilweise an der Konfiguration der Entwicklungsumgebung und den Tools lagen. Glücklicherweise können diese schnell behoben werden. Nutzerfreundlich ist dies allerdings nicht. Bei der Fehlerlösungssuche mithilfe des Internets ist kaum etwas zu finden, da die Arbeit mit dem EDC momentan ein neuartiges Thema ist.

Andererseits bietet das EDC Projekt gutes Infomaterial und viele Anleitungen, wie man den Konnektor richtig nutzt. Sehr hilfreich sind die vier Beispiele (samples) die sich mit im Projekt befinden. Dabei geht es vom Ausführen eines Konnektors bis hin zur Verbindung mit einer Cloud. Zusätzlich sind mehrere Anleitungen im Projekt verteilt. Diese sollen die jeweilige Funktion und Nutzung des Unterverzeichnisses erläutern und näherbringen.