The current EDC negotiation process triggers multiple unnecessary contract negotiations for the same asset, leading to inefficient performance. To address this, a new orchestrator is required to manage negotiations more effectively and prevent duplicate parallel negotiations for the same asset.
What's the benefit?
Reduce the amount of (unnecessary) contract negotiations to improve performance.
What are the Risks/Dependencies ?
Nothing to report
Detailed explanation
Isolation of jobs causes contract negotiations for the same asset. This will be improved.
Current implementation
Refer to section "Concept"
Proposed improvements
Refer to section "Concept"
Feature Team
Contributor
Cofinity-X @rogocof
Cofinity-X @mkanal
Committer
@ds-jhartmann
@ds-mwesener
@ds-lcapellino
Context:
The current EDC negotiation process triggers multiple unnecessary contract negotiations for the same asset, leading to inefficient performance. To address this, a new orchestrator is required to manage negotiations more effectively and prevent duplicate parallel negotiations for the same asset.
User Story
As a system architect,
I want to implement an Orchestrator for EDC negotiations,
so that multiple requests for the same asset are managed efficiently, reducing redundant contract negotiations and improving overall system performance.
Acceptance Criteria
[ ] Orchestrator handles multiple negotiation requests without initiating duplicate negotiations for the same asset.
[ ] Cached tokens are reused for subsequent requests.
[ ] ExecutorService configuration is adjustable to control parallelism.
[ ] Tested with multiple jobs using Wiremock Tests
[ ] Tested with E2E Tests
[ ] Measurement of 5 job executions and write it down in a confluence page before and after adjusting the code.
Hint
The orchestrator will manage ongoing negotiations using a ConcurrentHashMap with asset IDs as keys, and will limit parallel requests via an ExecutorService. Token caching will allow reuse of previously negotiated tokens to avoid repetitive EDC calls.
Concept
A new service “NegotiationOrchestrator” is introduced which is a middle layer between the already existing components EdcSubmodelClientImpl and ContractNegotiationService, EDCCatalogFacade and EndpointDataReferenceCacheService.
The service handles the following tasks:
orchestration of catalog requests by id
orchestration of catalog requests by type
orchestration of contract negotiations
caching of ongoing contract negotiations
caching of EDR tokens
To prevent too many parallel requests to the EDC, an ExecutorService handles the catalog requests and negotiations with a defined thread pool.
To cache the currently ongoing negotiations, a ConcurrentHashMap with EDC AssetIds as key can be used. Due to the asynchronous process within NegotiationOrchestrator, the future EDR can be created and added to the cache as soon as the method is called and will be removed only after the negotiation is completed. In addition a time to live can be added for cleanup.
To cache EDR tokens, the EndpointDataReferenceCacheService can be used. The caching service wraps EDR tokens into a object with a state indicating if the token is valid (i.e. can be used directly to authenticate the dataplane request) or expired (i.e. the validityPeriod is expired). After expiration the token can be reused to request a new token. Cache eviction is handled independent of token state and will use a configurable TTL to evict cached entries.
Special Case: Registry Negotiation
Contract offers for the digital twin registry are identified by a type. This changes the process slightly, so it is not only one contract offer which will be negotiated, but potentially multiple contract offers.
Since the NegotiationOrchestrator works asynchronously, we can simply start the EDR negotiation process for all the received contract offers and will receive a list of Future EDRs.
The process of NegotiationOrchestrator is left out of the chart, since it is the same as previous.
Precondition
*
Risk Dependencies
*
Test Cases
Test Case 1
Steps
Do something
Click something
Add something
Expected Result
Expectation
Expectation
Expectation
Architectural Relevance
The following items are ensured (answer: yes) after this issue is implemented:
[ ] This feature aligns with our current architectural guidelines
[ ] The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
[ ] Potential risks or conflicts with existing architecture has been assessed
Justification:(Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)
Additional information
[x] I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)
Overview
Explain the topic in 2 sentences
The current EDC negotiation process triggers multiple unnecessary contract negotiations for the same asset, leading to inefficient performance. To address this, a new orchestrator is required to manage negotiations more effectively and prevent duplicate parallel negotiations for the same asset.
What's the benefit?
Reduce the amount of (unnecessary) contract negotiations to improve performance.
What are the Risks/Dependencies ?
Detailed explanation
Isolation of jobs causes contract negotiations for the same asset. This will be improved.
Current implementation
Refer to section "Concept"
Proposed improvements
Refer to section "Concept"
Feature Team
Contributor
Committer
Context:
The current EDC negotiation process triggers multiple unnecessary contract negotiations for the same asset, leading to inefficient performance. To address this, a new orchestrator is required to manage negotiations more effectively and prevent duplicate parallel negotiations for the same asset.
User Story
As a system architect, I want to implement an Orchestrator for EDC negotiations, so that multiple requests for the same asset are managed efficiently, reducing redundant contract negotiations and improving overall system performance.
Acceptance Criteria
Hint
The orchestrator will manage ongoing negotiations using a ConcurrentHashMap with asset IDs as keys, and will limit parallel requests via an ExecutorService. Token caching will allow reuse of previously negotiated tokens to avoid repetitive EDC calls.
Concept
A new service “NegotiationOrchestrator” is introduced which is a middle layer between the already existing components EdcSubmodelClientImpl and ContractNegotiationService, EDCCatalogFacade and EndpointDataReferenceCacheService.
The service handles the following tasks:
To prevent too many parallel requests to the EDC, an ExecutorService handles the catalog requests and negotiations with a defined thread pool.
To cache the currently ongoing negotiations, a ConcurrentHashMap with EDC AssetIds as key can be used. Due to the asynchronous process within NegotiationOrchestrator, the future EDR can be created and added to the cache as soon as the method is called and will be removed only after the negotiation is completed. In addition a time to live can be added for cleanup.
To cache EDR tokens, the EndpointDataReferenceCacheService can be used. The caching service wraps EDR tokens into a object with a state indicating if the token is valid (i.e. can be used directly to authenticate the dataplane request) or expired (i.e. the validityPeriod is expired). After expiration the token can be reused to request a new token. Cache eviction is handled independent of token state and will use a configurable TTL to evict cached entries.
Special Case: Registry Negotiation Contract offers for the digital twin registry are identified by a type. This changes the process slightly, so it is not only one contract offer which will be negotiated, but potentially multiple contract offers.
Since the NegotiationOrchestrator works asynchronously, we can simply start the EDR negotiation process for all the received contract offers and will receive a list of Future EDRs.
The process of NegotiationOrchestrator is left out of the chart, since it is the same as previous.
Precondition
*
Risk Dependencies
*
Test Cases
Test Case 1
Steps
Expected Result
Architectural Relevance
The following items are ensured (answer: yes) after this issue is implemented:
Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)
Additional information