diff --git a/content/en/blog/20260126-data-plane-signaling/index.md b/content/en/blog/20260126-data-plane-signaling/index.md new file mode 100644 index 0000000..e24b354 --- /dev/null +++ b/content/en/blog/20260126-data-plane-signaling/index.md @@ -0,0 +1,80 @@ +--- +title: Data Plane Signaling +date: 2026-01-19 +description: > + What are our reasons to adopt the Data Plane Signaling protocol and to deprecate the EDC Data Plane Framework +--- + +Data Plane Signaling is a specification for interoperable communication between Dataspace Protocol Control Planes and +Data Planes ([github project](https://github.com/eclipse-dataplane-signaling)). + +We decided to fully adopt this specification and to deprecate the current approach. This will involve deprecating the +current implementation of the communication layer between the Control Plane and Data Plane in addition to the EDC Data +Plane Framework. + +## Rationale + +The Data Plane Signaling specification addresses key architectural ambiguities by clearly delineating the roles of the +Control Plane (orchestration and protocol-level authentication) and the Data Plane (actual data transfer and flow-specific +authentication). This separation resolves design confusion, establishes symmetry between push and pull patterns, and, +most importantly, creates a standard interface. This allows any application to become a compliant Data Plane, +fostering innovation and moving the industry toward a future where data sharing is a seamless, integrated layer within +sovereign applications, rather than a connector-centric task. + +## Approach + +The implementation of the Data Plane Signaling protocol in the EDC Control Plane is already progressing +([issue](https://github.com/eclipse-edc/Connector/issues/5323)), we expect to have a fully compliant version as soon as +a stable version of the Data Plane Signaling specification is released. + +At that point, we will deprecate the EDC Data Plane Framework in its entirety, and after 2 releases, it will be eligible +for removal from the codebase. If you are an EDC adopter, we recommend to start prototyping your Data Plane(s) +following the current specification. The dataplane-signaling team is already providing SDKs library in different +languages ([Go](https://github.com/eclipse-dataplane-core/dataplane-sdk-go), +[Rust](https://github.com/eclipse-dataplane-core/dataplane-sdk-rust), +[Java](https://github.com/[eclipse-dataplane-core/dataplane-sdk-java](https://github.com/eclipse-dataplane-core/dataplane-sdk-java)), +[.NET](https://github.com/[eclipse-dataplane-core/dataplane-sdk-net](https://github.com/eclipse-dataplane-core/dataplane-sdk-net))) +to help with this transition. + +Let's see from the technical point of view what are the advantages brought by this approach. + +### How It Works Now + +These diagrams are showing the current state-of-the-art; some details have been intentionally left out to focus on the +scope of Control Plane and Data Plane interaction. + +Two issues become apparent just by looking at the diagrams: +- **Vertical grouping**: The Data Plane is often considered part of the connector component together with the control + plane. While this may not necessarily be an issue, it creates confusion for those building dataspace applications + regarding the correct boundaries and leads to poor design. +- **Lack of symmetry**: The pull and push cases are handled quite differently on the consumer side, and the role of the + consumer’s Data Plane/client is not as clear as it should be. + +![legacy-pull.png](legacy-pull.png) + +![legacy-push.png](legacy-push.png) + +### How It Will Work with Data Plane Signaling + +Just a glance at the diagrams shows that a strong focus has been placed on separating the dataspace layer from the +“use case/application” layer. +This is not to say they were not separated before, but this specification formalizes it: the Control Plane and Data +Plane are two distinct architectural components serving different purposes. +While the Control Plane is responsible for wire protocol (DSP) communication and dataspace authentication, the Data +Plane handles the actual transfer and receipt of data, managing authentication for the chosen data flow protocol. + +With this specification, any application meant to share data in a dataspace can implement the Data Plane Signaling +specification and to become a Data Plane. This is the intended path forward: no more direct user-facing interaction +with the connector, but rather an application layer that relies on the dataspace to provide sovereign data sharing. + +![new-pull.png](new-pull.png) + +Another interesting concept is that the data address is not managed by the Control Plane anymore: its creation and use +happens completely in the Data Plane, while the control-plane just takes care to pass it to the counter-part through DSP. + +![new-push.png](new-push.png) + +## References + +- [Data Plane Signaling project](https://github.com/eclipse-dataplane-signaling) +- [Data Plane SDKs project](https://github.com/eclipse-dataplane-core) diff --git a/content/en/blog/20260126-data-plane-signaling/legacy-pull.png b/content/en/blog/20260126-data-plane-signaling/legacy-pull.png new file mode 100644 index 0000000..27f8dfb Binary files /dev/null and b/content/en/blog/20260126-data-plane-signaling/legacy-pull.png differ diff --git a/content/en/blog/20260126-data-plane-signaling/legacy-push.png b/content/en/blog/20260126-data-plane-signaling/legacy-push.png new file mode 100644 index 0000000..83944da Binary files /dev/null and b/content/en/blog/20260126-data-plane-signaling/legacy-push.png differ diff --git a/content/en/blog/20260126-data-plane-signaling/new-pull.png b/content/en/blog/20260126-data-plane-signaling/new-pull.png new file mode 100644 index 0000000..b594f07 Binary files /dev/null and b/content/en/blog/20260126-data-plane-signaling/new-pull.png differ diff --git a/content/en/blog/20260126-data-plane-signaling/new-push.png b/content/en/blog/20260126-data-plane-signaling/new-push.png new file mode 100644 index 0000000..ad53a98 Binary files /dev/null and b/content/en/blog/20260126-data-plane-signaling/new-push.png differ diff --git a/content/en/blog/_index.md b/content/en/blog/_index.md new file mode 100644 index 0000000..e263dec --- /dev/null +++ b/content/en/blog/_index.md @@ -0,0 +1,5 @@ +--- +title: Blog +menu: { main: { weight: 30 } } +--- +