Feature: Refactor Json Ld and edc serialization

[tom-rm-meyer-ISST]

As developer,
I want to use java classes to communicate with the EDC,
so that I don't need to focus on Json-LD.

Hints / Details

With #416 we did the first step to ensure interoperability during negotation. While looking in other repositories how they handle json LD currently only the IRS / Trace-X team seems to correctly handle it.

How they do the integration:

• They add dependencies to the EDC model: pom
• They configure the JsonLd (we should stick to remote context and our monitor impl) centrally: JsonLdConfiguration
• They use a transformer to map between EDC model classes and json-Ld: EdcTransformer, custom transfomers
• How they use the transformer.

Outcome / Acceptance Criteria

Outcome

• ...

Acceptance Criteria

• ...

Out of Scope

• ...

[eschrewe]

To be honest, I am not quite convinced of this proposal.

As it currently is, we are working with the JSON-representation of the policy. This choice seems quite natural to me, because after all we are receiving JSON as payload in the contract negotiation messages of the EDC management api. And we are testing the received JSON very diligently in the "testContractPolicyConstraints" method of the EdcAdapterService class to verify that it contains only the odrl-permissions we expect and nothing else. We also have unit-tests that show that our policy verification works as expected. And even aside from that, we had no arising issues that somehow indicated that there is something wrong with our current implementation.

Sure, we could change all that and add a transformation step. I.e. mapping the JSON representation to a java class first. But then we would still have to perform the same verification tests on the "Policy" class objects.

This mapping to a POJO class may offer advantages in cases, when you can expect to handle Policies in a broader sense. But that does not seem to be the case. For example, we don't store policies in a database. We use policies only in two quite narrowly scoped cases: When we create contract-definitions and when we do contract negotiations.

In both of these use cases we don't need the advantages which the usage of a Policy class could possibly offer.

Instead, the implementation of a transformation service, that performs the mapping from JSON to a Policy class POJO, is apparently not trivial (but rather complex), see the example code from the "item-relations-service" project.

And it may potentially be an avoidable source of other problems/bugs, we did not have before. I definitely don't want to be respectless towards the members of the "item-relations-service" project, but for me (as an outsider), it is not a given, that their code can be assumed to be 100 % flawless.

Yes, they have a UnitTest, but only one single happy-case test is shown there.

Perhaps, I may suggest a different proposal: Maybe, these transformation classes from the "item-relations-service" project could be moved to a separate library project. That project could then be thoroughly tested and verified and then published to maven repository. Then we, as members of the puris project, as well as maybe some other similar projects, could import that library and use it then.