目錄
簡介
DDS制定了一個能在分佈式應用的多個參與者之間有效分發數據的服務。此服務不是專用於CORBA的。該規範提供了平臺無關模型（PIM）和將PIM映射到CORBA IDL 實現的特定平臺模型（PSM）。對於更多的有關DDS的細節問題，開發者應該參考DDS規範（OMG Document formal/2015-04-10）,因爲其中包含了所有服務特徵的進一步說明。OpenDDS是OMG DDS規範的開源C++實現，該規範是由OCI公司進行商業支持和開發的。OpenDDS可以通過網址http://www.opendds.org/downloads.html進行下載，並且能夠與OCI TAO1.6a,2.0a和2.2a版本的最新補丁以及最新發行的DOC版本兼容。
1.1. 概述
在本節，我們將介紹有關DCPS層的主要概念和實體，並討論他們之間如何相互作用以及協同工作的。
1.1.1 基本概念
下圖顯示了DDS DCPS層的概述。
1.1.1.1 域
域是DCPS中的基本分區單元。 每個其他實體屬於一個域，只能與同一域中的其他實體進行交互。 應用程序代碼可以自由地與多個域進行交互，但必須通過屬於不同域的單獨實體進行交互。
1.1.1.2 域的參與者
域參與者是應用程序在特定域內進行交互的入口點。 域參與者是編寫或讀取數據所涉及的許多對象的工廠。
1.1.1.3 主題
主題是發佈和訂閱應用程序之間交互的基本方式。 每個主題在域中都有一個唯一的名稱發佈具有特定類型的數據。可以將主題發佈的數據類型制定成消息的鍵。 發佈數據時始終指定主題。 訂閱者通過該主題請求數據。 在DCPS術語中，可以爲主題上的不同實例發佈單個數據樣本。 每個實例都與密鑰的唯一值相關聯。 發佈數據時通過根據樣本使用的鍵值在同一實例上發佈多個數據樣本。
1.1.1.4 數據寫入器
發佈應用程序代碼使用數據寫入器將值傳遞給DDS。 每個數據寫程序都綁定到特定主題。 該應用程序使用數據編寫器的特定於類型的接口來發布該主題的示例。 數據編寫者負責編組數據並將其傳遞給發佈者以進行傳輸。
1.1.1.5 發行方
發佈者負責獲取已發佈的數據並將其傳播到域中的所有相關訂閱者。 採用的確切機制留給服務實現。
1.1.1.6 訂閱方
訂閱方從發佈者接收數據並將其傳遞給與其連接的任何相關數據讀取器。
1.1.1.7 數據讀取器
數據讀取器從訂閱方獲取數據，將其解析爲該主題的相應類型，並將對應的消息傳遞給應用程序。 每個數據讀取器都綁定到特定主題。 應用程序使用數據讀取器的特定於類型的接口來接收樣本。
1.1.2 標題的內置
DDS規範定義了DDS實現中內置的許多主題。 訂閱這些內置主題使應用程序開發人員能夠訪問所使用的域的狀態，包括註冊哪些主題，連接和斷開哪些數據讀取器和數據寫入器，以及各種實體的QoS設置。 訂閱時，應用程序會收到指示域內實體更改的樣本。
下表顯示了DDS規範中定義的內置主題：
1.1.3 服務質量政策
DDS規範定義了許多應用程序使用的服務質量（QoS）策略，以指定其對服務的QoS要求。 參與者指定他們從服務中需要的行爲，服務決定如何實現這些行爲。 這些策略可以應用於各種DCPS實體（主題，數據寫入器，數據讀取器，發佈者，訂閱者，域參與者），但並非所有策略都適用於所有類型的實體。訂閱者和發佈者使用請求與提供（RxO）模型進行匹配。 訂閱者請求一組最低要求的策略。 發佈者向潛在訂閱者提供一組QoS策略。 然後，DDS實施嘗試將所請求的策略與提供的策略進行匹配; 如果這些政策兼容，則形成關聯。
1.1.4 監聽者
DCPS層爲每個實體定義回調接口，允許應用程序進程“監聽”某些狀態更改或與該實體有關的事件。 例如，當有可供讀取的數據值時，將通知數據讀取器偵聽器。
1.1.5 條件
條件和等待集允許偵聽器在檢測DDS中感興趣的事件時使用另一種方法。一般模式是應用程序創建特定類型的條件對象，例如StatusCondition，並將其附加到WaitSet。
•應用程序在WaitSet上等待，直到一個或多個條件成立爲止。
•應用程序調用相應實體對象上的操作以提取必要信息。
•DataReader接口還具有采用ReadCondition參數的操作。
•QueryCondition對象是作爲ContentSubscription配置文件實現的一部分提供的。 QueryCondition接口擴展了ReadCondition接口。