Eclipse Dataspace Components on AWS: Data sharing fundamentals

Eclipse Dataspace Components 在 AWS 上：数据共享基础 | AWS 架构博客

Eclipse Dataspace Components 在 AWS 上：数据共享基础

这系列三篇博客将引导您在 AWS 上实现 Eclipse Dataspace Components（EDC），从基础概念到生产部署。第一部分将通过 IDSA 标准、数据空间协议（DSP）和 EDC 核心架构建立理论基础。第二部分将使用 Amazon Elastic Container Service（Amazon ECS）、Amazon Aurora 和 Amazon API Gateway 等服务，提供生产就绪的 AWS 部署模式。第三部分将通过成本优化策略和实际指导，完成在 AWS 上运行高效、可扩展数据空间基础设施的旅程。

国际数据空间协会（IDSA）是一个非营利组织，专注于建立和推广数据空间标准。数据空间被定义为“一组技术服务，用于促进不同实体之间可互操作的数据集共享”。在技术层面，数据空间包含参与者：数据消费者和数据提供者。核心部分是数据空间治理机构（DSGA）。DSGA 管理数据空间，执行规则和政策，并向参与者颁发会员凭证。

IDSA 规则和规范在数据空间协议（DSP）中实现。DSP 已成为 Eclipse 规范项目，可在 Dataspace Protocol GitHub 仓库中找到。标准化工作正在进行中，目前处于 ISO/IEC DIS 20151 批准阶段。Eclipse Dataspace Components（EDC）提供了根据 IDSA 要求实现数据空间的技术组件。

这些组件包括联邦目录（FC）、连接器和身份中心。FC 包含从数据空间中多个参与者收集的目录聚合仓库。这些目录通过定期爬取参与者的数据资产并存储在本地缓存中获取，以消除按需单独查询每个参与者的需要。连接器是使参与者之间能够共享数据的软件，而身份中心则管理参与者在数据空间中的凭证。Amazon Web Services（AWS）提供全面的云基础设施，支持 EDC 连接器等数据空间组件的部署和运行。AWS 提供可扩展的计算、存储和网络服务，帮助您构建符合 IDSA 标准和 ISO/IEC DIS 20151 规范的安全、合规且可互操作的数据空间。

为了在数据空间中以去中心化方式验证身份，使用去中心化声明协议（DCP）。DCP 是 DSP 的一个叠加层，用于在网络参与者之间建立信任。当发证人需要向验证人证明其身份时，首先会生成一个去中心化标识符（DID），其中包含其身份的信息。发证人将其可验证凭证（VC）存储在其身份中心。可验证凭证类似于证书：虽然证书机构验证公钥，但凭证发证人会使用特定属性验证 DID。验证人查找发证人的 DID，并通过 DID 文档中的信息验证 VC。

图1：去中心化声明协议（DCP）的高层架构图

图2：DID 文档处理的简化概述

EDC 的最后一个要素是不同类型的策略，包括成员策略、访问策略、合同策略和使用策略。

连接器的作用

EDC 连接器分为两部分：控制平面和数据平面。控制平面负责合同协商，并向数据平面发送消息以启动数据传输。数据平面负责在不同法律实体之间，将数据从提供方的 EDC 连接器传输到消费方的 EDC 连接器。

图 3：连接器控制平面和数据平面概览

EDC 连接器开源项目的结构

作为 EDC 项目的一部分，连接器仓库定义了连接器控制平面和数据平面的实现方式。以下是仓库结构的概述：

• /spi – 服务提供接口（SPI）是定义模块在 EDC 连接器内部如何通信的架构基础。它包含所有组件必须实现的基础接口和合同，建立标准化的集成模式。这一层还为开发者提供了扩展 EDC 连接器功能的蓝图，同时保持关注点的清晰分离，并确保核心组件与自定义组件之间的兼容性。

• /core – 核心模块代表 SPI 的基本实现。它包含连接器基本操作的实际工作代码，包括关键服务的默认实现和数据共享的业务逻辑。

• /extensions – 扩展层通过实际集成展示了连接器的模块化插件架构，包括与 AWS 等主要云提供商的连接。这些扩展既作为参考实现，也作为常见企业集成场景的即用型组件。

SPI 定义合同，Core 实现基础功能，Extensions 添加专用功能。这三个层次协同工作，构建了一个灵活且可扩展的数据空间连接器系统。“原生”Eclipse EDC 连接器默认不包含 AWS 扩展。若需添加 AWS 服务特定功能（如与 Amazon Simple Storage Service（Amazon S3）、AWS Secrets Manager 或 Amazon DynamoDB 的集成），需要将相应的 AWS 扩展包含到自定义的 EDC 控制平面和数据平面构建中。

EDC 定制指南概览

为原生 AWS 服务集成定制 EDC 连接器，可以创建一个专为 AWS 管理服务设计的解决方案，利用 AWS 的存储、安全和可扩展性功能。以下步骤可帮助连接器原生集成 Amazon S3 等服务（例如用作 Asset Administration Shell “Submodel Server”）进行数据存储，并使用 AWS Secrets Manager 进行凭证管理，而非依赖自托管组件的操作。

EDC 基于 Gradle 构建了一个模块化、基于插件的架构。原生连接器仅包含核心功能。要与特定云服务或持久化后端集成，需构建一个自定义版本，将 EDC 的核心模块与所需的扩展模块组合在一起。定制过程围绕三个概念展开：版本目录、启动模块和项目设置文件。

步骤 1：版本目录

版本目录（gradle/libs.versions.toml）是所有依赖项及其版本的集中注册表。在这里，您需要声明连接器所需的EDC模块、云提供商扩展和第三方库。EDC将其AWS扩展发布在org.eclipse.edc.aws Maven组下。您需要在与核心EDC构件（org.eclipse.edc）兼容的版本号下引用这些扩展。这个单一文件确保项目中所有模块共享一致的依赖版本。

步骤2：启动模块

启动模块是实际的可部署单元：一个用于控制平面，一个用于数据平面。每个启动模块都是一个小型Gradle子项目，其build.gradle.kts文件会列出运行时需要捆绑的扩展。典型的控制平面启动模块可能包含核心控制平面模块、一个元数据持久化扩展（如PostgreSQL或DynamoDB）、一个密钥管理扩展（如HashiCorp Vault或AWS Secrets Manager），以及针对目标存储系统的任何供应扩展。数据平面启动模块遵循相同模式，使用特定于数据平面的模块。两个启动模块通常都使用Gradle插件生成一个可执行的JAR文件。您只需包含实际使用的组件，从而保持连接器的轻量化和针对特定需求的定制性。

步骤3：项目设置

项目设置文件（settings.gradle.kts）会将所有模块注册到Gradle：您的启动子项目以及可能在本地开发的任何自定义扩展。例如，如果您编写了自己的扩展（如基于DynamoDB的资产存储），您需要将其放置在extensions/目录中，并在此处进行注册，以便启动模块可以将其作为项目依赖项引用。

最终的项目结构通常如下所示：

my-connector/
├── control-plane/
│   └── build.gradle.kts       # 控制平面启动模块
├── data-plane/
│   └── build.gradle.kts       # 数据平面启动模块
├── extensions/                # 可选：自定义扩展代码
├── gradle/libs.versions.toml  # 所有依赖项版本
├── build.gradle.kts           # 根构建配置
└── settings.gradle.kts        # 子项目注册

作为AWS上EDC定制化的开源参考实现，Dataspace Connector on AWS项目提供了相关实现。在本文中，您学习了使用新兴数据空间架构进行安全跨组织数据共享的基础知识。我们介绍了ISO/IEC DIS 20151数据空间标准化中包含的两种协议DSP和DCP，并讨论了EDC连接器——数据空间参与者所需的主要软件及其定制方法。

在第二部分中，我们将探讨适用于AWS上EDC连接器的生产就绪部署模式，研究支持数据空间基础设施安全性、可靠性和运营效率的架构最佳实践。要开始了解，可以探索Dataspace Connector on AWS项目，查看其Gradle构建设置是如何配置以支持使用Amazon DynamoDB进行无服务器、低成本的元数据持久化的。

参考资料

• https://internationaldataspaces.org/

• https://kb.internationaldataspaces.org/external/rulebook/001_Introduction/

• https://kb.internationaldataspaces.org/standards/

• https://github.com/eclipse-edc/Technology-Aws

关于作者

'"`