Notes for video: EDC-Con 2022/01 - EDC Conceptual Overview and Architecture

• Eclipse Dataspace Connector

  • 中文概念
    • Eclipse Dataspace Connector (EDC) 是一个开源项目，旨在提供一种标准化的方法来连接和共享数据空间中的数据。它是 Eclipse Foundation 下的一个项目，目标是促进数据共享和数据交换的互操作性。以下是 EDC 的一些关键特点和功能：
      • 数据互操作性：EDC 提供了一种标准化的方法，使不同系统之间能够互操作，进行数据交换，而不需要依赖于特定的技术或平台。
      • 数据治理和安全性：EDC 包含强大的数据治理和安全功能，确保数据在共享过程中得到保护，并且数据所有者可以控制谁可以访问其数据以及如何使用这些数据。
      • 模块化设计：EDC 具有模块化设计，允许用户根据自己的需求扩展和定制功能。用户可以添加或删除模块，以适应不同的数据共享场景。
      • 生态系统集成：EDC 支持与现有的 IT 基础设施和生态系统集成，包括云服务、企业系统和其他数据平台。
      • 标准化协议：EDC 使用标准化协议，如 HTTP 和 RESTful API，来确保与其他系统的兼容性和易用性。
      • 开源社区：作为一个开源项目，EDC 由一个活跃的社区进行开发和维护，用户可以参与其中，贡献代码和提出改进建议。
    • 通过这些功能，Eclipse Dataspace Connector 为组织提供了一种有效的解决方案，帮助他们在安全、可控和互操作的环境中共享数据。如果你有具体的需求或应用场景，EDC 也提供了丰富的文档和示例，帮助你快速上手。
  • ENGLISH
    • The Eclipse Dataspace Connector (EDC) is an open-source project designed to provide a standardized method for connecting and sharing data within data spaces. It is a part of the Eclipse Foundation, aiming to promote interoperability for data sharing and data exchange. Here are some key features and functionalities of the EDC:
      • Data Interoperability: EDC offers a standardized approach to enable data exchange between different systems, eliminating the need for specific technologies or platforms.
      • Data Governance and Security: EDC includes robust data governance and security features to ensure that data is protected during the sharing process. Data owners can control who has access to their data and how it is used.
      • Modular Design: EDC has a modular design, allowing users to extend and customize its functionalities based on their needs. Users can add or remove modules to fit different data sharing scenarios.
      • Ecosystem Integration: EDC supports integration with existing IT infrastructures and ecosystems, including cloud services, enterprise systems, and other data platforms.
      • Standardized Protocols: EDC uses standardized protocols such as HTTP and RESTful APIs to ensure compatibility and ease of use with other systems.
      • Open Source Community: As an open-source project, EDC is developed and maintained by an active community. Users can participate by contributing code and suggesting improvements.
    • With these features, the Eclipse Dataspace Connector provides organizations with an effective solution for sharing data in a secure, controlled, and interoperable environment. It also offers extensive documentation and examples to help users get started quickly, tailored to specific needs or application scenarios.
  • What role does the EDC play in a Dataspace?
    • This section likely covers the importance and function of the Eclipse Dataspace Connector within a data space, explaining how it facilitates data sharing and interoperability among different systems and organizations.
    • Eclipse Dataspace Connector在数据空间中的重要性和功能，解释它如何促进不同系统和组织之间的数据共享和互操作性。

  • EDC Architectural Principles and Design

    • This part will discuss the foundational principles and design aspects of EDC, including its modular architecture, standardization efforts, and how it ensures secure and efficient data exchanges.

      

    • 这一部分将讨论EDC的基础原则和设计方面，包括其模块化架构、标准化努力，以及它如何确保安全高效的数据交换
    • EDC架构原则
      • 模块化（Modular）
        • EDC的所有功能都以模块的形式提供。这意味着每个功能可以独立开发、测试和部署，从而提高了系统的灵活性和可维护性。
      • 可扩展性（Extensible）
        • 系统设计为可以扩展，允许添加新的功能模块以满足不断变化的需求。
      • 适应性（Adaptable）
        • EDC具有高度适应性，可以根据不同的使用场景和需求进行调整。
      • 弹性（Resilient）
        • 系统具有很强的弹性，能够在各种情况下保持稳定和高性能。
    • （Modular）
      • 用Java编写（Written in Java）
        • EDC使用Java编写，这使得它能够利用Java的跨平台特性和丰富的生态系统。
      • 所有功能都作为模块贡献（All functionality is contributed as a module）
        • 所有功能都以模块的形式贡献，使得系统可以根据需求选择性地加载和使用不同的模块。
      • 轻量级、可组合的运行时（Lightweight, composable runtime）
        • 系统运行时是轻量级的，并且是可组合的，能够高效地运行并满足不同的性能需求。
      • 最小依赖（Minimal dependencies）
        • 系统设计尽量减少外部依赖，从而降低了复杂性和潜在的兼容性问题。
    • 可扩展性（Extensible）
      • 为所有功能定义扩展点（Defines extension points for all features）
        • EDC为所有功能定义了扩展点。这意味着开发者可以在这些预定义的扩展点上添加或修改功能，而不需要修改核心代码。
      • 替换实现，例如数据库、安全性（Swap implementations, e.g., database, security）
        • 开发者可以替换系统中的某些实现，例如数据库或安全性模块，以适应特定需求或使用特定技术。
      • 创建自己的功能和能力（Create your own features and capabilities）
        • 用户可以根据自己的需求创建新的功能和能力，扩展EDC的应用范围。
    • 适应性（Adaptable）
      • 部署到多种环境（Deploy to diverse environments）
        • EDC可以部署到多种环境中，包括云环境、本地环境和边缘环境。这使得它能够在各种基础设施条件下运行，满足不同应用场景的需求。
      • 具备不同的能力进行部署（Deploy with different capabilities）
        • EDC可以根据需求进行不同能力的部署，确保系统能够灵活适应各种使用需求和技术要求。
      • 可伸缩（Scales up and down）
        • EDC具有良好的可伸缩性，可以根据负载需求进行扩展或缩减，确保在各种负载条件下都能高效运行。
    • 弹性（Resilient）
      • 利用已投资的高可用性基础设施（Leverages high-availability infrastructure that you have already invested in）
        • EDC利用您已经投资的高可用性基础设施，确保系统的稳定性和高性能。
      • 云服务（Cloud services）
        • EDC可以集成和利用云服务，提供可靠的计算和存储能力。
      • 数据存储（Data storage）
        • EDC能够利用现有的数据存储解决方案，确保数据的安全和可用性。
      • 数据传输技术（Data transfer technologies）
        • EDC可以利用各种数据传输技术，确保数据在不同系统之间的高效和安全传输。

  • The EDC Foundation

    • Here, the focus will be on the foundational aspects of EDC, such as its core components, the underlying technology stack, and the community or organizational support structure that maintains and evolves the project.
    • 这里的重点将是EDC的基础方面，如其核心组件、底层技术栈，以及维护和发展项目的社区或组织支持结构。
    • EDC设计：数据空间服务（Dataspace Services）
      • EDC提供了三个主要的服务模块，每个模块都有其核心模块系统，并共享一些公共模块。这些服务模块包括：
      • 注册表（Registry）
        • 注册和发现（Registration and discovery）
        • 注册表模块负责数据空间中参与者和资源的注册和发现。它使参与者能够找到并访问数据资源。
      • 目录服务（Catalog Services）
        • 发布和搜索（Publish and search）
        • 目录服务模块允许参与者发布和搜索数据资源。通过目录服务，参与者可以查找和获取所需的数据。
      • 连接器（Connector）
        • 合同谈判和数据共享（Contract negotiation and data sharing）
        • 连接器模块负责合同谈判和数据共享。它管理参与者之间的数据交换协议，并确保数据安全传输。
      • 共同模块（Common Modules）
        • 这些服务模块共享一些公共模块，以确保系统的一致性和可操作性。这些公共模块提供基础设施支持，如安全性、日志记录、监控等。

  • The Connector

    • This section is likely dedicated to the core functionality of the EDC connector itself, detailing how it connects different systems, handles data transfer, and ensures compliance with interoperability standards.这一部分可能专门介绍EDC连接器本身的核心功能，详细说明它如何连接不同的系统、处理数据传输，并确保符合互操作性标准。

      

    • 连接器：控制平面和数据平面
    • 连接器被划分为两个逻辑子系统：控制平面（control plane）和数据平面（data plane）。
      • 控制平面（Control Plane）
        • 控制平面负责管理和控制数据交换过程的各个方面，包括：
        • 验证（Verification）
          • 确保参与者身份和数据请求的合法性。
        • 合同谈判（Contract negotiation）
          • 管理数据交换协议的谈判和制定。
        • 监督策略执行（Oversee policy enforcement）
          • 确保数据共享过程中遵守预定义的安全和使用策略。
        • 管理资源配置（Manages provisioning）
          • 管理和分配系统资源，以支持数据传输。
      • 数据平面（Data Plane）
        • 数据平面负责实际的数据传输和处理，包括：
        • 数据移动（Moves bits）
          • 实际进行数据的传输和交换。
        • 大数据（Big Data）
          • 处理和传输大规模数据集。
        • 流媒体（Streaming）
          • 支持实时数据流传输。
        • 事件（Events）
          • 处理和传输事件驱动的数据。
      • 工作原理
        • 控制平面和数据平面之间有明确的分工，控制平面负责管理和控制，数据平面负责实际的数据传输。
        • 两个平面之间的交互确保数据传输的有效性、安全性和合规性。
        • Leverage Existing infrastructure

          

          

          

      • The Data Plane Framework, DPF5

        

        • 数据平面框架（The Data Plane Framework, DPF）
          • 动态路由数据平面（A dynamic routing data plane）
            • DPF是一个动态路由的数据平面，专为大数据处理和事件驱动优化。
            • 支持多路径传输（N-way transfers），提高数据传输的灵活性和效率。
          • 基于EDC基础构建（Built on the EDC foundation）
            • DPF建立在EDC的基础上，继承了EDC的核心模块和设计原则，确保了与EDC系统的兼容性和扩展性。
          • 初始版本在里程碑2发布（Initial release in Milestone 2）
            • DPF的初始版本将在项目的第二个里程碑阶段发布。
        • 主要特点
          • 优化大数据和事件处理（Optimized for big data and eventing）
            • DPF专为处理大数据和事件驱动的数据流而优化，提供高效的数据传输和处理能力。
          • 多路径传输（N-way transfers）
            • 支持数据的多路径传输，增强了数据交换的灵活性和可靠性。
        • 扩展和集成
          • DPF可以通过扩展模块与各种数据存储和传输技术集成，例如云服务、存储解决方案和事件处理系统。
        • The Connector: Asynchrony

          

          

        • 连接器：异步处理（The Connector: Asynchrony）
          • 异步系统（Asynchronous system）
            • EDC连接器是一个异步系统。这意味着数据请求和处理不是同步完成的，而是在不同步的情况下进行的。
            • 请求的异步状态转换（Requests asynchronously transition through predefined states）
              • 数据请求在客户端和提供者连接器上通过一系列预定义的状态异步转换。
          • 状态转换过程
            • 客户端（Client）
              • Initiated（启动）
                • 请求被启动。
              • Requested（请求）
                • 请求被发送到提供者。
              • Provisioned（提供中）
                • 请求正在处理中。
              • In progress（进行中）
                • 请求正在被执行。
              • Completed（完成）
                • 请求已完成。
            • 提供者（Provider）
              • Initiated（启动）
                • 请求被启动。
              • Requested（请求）
                • 请求已收到。
              • Provisioned（提供中）
                • 请求正在处理中。
              • In progress（进行中）
                • 请求正在被执行。
              • Completed（完成）
                • 请求已完成。
          • Impact
            • Does?

              

            • Policy enforcement

              

  • Policy Enforcement

    • This point will cover how EDC enforces data governance policies, ensuring that data sharing adheres to security, privacy, and usage policies defined by data owners and regulatory bodies.这一点将讨论EDC如何执行数据治理策略，确保数据共享符合数据所有者和监管机构定义的安全、隐私和使用策略。
    • 策略执行（Policy Enforcement）
      • 保持对数据的控制（Maintaining Control Over Data）
        • EDC通过策略引擎来执行和管理数据共享的策略，确保数据在共享和传输过程中遵循预定义的规则和规定。
      • 策略引擎（Policy Engine）
        • 策略引擎是EDC中的核心组件，负责管理和执行数据共享策略。通过策略引擎，用户可以定义和应用各种数据共享规则和限制。例如：
      • “这些资产只应与我的合作伙伴共享”（“These assets should only be shared with my partners”）
        • 这种策略规定某些数据资产只能与特定的合作伙伴共享，确保数据不会被未经授权的第三方访问。
      • “数据必须留在欧洲”（“Data must remain in Europe”）
        • 这种策略要求数据只能在欧洲境内存储和处理，以遵守特定的地理位置要求和数据保护法规。
    • 策略执行的功能
      • 访问控制
        • 管理和控制谁可以访问哪些数据。
      • 数据位置
        • 确保数据按照地理位置要求进行存储和处理。
      • 合规性
        • 确保数据共享和传输符合相关法律和法规的要求。
      • 通过策略执行，EDC能够提供一个灵活且安全的数据共享环境，使数据所有者可以保持对其数据的完全控制，防止数据滥用和泄露。
    • 资产和策略（Assets and Policies）
      • 数据被表示为资产（Data is represented as an asset）
        • 在EDC中，数据被视为一种资产，每个数据资产都具有特定的价值和属性。
      • 所有资产都与策略关联（All assets are associated with policies）
        • 每个数据资产都与相应的访问控制和使用策略关联，确保数据的安全性和合规性。
      • 如果我们必须为每个资产定义单独的访问控制和使用策略，这将会（If we had to define separate access control and usage policies for each asset that would be）
        • 繁琐且容易出错（Tedious and error-prone）
        • 存在安全风险（A security risk）
        • 数据官员难以制定公司标准（Difficult for the data officer to set corporate standards）
        • 在为同一资产定义不同的策略时过于复杂（Overly complex when defining different policies for the same asset, e.g., for different audiences）
      • 合同定义解决了这些问题（The contract definition solves these issues）
        • 通过合同定义，EDC能够简化资产和策略的管理过程，提供一个集中且统一的管理机制，减少错误和安全风险，提高管理效率。
    • 主要解决方案
      • 合同定义（Contract Definition）
        • 合同定义为不同的资产和策略提供了一个标准化的框架，使得数据官员可以更轻松地制定和管理公司级别的标准，并确保不同用户和使用场景下的策略一致性和合规性。
        • 合同定义（Contract Definition）
        • 顶层设计（Top-down design）
          • 策略附加到资产上（Policies are "attached" to assets）
            • 采用顶层设计，策略与特定资产分离。这种设计方式使得策略的制定和管理更加灵活，可以根据需要进行简化。
        • 主要特点
          • 解耦策略制定和特定资产（Decouple policy authoring from particular assets）
            • 策略的制定不依赖于特定的资产，从而提供了更大的灵活性。
          • 提供灵活性并可以在需要时简化（Provides flexibility and can be simplified when needed）
            • 这种设计允许在必要时简化策略管理过程，提升效率。
        • 包含内容
          • 访问控制策略（Access control policy）
            • 这是一个私有策略，用于控制谁可以访问数据。例如，“我的合作伙伴”（"my partners"）。
          • 合同使用策略（Contract usage policy）
            • 这是一个公开策略，规定数据的使用方式。例如，“数据必须留在欧洲”（"data must stay in Europe"）。
          • 资产选择器（Asset selector）
            • 指定哪些资产适用这些策略。例如，“适用于这些资产…”（"applies to these assets..."）。
    • Publishing Data
      • 发布数据（Publishing Data）
        • 数据官员定义合同定义（The data officer defines a contract definition in the EDC system）
          • 数据官员在EDC系统中定义合同定义。
          • 示例：合同定义适用于资产的所有部分（资产选择器）。
            • 访问策略：只能由某个成员公司的合作伙伴访问。
            • 使用策略：必须存储在欧洲，仅用于维护目的。
        • 数据所有者创建资产条目（The data owner creates an asset entry in the EDC system）
          • 数据所有者在EDC系统中创建一个资产条目。
          • 资产条目并不是实际的资产，而是指向资产存储位置的指针（例如，对象存储）。
          • EDC系统会自动将资产与系统中的合同定义关联起来。
        • 资产现在对满足关联合同定义中策略的其他参与者可用（The asset is now available to other participants that satisfy the policies contained in associated contract definitions）
          • 资产现在对其他满足关联合同定义中策略的参与者可用。
      • 过程总结
        • 数据官员在系统中定义合同定义，规定了访问和使用策略。
        • 数据所有者创建资产条目，指向资产的实际存储位置。
        • 其他参与者只要满足合同定义中的策略，就可以访问这些资产。
    • 运行时策略执行原则（Runtime Policy Enforcement Principles）
      • 没有单一的方法来执行策略（There is no single way to enforce policy）
        • 宽松与严格要求（Lenient vs strict requirements）
        • 数据穿越多样的计算基础设施（Data traverses diverse compute infrastructure）
        • 有些义务无法自动化（Some obligations cannot be automated）
      • 需要全面协调（Requires holistic coordination）
        • 可能涉及技术基础设施的各个层级（May reach to all levels of your technical infrastructure）
      • 示例
      • 数据必须存储在欧洲（"Data must be stored in Europe"）
        • 通过控制平面配置策略（Policy Configuration），确保数据存储在符合要求的基础设施中。
    • 运行时评估：策略引擎（Runtime Evaluation: The Policy Engine）
      • 可扩展的评估引擎（Extensible evaluation engine）
        • 支持纵向执行（Can support vertical enforcement）
        • 将策略语法解析为内部策略模型抽象语法树（Parses policy syntax into an internal Policy Model AST）
      • 评估器和转换器用于执行策略（Evaluators and transformers to enforce policy）
        • 评估器可以做出策略决策，例如：连接器是否被授权（Evaluators can make policy decisions, e.g., is a connector authorized）
        • 转换器可以创建并部署策略到不同的层级（Transformers can create and deploy policy to different levels）
          • 如OPA（开放策略代理），存储等（OPA, storage, etc.）
      • 作为运行时扩展贡献（Contributed as runtime extensions）
    • 详细功能
      • 策略模型（Policy Model）
        • 将不同的策略语言（如IDS, ODRL等）解析为统一的内部模型（AST）
      • 策略评估器（Policy Evaluator）
        • 评估并执行策略决策
      • 策略转换器（Policy Transformer）
        • 将策略部署到不同的技术基础设施，如云策略、存储配置等（Cloud Policy, Storage Config）

  • Federated Catalog Services

    • This final section will discuss the federated catalog services provided by EDC, which likely include features for managing and discovering data assets across distributed and federated data environments, enabling seamless data access and integration.最后一部分将讨论EDC提供的联邦目录服务，其中可能包括管理和发现分布式和联邦数据环境中数据资产的功能，从而实现无缝的数据访问和集成。
    • 联邦目录服务（Federated Catalog Services）
      • 查找和发布数据
      • 如何查找数据？（How do I find data?）
        • 涉及信任（Trust）、查询（Query）、使用策略（Usage Policy）。
      • 如何发布数据？（How do I publish data?）
        • 涉及信任（Trust）、安全（Secure）、保护（Protect）。
    • 完全和半中心化目录架构（Fully- and Semi-Centralized Catalog Architectures）
      • 需要一个代理来发布目录（Require a broker where participants publish their catalogs）
      • 示例
      • 中心化代理数据空间（Centralized Broker Dataspace）
      • 半中心化数据空间（Semi-Centralized Dataspace）
    • 中心化目录架构的常见问题（Common Issues with Centralized Catalog Architectures）
      • 数据可见性和主权（Data visibility and sovereignty）
        • 第三方访问组织的数据目录是否可接受？
        • 组织依赖第三方来宣传其数据是否可接受？
        • 第三方目录提供商能否正确执行组织的访问规则？
      • 可靠性和可扩展性（Reliability and scalability）
        • 在完全中心化系统中，如果目录宕机会发生什么？
        • 在半中心化系统中，如何管理大规模复制？
    • 联邦目录服务（Federated Catalog Services）
      • 解决数据可见性和企业可扩展性与可靠性问题（Solves the problems of data visibility and enterprise scalability & reliability）
      • 联邦缓存爬虫（Federated Cache Crawler, FCC）
      • 定期抓取并缓存其他参与者的目录
      • 数据查询在本地缓存中执行
      • 联邦缓存节点（Federated Cache Node, FCN）
      • 向其他FCC宣传资产
      • 通过访问策略和合同使用策略执行访问控制
    • 示例策略
      • 访问策略（Access Policy）：只允许我的合作伙伴访问此数据（"Only allow my partners to access this data"）
      • 使用策略（Usage Policy）：组织只能在欧洲存储此数据（"Organizations can only store this data in Europe"）
    • 联邦目录服务架构（Federated Catalog Services Architecture）
      • 每个节点由联邦缓存节点（FCN）和联邦缓存爬虫（FCC）组成
      • FCN使其资产目录对其他参与者可用
      • FCC定期抓取其他FCN实例并缓存结果
  • 数据空间的四个技术支柱
    • 发现（Discover）
      • 数据空间中的参与者可以发现其他参与者和数据资源。
    • 发布（Publish）
      • 参与者可以在数据空间中发布自己的数据资源。
    • 共享（Share）
      • 数据资源可以在数据空间内的参与者之间进行共享。
    • 保持控制（Maintain Control）
      • 各参与者可以保持对其数据和身份的控制，决定如何共享数据以及共享的策略。
  • 核心技术支柱
    • 身份（Identity）
      • 每个参与者都能控制自己的身份，决定与谁共享身份信息。
    • 信任（Trust）
      • 每个参与者决定信任谁，并根据信任关系进行数据共享。
    • 策略（Policy）
      • 每个参与者决定在什么策略下共享其数据，确保数据共享符合预定的规则和要求。
    • 互操作性（Interoperability）
      • 确保不同系统和平台之间能够互操作，实现无缝的数据交换和协作。