数据分发服务

数据交互服务

 对分布式实时应用程序而言，以数据为中心的需求要比以服务为中心的需求多，这意味着在分布式系统中参与者的主要目标是传播应用程序数据而不是共享服务。应用程序的供应者和消费者的数据类型可以在设计时就知道，也可能在应用程序执行期间被改变。以数据为中心的共享模式有效地实现了发布/订阅通信模型，这种模式有别于请求/响应通信模型。

 OMG实时系统的数据分发服务（DataDistribution Service（DDS）for Real-TimeSystems）与以数据为中心的分布式应用程序的性能要求和硬实时要求相适应。

 DDS允许参与通信的末端节点相互分离，因此节点能够动态地加入和离开分布式应用。DDS以数据为中心，所有的服务质量（QoS）参数在每一个末端节点的基础上都可以改在末端的可配置性是支持复杂数据通信模型的关键。

 简而言之，DDS就是按“哪里需要，何时需要”来分发数据。发布/订阅模型使变得容易，以数据为中心则解决的问题。

 随着Internet技术的广泛应用和计算机技术的飞速发展，各种应用系统的体系结构呈现出以网络为中心的趋势，这对通信的实时性、动态灵活性提出了更高的要求，同时要求分布式系统的各参与者之间采用一种具有松散耦合特性和通信服务质量保障策略支持的灵活通信模型和交互机制。

 DDS在处理复杂的数据流方面做得很优秀，通过对服务质量策略的控制，可以把对更新速率、可靠性和带宽控制有不同要求的模块很好地集成到同一个系统中。DDS能很好地处理不同种类的数据传输，可包括快速连接的节点、慢速连接的节点以及间歇性的连接（例如无线连接），这对于构建综合性系统无疑是一个有利条件。

 在基于信息系统的体系作战中，体系要处理各种复杂的数据流，这些数据流来自不同的传感器和终端，例如战场通信系统、舰船控制系统和航天测控系统等领域，这些复杂的数据流既有传统的应用模式，也有企业级应用模式，还有实时应用、嵌入式应用当前较为流行的实时CORBA技术，由于它是以对象和服务为中心，采用了C/S通信模式通信机制较为复杂，数据收发需要建立连接的过程，不能完全满足系统对实时性能的需要并且它没有服务质量策略支持，不能满足通信灵活性要求。Java消息服务JMS包含点对点和发布/订阅两种消息模型，提供可靠消息传输、事务和消息过滤等机制，适合大规模以数据为中心的网络，但是它缺乏应用级服务质量策略支持，仍然不适合处理复杂的数据流，因此急需一种能为实时系统应用开发者提供高级抽象接口的同时还能有效合理地控制部署实时系统所需的服务质量策略来满足分布式实时应用需求的网络中间件。

 

复杂数据流示意图

  数据分发服务是一个用于实时分布式应用程序的网络中间件，它提供了程序员在嵌入式或企业设备或者节点之间分发时间关键数据时所需的通信服务。DDS使用发布/订阅通信模型，使数据分发变得有效和稳健。很多分布式应用现在就有，其更多的应用在未来。所有的分布式应用有一个共同条件，即必须在不同的执行线程之间传递数据。这些线程有可能在同一个处理器中，也可能散布在交叉的不同节点上。相应地，开发者必须设置多个节点，每一个节点上有多条线程或进程。这些节点或进程的联系是靠一种传输机制运行的，例如以太网、共享内存、虚拟机总线基架或无线网络。节点之间的标准化通信路线通常用TCP/IP这类基础协议或HTTP这类较高级的协议。共享内存访问典型的用法是用于同一个节点的进程运行，它也可用于无论何处的公共存储器访问。

 下图所示的是一个简单的分布式应用的例子：一个单片机连接了一个温度传感器电路和以太网，传感器以一个确定的频率采集温度数据。图中的网络中还连接了一个工作站它是用来给操作员显示数据的。DDS的实时系统数据分发服务机制使这种数据通信路径更便利。

 使用数据分发服务，系统设计员和程序员从灵活的通信基础设施开始，可在广泛的计算机硬件、操作系统、语言和网络传输协议条件下工作。DDS是高度可配置的中间件，这样程序员能够调整它，使其满足应用程序的特定的通信要求。

简单的分布式应用

 中间件是位于应用程序和操作系统之间的一个软件层。网络中间件将应用程序从基计算机架构、操作系统和网络堆栈（如图1-6所示）的细节中隔离开。网络中间件通过允应用程序发送和接收信息，简化了分布式系统的开发程序，无须使用低层协议编程（如SOCKET或TCP/IP）。

DDS是基于发布/订阅模式的通信模型。发布/订阅中间件提供一种简单、直观的方式分发数据，它将创建和发送数据（数据发布者Publisher）的软件与接收和使用数据（数据订者Subscriber）的软件分离开。Publisher简单声明其发送意图并发布数据。Subscriber声明其接收意图，然后中间件自动传送数据。

除了模型的简便性，发布/订阅中间件可以处理复杂的信息流模式。发布/订阅中间件的使用将实现更简单、更模块化的分布式应用程序。更重要的是，发布/订阅中间件可以自动处理所有的网络琐事，包括连接、失败和网络变化，这消除了用户应用程序为那些特殊情况进行编程的需要。经验丰富的网络中间件开发人员都知道，处理这些特殊需求要花费80%的精力和代码。

网络中间件

位于网络中间件底层的通信模型是应用程序如何通信的最重要的因素。通信型影响性能，完成不同通信传输的易用性、检测错误的能力、不同错误条件下的健壮性。不幸的是，没有“一刀切”的做法来处理分布式应用程序。不同的通信模型适合不同类别的应用领域下面简要描述3个主要的网络通信模型：

• 点对点模型；
• 客户端/服务器模型；
• 发布/订阅模型。

点对点模型。点对点是通信模型中最简单的形式，如图1-7所示。电话是日常生活中点对点通信模式的一个例。如果要使用电话，用户必须知道对方的地址（电话号码），旦连接建立，用户可以享用高带宽对话。然而，当用户必须多人同时对话时，电话无法工作电话实际上是一对一的通信。

TCP是20世纪70年代设计的一种点对点网络协议。TCP提供了可靠的高带宽通信但它难以应对拥有多个通信节点的系统。

客户端/服务器模型。为了解决点对点模型的可扩展性问题，开发者转向了客户端/服务器模型。客户端/服务器通信模式指定一个特殊的服务器节点，它可以同时连接多个客户端节点，如图所示。客户端/服务器是一个“多对一”的架构。通过电话订购比萨，是一个客户端/服务器模型的通信例。客户端必须知道比萨店的电话号码并下订单。比萨店可以处理多个订单，而不必提前知道客户端的位置。下订单之后（请求），比萨店询问客户端（比萨）应发送至何处。在客户端/服务器模型中，每个响应绑定一个事先请求。结果是，该响应可适合每个请求。换句话说，每个客户端发出请求（订单），而每个回复（比萨）用于一个特定的客户端。

点对点模型

 

客户端-服务器模型

当信息集中的时候，例如数据库、事务处理系统和文件服务器，客户端/服务器网络架构的效果最好。然而，如果多个节点生成信息，客户端/服务器架构要求所有信息发送到服务器，随后再分发到各客户端。这种方法低效，并排除确定性通信，因为客户端并不知道新信息在服务器上何时可用，而且当客户端请求和接收数据时，它为系统埋下了不确定的种子。

发布/订阅模型。发布/订阅应用程序是一种典型的分布式应用程序，它们之间通过终端节点匿名发送（发布）和接收（订阅）数据，如下图所示。通常，若发布者要与订阅者建立通信，只需知道数据的名称和定义就可以了。发布者和订阅者都无须知道对方的其他信息。只要相关的应用程序知道它正在传输何种数据就能够通过发布/订阅模式将数据传递至恰当的节点，并且不用单独建立连接。发布者负责收集恰当的数据并将数据发送至所有注册的订阅者。订阅者负责从发布者那里接收恰当的数据并将数据呈现给感兴趣的用户。

在发布/订阅通信模型中，计算机应用程序（节点）“订阅”它们所需要的数据，“发布”它们希望共享的数据。数据在发布者和订阅者之间直接传递，而无须进入中央服务器。多数预期到达很多人的时间敏感信息是通过发布/订阅系统发送的。发布/订阅系统在日常生活中的例包括电视、杂志和报纸。

发布/订阅通信架构对分发大批时间敏感信息时非常有效，甚至可用于不可靠传送机制。这种各节点间直接和同时的通信使得发布/订阅网络架构成为拥有复杂时间关键数据流的系统的最佳选择。

发布/订阅模型提供了以下拥有诸多优势的系统架构，但它并非所有通信类型的最佳选择。

 发布-订阅模型

 在以数据为中心的通信中，通信应用程序间数据的分发是重点。以数据为中心的系统由数据发布者和订阅者组成。通信基于已命名的数据流，流从Publisher向Subscriber传送已知类型的数据。

 相反，在以对象为中心的通信中，基本概念是应用程序间的接口。接口由一组已知类型方法（方法参数的数量和类型）组成。以对象为中心的系统由接口服务器和接口客户端组成，通信则基于客户端在对应服务器所服务的命名接口上调用方法。

 以数据为中心和以对象为中心的通信方式是分布式系统中互补的两种模式。应用程序可能要求后者，然而，实时通信通常更适合以数据为中心的模式。以数据为中心的通信能够指定各种参数，例如发布速率、订阅速率、数据有效长度等参数。这些服务质量（QoS）参数有助于系统设计者根据数据指定段的要求和有效性构建分布式应用程序。以数据为中心的环境能够使用户根据分布式应用的指定需求定制通信机制。“发布/订阅”这种通信机制已经成为一种专有的解决方案，DDS通过提供标准化的接口使数据为中心的发布/订阅通信规范定形。

 如下图所示，嵌入式单片机和工作站都可以用DDS作为它们的软件模块。在嵌入式单片机上，DDS提供给温度传感器详细的QoS参数；在工作站上，DDS允许订阅根据指定QoS 参数生成的温度传感器数据。

 以数据为中心的应用在作战信息系统中的优势更为明显。这里以高速雷达为例,它需要向许多不同的订阅者发布雷达轨迹,为了能够追踪来袭的导弹,它必须向武器系统发送每秒2000多次的更新。对于这个订阅者来说,它需要最新的数据,因此如果由于传输错误造成样本丢失,不要浪费时间重发旧的数据。与此同时,日志系统需要雷达提供一切追踪数据以备以后分析,这些数据可能还需要多播到50个显控屏幕上,但这些控制屏每秒钟只能采样10个样本。每个屏幕可进一步选择其感兴趣的区域,例如只显示5英里范围内、朝我方行进并且已经确认为敌方的雷达轨迹。

 DDS可以在同一时间内处理上述的所有情况,且这只是一小部分。因为中间件帮用户解决了所有这些问题,应用程序只需要集中在逻辑和处理部分,大大减少了系统设计的工作量,而且中间件在处理这些问题时不会影响应用程序。用户可以想象这对应用开发和集成起到了多大的简化作用。现在,假如这一切都正常运行,然后需要添加一个新功能。例如我们需要用雷达来协调本地区的航空交通。由于每个功能都有清晰的定义,我们不需要改变任何原有的应用,新的应用程序只是插入“数据总线”便能开始工作。

 当然,这些功能的前提是不受加载中间件的影响。DDS对系统的影响各有不同,但那些设置了点对点对等可靠多播的用户很少会受到较高负载的影响。如果使用得当,DDS比其他中间件的速度要快得多。除此之外,QoS策略还增加了故障检测层。如果新的负荷引起超载,中间件将立即通知其他应用程序：它们的合约出现了问题。这有助于在早期发现设计问题,尤其是在系统测试中。不仅如此,它也允许运行中的系统在发生上述情况时采取有效的补救行动。

 DDS利用API发送和接收数据,它使开发者们摆脱了网络编程的烦恼。依靠控制数据传输的规范,分布式应用程序的开发者可以专注于具体应用程序的操作,而不用考虑这些程序在环境中如何与其他应用程序通信。一些收集或产生数据（通过接口连接传感器、文件机载数据计算等）的应用程序,都可以利用 DDS框架发送（发布）自己的数据。类似地,那些需要在分布式环境中获取数据的应用程序也可以利用DDS框架接收（订阅）特定的数据DDS控制着发布者和订阅者之间所有的通信。

 通过“发布/订阅”方式,DDS在数据发送者和接收者之间建立了抽象的通信。数据发布者无须知道每一位接收者,它们只需知道所传输的具体数据类型。这对订阅者同样适用,订阅者无须知道发布的数据是从哪里来的,只需知道自己具体想接收什么类型的数据即可。在下图中,嵌入式单片机将当前的温度传感器数据作为一个参数调用,并用一个简单的“写人”发布数据包。在工作站上,应用程序要么等待数据变为可用,要么创建一个回叫程序（callbackroutine）直接接收数据。一旦数据可用,工作站应用程序可从DDS中间件中提取。

 简单的分布式应用

 

DDS支持超出了基于发布/订阅模型的机制,主要好处是通信中使用DDS的应用程序完全是可区分的,处理它们相互的交互仅花费极少的设计时间。特别是,应用程序无须关心其他参与应用程序的信息（包括其存在或位置）。DDS自动处理数据发送的各个方面,无须用户应用程序的任何介人，

 

DDS允许用户将服务质量（QoS）参数作为配置选项,具有自动发现机制和方式,能够指定发送和接收数据时所用的行为。该机制提前配置,在用户方无须更多工作。通过用完全匿名的方式交换消息,DDS极大地简化了分布式应用程序设计,并鼓励了模块化、结构合理的方案。

 

另外,DDS包括下列特征,它们用于满足分布式实时应用程序的要求。

 

1） 以数据为中心的发布/订阅通信。简化了分布式应用程序编程,并为时间关键数据流提供了最小开销。

 

• 为管理相同数据的多个来源清除语义分歧。
• 高效数据传输、定制的服务质量和错误通知。
• 使用Subscriber设置的最大速率,保证定期获取数据样本，
• 数据到达时,回调例程通知的开销最小化。
• 当数据在预期截止期限内未到达时发出通知。
• 有效地向多个计算机发送相同数据的能力。

 

2） 用户定义的数据类型。使用户能够调整发送至各应用程序的数据的格式

 

3） 可靠的数据传递。使订阅应用程序能够指定样本的可靠传送。

 

4） 多种通信网络。使用DDS的多个独立通信网络（领域）可被用于相同的物理网络应用程序仅能参与其所属领域,单独的应用程序可被配置为参与多个领域。

 

5） 对称架构。使用户应用程序强健：

 

• 没有中央服务器和特权节点，这样系统更加稳健。
• 系统可以在任意时间动态添加或移除订阅和发布。

 

6） 可拔插的传输框架。包括确定新传输插件和运行它们的能力。DDS支持标准UDP/IP可插拔传输和共享内存传输。它可被配置为在多种传输机制下操作,包括底层传输协议、交换结构和新网络技术。

 

7） 多个内置传输。包括UPD/IP 和共享内存传输。

 

8） 多语言支持。包括用于C、C++、C++/CLI、C#和 Java 编程语言的 API。

 

9） 多平台支持。包括支持UNIX（Linux和Solaris）、实时操作系统（INTEGRITYVxWorks、QNX和LynxOS）和 Windows（2000、2003、CE、Vista 和 XP）。

 

10） 符合标准。

 

• API符合OMG的DDS规范中的DCPS层。
• 数据类型符合OMG接口定义语言（IDL）
• 数据包格式符合国际工程协会针对RTPS有线协议的公用规范。

设计原则

 

DDS最主要的优点是可以在原来系统中“插入”新的应用而无须重新设计其他接口,这看起来虽然简单,但是做到这一点却很困难。拥有一个可插入的接口需要假定“总线”能够捕获全部关键的实时性要求,例如数据是何种类型?何时能够获取?何时发出?如果不能及时得到将会发生什么?数据是否已经备份?这些数据如何接入?而且这还基于一个假设,即使增加更多的负载也不会影响整个系统的性能,如果能做到这样,应用之间不再直接关联。这便是一个隐含的松耦合系统。

从更高层面看,DDS的数据总线参与者只需订阅它们需要的信息,并发布它们产生的信息。在这里,信息也称为“主题”,具有安全性以及容易集成的特点。中间件自动“发现”新的加人者,它们之间的数据通信在信息流开始之前就已完成,所有的应用都知道它们将获取什么（被称为“内容预知”）。由于数据流无须经过服务器或同步等延迟,该系统能够满足快速和实时性的要求。DDS无疑是性能最高的中间件。

 

DDS成功的关键在于它定义了清晰的信息模型。如果你定义的信息模型正确,那么各个应用在设计时就可以明确它们的需要。在运行时,它们又通过发布/订阅模式的中间件实现。这些模块并不直接相互依赖,这是避免耦合的关键。这些应用通常采用自适应模式其他信息技术（例如JMS）不能做到这一点,因为它们无法定义类似的信息模型。

 

DDS启用了 20多个“服务质量（QoS）”策略来定义信息模型。QoS策略设置了信息发布者是否能提供可靠的信息流、发布数据的速度有多快、希望何时发现数据。各个应用可以通过QoS明确其需求,甚至可以做到通过时间或信息的内容来筛选更新信息。中间件还能“听到新加入者的需求,并决定发布者是否能满足这些需求。如果可以,中间件会在发布者和应用之间建立“合约”,并开始发送数据。如果不可以,它会报告发生了一个错误。例如,一个合约可以是这样的：发布者将以毫秒级的速度更新订阅者,而且是可靠的通信方式,如果传输发生错误请重新发送,一旦发布者失败,就可以切换到备份数据。这只是其中的一个例子,实际上，DDS的QoS策略可以集成数以百计的复杂且苛刻的应用。由于中间件能够做出快速反应,使得通过这样的设置来满足苛刻的实时系统成为可能。实际应用的DDS系统在数以百万对订阅和发布者之间每秒钟发送数百万的消息,而延迟仅有几十微秒。设计人员可以提出时间要求,以支持有明确发送需求的程序。可靠的多播模式可确保新的“外挂程式”不对程序造成负担。它还具有很好的排列功能,可以部署在多达1000台计算机的系统里。DDS尤其适用于对不间断、可靠性有很高要求的应用中,类似作战管理系统或电网管理系统等应用。

 

 传输框架

 

DDS使用规范的IDL接口初始化和控制服务。数据传输是通过DDS特定的传输框架实现的,该框架允许服务得到大量传输协议的使用。这指的是可插拔传输,它使DDS的扩展性成为其架构的一个重要部分。DDS目前支持TCP/IP、UDP/IP、IP多路、共享内存和如下图所示的RTPSUDP传输协议。传输通常通过配置文件规定,并附属于发布者和订阅者程序中的多个实体。

 

 DDS可扩展传输框架

 

DDS利用一个可插拔的传输结构,允许数据通过应用程序开发者选择的传输方式和列集的实现来传输。从概念上讲,该构架借助于TAO的可插拔协议框架。DDS当前支持TCP和UDP点到点传输,也就是不可靠和可靠多播,使用高性能列集实现。这个可拔插的传输结构允许DDS用户根据应用程序部署所需传输同质或者异质来优化DDS安装。这些选择可以被提取且不影响应用程序代码本身，如下图所示。

 

DDS可插拔结构

 

列集代码由指定的DDS的IDL编译器产生。单个的独立的DCPS信息库（DCPSInfoRepo）担任一个中心信息交易所,联合发布者和订阅者。在幕后DDS用CORBA与DCPSInfoRepo进程联合发布者和订阅者进行通信。发布者与订阅者的数据传输直接在发布进程和订阅进程之间进行。在发布或者接收DDS数据时,DDS创建自己的线程用于RB 和非 CORBA I/O。

 

OMG数据分发服务规范分成两个独立的架构层。低层是以数据为中心的发布/订阅层,发布/订阅通信机制包含了类型安全接口。高层是数据本地重构层（DLRL）,它允许应用程序开发者在DCPS层上面构建一个本地对象模型，在应用程序中屏蔽了DCPS知识。每一层都有其自己的一套概念和使用模式,从而可以分开讨论概念和术语。

 

发布订阅

 

 

 以数据为中心的发布/订阅（DCPS）是OMGDDS标准的一部分,它处理以数据为中心的发布/订阅通信。DCPS层负责有效地将数据从发布者传送到感兴趣的订阅者,它实现了在发送端的发布者和数据写入器,在接收端的订阅者和数据读出器的概念。DCPS层由一个或者多个数据域组成,每个域包含一套参与者（发布者和订阅者）,它使用DDS通信。每个实体（例如发布者或订阅者）属于某个域,每个进程有一个域参与者,分别为数据域的一个成员,如下图所示。

 

域与域参与者示意图

 

在数据域内,主题标识数据,这是一种特定的域段,它允许发布者和订阅者明确地引用数据。在一个域内,主题有一个唯一的主题名称、数据类型和一套QoS策略。同一数据类型可以发布多个主题,但每个主题只关联一种数据类型。关联在发布者,数据写人器,每种特定数据源的主题决定了发布者的行为。同样,关联在订阅者,数据读出器,每种特定接收数据的主题决定了订阅者的行为。

 

DDS规范定义了很多服务质量（QoS）策略,应用程序用来指定它们的可靠性、资源使用、容错和其他要求的服务。参与者指定来源于服务的行为,服务决定如何实现这些行为。这些策略可以被用于多种 DCPS实体（主题、数据写入器,数据读出器、发布者、订阅者和域参与者）但是不是所有的QoS策略都适合各种类型的实体。

 

发布者和订阅者协作通过提供请求范例来指定QoS策略。发布者提供一套QoS策略给所有的订阅者,订阅者请求一套它需要的QoS策略。DDS实现这些机制并尽量使请求的策略与提供的策略相配。如果策略相容,那么发布与订阅相配。DDS支持全套的DCPS质量服务（QoS）,如下图所示。

 

 QoS策略