feat: added new connect & exchange pattern first draft

[matbmoser]

Description

This pattern is mentioned here in this issue: #5

I have added the same content, as a first draft. It can be refactored in the future if needed.

Please add yourself to the authors list if you review the pull request.

The idea is to merge it as a draft so we have already something, and then we can continue to work on it as a community.

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

• DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
• Copyright and license header are present on all affected files

[lgblaumeiser]

Sorry for having so many comments, I think your idea is a really good one, but we have to work on clarity to get the idea through.

One thought that came to my mind when I read this is, that it is really a good question what kind of document this is. With referring to a non-standardized feature, it is a Tractus-X topic and recommendation for usage of Tractus-X means. But there is a general pattern behind it, which says, that for assets with a character of being used by the same consumer multiple times, long living contracts build a steady connection that should be reused for the length of the contract validity. This is a Catena-X message.

Again this ends up in this void, that we only want to standardize interactions between dataspace participants, but we provide an infrastructure with Tractus-X that is easily misunderstood and actually should not be referred to by use case standards, and only in a very limited way in KITs.

We are currently discussing in CX-Next TAP 7.1 about a general KIT that describes the interaction between two participants and the Industry Core Committe is also planning something along this line. Could be a good embedding for this proposal also towards use cases.

As it is now, your target audience are the Tractus-X Use Case apps and proprietary app developer that use the Tractus-X EDC as connector implementation.

[matbmoser]

We are currently discussing in CX-Next TAP 7.1 about a general KIT that describes the interaction between two participants and the Industry Core Committe is also planning something along this line. Could be a good embedding for this proposal also towards use cases.

Wonderful, I was already in some conversations with people interested a "Kickstart KIT" which I also mention in this pattern.

[matbmoser]

As it is now, your target audience are the Tractus-X Use Case apps and proprietary app developer that use the Tractus-X EDC as connector implementation.

I will add this target then

[matbmoser]

@lgblaumeiser please review it again, I have added some new diagrams that will help to understand the concept.

[ndr-brt]

generally speaking, I think this would be more effective if designed as an EDC client library more than an EDC extension. Details in the comments

[ndr-brt]

this diagram is quite hard to understand also by reading the text above in the document. Could it be reduced to only a single interaction between a consumer and a provider and relative apps?

[matbmoser]

I can add a simple diagram too
That diagram serves the prurpose of showing the general context on a "mesh" of companies.
But you are right I got the feedback that people additionally want to have it with consumer and provider.

[matbmoser]

I forgot to include this diagram:

[ndr-brt]

this diagram is quite hard to understand also by reading the text above in the document. Could it be reduced to only a single interaction between a consumer and a provider and relative apps?

[matbmoser]

I forgot to include this diagram:

[matbmoser]

@ndr-brt Thanks for the detailed review!!!

I will revise your points and I ping you back when I am done :)

[matbmoser]

@ndr-brt I wanted to represent something specifically with the connect and exchange labels in the left, I tried to do it with mermaid but I was not able to do it. Even though I love mermaid I have made it with Draw.io as mentioned in the TRG 1.4 and it is able to be editable.

I have included your changes and points, removed the points I could not explain or made no sense, and added the new 1:1 diagram.

Thanks for the review!

@lgblaumeiser and @ndr-brt could I get an approval?

In case there is something to change then open another PR :)

[matbmoser]

I have added you @ndr-brt in authors and indicated the last review date

[lgblaumeiser]

Bascially reformulations to improve readability, hope this is ok for you! Choose as you like.

[lgblaumeiser]

That is not a case, as this requires that there is a new asset with the changed policies, existing contracts can be cancelled sind EDC 0.8.0 from the provider, but as this is a legally binding contract, this requires to handle the legal stuff prior to do so.

[matbmoser]

I will add all of them it's fine for me, thank you for remarking the points!! :)

[ndr-brt]

@matbmoser my review was still pending, merge was not supposed to happen yet

[matbmoser]

We can still revert it. I have included all the changes your requested, and since you not restricted the merging I believed it was ok to merge already.
If you see that there is something missing, please open another PR and I will approve it so we can merge your changes.

Sorry for the inconvenience...

[matbmoser]

@ndr-brt #7

We can still revert it I just need your approval.

[ndr-brt]

@ndr-brt #7

We can still revert it I just need your approval.

no need to revert, it is only a draft document in any case, but for the future it's better follow the good practices and wait for all the pending review to be approved before merging ;)

[matbmoser]

@ndr-brt #7
We can still revert it I just need your approval.

no need to revert, it is only a draft document in any case, but for the future it's better follow the good practices and wait for all the pending review to be approved before merging ;)

Fair enough, sorry for my mistake, please also block the merging next time so I can also know you want to check it before I merge it :)

I will close the revert PR.