1  引言

分布式计算是指各种不同的工作站通过网络互相连接，由分布式系统提供跨越网络透明地访问各种异构设备所需要的支持，使得用户可以充分利用网络上的各种计算资源来完成自己的任务[1]。与网络技术的发展和日益增长的应用需求相适应，分布式计算已经成为新一代计算和应用的主流。分布式计算中所涉及的分布式系统是指组件分布在网络计算机上且通过消息传递进行通信和动作协调的系统[2]。分布式系统具有以下特征：组件的并发性、缺乏全局时钟、组件故障的独立性。构造分布式系统的挑战主要是其组件的异构性、开放性（指允许增加或替换组件）、安全性、可伸缩性（指用户数量增加时能正常运行的能力）、故障处理以及组件的并发性和透明性。构造和使用分布式系统的主要动力来源是资源共享，因此分布式系统之间的通信和集成技术一直是关注的重点。

中间件是指一个软件层，它提供了一个编程抽象以及对底层网络、硬件、操作系统和编程语言异构性的屏蔽，同时还为服务器和分布式应用的编程人员提供了一致的计算模型。中间件能够很好的完成异构分布系统的集成，互操作，并且能够很好地保证这些系统的可移植特性，因而极大地降低了开发分布式应用的周期，能够提高系统的可靠性，是当前分布式应用开发和分布式系统集成的主要手段。

本文对分布式企业应用和分布式实时应用的集成技术进行了简要介绍。

2  分布式企业应用集成技术

企业自上世纪七十年代开始使用IT支持系统至今，一些大型企业中各种IT支持系统平均达数十种之多。它们大部分是一个个的信息孤岛，管理着企业特定的各个职能部门的工作，相互之间缺乏有效的通信。随着信息技术的不断发展，今天的企业需要一个集成的、开放的、面向用户且随需而变的IT支持系统，因此面临着应用系统的整合问题。不同的应用（尤其是不同企业的）的开发语言不同，部署平台不同，通信协议不同，对外交换的数据格式也存在着差异，如何去解决解决语言差异、平台差异、协议差异、数据差异所带来的高代价的系统集成是这个问题的关键。

企业应用集成（Enterprise Application Integration，EAI）将企业中的业务流程、应用系统、硬件和各种标准联合起来，在两个或更多的企业应用系统之间实现无缝集成，是它们像一个整体一样进行业务处理和信息共享。企业应用集成不仅包括企业内部的应用系统集成，还包括企业与企业之间的集成，以实现企业与企业之间的信息交换、商务协同、过程集成和组建虚拟企业和动态联盟等。目前，常用的企业应用集成技术有远程过程调用技术、分布式对象技术、面向消息的中间件技术和Web服务技术。

2.1 远程过程调用技术

最早提出远程过程调用的是美国Birrell和NelSon，其后在Xerox工作站上实现，它非常类似于在单机编程过程中经常使用的过程调用（Procedure Call）。在分布式环境下，远程过程调用允许本地计算机上的程序调用远程计算机上的进程。远程过程调用允许发送一个请求（客户进程）到远地进程即被调用者，被调用者或服务器进程执行这个过程并发回一个结果（响应）消息。该方法最主要的特点是程序不需要知道调用的过程是本地还是远地。远程过程调用和传统的过程调用不同就在于调用者（Caller或Client）和被调用的进程（Server）是在不同的机器上的不同的进程。

1987年，Sun Microsystem公司开发了开放式网络计算（ONC）RPC系统，作为它的网络文件系统（NFS）的基本通信机制；同年，Apollo Computer公司为其操作系统开发了网络计算系统（NCS）的RPC系统。在1989年，开放式软件基础设施（OSF）组织为RPC系统发出了技术请求（RFT），并收到了两个主要提案：一个来自HP/DEC，基于NCS；另一个来自Sun，基于ONC。最终，OSF选择NCS作为其分步式计算环境（DCE）的RPC机制。1990年，Microsoft基于DCE/RPC的修订版开发了RPC机制，使得RPC技术得到了更广泛的应用。

远程过程调用的灵活性体现在它的跨平台性上，它不仅远端的子程序，而且这种调用是可以跨越不同操作系统平台的。而远程过程调用的缺点在于其采用了同步通信方式，适合于小型的简单应用。对于一些大型的应用，需要支持多种通信模式时，远程过程调用就不太适合。

2.2 分布式对象技术

二十世纪九十年代，随着面向对象技术的广泛应用和和分布式系统成为计算机系统和应用的主流技术，出现了分布式对象技术。分布式对象技术是面向对象技术和分布式技术的结合，其提供了一种通讯机制，透明地在异构的分布式计算环境中传递对象请求，而这些对象可以位于本地或远程机器。主流的分布式对象技术有以下三种：

l  对象管理组织（Object Management Group, OMG）制定的CORBA（Common Object Request Broker Architecture，通用对象请求代理架构）技术。

l  Microsoft公司提出的DCOM（Distributed Component Object Mode，分布式组件对象模型）技术。

l  Sun公司提出的RMI（Remote Method Invocation，远程方法调用）技术。

CORBA是OMG专门为异构平台上不同语言开发的分布式对象进行互操作而制定的规范。OMG组织是一个国际性的非盈利组织，成立于1989年，致力于面向对象软件开发的实践与理论，制定工业指南和对象管理规范，加快对象技术的发展。其目标是为应用开发提供一个公共框架，使得基于对象的软件在分布异构环境下具有良好的可重用性、可移植性和互操作性，从而能够在由多种操作系统构成的异构分布环境中，方便的建立异构分布式应用系统，或实现企业信息资源的集成。为实现上述目标，OMG组织成立后不久就制定了OMA（Object Management Architecture，对象管理体系结构）参考模型，其主要包含四个部分：应用对象（Application Object）、对象服务（Object Service）、公共设施（Common Facilities）和对象请求代理（Object Request Broker）。针对OMA中的核心部分ORB，OMG组织制定了CORBA规范。CORBA规范屏蔽了底层硬件、操作系统和网络协议的不同，使开发者能够将精力集中到应用逻辑上，而不需考虑复杂的异构环境通信问题。1991年，CORBA1.1规范正式提出，定义了IDL接口语言和ORB对象请求代理中间件。1995年，OMG发布CORBA 2.0，提出了IIOP（Internet Inter Object Protocol），用以规范不同厂家的ORB之间的互联互通。自此，CORBA逐渐成型，2002年，OMG组织正式发布了CORBA3.0规范。

CORBA规范给出了ORB的基本结构及其各部分的功能描述，包括：界面定义语言（IDL）、静态调用界面（IDL Stub）、ORB界面、动态调用界面（DII）、静态框架界面（SS）、动态框架界面（DSI）、对象适配器（OA）、界面库、对象实现库和ORB间的互操作协议IIOP，其关系如下图所示。

图1. CORBA ORB的结构

对象的界面通过IDL定义，独立于对象的实现。IDL编译器将对象的IDL文件编译成客户端的存根（Stubs）和服务器端的框架（Skeleton）。客户端根据IDL Stubs使用静态方式调用对象服务；或根据界面库中得IDL描述信息采用动态调用方式搜索可用的服务，找到这些服务的界面并构造使用这些服务的请求。对象实现在执行客户请求时，通过对象适配器获取ORB的服务。对象适配器是对象访问ORB服务的主要通道，拓为实例化的对象服务提供运行环境，接收客户请求并传送给服务对象。此外，对象适配器还负责为服务对象分配对象ID，以及将对象类和实例化对象注册到对象实现库中。对象实现库包含了允许ORB查找和调用对象实现的相关信息，是ORB进行对象匹配的场所。CORBA自发布以来，已经有很多实现。目前市场上流行的产品有：IONA公司的Orbix，Inprise/Borland公司的VisiBroker等。

DCOM是由Microsoft于1996年提出的分布式对象构件标准，旨在提高应用软件的互操作能力。COM（Component Object Model，组件对象模型）技术使得程序的各个组件之间可以用一种统一的方式进行交互，而DCOM实际上是COM技术在分布式环境中的扩展，它建立在DEC（分布式计算环境）的RPC规范之上，可以实现在两台不同的计算机之间调用COM对象，对象间的通信通过网络来传输。DCOM屏蔽了COM对象的位置差异，使用户不需知道COM对象的实际位置，就可以使用该COM对象。

图2. DCOM整体结构图

DCOM的整体结构如上图所示。DCOM利用RPC提供分布功能，当客户进程调用接口上的方法时，DCOM将方法调用转换为RPC调用。RPC机制自动完成数据的包装和解包、数据格式的转换、建立网络会话和处理网络调用。可以说DCOM提供了一种面向对象的RPC机制。

RMI是Sun公司于1997年所提出的分布式计算模型，用以解决访问Java分布式对象的通信问题。Java是一个提供了可移植的面向对象编程语言和高性能的Java虚拟机组成的应用系统运行和开发平台。RMI能够支持一台Java虚拟机（JVM）上的对象与另一台Java虚拟机（JVM）上的对象进行通信。RMI的架构如下图所示，包含三层：桩/骨架层、远程调用层、传输层。

图3. RMI结构图

其中，Stub/Skeleton Layer监听客户端产生的远程方法调用，将这些调用转换为服务器端的远程RMI服务。Remote Reference Layer负责解释与管理客户对服务器上远程对象的引用。Transport Layer为服务器端RPL与客户端RPL建立连接。由于Java的天生跨平台优势，RMI的跨平台能力很强，但它只是Java体系的一部分，对纯Java应用的集成能力很强，并没有跨语言的互操作能力。而企业在信息化过程中，存在大量非Java开发的遗留系统或采用其它技术开发的独立系统，这样就大大增加了RMI在企业信息资源集成中的成本。

分布式对象技术能在一定程度上解决分布式系统的通信和集成问题，但是存在着一些问题，如交互双方以紧耦合的同步通信方式绑定，基于二进制通信协议，并采用跨逻辑层的紧密集成，容易导致可伸缩性问题。另外RMI和DCOM技术限于特定平台，不能实现异构系统之间的集成，CORBA技术实现复杂，投入高。为了解决分布式系统之间集成的紧耦合问题，产生了面向消息的中间件技术。

2.3 面向消息的中间件技术

面向消息的中间件（Message-Oriented Middleware，MOM），提供了以松散耦合的灵活方式集成应用程序的一种机制。它们提供了基于存储和转发的应用程序之间的异步数据发送，即应用程序彼此不直接通信，而是与作为中介的MOM通信。MOM提供了有保证的消息发送，应用程序开发人员无需了解远程过程调用（RPC）和网络/通信协议的细节。面向消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

传统的面向消息中间件通常采用点对点的消息传输结构，通常由消息队列服务、消息传递服务、消息队列和消息应用程序接口API组成，其典型的结构如图4所示。其基本工作原理为：在消息发送方，消息发送者调用发送消息的API函数，将需要发送的消息经消息队列服务存储到发送消息队列中；通过双方消息传递服务之间的交互，经消息队列服务将需要发送的消息从发送队列取出，并送到接收方；接收方再经它的消息队列服务将接收到的消息存放到它的接收消息队列中；在消息接收方，消息接收者调用接收消息的API函数，同样经过消息队列服务，将需要的消息从接收队列中取出，并进行处理。消息在发送或接收成功后，消息队列服务将对相应的消息队列进行管理[3]。

图4. 点对点消息传递模型

在这种交互方式中，发送方对消息进行打包时需要显明地标注接收方的地址。因此，尽管消息的接收方和发送方是松耦合连接的，相互通信不必保持同步，但由于在消息中必须绑定接收方地址，导致在广域、大型应用系统中使用消息中间件不够灵活，系统扩展比较困难。为了增加消息发送方和接收方之间对地址的透明性，1990年代末期以后，消息中间件开始向发布/订阅架构转变，并成为企业应用集成中间件的一种核心机制，而基于发布/订阅架构的消息中间件通常称为发布/订阅消息中间件（Publish/Subscribe Middleware，简称P/S MOM）或消息代理（Message Broker），以与传统的消息中间件相区别。

在基于消息代理的分布式应用系统中，消息的发送方称为发布者，消息的接收方称为订阅者，发布/订阅模型用称为主题的内容分层结构代替了点对点模型中的惟一目的地，不同的消息通过不同的主题进行区分。发布者向消息代理发布其它应用系统感兴趣的消息，而订阅者从消息代理接收自己感兴趣的消息，发布者和订阅者之间通过消息代理进行关联。消息代理的基本结构如图5所示

图5. 发布/订阅消息传递模型

消息代理具有很好的灵活性和可扩展性，并支持主动、实时的信息传递方式，当消息发布者有动态更新的数据产生时，消息代理会通过事件的发布主动通知消息订阅者存在新的数据可用，而无需消息订阅者进行频度无法确定的查询。消息代理适合于具有实时性、异步性、异构性、动态性和松耦合的应用需求。

由于没有统一的规范和标准，基于消息中间件的应用不可移植，不同的消息中间件也不能互操作，这大大阻碍了消息中间件的发展。JMS(Java Message Service，Java消息服务)是SUN及其伙伴公司提出的旨在统一各种消息中间件系统接口的规范。它定义了一套通用的接口和相关语义，提供了诸如持久、验证和事务的消息服务，它最主要的目的是允许Java应用程序访问现有的消息中间件。JMS规范没有指定在消息节点间所使用的通讯底层协议，来保证应用开发人员不用与其细节打交道，一个特定的JMS实现可能提供基于TCP/IP、HTTP、UDP或者其它的协议。目前许多厂商采用并实现了JMS API，比较流行的JMS商业软件和开源产品包括：IBM公司的MQSeries、BEA公司的WebLogic、Progress公司的SonicMQ、开源产品Apache Active MQ和OpenJMS。这些产品已经广泛地应用在金融、邮电、交通、政府等数据传输频繁、交易量大的行业。

虽然消息中间件能够在客户和服务器之间提供同步和异步的连接，并且在任何时刻都可以将消息进行传送或者存储转发，但是大多数MOM实现方案提供的都是与自己核心设备通信的本地API，影响了应用程序在此类实现方案之间的移植性，从而导致将实现锁定于特定服务器供应商的问题，另外通信的消息是通信双方约定的格式，制定通信协议本身就是一个复杂的过程。

2.4 Web服务技术

Web服务提供了一种在广域网络上共享数据和功能的方法，是分布对象技术的重要补充。Web服务是一种通过URI标识的软件应用，其接口及绑定形式可以通过XML标准定义、描述和检索，Web服务能够通过XML消息及Internet协议完成与其他软件应用的直接交互[4]。它是传统组件技术在互联网应用环境下的延伸，其目的和作用是提供一种统一的规范和技术，为连接异构的企业应用系统提供基础，为互联网软件应用提供统一的功能描述和共享机制，提供一种在不同平台/系统之间进行应用层功能自动整合、自动化处理所需要的技术架构。

Web服务采用一套完全开放且独立于实现平台及程序设计语言的交互机制，形成了较为全面的协议族，其中SOAP、WSDL、UDDI以及上层面向服务组合的WS-BPEL等构成了Web服务协议族的核心。此外，许多WS-*系列规范针对Web服务的各个非功能特性进行定义，如关注Web服务安全的WS-Security系列规范、关注Web服务事务管理的WS-Transaction系列规范等。这些技术规范的逐步完善使得Web服务从众多服务实现中脱颖而出，成为实现服务网格的重要技术基础。

图6. Web服务协议栈

1996年，万维网联盟(W3C)开始从事可扩展标记语言XML的工作。1998年2月10日发布了XML1.0，它是一种开发简单而又可扩展的、结构化和半结构化信息文本表示机制。XML的语言的提出为Web服务相关标准的制订做出了里程碑式的贡献，目前几乎所有的Web服务标准都建立在XML语言的基础上。随后，W3C提出了一系列Web服务相关的重要协议和标准。2000年，W3C组建了XML协议工作组，该工作组提出的简单对象访问协议SOAP（Simple Object Access Propotol）[5]是Web服务通信的事实标准。SOAP支持应用程序与应用程序之间的通信，主要应用于商务对商务的通信以及企业应用集成。SOAP定义了如何通过软件以独立于各种编程语言或平台的方式来构造消息、处理消息，从而使那些用不同编程语言编写的程序之间具有互操作性，并能够在不同的操作系统上运行。Web服务描述语言WSDL（Web Services Description Language）[6]用于描述Web服务的功能调用语法。它将Web Services描述定义为一组服务访问端点，客户端可以通过这些服务访问端点对包含面向文档信息或面向过程调用的服务进行访问(类似远程过程调)。2003年5月结构化信息标准促进组织（OASIS）批准了一项跨网络寻找网络服务的技术，将统一描述、发现和集成协议UDDI2.0[7]版本批准为标准。UDDI 提供了一组基于标准的规范用于描述和发现服务，还提供了一组基于因特网的实现。服务注册中心存储了描述商业或其他实体的信息及其提供的服务的相关技术调用界面(或API)。至此，以上协议的引入和发布奠定了Web服务的基础。

Web服务体系结构基于三种角色（服务提供者、服务消费者和服务注册中心）之间的交互，如下图所示。服务提供者是一个可通过网络寻址的实体，它接受和执行来自服务消费者者的请求。它将自己的服务和接口契约发布到服务注册中心，以便服务消费者可以发现和访问该服务。服务消费者是一个应用程序、一个软件模块或需要一个服务的另一个服务。它发起对注册中心中的服务的查询，通过传输绑定服务，并且执行服务功能。服务消费者根据接口契约来执行服务。服务注册中心是服务发现的支持者。它包含一个可用服务的存储库，并允许感兴趣的服务消费者查找服务提供者接口。面向服务的体系结构中的协作遵循“查找、绑定和调用”范例，其中，服务消费者执行动态服务定位，方法是查询服务注册中心来查找与其标准匹配的服务。如果服务存在，注册中心就给消费者提供接口契约和服务的端点地址。

图7. Web服务中的三种角色

由于Web服务采用基于XML的开放的Web规范技术，具有更好的封装性、高度的可集成性以及更好的开放性与互操作性。相对于COM/DCOM，RMI和CORBA等分布式组件模型，Web服务具有松散耦合性、简单性、高度可集成性和开放标准等特点。通过Web服务能够屏蔽分布式系统间的差异，为跨平台、松耦合、语言无关的网络环境下的资源共享和集成提供了解决方案。

Web服务运行平台为Web服务提供了运行和管理环境，实现了服务部署、执行、管理、监控等功能，使得服务能够遵照标准的服务契约向服务消费者提供业务功能。目前，主流的开源Web服务运行平台包括：Apache的Axis[8]、Axis2[9]和Apache CXF[10]。商业Web服务平台包括IBM 的WebSphere[11]、Microsoft的Windows通信框架（Windows Communication Framework，WCF）、SUN的Sun GlassFish Enterprise Server[12]等。

3  分布式实时应用集成技术

实时（Real Time）计算一般是指这样的计算活动，其正确性不仅依赖于计算的逻辑结果，而且依赖于产生结果的时间[13]。因此，实时计算的核心问题是计算活动的时间可预测性（predictablity）或者时间的确定性（determinism）[14]。时间可预测性指能够预先知道某个任务是否与应用的时间约束相符合的特性[15]。

目前的企业分布式集成技术及中间件能够提供良好的开发平台和通讯支持，但是它们缺乏对分布式实时应用的时间约束的支持能力。尤其随着分布式计算技术和分布式应用的深入发展，一些关键业务领域也都使用分布式技术进行构建。在20世纪九十年代，分布对象(Distributed Object)技术是分布计算领域的主流技术，因此，以分布对象为基础，对象管理组织OMG提出了实时CORBA规范，用于开发分布式实时应用和系统集成。然而，随着分布式系统的广泛应用，各分布节点之间信息交换的需求越来越大，信息交换的质量（可靠性、时间延迟）要求也越来越高。传统的基于C/S架构的分布式软件系统基本上都是以业务流程为中心的，数据参杂在业务流程中，随着业务流程而流动，例如实时CORBA就属于这种架构。这种架构下系统大多采用远程过程调用（RPC）的方式来完成节点之间的信息交互，数据通过函数参数或返回值的形式传送。这样传送的数据量小，效率低，更存在中心服务器瓶颈、单点失效等严重问题，无法满足实时环境下以数据共享和集成为目标的分布式应用需求。OMG针对此需求提出DDS（Data Distribution Service，数据分发服务）规范，DDS采用以数据为中心的发布-订阅模型，实现了分布式异构环境下海量数据的实时传输。以下对这两种分布式实时系统集成技术进行简要分析。

3.1 实时CORBA技术

实时应用需求随着网络应用的普及而日益显得迫切，OMG组织为了促进实时CORBA技术的发展，于1997 年9月提出了实时CORBA 1. 0 的RFP（request for proposal），得到了来自Alcatel、Hewlett2Packard、Lucent、OOC、Sun、Tri-Pacific、Nortel、IONA、Lockheed-Martin和Visigenic等成员独立或者联合提交的实时CORBA规范草案。 最终，于1999年3月，OMG发布了实时CORBA 1. 0规范。实时CORBA 1. 0规范建立在CORBA 2.2规范以及COSS规范的基础上，它本身是对CORBA规范的一个扩展，下图表示了实时CORBA 1.0的体系结构中的实体[16]。

图8. 实时CORBA扩展

实时CORBA规范定义了一组标准的接口以及策略供用户来控制和配置系统的处理器资源、内存资源和通信资源。处理器资源的标准控制机制包括线程池、CORBA优先级、互斥机制和全局调度服务等；内存资源的标准控制机制主要有请求队列等；而通信资源的标准控制机制则有协议特性设置和显式绑定等。线程是实时CORBA系统进行调度的实体，规范中对线程提供了更加丰富的控制和配置方式以支持实时应用；定义了CORBA 优先级，用于确定CORBA对象调用被处理的先后顺序，并定义了优先级映射接口（Priority Mapping），用于CORBA 优先级和本地优先级之间的映射；定义了2 种设置CORBA 优先级的模式：客户传递模式以及服务器指定模式；定义了互斥接口Mutex以协调对系统共享资源的竞争；定义了全局调度服务，应用可以向该调度服务对象指定各种有关参数，例如，周期和执行时间等[16]。与其他CORBA 规范一样，实时CORBA规范只定义了实时CORBA系统的关键部件以及它们提供给用户使用的接口，而对实现没有任何规定。

对实时CORBA 进行研究，并取得代表性研究成果的应用系统是Washington大学计算机系分布对象计算研究组的TAO(The ACE ORB)系统和Rode Island大学计算机系的NraD/URI CORBA系统。TAO系统[17]的研究集中在实时CORBA系统的体系结构和CORBA系统的性能优化策略，并在此基础上实现了高性能的实时CORBA系统。TAO系统的主要组成部件包括：基于ATM 网卡的吉比特输入/输出子系统、实时应用QoS描述方法、实时任务调度服务以及高性能的对象适配器和表示层处理模块等。NraD/URI CORBA系统[18]的目的则是为了支持CORBA 系统动态的端到端时间限制需求。与TAO 系统不同，NraD/URI CORBA系统是通过扩展IONA 公司的CORBA产品Orbix系统实现的，因此，它对通用CORBA系统的修改相对较少。NraD/URI CORBA系统的主要组成部件包括：实时参数描述方法、全局时钟服务和全局优先级服务等。

3.2 数据分发服务技术

在大型网络中心系统中，信息的实时交换最为关键。从多个源产生的信息必须由信息制造者按QoS要求将信息请求者感兴趣的信息进行分发。特别是在实时和关键性任务系统中，“在正确的时间和地点获取正确的数据”是非常关键的任务。对象管理组织OMG认识到在分布式实时系统中的实时数据交互的需求，从而，组织在网络、信息管理、分布式、实时和关键性任务系统方面具有丰富经验的会员定义了DDS（Data Distribution Service，数据分发服务）规范[19]，在2004年12月发布其1.0版本，2007年1月分布1.2版本。DDS采用以数据为中心的发布-订阅模型，提供了强大的数据QoS控制策略，实现了分布式系统中数据实时、可靠、高效地分发，能够广泛应用于航空、国防、分布仿真、工业自动化、分布控制、机器人、电信等多个领域。

DDS规范标准化了分布式实时系统中数据发布、传递和接收的接口和行为，定义了以数据为中心的发布-订阅机制，提供了一个与平台无关的数据模型（此模型能够映射到各种具体的平台和编程语言）。DDS允许应用程序实时发布其拥有的信息，并订阅其需要的信息，较好的处理了不可靠网络通信中数据的自动发现、可靠性和冗余性等问题，可应用在要求高性能、可预见性和对资源有效使用的关键任务领域。

DDS规范描述了两个层次的接口[20]：低层的DCPS（Data-Centric Publish-Subscriber）用于完成数据的发布、订阅，其目的是发布者能够高效地将正确的信息传递给适当的订阅者；高层的DLRL（Data Local Reconstruction Layer）用于数据在本地的表示，其目的是使应用程序能更加直接的访问交换的数据，并能与本地语言完美的结合起来。

DCPS层是DDS规范的核心，它提供了数据发布的基础架构，确保正确有效地传输信息给适当的接收者。该层建立了一个“全局数据空间”的概念，发布者和订阅者在该全局空间中分别发布和订阅自己需要的数据类型，通过中间件处理后，再进行数据传送，将传统的C/S模式转为以数据为中心的服务模式。在该模式中，数据并非存在于所有计算机的地址空间中，它仅存于那些对它感兴趣的应用程序的本地缓存中，而这一点正是发布-订阅模型的关键所在[21]。图9显示了DDS中数据的传递过程，图中主要包括以下几个实体：生产者（Producer）及其中的数据发布者（Publisher）和数据写入者（DataWriter），消费者（Consumer）及其中的数据订阅者（Subscriber）和数据读取者（DataReader），主题（Topic）及其对应的数据对象（DataObject）和数据域（Domain）。

图9. DDS通信模型

Publisher是一个负责分发数据的实体，它可以发布不同类型的数据。生产者中的应用程序通过DataWriter的写操作来写数据。写操作以对象的适当类型作为参数，当定义与DataWriter相关联的Topic时对象的类型就得到确定。对象有了新值，写操作就会通知中间件，但立即构建网络通信并不是必须的。由Publisher负责决定何时发送数据以及执行实际的发送操作，这一行为通过相关的QoS驱动。Subscriber负责接收并分发不同类型的数据，根据Subscriber的QoS，可以接收已发布的数据。而消费者中的应用程序想要获取Subscriber接收到的数据，就必须使用一个与Subscriber关联的类型化的DataReader。DataWriter对象和DataReader对象之间的联系通过Topic对象来实现。Topic包含名称（在系统中唯一的）、数据类型和与数据本身相关的QoS。通过Topic，使空间上、时间上关系松散甚至毫无关联的发布者和订阅者之间产生了关联。

DDS规范定义了较为全面的QoS控制策略，每个DCPS实体都有自身的QoS策略。在主题订阅时，DDS检查发布者发布的主题是否满足订阅者的要求，并检查其QoS策略是否兼容，如果是则在发布者和订阅者之间建立连接，进行点对点的数据传送。否则就给出不相容错误提示，如图10所示。因此，DDS能够在每一对发布者和订阅者之间建立独立的QoS协定。这使得DDS可以很好地配置和利用系统资源，协调可预言性与执行效率间的平衡，支持复杂多变的数据流需求。

图10. DDS通信中的QoS失配

DDS规范提供了21种灵活的数据传输QoS控制策略，能够提供实时系统所要求的性能可预测性和资源可控性，其中比较重要的QoS策略如下：

?  Durability（持久性）：如果创建发布者时此属性被选中，那么所创建的发布者将在内存中保存其发布数据的历史记录，要保留的数据总量由History属性。Durability允许后加入的订阅者获得在订阅者创建之前已经发送过的数据。

?  Reliability（可靠性）：如果创建发布者时此属性被选中，那么所创建的发布者会交付所有的数据发送。如果由于通信错误导致订阅者不能接收到数据，数据服务将会修复该错误并重新发送数据。默认状态下，发布者进行尽力服务，不会重发丢失的数据。

?  History（历史记录）：控制发送队列中的数据总量，此属性的使用与Durability及Reliability属性相关联。如果Durability属性被选中，那么History属性决定有多少历史数据会被传送给后加入的订阅者。

?  Liveliness（活跃性）：用于检测发布者的状态，甚至当它没有活跃地发送数据时也可以检测。

?  Deadline（时间限制）：对于发布者而言，Deadline是发布者承诺更新数据的时间间隔；对于订阅者而言，Deadline是期望从发布者得到数据更新的最大时间间隔。

DDS为实时环境下以数据为中心的分布式应用提供了实时、高效、可靠的通信服务，能够实现分布式异构环境下海量数据的实时传输。其具有以下特点[22]：

?  复杂的数据流处理：DDS通过对数据传输QoS的灵活控制，可以将对更新速率、可靠性和带宽控制有不同要求的模块很好地集成到一个系统中。

?  低时延和高吞吐量：DDS不需要中心服务器，可以使用直接点到点传输和事件驱动传输，消除了由于网络中转而引起的时延，与C/S模型相比大大提高了传输速度。另外，DDS还允许应用程序通过降低可靠性来进一步缩短时延，如采用“best-effort”方式传输。同时，DDS可利用UDP协议，将单个网络分组同时发送给多个分布式节点，极大的提高了传输的吞吐量。

?  容错：DDS采用点对点的数据传输，不存在中心节点。，避免了单点失效问题，实现了高容错性。

?  动态配置：DDS的发布/订阅通信模型能够很好的适应具有动态配置变化的系统，能够快速发现新的节点及其主题。当网络被分割成两半时，每一半能独立地工作如果网络被修复，将会自动重新连接，继续提供全部服务。

尽管DDS具有以上特点，但并不能满足所有的通信要求。例如，DDS不适合与请求-响应服务、文件传输和事务处理。文件传输通常对信息进行一次性请求，适合于采用C/S模式。同样的，精确控制的序列化通信，如可靠的、一次性处理过程，也不适合于采用DDS规范。

目前，比较流行的DDS商业产品和开源软件包括：美国RTI公司的NDDS（Network Data Distribution Service）、美国PrismTech公司的OpenSpliceDDS、OCI（Object Computing Incorporated）开源软件OpenDDS等。

4、总结

二十世纪九十年代以来，互联网逐渐成为新的计算基础设施，其出现和普及使计算机软件开发、部署、运行和维护的环境开始从封闭、静态逐步走向开放、动态。越来越多的企业提供基于互联网的服务，新的业务模式得到了发展，企业业务系统之间的交互逐渐增强，系统之间的通信和集成问题凸现出来，即使在企业内部也存在异构系统之间的整合问题，因此，发展出了各种分布式系统集成技术。根据所面向的应用不同，可分为分布式企业应用集成技术和分布式实时应用集成技术。

在分布式企业应用集成技术中，最初的远程过程调用技术解决了不同计算机之间进程交互的问题。随着面向对象技术的广泛应用，诞生了分布式对象技术，如OMG组织的CORBA技术，Java阵营的RMI技术，微软的DCOM技术。这些技术能在一定程度上解决分布式系统的通信和集成问题，但是存在着一些问题，如交互双方以紧耦合的通信方式绑定，基于二进制通信协议，并采用跨逻辑层的紧密集成，容易导致可伸缩性问题。为了解决分布式系统之间集成的紧耦合问题，产生了面向消息的中间件技术（MOM）。但是大多数MOM实现方案提供的都是与自己核心设备通信的本地API，影响了应用程序在此类实现方案之间的移植性，从而导致将实现锁定于特定服务器供应商的问题。Web服务技术采用一系列完全开放且独立于实现平台及程序设计语言的Web规范，具有更好的封装性、高度的可集成性以及更好的开放性与互操作性。相对于COM/DCOM，RMI和CORBA等分布式组件模型，Web服务具有松散耦合性、简单性、高度可集成性和开放标准等特点。

在分布式实时应用集成技术中，实时CORBA技术以分布对象为基础，可用于开发分布式实时应用和系统集成。然而，在面临实时环境下以数据共享和集成为目标的分布式应用需求时，传统的基于C/S架构的分布式软件系统存在中心服务器瓶颈、单点失效等问题。数据分发服务（DDS）技术采用以数据为中心的发布-订阅模型，实现了分布式异构环境下海量数据的实时传输。