Implementing a Policy Engine-Based Validation Module in Marketplace Backplane #4890
-
|
Hello everyone, We’re working on a project to add a module to the backplane of a marketplace that will handle the tasks of the Policy Engine. The goal is that, based on a catalog offer and the corresponding Virtual Credits (VC) of the user, the system can validate whether the transaction is feasible or not. My question is whether it’s feasible to use the Policy Engine from the connector in isolation to implement this module without breaking or disrupting the existing code. I’m looking for information on whether there’s any starting file or API that could be used to integrate the existing Policy Engine module without needing to rewrite all the logic. I would really appreciate any guidance or prior experiences you can share to help me figure out where to start and ensure a smooth integration. Thank you in advance! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
This question is too vague to answer. Discussions are intended for specific questions related to the codebase. You may want to try the Discord channel for more general questions. That said, it's difficult to understand what you are trying to accomplish, given the general description. The policy modules can be used standalone (they are published as Maven modules) and are independent from other parts of the codebase. However, from what I can discern, I would question whether EDC and DSP are relevant to your use case. DSP interactions are always between two parties, and there are no interactions between users at the protocol level. This is by design, and DSP purposely does not have any notion of a "user." Similarly, there is no "multi-party marketplace" concept in EDC or dataspaces as defined by DSP. I would go back and read the DSP specification and EDC documentation closely to understand this and then reassess if these technologies are relevant to your use case. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reply and the clarification! I wasn’t aware of the Discord channel, could you kindly provide the name or link to it? I’ll make sure to ask there for more general questions. Just to clarify the architecture. Our clients and providers do use EDC, but the architecture we are working with involves having a federated catalog exposed through a marketplace. The connectors will implement the Policy Engine, and the goal is to reuse that Policy Engine already implemented in the connector to validate whether a transaction is valid or not from the marketplace (not DSP involved in this point). The idea is to pass the offer that the consumer wants to acquire, along with their credentials, for validation. Thanks again for your help! |
Beta Was this translation helpful? Give feedback.
-
|
That architecture seems quite a bit different than a dataspace from a DSP perspective. Again, I can't comment definitively on individual use cases, but my recommendation is to read the DSP specification and EDC documentation carefully. Dataspaces are inherently decentralized, and both documentation sets explain why central brokers (and "marketplaces") are generally frowned upon. Specifically, look at the federated catalog architecture and reasons for not using a central broker (again, explained in the documentation). It's a much simpler solution, will scale better, and inherently allows for policy evaluation without resorting to creating an entirely separate infrastructure based on an extracted Policy Engine. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks I think now I understand. Anyway, could you let me know the name of the Discord channel? |
Beta Was this translation helpful? Give feedback.
That architecture seems quite a bit different than a dataspace from a DSP perspective. Again, I can't comment definitively on individual use cases, but my recommendation is to read the DSP specification and EDC documentation carefully. Dataspaces are inherently decentralized, and both documentation sets explain why central brokers (and "marketplaces") are generally frowned upon. Specifically, look at the federated catalog architecture and reasons for not using a central broker (again, explained in the documentation). It's a much simpler solution, will scale better, and inherently allows for policy evaluation without resorting to creating an entirely separate infrastructure based on an ext…