OpenDDS概述

    OpenDDS是OMG数据分发服务（DDS）的一种开源实现，它遵循实时系统v1.2的DDS规范（OMG Document formal/07-01-01）和实时公布/订阅互操作性通信协议v2.1的DDS-RTPS规范（OMG Document formal/2010-11-01）。
    OpenDDS由OCI公司设计和维护，可从http://www.opendds.org/的OpenDDS社区门户中获得帮助，目前的最新版本为v3.5。
    DDS为了在分布式应用程序中让参与者有效地分发数据，定义了一个服务，此服务不是特定于CORBA。此规范提供了两个模型：一个平台无关模型（PIM）和一个把PIM映射到CORBA IDL实现上的平台相关模型（PSM）。此服务又被分为两层接口：以数据为中心的发布/订阅（DCPS）层和可选择的数据本地重构（DLRL）层。DCPS层根据与数据主题、发布者以及订阅者相关的QoS约束条件，将发布者的数据传输给订阅者。DLRL层允许远程局部对象像访问本地数据一样共享分布式数据。其中，DLRL层是以DCPS为基础的。
    关于DDS的更多细节，开发者可以参考DDS规范（OMG Document formal/07-01-01），该规范更深层次的说明了服务的所有特性。
    注：目前，OpenDDS实现的DCPS层主要符合OMG DDS v1.2规范，不涉及DLRL的功能实现，更多信息请参考http://www.opendds.org/。

DCPS概述
    这一章节，主要介绍DCPS层的概念和实体，以及它们之间的协调交互。

基本概念
    如下图所示，展示了DDS的DCPS层核心概念图。后面的小节将详细说明此图中的一些概念。

图 1‑1 DCPS层核心概念图

域（Domain）
    域是DCPS内部最基本的分区单元。每一个实体只能属于一个域，只有属于同一个域的实体之间才可以交互信息。应用程序可以自由的通过多个不同域内的独立实体相互作用，实现多个域间的信息交互。

域参与者（DomainParticipant）
    域参与者是分布式应用程序在某个域内相互交互的入口点，以方便在特定的域中进行交互，是其它负责数据读、写的域实体的工厂。

主题（Topic）
    主题是发布、订阅应用程序之间数据交互的根本手段，在一个域内，每个主题有唯一的名字和特定的数据类型。每个主题数据类型可以指定0个或多个字段作为键，当数据发布时，发布端需要指定主题，订阅端通过该主题订阅数据。在DCPS模型中，可以通过不同实例发送同一主题的多个不同数据样本，每个实例拥有一个唯一的键值。在同一实例上发布的多个数据样本均使用相同的键值。

数据写者（DataWriter）
    发布端应用程序通过数据写者将数据传给DDS，每个数据写者都与一个主题绑定。应用程序使用数据写者提供的接口发布主题的数据样本。数据写者负责数据打包，并将数据包传给发布者用于传输。

发布者（Publisher）
    发布者负责将发布数据传输给该域中所有相关的订阅者，所采用的准则机制由服务的实现来决定。

订阅者（Subscriber）
    订阅者负责接收来自发布者的数据，并将数据传给所有相关联的数据读者。

数据读者（DataReader）
   数据读者负责从订阅者处获取数据，并解包之后将数据样本传给应用程序。每个数据读者都与一个主题绑定。应用程序使用数据读者的特定类型接口来接收样本数据。

内建主题
    DDS规范定义了许多内建在DDS实现中的主题。订阅这些内建主题可以使应用程序开发者访问正在使用的域的信息，包括哪个被注册了、哪个数据读者和哪个被连接以及被断开、以及各种各样实体的QoS设置。当这些内建主题被订阅时，应用程序就能接收到域内实体所发生的改变。
下表是DDS规范中定义的内建主题。

表 1-1 内建主题

QoS策略
    DDS规范定义了许多QoS策略，以便应用程序来指定自己的服务质量要求。参与者指定它们需要的行为，然后服务决定如何实现这些行为。这些策略被应用于所有DCPS实体（包括主题、数据写者、数据读者、发布者、订阅者、域参与者等），但不是所有的策略都适用于所有的实体类型。
发布者和订阅者通过请求-提供(RxO)模式相匹配。订阅者请求一组最低程度的策略，发布者向潜在的订阅者提供一组策略。然后DDS实现试图将请求的策略和提供的策略相匹配，如果策略兼容，就形成关联。
    QoS策略的具体内容将在后续章节进行详细介绍。

监听者
    DCPS层为每个实体定义了一个回调接口，以方便应用程序监听实体的状态改变或者有关的事件。例如，当有数据可读的时候，数据读者监听者就发出通知。

条件
    DDS中的条件和等待集为监听者检测感兴趣的事件提供了选择，一般模式是：
    1、应用程序创建一个特定的约束条件，如状态条件，并将其绑定到一个等待集上；
    2、应用程序在等待集上等待，直到约束条件为真；
    3、应用程序使用等待的结果开始获取它期待的信息；
    4、数据读者接口也提供了带有读取条件参数的接口；
    5、提供了查询条件，以作为内容订阅配置文件实现的一部分。查询条件接口扩展了读条件接口。