FAQ

[mspiekermann]

General Information

1. Why do I need a framework to build Dataspace components?

We expect a multitude of components will be implemented to build Dataspace environment as there are various different requirements for business cases that are enabled by this new approach for trusted data sharing.
A comprehensive framework, that supports the developer of such components can save them time, stress and hassle as all core features are solved.
By using the EDC, developers of Dataspace technologies can focus on their individual business value.

2. Where can I find the documentation?

EDC documentation is available on the project website. You find the documentation through the main navigation or via the direct link. The documentation consists of two main sections. The adopter’s manual and the contributor’s manual. The first provides insights on how to make use the framework to build your dataspace components on EDC’s codebase. The latter gives details for people that want to contribute to EDC’s codebase themselves.

3. What extensions are available to be used out of the box?

The EDC framework provides some extensions out of the box. For example, there are in-memory implementations available for the persistence layer. Ofc, those are not recommended in any way for productive usage. Throughout the time, some more comprehensive extensions made it into the EDC project. Those are mainly the extensions provided by the hyperscalers in their corresponding Technology repositories. Beside the extensions in EDC repositories, there are extensions provided by derivates (e.g. Tractus-X). Others are listed on the known-friends list.

4. Is Microsoft Windows supported?

Windows is not a supported OS at the moment. If Windows is a must, we recommend using WSL2 or a setting up a Linux VM.

5. Is EDC free to use?

Yes, the EDC framework is provided under the Apache 2 License, as in the LICENSE files of every repository. This means you can use EDC for commercial purposes. You are free to fork it, modify it, distribute it without a copy-left. Still, Apache 2.0 comes with some dos and don’ts, that are nicely summarized on tl;drLegal.

6. I need support, where and how can I get help?

There is no commercial support available yet. Nevertheless, we have a highly engaged community which is happy to help you with issues and questions. While there are multiple channel available, it is recommended to join our Discord channel . There are always people willing to help, if the request is nicely formulated and shows that people take time to investigate on their own first.

7. Who is involved?

The EDC was initially founded by Amazon AWS, BMW AG, Daimler TSS GmbH, Deutsche Telekom AG, Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., Microsoft, SAP SE, ZF Friedrichshafen AG.

An always up to date list of who is involved in EDC can be found on the who is involved page

Architecture, Components and Features

8. What are the design principles of EDC?

The EDC are designed and implemented on top of few fundamental architectural principles, which includes asynchrony, single-thread processing, idempotency, and error-tolerance.

The overall design principles of EDC consist of four pillars:

• Modularity: Lightweight, composable runtime, minimal dependencies),
• Extensibility: Swap implementation, create your own features and capabilities
• Resiliency: Leverages high availability infrastructure
• Adaptability: Deploy to diverse environments with different capabilities

9. What components are provided by the EDC?

The Eclipse Dataspace Components framework consists of a set of components to build dataspace environments. The main components are the Connector, the FederatedCatalog, and the IdentityHub. However, there are other components, extensions, and supportive repositories.

Feel free to check the list of repositories for a comprehensive overview of all the components provided by the framework.

10. What is the difference between Control Plane and Data Plane?

The control plane is responsible for assembling catalogs, creating contract agreements that grant access to data, managing data transfers, and monitoring usage policy compliance.

A data plane is responsible for transmitting data using a wire protocol at the direction of the control plane. Data planes can vary greatly, from a simple serverless function to a data streaming platform or an API that clients access. One control plane may manage multiple data planes that specialize in the type of data sent or the wire protocol requested by the data consumer.

11. I need a data marketplace for my dataspace, does EDC support this?

The EDC architecture focus on building a decentralized ecosystem of participants to share data without the necessity of a central party. Nevertheless, EDC also aims on enabling as much business cases as possible, for example a marketplace. While a marketplace therefore is not a mandatory component, companies that want to provide a marketplace service with added value for the participants are welcome to do so. This can be achieved by the right configuration of the FederatedCatalog component. Some initial documentation on how this may look like can be found in the Catalog Architecture, see Broker configuration.

12. What data transfer types are supported (out of the box)?

We hear this question a lot, but actually it is the wrong question to ask in the direction of EDC project. The EDC framework provides all the required interfaces to support push, pull and streaming scenarios. Those can be used to implement extensions for all kind of data transfer types. So, the bold answer is: all! But, EDC is not responsible for implement and maintain extensions for all the types.

We know of some extensions, especially the once contributed as OSS, but there might be much more extensions out there used by commercial services or internal use cases only that will never be an extension within the EDC project itself or be listed as a known-friends.

Note: If you, as a first step, just want to play around, we recommend to use the available HTTP, AWS S3, Azure Blob Storage, or Huawei OBS extensions from the EDC repositories as a starting point.

Relations

13. Eclipse Dataspace Components vs. Eclipse Dataspace Connector

Back in 2021 the project started as Eclipse Dataspace Connector. But, already years ago we changed the scope of the project from a Connector implementation to a comprehensive framework for dataspace technologies. Thus, the project was renamed to Eclipse Dataspace Components (EDC) and spans the concepts and implementations of all the components. Unfortunately, internet never forgets, so there are still some old references to the C standing for Connector.

Now as you know the difference, help us to get rid of the misuse of the abbreviation.

14. What is the relation of EDC and DSP + DCP?

The Dataspace Protocol (DSP) and the Decentralized Claims Protocol (DCP) are specification projects in governed by the Eclipse Foundation to specify protocols (message types, sequences, bindings) for interaction of participants within a Dataspace. The EDC is the reference implementation of these protocols and is committed to stay up to date with new protocol releases.

For details of the DSP and DCP, please have a look in the corresponding repositories (note: on the right in the “about” section, a link to a rendered version is available) or feel free to reach out to the Eclipse Foundation Working Group (EDWG).

15. What is the relation to Tractus-X?

While EDC provides a comprehensive framework to build Dataspace components, we expect multiple derivates of it with concrete implementations of extensions and bundling those into downloadable and out of the box usable software. Tractus-X is such a derivate as it makes heavily use of EDC for example for their Connector component.

Note: The name Tractus-X-EDC is misleading as it refers to the former scope of a Connector implementation.

Contributions

16. How can I support the project to ensure its continuance?

We are open to any kind of contribution, non-code and ofc code-related ones as long as they are following our contribution guidelines. We know that OSS lives through a flourish community and people who are willing to make the project grow and successful.

So, if you are a developer, technical writer, designer, architect, sales guy, whatever, raise your hand and show your willingness to support. We have plenty code and non-code activities that needs your supported.

In case you have a project, which builds on top of EDC but have no people to support the project directly? Feel free to sponsor the work on the EDC project by the committers and contributors. Contact the Committer team via the Eclipse Foundation or directly via Discord.

17. How can I write my own extension?

The EDC’s design is centered on managing and assembling extensions. Thus, the framework’s success can be measured by its adoption and others providing extensions for the multitude of extension points.
To write your own extensions, follow the adopter’s documentation carefully. It details on how to add customizations, features, and new capabilities to EDC components. It outlines the EDC module system, extension basics, and extension services.

If you have worked on an extension, there are different levels on how you might become adopted by the EDC project – most likely as a “friend”. There are guidelines on how to get adopted with details on this topic.

Releases

18. What are the release cycles?

EDC has no clear defined release cycles. We are aiming of a sprint cadence of 6 to 8 weeks with a release at the end of each sprint. Anyhow, there are exceptions of this and while we have bug-fix releases in between, there might also be a release postponed to integrate a feature that is currently worked on.

Releases are always publicly announced (Discord, GitHub, EDC mailing list). They follow semantic versioning, our deprecation policy, and release news can be found within GitHub for all components. The release pages (e.g. for the Connector) provides additional information on breaking changes, bugfixes, added features, updated dependencies, etc.

19. When to expect a version 1 release?

Often times we are asked for a version 1. For an OSS project, a version 1 is a huge step as it comes with expectations the committers need to care of and by far is a promise for quality on its own. This is why we actually see a lot of OSS projects in production without having a v1 release. But, we know that this is often requested for management purposes and to convince sponsors of a technology.

So here is the answer for your manager: Q4 2025. We are considering the Dataspace protocols (DSP and DCP) will have their official releases as ISO PAS submission planned for October. As their reference implementation we will ensure to integrate the latest specification and afterwards will make our EDC v1 release.

20. What about backward compatibility?

EDC releases provide a section of breaking changes coming with a specific release. Already through the issue and PR workflow, the label ‘breaking change’ points to adopters to have a look and investigate the impact on their extensions and environments.
In addition, the EDC project has an API Maturity Levels and Deprecation Policy (MLDP). Those deprecation rules are enforced for official releases, not individual commits, and are tied to the maturity level of an API.