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
内建主题
主题名
|
描述
|
DCPSParticipant
|
域参与者
|
DCPSTopic
|
主题
|
DCPSPublication
|
数据写者
|
DCPSSubscription
|
数据读者
|
QoS策略
DDS规范定义了许多QoS策略,以便应用程序来指定自己的服务质量要求。参与者指定它们需要的行为,然后服务决定如何实现这些行为。这些策略被应用于所有DCPS实体(包括主题、数据写者、数据读者、发布者、订阅者、域参与者等),但不是所有的策略都适用于所有的实体类型。
发布者和订阅者通过请求-提供(RxO)模式相匹配。订阅者请求一组最低程度的策略,发布者向潜在的订阅者提供一组策略。然后DDS实现试图将请求的策略和提供的策略相匹配,如果策略兼容,就形成关联。
QoS策略的具体内容将在后续章节进行详细介绍。
监听者
DCPS层为每个实体定义了一个回调接口,以方便应用程序监听实体的状态改变或者有关的事件。例如,当有数据可读的时候,数据读者监听者就发出通知。
条件
DDS中的条件和等待集为监听者检测感兴趣的事件提供了选择,一般模式是:
1、应用程序创建一个特定的约束条件,如状态条件,并将其绑定到一个等待集上;
2、应用程序在等待集上等待,直到约束条件为真;
3、应用程序使用等待的结果开始获取它期待的信息;
4、数据读者接口也提供了带有读取条件参数的接口;
5、提供了查询条件,以作为内容订阅配置文件实现的一部分。查询条件接口扩展了读条件接口。
加载中,请稍候......