AWS Architecture Blog
本系列部落格共分三部分,引導您在 AWS 上實作 Eclipse Dataspace Components (EDC),從基礎概念到正式部署。第一部分以 IDSA 標準、Dataspace Protocol (DSP) 以及 EDC 核心架構建立理論基礎。第二部分提供使用 Amazon Elastic Container Service (Amazon ECS)、Amazon Aurora 及 Amazon API Gateway 等服務的生產就緒 AWS 部署模式。第三部分以成本最佳化策略及在 AWS 上執行高效、可擴展資料空間基礎架構的實務指引完成本系列。
International Data Spaces Association (IDSA) 是一個非營利組織,致力於建立並推廣資料空間的相關標準。資料空間被定義為「促進不同實體之間可互通資料集分享的一組技術服務」。在技術層面上,資料空間包含參與者:資料消費者與資料提供者。中央設有 Dataspace Governance Authority (DSGA)。DSGA 負責管理資料空間、執行規則與政策,並向參與者發行成員憑證。
IDSA 的規則與規範實作於 Dataspace Protocol (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 規範的安全、合規且可互通的資料空間。
為了以去中心化方式驗證資料空間中的身分,使用 Decentralized Claims Protocol (DCP)。DCP 是 DSP 之上的覆蓋層,用以在網路參與者之間建立信任。當發行者需要向驗證者證明其身分時,會先產生去中心化識別碼 (DID),其中包含其身分相關資訊。發行者將可驗證憑證 (VC) 儲存在其身分中樞中。可驗證憑證類似於證書:憑證授權單位驗證公開金鑰,而憑證發行者則驗證具有特定屬性的 DID。驗證者查詢發行者的 DID,並利用從 DID 文件取得的資訊驗證 VC。

圖 1:Decentralized Claims Protocol (DCP) 概觀圖

圖 2:DID 文件處理簡化概觀
EDC 的最後一個要素是不同類型的政策,包括成員資格、存取、合約及使用政策。
連接器的角色
EDC 連接器分為兩部分:控制平面與資料平面。控制平面負責合約協商,並向資料平面傳送訊息以啟動資料傳輸。資料平面則負責將資料從提供者的 EDC 連接器傳輸至消費者,跨越不同的法律實體。

圖 3:連接器控制平面與資料平面概觀
EDC 連接器開源專案的結構
EDC 專案中的 Connector 儲存庫 定義了連接器控制平面與資料平面的實作方式。以下概述儲存庫的結構:
/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 的整合,您需要在自訂 EDC 控制平面與資料平面建置中納入對應的 AWS 擴充。
高階 EDC 自訂指南
為原生 AWS 服務整合自訂 EDC 連接器,可建立可利用 AWS 受管服務進行儲存、安全與擴展的專用解決方案。以下步驟可協助您的連接器原生整合 Amazon S3 等服務(例如作為 Asset Administration Shell「子模型伺服器」使用)以及 AWS Secrets Manager 進行憑證管理,而非依賴自我管理元件的操作。
EDC 使用建構於 Gradle 之上的模組化、外掛程式式架構。原版連接器僅提供核心功能。若要與特定雲端服務或持久性後端整合,您可以組合自訂建置,將 EDC 的核心模組與所需的擴充結合在一起。自訂作業圍繞三個概念:版本目錄、啟動器模組以及專案設定檔。
步驟 1:版本目錄
版本目錄 (gradle/libs.versions.toml) 是所有相依性及其版本的集中式登錄檔。您可以在此宣告連接器所需的 EDC 模組、雲端供應商擴充以及協力廠商函式庫。EDC 在 org.eclipse.edc.aws Maven 群組下發布其 AWS 擴充。您可以參照這些擴充以及相容版本編號的核心 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 # Control plane launcher
├── data-plane/
│ └── build.gradle.kts # Data plane launcher
├── extensions/ # Optional: Custom extension code
├── gradle/libs.versions.toml # All dependency versions
├── build.gradle.kts # Root build config
└── settings.gradle.kts # Subproject registrations
Dataspace Connector on AWS 專案提供 EDC 在 AWS 上自訂的開源參考實作。在本文中,您已了解使用新興資料空間架構進行安全、跨組織資料分享背後的基本原理。我們涵蓋了 ISO/IEC DIS 20151 資料空間標準化中包含的兩個協定 DSP 與 DCP,並討論了資料空間參與者所需的主要軟體 EDC 連接器,以及如何對其進行自訂。
在第二部分,我們將探討 EDC 連接器在 AWS 上的生產就緒部署模式,檢視支援資料空間基礎架構安全性、可靠性與營運效率的架構最佳實務。若要開始使用,請探索 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
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.