Protocol
Overview（概要）
本プロトコルは ODS-RAM の L4「Discovery and Search」に対応する Fundamental Protocol であり、メタデータをもとにした探索・検索の高度化を担うものであり、 Metadata Exchange 上に公開された情報を利用してリソース探索とエンドポイント解決を行う。
Abstract Normative Specification（抽象仕様）
Concepts and Roles
事業ドメイン（Business Domain）
特定のビジネス領域。事業ドメインごとにDiscovery Service等の共通サービスが構築され得る。
データ/サービス提供者(Provider)
事業ドメインに関するデータ/サービスを提供する。複数のリソースを管理することができる。
データ/サービス利用者(Consumer)
データ/サービス提供者のデータ/サービスを利用する。
メタデータサーバ（Metadata Server）
メタデータをRDFとして公開する。Metadata Endpointで外部からの取得要求を受け付け、静的データについてはMetadata Storeから取得し、動的データについてはApplication Serverなどに随時取得しにいく。
メタデータストア（Metadata Store）
メタデータをRDFとして格納する。主に静的データを扱う。
メタデータクライアント（Metadata Client）
メタデータを取得する。ブラウザの場合は、javascriptライブラリなど
メタデータエンドポイント（Metadata Endpoint）
Metadata ServerにおけるRDF取得エンドポイント。SPARQLエンドポイントも含む。
ディスカバリーファインダー（Discovery Finder）
どのディスカバリーサービスを用いるかを探すサービス。ディスカバリーサービスの宛先を含むメタデータが得られる。
ディスカバリーサービス（Discovery Service）
リソースの属性（緯度経度、文字列など）をもとにメタデータを検索する。メタデータには、検索対象のリソースの他に、これに関するデータ/サービス提供者のインターフェースの意味と宛先（エンドポイント）が含まれる。エンドポイントは、Metadata Endpointの他に、各サービス（予約など）のエンドポイントも含まれる。
（補足） 「Why Open Dataspaces：設計思想とアーキテクチャパラダイム」で記述されている「Discovery Service」は、本プロトコル仕様における「Discovery Finder」（Discovery Serviceの探索）と「Discovery Service」（宛先（エンドポイント）の探索）を包含する概念である点に注意のこと。
Scope
Discovery Service解決
リソース検索
エンドポイント取得
Normative Requirements
shall: Discovery Service は、検索可能とするリソースを登録できるAPI（register）を持たなければならない。
Rationale: Discoveryは、サービスの提供者やデータの保持者が、保有するデータやサービスを検索対象となるために利用するのを原則としているため。Discovery Serviceは、Webサーチエンジンのように受動的（Passive）なインデックス化ではなく、サイト側が登録する能動型（Active）なインデックス化を行う。
shall: クライアントが、データやサービスにアクセスするために必要なエンドポイントの解決をするために、属性をキーとして、エンドポイントを含むメタデータを返すAPI（find）を持たなければならない。
Rationale: 分散データマネジメントでは、データやサービスの場所がグローバルに任意とし、データやサービスの実態を各者が管理可能とすることでデータ利用制御を実現するが、クライアントからはデータの発見が課題となってしまうため、検索のキーとなる属性からデータやサービスのエンドポイントにアクセスできるようにする必要があるため。
shall: Discovery Serviceは、検索結果として、リソースのエンドポイントを含むメタデータを返却しなければならない。
Rationale: Discovery Serviceは、データやサービスの場所を特定するために利用されるため、検索結果としてエンドポイントを含むメタデータを返却する必要があるため。
should: Discovery Serviceは、キーワード検索をサポートすることを原則とする。文字列をキーとして、エンドポイントを含むメタデータを返すAPI（find）を持つ。
Rationale: キーワードの一致から、そこに関連したデータやサービスのメタデータを返すインデックスが広く有用であるため。
should: Discovery Serviceへのメタデータの登録は、一定時間（TTL）後に無効となることを原則とし、継続的に検索可能とするには、継続（Keep Alive）指示を行うことを原則とする。
Rationale: データ/サービス自体が存在しなくなった際に、そのメタデータのみが存在している状態を可能な限り排除するため（c.f. 分散システムにおけるソフトステート管理）
may: Discovery Serviceは、地理空間検索をサポートしてもよい。地理空間属性をキーとして、エンドポイントを含むメタデータを返すAPI（find）を持つ。
Rationale: 実世界における緯度・経度から、そこに関連したデータやサービスのメタデータを返すインデックスがユースケースによっては有用であるため。
may: Discovery Serviceにおけるメタデータ管理の一貫性要件は、Eventual Consistencyとしてもよい。
Rationale: 分散システムにおいてはスケーラビリティと障害耐性が重要であるため。Discovery Serviceに格納されるメタデータが、元のデータ/サービス提供者のメタデータとの一致性は、データ/サービスにアクセスする際に検証することで、多くの場合、問題とならない。
may: Discovery Service自体のメタデータも、前記要件と同様な形式（例：SAMMによるサービス定義）・手法で管理される。
Rationale: クライアントから統一的にアクセス可能となるため。
may: 各分野におけるDiscovery Serviceの構築は、インデックス化する属性の設定を前記メタデータ（例：SAMMによるサービス定義）を設定することで、Discovery Serviceの構築に必要な部品が構築される。
Rationale: 各分野におけるDiscovery Serviceの構築には、データベースの構築、メッセージの受理・応答などの処理が必要であるが、その多くは共通的な作業であり自動生成可能である。一方、Discovery Serviceの開発者が担うべき処理も多少存在することからテンプレートまでの生成とする。
shall: Discovery Finderは、クライアントが、Discovery Serviceにアクセスするために必要なエンドポイントの解決をするために、Discovery Service名あるいは利用する分野の名称等から、Discovery Serviceのエンドポイントを含むメタデータを返すAPIを持たなければならない。
Rationale: Discovery Serviceの宛先自体が、分野ごとに複数ありえるため、この宛先解決自体が必要となるため。
should: クライアントは、固定的にDiscovery Finderの宛先やAPIなどのメタデータ情報を予め保持していることを原則とする。
Rationale: Discovery Finderは、Open Dataspaces内にて唯一、あるいは少数の限定された数存在することを想定し、また分野ごとのDiscovery Serviceの取得が要求される頻度は高くないため、少数ノードで対応できるため。
Message Types
findDiscoveryService
Metadata Client ⇒ Discovery Finder
Discovery Serviceの検索
findResource
Metadata Client ⇒ Discovery Service
リソースの検索
Protocol Flow
State Machine（状態遷移）
States（状態）
データ/サービス提供者に関する情報が、Discovery Serviceに登録されると、この情報のライフサイクル管理は次の状態遷移で管理される。
初期状態
Discovery Serviceに登録される前の状態
Active
Discovery Serviceに登録され、サービスの情報が検索可能となっている状態
終了状態
Discovery Serviceに登録されていない状態、あるいは無効化されている状態
create
データ/サービス提供者に関する情報のDiscovery Serviceへの登録
delete
データ/サービス提供者に関する情報のDiscovery Serviceからの削除
timeout
データ/サービス提供者に関する情報の作成/更新後、一定時間を経ったことを契機とする無効化
keep alive
データ/サービス提供者に関する情報を継続的に検索可能な状態とすることの指示
State Machine Diagram（状態遷移図）
Error Handling（エラー処理）
本プロトコルで使用されるエラー処理について記す。
Invalid Query
条件不正
入力修正
Not Found
該当なし
通知のみ
System Error
内部障害
管理者通知
最終更新