OMGのデータ・ディストリビューション・サービス（DDS）

今回と次回に分けて，OMGのデータ・ディストリビューション・サービス（DDS）について，データ中心型，出版／購読モデル型のデータ配信を例にお話しします。

DDSは，データ中心型の出版／購読（Publish/Subscribe）モデルに基づくアプリケーション構築のためのリアルタイムネットワーク環境とインフラストラクチャを定義しています。DDSは，軍事アプリケーションや産業用あるいは科学アプリケーションで広く使われおり，仕様の普及の速さは，仕様そのものを制定したOMGメンバー自身が驚くほどで，仕様そのものも急速に強化されてきており，現在ではインターオペラビリティ・プロトコル，UMLプロファイル，動的定義が可能なトピック型，C++への（IDL経由でない）直接のマッピング，軽量CORBAコンポーネントモデルの標準的な実装などが準備されています。

今回は標準の中核部分（出版／購読モデルおよびデータ中心型モデル）を解説し，次回は現在進行中の拡張部分（DDSインターオペラビリティプロトコルなど）を紹介したいと思います。

「出版／購読モデル」と「データ中心型モデル」

「出版／購読（publish-subscribe）モデル」を使って，アプリケーションは匿名でデータを作成（出版）し（注1）⁠，受信者はサービスを通じてデータを受け取ることにより通信が行われます（注2）⁠。図1は，典型的な構成例です。

データの提供者は，「⁠Write」ルーチンをコールしてデータをシステムに入力するのに対し，データの消費者側は，データの有無をときどきポーリングして確認するか，あるいは，新規データが入力された際に呼び出されるコールバックルーチンを用意・待機して，データを受信します。アプリケーション，あるいはその設計者は，データがどのようにして出版者から購読者に渡されるかは関知する必要がまったくなく，通信のサービス品質（QoS）に応じて確実にデータの送受信が行えます（注3）⁠。

「データ中心」の言葉の意味ですが，データの消費者がデータの生産者から，必要なデータを必要なときに必要な分だけ，データの発信源とデータの種類に応じて調整しながら確実に受け取れるように，DDS環境が設計構築されていることを意味します。

出版者は誰が自分のデータを予約購読しているかを知る必要はまったくなく，購読者側は出版元の身元を知る必要はありません（注4）⁠。

トピック（注5）の集まりとその定義域のことをドメインと呼びます。

ドメイン内で出版されたデータは，（⁠次に説明されるキーを設定してない限り）当該トピックのすべての購読者によって，指定されたサービス品質（QoS）に応じて受信されます。

ネットワーク上でドメインごとにアプリケーションを分けることもできますし，逆に1つのアプリケーションが複数のドメインにまたがって所属することもできます。また，トピック内で，データの一部をキーとして指定することができ（キーは構造体であっても構いません）⁠，個々のキーの値は独立したデータチャネルとして機能します（注6）⁠。

アプリケーションは，予約購読する際，データ型とともにキーを選択することが可能であり，さらにQoSパラメータをキーごと（！）に設定できます。キーの数は制約がありませんので，1つのトピック内に数千もしくはそれ以上の並行するデータチャネルを作ることができます。

アプリケーションは，データを出版するためにデータライタを呼び出し，データを受け取るためにデータリーダを呼ぶか，あるいはデータが来たときに呼び出されるコールバックルーチンを用意して待機します。アプリケーションの個々のインスタンスは，出版もしくは購読するトピックごとに別々のデータライタもしくはデータリーダを持ちます。1つのアプリケーションのインスタンスに関連するデータライタ群は，1個の出版者（Publisher）を共用し，同じようにデータリーダは1 個の購読者（Subscriber）を共用します。

出版者（Publisher）と購読者（Subscriber）は独立して，供給もしくは消費しようとするトピックごとに，サービス品質（QoS）を，最高およそ20個の特性パラメータ使って指定できます（注7）⁠。妥当な一貫性があることを前提として，QoSパラメータは，ライタ側とリーダ側で異なっていても構いません。1つのトピックに対しQoSパラメータが異なる複数のライタが存在してもよく，複数のリーダが異なるパラメータを持っていても構いません（同一のデータを別々の目的で使用できます）⁠。

例を挙げると，特定のトピックのために，出版者はいかに速くデータを出版することができるかをQoSとしてセットしたいと考え，一方，購読者は同一のトピックに対し，いかに高頻度にデータにアクセスできるか，といったことをQoSパラメータとしてセットしたいと考えるようなケースが考えられます（同じシステム内で，同一トピックに対し，異なる出版者と購読者群が，おのおの異なる値をパラメータとして設定するかもしれません）⁠。

DDS標準は，これらのリアルタイム性と堅牢性の要件を，できるだけ少ない資源で実装できるように設計されています。DDSは，軍事分野，宇宙航空分野，産業分野の領域で広く使われており，世界中の海軍や戦闘機を初めとする航空機，宇宙船，無人の空陸用偵察機，科学探査装置，産業用機器などでの使用が報告されています。逆に，少数個の巨大なファイルをポイントツー・ポイントで移動させるようなアプリケーションはDDS向きではありません。

注1）

データの作成者は必ずしも明示される必要はありません。たとえというと，システムは，匿名の記者による投稿や，秘密結社的な出版社の存在を許すことを意味します。これは，アプリケーションによっては，情報の発信源が第3者に判明してはいけない場合も想定しているためです。

注2）

どんなデータを受け取るかは，購読者が事前に予約（subscribe）して決めます。なお，このことが，この通信モデルが出版／（⁠予約）購読モデルと呼ばれる理由です。

注3）

DDSベースの出版／購読モデルでは，サービス品質（QoS）をきめ細かく設定できます。

注4）

出版者の身元情報は，データチャネルに抽象化されて保存されています。なお，DDSでは，このデータチャネルのことをトピックと呼びます。

注5）

トピックは，新聞でいうと政治欄や芸能欄といった分類されたテーマのことを意味します。DDSではトピックはユーザ定義可能な型として規定されており，政治型とか，さらに「日本国内の政治」型あるいは「中国国内の政治」型とか言ったふうに細かく自由に定義できます。そして，おのおのの型のインスタンスがニュース（あるいはデータ）にあたります。

注6）

例を挙げると，政治型で「オバマ大統領」をキーの値として設定するような場合，政治型のニュースの中でオバマ大統領関連のニュースだけのデータチャネルを作ることができます。

注7）

ほぼあらゆるニーズのQoS特性に対応できます。