作者：Gerardo Pardo-Castellote（RTI首席技术官）Bert Farabaugh（RTI公司现场应用工程总监）Andy Krassowski（RTI现场应用工程师）

一、摘要

为了满足分布式应用程序的通信需求，一类可靠的特性被称为数据分发服务（DDS™）。许多不同类型的分布式应用程序都可以使用DDS基础设施作为其数据通信的主干。本文是分布式应用程序的概述，描述了DDS及其组件的核心特性，并讨论了DDS如何帮助开发人员设计分布式应用程序并实现数据中心性。

典型分布式应用程序

所有分布式应用程序的一个共同要求是需要在不同的独立模块或组件之间传递数据。这些模块可以在同一个处理器上执行，也可以在不同的节点上分布。通常会有一个组合——多个节点，每个节点上都有多个进程，每个进程都包含一个或多个模块。

每个节点或进程都通过以太网、共享内存或无线带宽技术等传输机制进行连接。可以使用基本协议如TCP/IP或更高级别的HTTP协议在每个节点之间提供标准化的通信路径。共享内存（SHMEM）访问通常用于在同一节点上运行的进程。

图1显示了一个简单的分布式应用程序的示例。在本例中，嵌入式单板计算机（SBC）通过硬连线连接到温度传感器，并连接到以太网传输端。它负责以特定的速率收集温度传感器的数据。同样连接到网络的工作站负责在屏幕上显示该数据，供操作员查看。

DDS是一种可以用来促进这种实时信息交换的机制。

图1 简单的分布式应用

二、什么是DDS？

DDS是一系列标准，它指定了分布式应用程序可用于交换实时数据的API、协议和安全机制。应用程序所使用的软件应用程序编程接口（API）是基于一个安全的、服务质量（QoS）感知的“以数据为中心的发布订阅”（DCPS）模型。这意味着应用程序只需要关注它们希望产生或使用的数据，以及所需的QoS。DDS基础设施负责处理其余的部分。由于DDS是作为一个“基础设施”解决方案实现的，因此可以添加它作为任何软件应用程序的通信接口。

DDS优点

1. 开放标准和生态系统。所有方面都受对象管理组®（OMG®）标准管理，包括应用程序API、总线协议、类型系统、序列化格式和安全机制。这里有一个丰富的供应商生态系统，它们提供基于DDS的产品和应用程序。
2. 基于一个简单的“发布-订阅”通信范式。支持一对一、一对多、多对一、多对多的通信。
3. 灵活和适应性强的架构，支持“自动发现”应用程序和端点的架构。
4. 监视应用程序和端点存在性、可用性和活动性的内置机制。
5. 低开销和无服务器，因此它可以与高性能系统一起使用。
6. QoS感知。允许应用程序指定每个数据流的非功能特性，如可靠性、耐久性、使用寿命、所有权、存活性等。开发人员可以保留对系统中单个数据流的完全控制。
7. 确定性的数据传递，因此它可以用于实时系统。
8. 可扩展，因此它可以处理具有数千个应用程序和数十万个单个数据项的大型系统。
9. 有效地使用传输带宽
10. 细粒度的以数据为中心的安全。连接系统的每个节点都经过身份验证，细粒度策略控制每个节点可以发布和订阅的信息。数据流是单独的隔离和受保护的加密方式

如图2所示，DDS提供了一个基础设施层，使许多不同类型的应用程序能够相互通信

图2 DDS基础结构

DDS规范由OMG管理，OMG是管理SysML、UML®和许多其他标准的同一组织。任何DDS指定的副本都可以从OMG网站www.omg.org/spec或www.ddsfoundation.org/omg-dds-standard/获得。通过正式指定在线数据格式、安全机制、发现协议、多种语言的API和QoS行为，DDS使开发人员能够利用经过验证的技术和未来验证他们的设计。

三、什么是发布-订阅？

发布-订阅（发布-订阅）应用程序通常是由一个模块组成的，这些模块通过匿名发送（发布）数据和匿名接收（订阅）数据来相互通信。通常，发布者与订阅者通信唯一需要的是主题名称（标识流）和相关的数据类型(这定义了用于读/写数据的应用程序级api，以及将从应用程序数据转换为网络表示的机制)。发布者不需要任何关于订阅者的信息，反之亦然。
发布-订阅基础设施能够将数据传递到适当的节点，而无需手动设置单个连接。发布者负责收集适当的数据，并将其发送给当前注册的订阅者。订阅者负责从适当的发布者接收数据，并将数据呈现给感兴趣的用户应用程序。

四、“以数据为中心”是什么意思？

以数据为中心指的是以数据为中心的体系结构，而应用程序可能会来来去去。在这些系统中，数据模型先于并超越任何给定应用程序的实现。
像DDS这样的以数据为中心的通信基础设施为分布式应用程序提供了“共享状态”的能力，而不是简单地交换消息。消息交换已成为达到目的的一种手段。通过以数据为中心的通信，可以通知应用程序对共享状态的相关更改，包括对数据值的更改、新数据对象的存在，甚至是访问共享状态的其他应用程序的可用性和活动性。
以数据为中心的通信可以为应用程序提供更强的一致性模型（例如，最终的一致性），这极大地促进了构建健壮的和高可用性的应用程序。
以数据为中心的模型还为应用程序提供了一种可以及时解耦的机制。例如，一个延迟连接的应用程序可以只观察当前状态，以便“赶上”系统的其他部分。它不需要处理导致过去状态更改的所有中间消息——相反，它只需要关注最终的结果。
日历系统提供了共享状态的一个很好的示例。查看日历可以给您提供所有当前约会的快照。发送消息以更新日历（创建/删除或更改约会），但最重要的是最终结果。如果不支持访问（日历）共享状态，应用程序将必须处理所有中间消息，以到达日历的当前状态。
由于以数据为中心，DDS提供了除消息交换之外的api和协议，并允许访问和更新共享状态。

五、QoS感知意味着什么？

像DDS这样的可感知qos的通信基础设施提供了指定调节信息交换的各种非功能特性（服务质量参数）的能力。
系统的功能特征描述了系统应该做什么——换句话说，也就是它所执行的功能。应用于发布-订阅基础设施时，它指定了它应该发布和订阅的主题、关联的数据类型、应该创建和删除数据对象等。
系统的非功能特性描述了系统应该如何执行这些功能。应用于发布订阅基础设施，它规定了信息交换的许多特征，例如使用各种协议级机制来确保可靠的数据交付，监控应用程序可用性，确保数据新鲜度，控制带宽和资源使用等。
DDS QoS参数允许系统设计人员根据对每个特定数据块的需求和可用性来构建一个分布式应用程序。这可用于优化您的分布式应用程序，以满足其特定的要求。

六、什么是以数据为中心的安全？

安全系统必须保护信息的机密性和完整性，并提供身份验证和访问控制机制，以确保数据仅被预期的应用程序访问。
DDS提供了标准的非粒度安全机制，在允许每个应用程序加入DDS域之前对其进行身份验证。此外，非粒度权限控制每个应用程序可以读写的主题，内置的加密机制分别保护每个端到端数据流，以确保数据的完整性和/或机密性。对所提供的机制的详细描述超出了本文的范围，但这些细节可以在OMG提供的DDS-Securte™指定中找到（见www.omg.org/spec/DDS-SECURITY/）。

七、DDS如何帮助开发人员？

使用发布-订阅通信机制的解决方案通常是通过专有的解决方案来完成的。DDS通过提供标准化的接口和实现所需功能的必要协议，形式化了具有qos感知的以数据为中心的发布-订阅通信范式。
在图1所示的示例中，DDS将是嵌入式SBC和工作站上的一个软件模块。在嵌入式SBC方面，DDS将允许通过QoS参数发布具有指定的传递行为的温度传感器数据。在工作站端，DDS将使已声明的订阅能够根据由QoS参数转换的指定接收特性来接收温度传感器数据
通过依赖于控制数据传播并提供对共享状态的访问，分布式应用程序开发人员可以集中于他们的指定模块的操作——而不用担心他们将如何与系统中的其他模块通信。
收集或生成数据的应用程序（通过与传感器、文件、机载数据计算等的接口）。可以使用DDS框架来发送（发布）他们的数据。类似地，需要来自分布式系统中其他应用程序的数据的应用程序可以使用DDS框架来接收（订阅）特定的数据项。DDS处理发布端和订阅端之间的所有通信。
通过对数据通信的发布-订阅方法，DDS抽象了数据发送者和接收者之间的通信。发布端不需要知道每个单独的接收者——他们只需要知道正在共享的特定主题以及如何发送它。对于订阅者也是如此。订阅者不需要知道已发布的数据来自哪里；他们只需要知道他们希望接收的特定数据类型以及如何接收它。

图3 DDS简单的分布式应用

在图3中，嵌入式SBC使用当前的温度传感器数据作为参数，通过一个简单的“写入”调用来发布数据包。在工作站端，应用程序可以在等待数据可用时进行阻塞，设置一个回调例程以在数据到达时立即被通知，或者按需检查其本地缓存以访问最新的值。

八、DDS实体的概述

DDS API定义了以下实体：

• DomainParticipant
• DataWriter
• Publisher
• DataReader
• Subscriber
• Topic

图4显示了DDS中的实体是如何相关联的。下面的部分包含了在DDS中使用的实体的更详细的描述

图4 DDS实体

在图4中，域参与者加入了一个DDS域。域表示提供访问共享状态的共享数据空间（数据库）。共享状态被组织为已命名的主题。每个主题都可以包含多个数据对象。每个数据对象都由对象中指定的关键字段的值来标识。使用datawriter发送数据并更新数据对象。每个datawriter都与一个主题相关联，因此它只能用于发送或更新属于该主题的数据主题。同样地，也可以使用datareader来访问数据对象。每个datareader都与一个主题相关联，并且只能访问和接收属于该主题的数据主题。发布者用于分组和管理datawriter。订阅者用于分组和管理datareader。

九、域和域参与者

域是用于将各个应用程序绑定在一起以进行通信的基本构造。分布式应用程序可以选择对其所有数据中心通信使用单个域。
图5显示了一个在五个节点上有六个应用程序的系统的例子，所有这些节点都在同一个域中通信。

图5 单个域的系统

DDS还具有支持多个域的能力，从而为开发人员提供了一个系统，可以根据不同的数据访问需求进行扩展或隔离。当一个特定的数据实例发布在一个域上时，附加到任何其他域的参与者将不会接收到它。
多个域提供了有效的数据隔离。一个用例是设计一个系统，其中所有与命令/控制相关的数据通过一个域交换，而状态信息在另一个域内交换。
在图6中，三个应用程序在域A中通信命令/控制数据，其他三个应用程序在域b中通信状态数据。对于非常大的系统，开发人员可能希望在其整个系统中的每个功能区域有不同的域。
多个域也是控制在现有系统中引入新功能的一种好方法。假设您有一个分布式应用程序，它已经经过测试和验证，可以正常工作，然后需要添加新的功能。您希望最小化新功能的影响，并在不破坏现有功能的情况下保留它。
在图6中，将一个新域添加到现有应用程序中。域C中的新数据流将不会影响旧域中的现有数据流。新的域提供了一个孤立的容器，用于测试新的功能。在测试完成后，新的应用程序（App 7和App 8）可以仅仅通过更改其指定的域而添加到原始系统中。

图6 多个域的系统

应用程序使用“域参与者”来加入DDS域。域参与者允许开发人员为相应域中的所有datawriter、datareader、发布者和订阅者指定默认的QoS参数。可以设置默认侦听器回调例程来处理DDS基础设施报告给应用程序的事件或错误条件。这使得它很容易指定应用程序在收到尚未在关联实体上设置特定监听器例程的通知时将遵循的默认行为：发布者、订阅器、datawriter或datareader。
一个DDS域由两个参数标识：一个整数域ID和一个字符串域标记。这些都是在创建每个域参与者时被指定的。只有为两个参数（ID和Tag）指定相同值的参与者才能加入相同的域，从而能够发现并相互通信。

十、数据写者和发布者

数据写入器是应用程序将数据发布到DDS域的主要访问点。一旦创建和配置了正确的QoS，应用程序只需要执行一个简单的写调用，例如在这个C++示例中：writer->write(data, instance_handle);
发送应用程序控制数据发布的速率。订阅者可能对他们希望接收数据的频率有不同的要求。一些订阅者可能想要每个单独的数据样本，而另一些人可能想要速度慢得多的数据。一些订阅者可能希望查看对对象的每个更新，而另一些人则对最新的更新（即当前状态）更感兴趣。这可以通过指定不同的QoS策略来实现，例如历史记录或TIME_BASED_FILTER。如果一个基于时间的过滤是为datareader指定的，那么datawriter可以避免以比实际需要的速度向该阅读器发送数据更新。因此，这将减少整体的网络带宽。当执行写入时，DDS软件将把这些数据从本地datawriter缓存复制到主题的每个datareader的本地缓存中。图7显示了发布数据所需的实体（域参与者、主题、datawriter和发布者）是如何关联的。

图7 发布模型

发布端用于将各个datawriter分组在一起。开发人员可以为发布者指定默认的QoS行为，并将其应用于该发布者组中的所有datawriter。

十一、数据读者和订阅者

datareader是应用程序访问DDS域中的数据的主要访问点。图8显示了与订阅关联的实体。一旦创建和配置了正确的QoS，就可以通过三种方式之一通知应用程序数据可用：
• 回调函数
• 轮询DataReader
• waitset
访问接收数据的第一种方法是设置一个侦听器回调例程，DDS将在接收数据时立即调用该例程。您可以在该回调例程中执行您自己的指定软件来访问数据。
第二种方法是“轮询”或查询本地数据读取器缓存，以确定数据是否可用。
最后一种方法是设置一个“waitset”，应用程序在这个集合上等待，直到一组特定的条件被满足，然后从数据阅读器访问数据。

图8 订阅模型

使用这三种方法可以使开发人员能够灵活地访问数据。访问数据是通过调用数据读取器上的take()或read()来完成的。take()操作在应用程序使用后将数据从本地数据阅读器缓存中删除数据；在应用程序使用数据后，read()操作将数据保留在本地数据阅读器缓存中，允许应用程序多次访问数据。
订阅者用于将各个datareader分组在一起。与以前的发布者类似，这允许您合并一组默认的QoS参数和事件处理例程，这些例程将应用于该订阅服务器组中的所有datareader。

十二、主题

主题提供了datawriter、datareader和共享的全局数据空间（域）之间的逻辑连接。
在共享数据空间中，每个主题都由一个简单字符串的主题名称标识。该名称唯一地标识了DDS域内的主题。
如果您熟悉发布-订阅系统，那么您可以将每个主题视为标识一个单独的信息流。从以数据为中心的角度来看，每个主题都代表了一个单独的数据对象集合。主题中的所有数据对象都具有相同的类型或密切相关（兼容）类型。此外，每个数据对象都由被指定为“关键字段”的数据字段中的某些字段的值来标识。
共享数据空间中的主题将对那些被集体观察到的状态的相关对象进行分组。例如，空中飞行管理应用程序可以使用一个名为“飞行状态”的主题来共享所有航班的当前位置和状态。每个单独的飞行可以通过关键字段（例如，航空公司和航班号）的组合来识别，或者其他一些唯一的标识符（例如，飞机尾号）也可以作为关键字。将所有这些对象分组为一个单一的“飞行状态”主题，允许一个datareader观察（订阅）多个航班的状态，并被通知航班的创建/出现和完成，等等。同样地，一个datawriter可以用于更新多个航班。
针对Keys使用的更多细节，请参见下面的“主题键”。
每个域参与者必须创建本地主题对象，以标识其要访问（读或写）的共享数据空间主题。在创建本地主题对象时，应用程序必须同时指定主题名称和关联的数据类型。
要发布数据，应用程序将创建一个数据写入器对象，并将其与本地主题相关联。同样地，为了订阅数据，应用程序将创建一个数据阅读器对象，并将其与一个本地主题相关联。要进行通信，与数据写入器关联的主题名称必须与数据阅读器关联的主题名称相匹配。但是，与数据编写器和数据阅读器主题相关联的数据类型不需要相同。它们只需要相互兼容即可。我们将在下面进一步详细说明这一点。

十三、数据类型

在以数据为中心的系统中，被发布和订阅的数据总是具有一个关联的数据类型。datawriter和datareader是专门针对已发布/订阅的类型编写的，并向应用程序传递强类型的数据。
但是，不需要在编译时就知道数据类型，因为DDS提供静态和动态API。例如，动态API使应用程序能够创建任意类型的编写器和读取器，这些类型在运行时被删除或发现。然而，一旦创建了数据写入器或数据阅读器，它的类型也会被删除，即使使用动态API进行访问.
强类型系统提供了更强的契约，便于设计和组合模块化系统。它们还提供了更具确定性的行为，并可以利用语言机制来实现更好的性能和资源管理。这些都是实时、可靠、安全、关键的基础设施系统的重要方面，这些系统构成了DDS通常的应用程序空间。
然而，除非需要谨慎，否则分布式强类型系统也可能是刚性和不灵活的，从而阻止系统的可组合性和演化。
因此，DDS不要求数据编写器和数据阅读器与相同的数据类型相关联。相反，DDS只要求类型是兼容的，或者更准确地说，由数据写入器发布的类型可分配给由数据阅读器订阅的类型。在DDS-XType™指定中定义的精确可分配规则超出了本文的范围。一般来说，类型可分配性规则是允许安全类型进化——也就是说，数据作者的类型可以不同于数据读者，只要读者能够预期的信息，而不是错过任何“基本”信息需要正确解释数据。
DDS指定提供了定义数据类型的各种机制。最流行的方法是使用OMG接口定义语言版本4.x（IDL4）。IDL4同时是一种用于定义数据类型和接口的ISO和OMG标准语言。IDL4的语法与C-++非常相似。
IDL4支持以下基元数据类型：

• char, wchar, octet
• int8, uint8
• int16, short, uint16,unsigned short
• int32, long, uint32,unsigned long
• int64, long long, uint64,unsigned long long
• float, double, long double
• boolean
• enum
• bitmap, bitset
• string, wstring

例如，这里是在最常用的RTI“shapes demo”中使用的数据类型的定义：
@appendable
struct ShapeType {
@key string<256> color;
@range(0, 256) int16 x;
@range(0, 256) int16 y;
@min(10) uint16 size;
};
在本例中，类型ShapeType是一个主题类型。主题名称可以是应用程序选择的任何字符串，例如，“正方形”或“圆圈”。此外，本示例还显示了一些用于反映字段的各个方面的IDL关键字。“@key”引用了包含主题键（下面描述）的字段，而“@range”引用是为了注意到，在这种情况下，x和y的值只能在0到256之间。一个完整的IDL关键字列表可以在OMG IDL指定中找到。

主题键

在主题类型的定义中，可以选择一个或多个数据成员作为该类型的“键”。DDS使用关键成员的值来识别主题中的每个单独的数据对象。对具有不同键的主题数据对象的更新是相互独立的。换句话说，由键值K1标识的主题数据对象的更新将修改K1对象中其余成员的值，但不影响或替换主题中其他数据对象的相应值。使用上面的“形状”示例，主题“方形”的数据对象，其中形状类型成员颜色的值是“蓝色”，更新与同一主题“方形”中的数据对象不同，其中的颜色是“绿色”。因此，应用程序可以更新主题“Square”中的“蓝色”数据对象的x、y和大小值，而不会影响同一主题上的任何其他数据对象（例如，主题“Square”中的“绿色”数据对象）。
DDS可以保留对每个数据对象进行的更新的特定历史记录，并提供API来读取每个数据对象的当前和最近的更新（通过指定键）。
DDS还可以通知应用程序中数据对象的出现和/或消失。例如，在主题“Square”上接收具有以前从未见过的颜色值的数据，或者从正在更新特定数据对象（例如，主题“Square”中的“蓝色”数据对象）的所有数据写入器的系统中消失。
键也可以用于实现对数据流的即时控制。每个单独的键值都创建一个独立的信息流，数据阅读器可以选择只读取具有特定键值的数据对象。
在构建可扩展的应用程序时，使用键也很重要。拥有一个具有多个键的主题远比拥有多个主题（例如，每个键值一个）更有智谋性。它还可以简化应用程序的开发和演化。在图3前面所示的分布式应用程序中，假设有多个嵌入式SBC，每个SBC都带有自己的温度传感器。如果没有密钥，您将需要为每个不同的SBC/温度传感器对创建单独的主题。这些主题的主题名称可能是：

• “Temperature_Sensor_1”
• “Temperature_Sensor_2”
• “Temperature_Sensor_3”
• 等等…

尽管每个主题都有相同的数据类型，但我们使用不同的主题名称将迫使创建多个主题，相应地，由多个数据阅读器和数据编写器来读/写单独的主题。如果你想在系统中添加另一个传感器，你必须：创建一个新的主题，“Temperature_Sensor_N”；创建一个新的数据写入器来编写它；并创建一个新的数据阅读器来读取它。
但使用key，你只需要一个主题，名为“Temperature”，具有以下类型的定义：
struct TemperatureType {
@key uint32 sensorId;
float value;
};
当订阅者从“Temperature”的所有发布者接收到数据时，它将把这些数据相对于它的关键值呈现给应用程序，在这种情况下，关键值是传感器id。可以添加新的传感器，而不需要创建一个新的主题。发布应用程序只需在准备发布该数据时填写新的传感器id。
key促进了多对一的场景，其中多个应用程序将数据写入同一主题。只要应用程序编写单独的键，每个流都可以单独保存——而且一个数据写入器的值就不会与另一个数据写入器编写的值发生冲突。多个数据由写器也可以更新相同的数据对象（即，为关键成员编写引用相同值的更新）。这可用于提供冗余和/或仲裁特定数据对象的所有权/控制。使用QoS策略、所有权和所有权强度来合并冗余和所有权控制场景。

十四、主题内容过滤

除了标准主题外，还有针对ContentFilteredTopics的构造。
ContentFilteredTopics允许数据阅读器指定一个过滤器表达式，该表达式只选择在指定主题上发布的数据样本的一个子集。在我们的简单示例中，这可能只允许一些订阅者在温度超过感兴趣的特定限制时接收和处理数据。
通过利用针对常见设计问题的标准化解决方案，DDS用户能够专注于他们的应用程序逻辑，并让通信框架来处理指定的数据移动。

在DDS中的服务质量

为每个DDS实体提供QoS策略是DDS提供的一个重要能力。能够为每个单独的领域参与者、主题、出版商、订阅者、数据阅读器或数据编写器指定不同的QoS策略，这为开发人员提供了一个很大的调色板来设计他们的系统。这是DDS提供的Qos感知数据中心性的本质。
DDS QoS参数包括：

• Deadline
• Destination Order
• Durability
• Entity Factory
• Group Data
• History
• Latency Budget
• Lifespan
• Liveliness
• Ownership
• Ownership Strength
• Partition
• Presentation
• Reader Data Lifecycle
• Reliability
• Resource Limits
• Time-Based Filter
• Topic Data
• Transport Priority
• User Data
• Writer Data Lifecycle

通过这些策略的组合，系统架构师可以构建一个分布式应用程序来解决所有的需求范围—从简单的通信模式到复杂的数据交互。

总结

数据分发服务标准是一系列的OMG特性，它为信息交换和应用程序集成创建了一个简单而强大的体系结构。
主题允许节点和应用程序模块相互抽象，因此节点和模块化组件就可以动态地进入和离开分布式应用程序。DDS提供了一个基于QoS感知的“以数据为中心”的发布-订阅模型，因此可以将QoS策略合并在每个端点的基础上。这种细粒度的兼容性对于支持复杂的数据通信模式至关重要。
DDS提供了一个基于标准的API，用于以一个扩展的语言列表（C、C++、Java、c#、Ada和Python）发送和接收数据。它提供了消除数据模型的方法，以及一个标准的总线协议，以确保由不同供应商开发的模块化组件之间的互操作性。通过使用单一的数据模型，开发人员不必担心任何网络编程、数据序列化和表示差异。
简单地说，DDS将数据“分配在你想要的地方，在你想要的时候，在你想要的时候”。使用发布-订阅模型，可以很容易地指定“所在位置”。数据中心性支持“何时”，而qos感知支持“如何”。

更多信息：

杰拉多·帕尔多-卡斯特洛特博士是加利福尼亚州森尼维尔市RTI的OMG和首席技术官数据分发服务机构的联合主席。他是许多DDS专业著作的主要作者。伯特·法拉博和安迪·克拉索夫斯基是RTI的工程工作人员。RTI在其产品线中创建了DDS指定的第一个商业用实现。
本文来源于OMG实时系统的指定数据分发服务，可从www.omg.org免费提供。如果您对本白皮书有任何疑问或意见，请通过info@rti.com联系我们。

附录：
本文件中使用的术语的术语表

Callback Routine：回调例程是一个应用程序提供的函数，由DDS基础设施调用，以便通知应用程序的相关事件。回调通常在DDS基础设施线程的上下文中调用，但也有一些机制，应用程序可以提供执行这些调用的线程池。
Container：是项目的逻辑分组。项目可以是节点、应用程序、发布和订阅。
Entity: DDS中的实体是指构成DDS API基础的一类软件对象。这些对象允许应用程序控制DDS基础设施的操作、加入DDS域、删除正在推送和订阅的内容、访问数据等。主要的DDS实体是：出版商、订阅者、数据编写者、数据阅读器、域参与者和主题。
Infrastructure:一个基础平台接口，所有注册的应用程序都使用一组公共的功能。
Messages (Data Samples):消息（或者在DDS中称为数据示例）是从发布者传递到其预期订阅者的单个信息包。数据样本包含应用程序级的数据，以及关于数据的信息（例如，时间戳、序列号、发送者的标识等）。
Nodes：节点是一个连接到形成网络的其他节点的计算机元素。通常，节点是分布式的，并通过传输方式相互通信，例如以太网。
Processes：进程是指由在同一个地址空间中运行的一个或多个执行线程组成的计算机程序，以执行某种功能。
RTOS：实时操作系统（RTOS）是一种提供确定性时间和资源使用行为的操作系统，这样应用程序能够更好地预测它们的定时行为，并始终满足实时约束。
Socket：套接字是由操作系统提供的一种典型机制，可用于在可能驻留在相同或不同节点中的进程之间进行通信。
Topic：DDS中的一个主题是数据生产者与消费者配对的方法。在共享数据空间中，主题将通过其字符串名称取消主题。在本地，每个应用程序通过提供主题名称和它们打算使用的主题的数据类型来消除它使用的主题。不同应用程序用于进行主题通信的数据类型不一定是完全相同。这些类型很适合于兼容。这允许应用程序在不破坏互操作性的情况下发展和修改数据类型。
关于RTI
RTI是全球最大的自主系统软件框架公司。RTI Connext®是世界领先的开发智能分布式系统的架构。独特的是，Connext直接共享数据，将人工智能算法与实时设备网络连接起来，以建立自主系统。
RTI是确保客户成功部署生产系统方面的最好选择。RTI软件有超过1800种设计，运行超过250个自动驾驶汽车项目，控制北美最大的发电厂，协调美国海军舰艇的战斗管理，驱动新一代医疗机器人，支持飞行汽车，并为医院和紧急医疗提供24/7的情报。RTI运行着一个更聪明的世界。
RTI是符合对象管理组®（OMG®）数据分发服务（DDS™）标准的产品的领先供应商。RTI是一家私人控股公司，总部位于加利福尼亚州的森尼维尔，总部位于科罗拉多州、西班牙和新加坡。