759 upgrade edc client to v3 #776

DaviddeBest-TNO · 2025-12-17T14:04:07Z

No description provided.

…olicy/contract definition and catalog request

…process to v3 of EDC API

… reference

…rocess record

DaviddeBest-TNO · 2026-01-15T14:56:55Z

@bnouwt First comment on changes in the Knowledge Directory. We will not be able to avoid sending the EDC participant ID and protocol URL to other KERs through the Knowledge Directory as a KER needs this information to do a catalog request of another participant and it cannot get this information from anywhere else. So the changes in its API input are necessary I would say

bnouwt

Hi @DaviddeBest-TNO, you did a nice job with this pull request.👍

As usual I have been extra picky for the review and this results in quite a few comments, but most are not really mandatory fixes. One thing I do think requires fixing is the fact that users have to manually build the testkd and testsc docker images for the example to run successfully. We either need to add this to the README.md or make sure the docker images are publicly available (which it should after we release the next version of the KE).

As mentioned before, I do not really like the additional KER properties being distributed via the knowledge-directory. I did try to find ways to not having to (see various comments), so I would like to discuss those with you. If we conclude those are not feasible/possible/desirable, then I will accept these additional fields.😢

So, let's discuss this PR further and get it merged!

Regards, Barry

bnouwt · 2026-01-16T09:02:16Z

...connector-api/src/main/java/eu/knowledge/engine/smartconnector/api/SmartConnectorConfig.java

 	 * Key to configure where a KER can reach the management API of its own control
 	 * plane if using EDC.
 	 */
 	public static final String CONF_KEY_KE_EDC_MANAGEMENT_URL = "ke.edc.management.url";


Both CONF_KEY_KE_EDC_PROTOCOL_URL and CONF_KEY_KE_EDC_MANAGEMENT_URL refer to this KER's control plane. Is the first one only necessary to send to other KERs, so they know how to reach this KER's control plane, or is this KER also using that URL?

bnouwt · 2026-01-16T09:18:36Z

...in/java/eu/knowledge/engine/smartconnector/runtime/messaging/RemoteKerConnectionManager.java

-	}
-
-	URI getEdcConnectorUrl() {
-		return this.myEdcConnectorUrl;


Nice to see that all this token code can be removed from the KER code. If I understand correctly, the KER does not need to know anything about the token, because the http-proxy-data-plane checks and strips the token and only sends the request to its KER if the token is valid. Correct?

bnouwt · 2026-01-16T09:28:47Z

.../src/main/java/eu/knowledge/engine/smartconnector/runtime/messaging/RemoteKerConnection.java

+			}
+			this.remoteKerUri = uri;
+		}
+		else if (kerConnectionDetails.getExposedUrl().getUserInfo() != null) {


If I understand this code addition correctly; based on the this.transferProcess check we determine to either use the getExposedUrl() or the counterPartyDataPlaneUrl(). Would it be possible to merge the ke.runtime.exposed.url and ke.edc.dataplane.public.url configuration properties for a KER? If so, we could only use the exposed url and configure it to point to the data plane public url if we use EDC and to the regular KER url if we do not use EDC. Or do we need both a remote KER's exposed and dataplane url when using EDC?

One additional thought: would this code be necessary if we would want to support mixed knowledge networks, where some KERs use EDC and some don't? I somehow do like the idea of supporting this, but we need to check very carefully how this influences the trust in the network.

bnouwt · 2026-01-16T09:31:07Z

.../src/main/java/eu/knowledge/engine/smartconnector/runtime/messaging/RemoteKerConnection.java

-			InMemoryTokenManager tokenManager, KnowledgeEngineRuntimeConnectionDetails kerConnectionDetails) {
-		this.myExposedUri = myExposedUri;
+	public RemoteKerConnection(MessageDispatcher dispatcher, KnowledgeEngineRuntimeConnectionDetails kerConnectionDetails,
+		TransferProcess transferProcess) {


Maybe add javadoc comments to the transferProcess that indicates that this is related to whether EDC is used or not. Currently, it is unclear from this class that and how EDC influences it.

bnouwt · 2026-01-16T09:34:06Z

.../src/main/java/eu/knowledge/engine/smartconnector/runtime/messaging/RemoteKerConnection.java

-			if (this.edcService != null)
-				requestBuilder = requestBuilder.setHeader("Authorization", authToken);
+			HttpRequest.Builder requestBuilder = HttpRequest.newBuilder(new URI(this.remoteKerUri + "/runtimedetails"));
+					//.headers("Content-Type", "application/json");


I would still be interested in knowing why this header is not allowed when using EDC. Also, since we have this transferProcess check, we might use the same check to add the Content-Type header or not. Also, if we decide the Content-Type is not relevant (although I think it is more elegant to state the content of the request), we should probably just remove this comment altogether.

bnouwt · 2026-01-16T10:28:48Z

examples/edc-example/README.md

-Execute the following steps to run the example:
-1. In this project, execute a `mvn clean install`.
-2. In the `knowledge-directory` directory in this project, execute `docker build . -t testkd:1.4.0`.
-3. In the `smart-connector-rest-dist` directory in this project, execute `docker build . -t testsc:1.4.0`.


When I tried this example, I still needed to build this testsc image.

bnouwt · 2026-01-16T10:30:43Z

examples/edc-example/docker-compose.yml

Apparently, both the yaml and yml extension are fine, but I do read that docker-compose is no longer preferred. Maybe rename to compose instead?

bnouwt · 2026-01-16T10:36:26Z

examples/edc-example/docker-compose.yaml

+
+  knowledge-directory:
+    container_name: knowledge-directory
+    image: testkd:1.3.3-SNAPSHOT


Preferably, we use a docker image from the github docker image repository here. Of course, until we actually release a new version of the KE with the necessary code from this pull request, it will not work, but once we release it and the docker image becomes available this example does not require manually building these images.

So, if we do not wait too long with releasing a new KE version, maybe just rename this to ghcr.io/tno/knowledge-engine/knowledge-directory:1.4.0 (a not working EDC compliant docker image) and update it to the next version (1.4.1) as is already part of the KE release steps.

bnouwt · 2026-01-16T10:37:32Z

examples/edc-example/docker-compose.yaml

+
+  alice-ker:
+    container_name: alice-ker
+    image: docker.io/library/testsc:1.3.3-SNAPSHOT


Preferably, we use a docker image from the github docker image repository here. Of course, until we actually release a new version of the KE with the necessary code from this pull request, it will not work, but once we release it and the docker image becomes available this example does not require manually building these images.

So, if we do not wait too long with releasing a new KE version, maybe just rename this to ghcr.io/tno/knowledge-engine/smart-connector:1.4.0 (a not working EDC compliant docker image) and update it to the next version (1.4.1) as is already part of the KE release steps.

bnouwt · 2026-01-16T10:42:55Z

examples/edc-example/docker-compose.yaml

+      KE_EDC_PROTOCOL_URL: "http://host-alice:9183/api/dsp"
+      KE_EDC_MANAGEMENT_URL: "http://alice-control-plane:9082/api/management"
+      KE_EDC_DATAPLANE_PUBLIC_URL: "http://host-alice:8194/api/v1/public"
+    depends_on:         # Necessary?


Ideally, we use the more elaborate depends_on syntax and use the service_healthy condition, but this is only a nice to have I think.

DaviddeBest-TNO linked an issue Dec 17, 2025 that may be closed by this pull request

Upgrade EDC client to v3 #759

Open

DaviddeBest-TNO added 29 commits January 15, 2026 09:26

Update requests of EDC connector client to v3 for registering asset/p…

f36a515

…olicy/contract definition and catalog request

Rename log to capitalized

0f9c302

Reformat EDC files

d9e5a28

Change EDC service to only hold one client

0e81c57

Update requests for catalog request, contract agreement and transfer …

e530b7a

…process to v3 of EDC API

Add participant id to runtime connection details

b91988a

Add polling for transfer process status and request for endpoind data…

8dd52af

… reference

Proxy datatransfer of runtimes via EDC dataplanes

6fd8009

Remove token posting and checking

e595050

Move loading of config to EDC service

739be91

Remove EDC properties object

397ad44

Clean up EDC service

8b231c4

Merge EDC service and client into one class

e2d2f1b

Remove unused functions

34d5597

Move creation of transfer process to edc service and reuse Transfer p…

df0bd51

…rocess record

Clean up unused variables

981c408

Remove unused tokenmanager class

3229396

Remove unused Token record class

5660d9b

Refactor configuring connector

7f09290

Remove unnecessary config values

0a3c141

Combine EDC properties in participant properties object

ccb29f4

Rework EDC service class

60a603a

Remove unused exposed URI

569d531

Move temporary EDC example to this repository

b794414

Fix null bug

ad17901

Update README for EDC example

9281d06

Update README and add log statement

4ec680f

Apply stash

c40afe6

Remove obsolete instructions in docs

c0556ac

DaviddeBest-TNO added 4 commits January 15, 2026 09:32

Remove irrelevant file

01f676f

Remove unused env vars in docker compose

766e56a

Change EDC images

f2d6163

Remove old logging

61b79cc

DaviddeBest-TNO force-pushed the 759-upgrade-edc-client-to-v3 branch from b77be62 to 61b79cc Compare January 15, 2026 14:07

DaviddeBest-TNO marked this pull request as ready for review January 15, 2026 14:07

Update README EDC example

a43f133

Update note

7c1ae27

bnouwt requested changes Jan 16, 2026

View reviewed changes

759 upgrade edc client to v3 #776

Are you sure you want to change the base?

759 upgrade edc client to v3 #776

Uh oh!

Conversation

DaviddeBest-TNO commented Dec 17, 2025

Uh oh!

DaviddeBest-TNO commented Jan 15, 2026

Uh oh!

bnouwt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants