第3章 システム構成例
本章では、ODSのアーキテクチャを実装するパターンとして、代表的な2つのサービスモデルとシステム構成例を示す。
分散型サービスモデル：ドメインオーナー自身がSelf-Serve Data Platformを構築し、DPQMに基づくData/Ontology Productを提供するという方式
連邦型サービスモデル：DPQMを構成する基本的なソフトウェアスタックをマネージドサービス事業者に代理で提供してもらいながら、ドメインオーナーとして、Data/Ontology Productの提供に責任を持つという方式
分散データマネジメントをどのようなサービスモデルで実装するかは、「どの機能を、どの主体が、どの範囲で提供するか」によって構成が変わる。
3.1 分散型サービスモデル
分散型サービスモデルでのシステム構成例を図1に示す。
図 1 分散型サービスモデルのシステム構成例
分散型サービスモデルでは、データ提供者・データ利用者の双方が、分散データマネジメントを成立させるために必要な機能をそれぞれ保持する。 典型的には、以下の要素が参加者（データ提供者・データ利用者）側に配置される。機能詳細は、ODPを併せて参照いただきたい。
Metadata Exchange
Discovery and Search
Identity and Trust、Credential Service
Transaction（コントロールプレーンオーケストレータ、データプレーンモジュール）
Logging
Heuristic Contracting、Clearing and Payment（オプション）
3.2 連邦型サービスモデル
連邦型サービスモデルでのシステム構成例を図2に示す。
図 2 連邦型サービスモデルのシステム構成例
連邦型サービスモデルでは、ODS Middlewareがデータ提供者側にDSSPとして配置される。DSSPは、参加者が個別に整備するには負担が大きい領域を補い、参加者が「データを提供・利用する」ことに集中できる状態を作ることができる。
3.3 オプトインと後方互換性
ODS-RAMにおいて、それぞれのレイヤは互いに独立しており、疎結合する形で一連の分散データマネジメントに係る機能を果たす。そのため、ドメインが有する性質・特性に応じて、必要となるレイヤ数を選択的に決定することができる。 例えば:
ある横断的なドメインにおけるデータの宛先及び意味が明白な場合、Ontology Product（L4～L2で構成されるセットの実装）を省略して、L3～L1でまずはData Productを先行実装しても構わない。
上記の連邦型サービスモデルの構成で言えば、L3：Identity and Trust、Credential Service、L2：Transactionの実装と、L1：Data Store、インダストリサービスを先行実装しても良い。
ODPの実装においては、Save Money, Make Moneyを基調とする市場の要求に応じて、オプトインできることに配慮した、必要最小限（Minimal Yet Viable）な設計を重視している。これを実現するため、プロトコルは疎結合に構成され、後方互換性を設計段階でビルトインしている。 本章で示した２つのサービスモデルを構成するコンポーネントは、市場の特性や成熟度に応じて選択され、段階的に導入、拡張していくものと考えていただきたい。
以降の章は以下のとおりである:
第4章は、ODS SDK for Onboardingが提供するデプロイ定義ファイルを使って、参加者同士でのデータ交換を実施できる最小構成の構築手順を示す。構築の対象は、L3、L2、L1、Logging、Clearing and Payment（オプション）である。
第5章は、ODS SDK for Semanticが提供する、SAMMによるセマンティック定義（Aspect Modelファイル、WebサービスAPI定義ファイル、インスタンスファイル）の作成方法と、Discovery Serviceへの登録方法、SDKの使い方と環境構築手順を示す。
最終更新