什么是实时SOA？

Stan Schneider

美国RTI公司CEO，斯坦福博士

概述

随着实时分布式系统复杂度的不断增加和研发规模的迅速扩大，系统集成的难度和风险都在大幅提高。不同阶段独立研发的各大系统之间需要集成，我们通常称为“系统中的系统”。众所周知，企业级系统通过SOA，即面向服务构架来加强集成。然而，企业级的技术并不能完全满足实时系统的要求，特别是对时间控制有严格要求的系统。

这就引申出另一个概念，就是所谓的“实时SOA”。那究竟什么是实时SOA呢？理想情况下，它类似与企业级SOA，其体系结构可以有效地整合和集成各大系统。与企业级SOA不同的是实时SOA可以处理对时间要求极高的实时系统，并利用企业级技术将他们相互连接起来。对象管理组织（OMG）的数据分发服务器（DDS）标准为实时SOA提供了合适的框架。但作为一个对等的协议，DDS无法自动整合多个系统，这就需要在各DDS系统之间运用正确的协议和其它整合技术，才能够连接不同团队构建的独立系统并集成多种应用。

本文简述了如何运用SOA原则建立一个快速实时分布式系统，该系统基于DDS标准和技术，并包括实时和企业级的功能。

集成的重要性

2006年11月2日，美国海军有意炸沉“福吉谷”号宙斯盾巡洋舰，这艘只服务了18年的第四代巡洋舰的设计寿命至少为30年，那究竟发生了什么使得美军要主动销毁它呢？这艘巡洋舰的船体设计是合理的，发动机和主要设备也能够正常工作，问题只是在于系统软件无法升级到新的技术和现代武器系统。这是一个令人震惊的事实：系统软件升级的代价已经超过了保留10亿美元的资产○1。 

为什么会这样？众所周知，复杂系统的集成是十分困难的，协调不同子系统的开发团队更是一项挑战。在过去，唯一的办法就是把整个系统的开发采用“烟囱式（STOVEPIPING）”垂直管理和运作模式。 这种模式成本巨大，更糟的是它还不鼓励可扩展的设计，导致集成和维护成本直线上升。从宙斯盾巡洋舰这个事件中可以看出，集成和维护的成本超过了船体本身，而这并不是偶然的特例。在很多行业中，实时系统集成的成本无法控制。

这种状况再也不能继续下去了！

系统集成的问题

系统集成的成本和风险随着系统和团队规模的扩大而不断增加。小型团队不需要太多的协调工作，比如一个团队只有10个程序员，他们只需每周例会，审查进展情况、检查接口和设计的变更等。100个人的团队则必须分成若干小组，文件设计、审查和项目管理也逐渐变得很重要。

随着团队规模的增加，公司面临的压力是争取并完成更大的项目。该项目可能包括多个公司和组织之间的协作。在这种情况下，接口便成为谈判的细节，技术选择也变得十分困难，整个团队的设计审查成为关键。系统集成的成本大大增加，尤其是前期工作的开销。细小的变动也需要细致的文件备份和进度控制，甚至追加费用。

如果还要考虑时间因素，则问题将变得更为复杂。大型系统的开发和维护通常需要跨越多个时间段，这意味着旧的技术和设计必须以某种方式保留与新版本的良好接口，否则可能带来严重后果。企图开发无需升级的“定制”软件（类似开源的诱惑）是错误的想法，如果原有软件无法更新到最新的平台，所有相关的技术都必须改变。“重用”是一个永远难以实现的梦想。与升级不同，承包商通过看似简单的更新收取了数亿美元的费用。

简而言之，大型系统集成的成本极大并对系统维护有着极大的影响。

 

图1: 集成成本随系统增大

集成规模随着系统增大迅速膨胀，构建和维护大系统的成本和风险完全由集成主导。

耦合性问题

系统集成为何如此重要？根本原因在于系统是由很多模块组成的，而这些模块由不同的小组设计。当一个团队变大时，协调和交流就变得十分困难。大型团队构建的系统只能由独立设计、实施和管理的子系统组成，显然这并不容易。

实时系统的集成

我们的第一个挑战是用独立设计的模块构建高性能的实时分布式系统。

图2显示了典型的传统设计模式，即运用“客户端/服务器”或“远程对象”技术，如CORBA、ODBC、RMA、OPC等。在开发过程中，首先必须确定系统功能，然后再设计每一条信息访问方法和接口。这些数据“隐藏”在各个对象背后，每个设备或端点数据处理的要求事后进行。这种设计假定网络是相对静态的，服务器总是存在和可访问，服务器/客户端关系明确，客户知道在何处、更重要的是何时申请数据，所有应用都有类似的交付要求。它还假定一个“同步”处理的模式，客户端请求服务器，然后等待答复。但随着系统复杂度的增加，这个以“服务器为中心”的设计很容易崩溃，而且这种设计使得增加新的系统或数据（图2中红色线）非常困难。每个服务器通常还和各自的客户端耦合，除非现有的接口能够提供所需的一切信息，否则每个与新的数据有关系的接口都必须重新设计。

 

图2：传统OO设计的紧耦合网络

传统技术需要开发人员定义为每个函数访问方法，然后实现服务器和其它特殊接口。这导致“意大利面条”式的网络设计和“烟囱式”的系统。

图3描述的是一种以数据中心的设计方法。这种设计方法仅需要开发人员定义各个子系统数据的输入和输出，这与前面隐藏数据的方法正好相反，这种方式中信息流影响着每个模块。

这种中间件能够自动发现信息发布者和接收者，并即时提供所需要的数据。这种“以数据为中心的发布/订阅”设计模式消除了耦合，大大简化了苛刻或复杂系统对数据共享需求的集成难度。因此，对象管理组织（OMG）迅速制定了数据分发服务（DDS）标准，并很快在很多系统中得到了广泛应用。在全球，大部分军事系统的集成技术都采用了DDS。它还在金融贸易、自动驾驶辅助系统、空中交通控制和能源等行业得到了广泛和成功的应用。

 

图3：以数据为中心的设计引入虚拟“总线” 概念

以数据为中心的发布/订阅模式清晰地定义了接口和模型信息。有了清晰的接口，各个部件很容易接入“数据总线”。

新的应用带来的问题

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

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

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

DDS启用了20多个“服务质量（QoS）”策略来定义信息模型。 QoS策略设置了信息发布者是否能提供可靠的信息流、发布数据的速度有多快、你希望何时发现数据。各个应用可以通过QoS明确其需求，甚至可以做到通过时间或信息的内容来筛选更新信息。中间件还能“听到”新加入者的需求，并决定发布者是否能满足这些需求。如果可以，中间件会在发布者和应用之间建立“合约”，并开始发送数据。如果不可以，它会报告发生了一个错误。例如，一个合约以是这样：发布者将以毫秒级的速度更新订阅者，而且是可靠的通信方式，如果传输发生错误请重新发送，一旦发布者失败，就可以切换到备份数据。

这只是其中的一个例子，实际上DDS的QoS策略可以集成数以百计的复杂且苛刻的应用。由于中间件能够做出快速反应，使得通过这样的设置来满足苛刻的实时系统成为可能。实际应用的DDS系统在数以百万对订阅和发布者之间发送每秒钟数百万的消息，而延迟仅有几十微秒。设计人员可以提出时间要求，以支持有明确发送需求的程序。可靠的多播模式可确保新的“外挂程式”不对程序造成负担。它还具有很好的排列功能，可以部署在多达1000台计算机的系统里。DDS尤其适用于对不间断、可靠性有很高要求的应用中，类似作战管理系统或在电网管理系统等应用。

在雷达中的应用

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

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

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

集成系统中的系统

所以，综上所述，DDS中间件采用以数据为中心的发布订阅模式连接实时系统。在上述的应用中DDS无疑是正确的架构，它定义了接口、时机和QoS策略。一切都围绕着减少延迟并提高速度。

但这并非分布式系统集成的全部内容。大系统开发和维护的生命周期一般需要很多年，期间还可能碰到预期外的系统集成问题。例如，在DDS的网络（称为“域”）中，需要集成到虚拟总线中的应用必须有统一的主题和类型。即使每个人都使用DDS，不同的组可选择不同的主题和类型，而单个组的设计将随时间而改变。因此，要整合这些系统，我们至少要集成多个不同的DDS域。此外，并非所有的系统都在使用DDS，我们还需要整合多种不同的协议，如原有的系统和企业级技术。

可见，DDS使得模块之间成为松耦合的方式，这使得集成各个系统成为可能，但这还远远不够。

SOA：企业级松耦合的开发流程

让我们退一步来观察成功运用在企业级系统和系统之间集成的技术：面向服务架构，即SOA。 SOA是一种体系架构，由独立的“服务”来建立复杂系统。如果熟悉“SOA”这个词，你可能知道它通常基于Web Service设计。 Web Service和SOA在企业中有惊人的成功应用，因为他们采用了松耦合的开发模式，SOA和Web Service成为主导了当今企业级系统集成的构架。

SOA基于Web Service集成企业级系统，通过面向服务实现业务功能的独立实体，松耦合的这些应用程序可独立开发，并在后期集成。比如一个网上商店可收取您的信用卡，并安排通过多个厂商出货。这些应用并非在同一时间或同一地点设计，他们通过独立的模块集成。各种应用显然可以即插即用，不同时间和不同的团队可开发各种应用，甚至使用不同的技术。

本篇不对Web Service的工作原理进行详细的描述，一言以蔽之，其主要特点是灵活的接口定义（WSDL文件）、知道哪里得到这些接口协议（UDDI服务器）和共享（XML）的类型定义。

如果将Web Service和DDS进行比较，可以看到两者尽管实现的方式差别很多，但很多方面非常相似：都支持的接口定义（WSDL和QoS）、接口服务（UDDI和DDS的主题发现）、和内容识别式的类型共享（XML和DDS的类型发现）。而这些都是分布式系统集成的核心功能。

企业级服务总线ESB

但是企业级SOA具有一些DDS所没有的东西。比如，在运行时，企业级SOA利用了一种关键的集成技术，即应用程序调用所需的企业服务总线（ESB）。 ESB运行在单一的逻辑机器上，称之为“总线”，但它不是一个分布式的概念。ESB具有协议互换功能，它类似“路由”方式把消息传到适当的服务中，比如SOAP和JMS等，它也可以转化服务之间的类型。有了这些功能，ESB可以连接独立开发的应用程序，即使他们并不共享类型或者不知道从哪里得到他们所需要的数据。见图4。

 

图4：企业级系统通过ESB集成

企业级SOA运用了企业级服务总线（ESB）来连接各个应用需求到合适的服务，它能够在独立的团队和不同时间构建复杂系统。ESB能够在执行时连接各个应用。

为了集成独立的实时分布式系统，DDS也需要类似ESB的总线。

实时系统之间的集成

因此，如果我们的目标是不同的实时系统之间以及和企业级系统之间进行集成，这需要解决以下三个问题：

1.我们是否可以用企业级SOA技术集成实时系统？

2.我们是否可以用企业级SOA技术集成实时系统和企业级系统？

3.我们是否可以利用SOA原理扩展DDS，使其集成实时和企业级系统？

让我们分别来看一下这三个问题。

1.我们是否可以用企业级SOA技术集成实时系统？

一个明显的事实是，仅仅依靠Web Service和ESB来集成实时系统还远远不够。Web Service既没有时间控制的概念，也没有足够的QoS策略，其参数设计也常常与实时系统不符。更糟的是，企业级SOA系统的关注点在于部署和管理。ESB中的关键构件通常在数据中心，但在一个典型的实时系统应用中，比如作战系统，如果把一个数据中心放在战场上，那就等于你根本不想赢得这场战争。

接下来的问题是性能。企业级SOA无法满足作战系统等实时应用中的实时性要求。有些Web Services的供应商把他们的Web Services称为“实时SOA”。他们对实时的理解往往是类似网络交易中在最多十分之一秒内做出的反应，这当然比人工快，但这无法控制雷达系统。实时系统必须每秒发送高达数百万的消息，而延迟必须控制在亚微妙级。Web Services显然太慢了！

即使有快速的Web Services也行不通，Web Services对时间没有控制，所以你不能在确定的时间内获取或发布所需的信息，实时并非仅仅对速度有要求。例如在一个雷达系统中，如果接收数据不及时，哪怕是延迟一点点可能都会导致毁灭性打击，因为来袭导弹不会等你。

可见，企业级SOA无法满足实时系统的要求。

2.我们是否可以用企业级SOA技术集成实时系统和企业级系统？

如果企业级SOA无法连接实时系统，它能否将实时系统连接到企业级系统上呢？当然有很多企业级技术可以与DDS连通。例如Apache Camel支持1000插件协议。比方说，如果你需要将一个战术的实时系统连接到它的企业支持环境中，你何不插入DDS呢？

这听起来的确很有吸引力。事实上，RTI公司曾经尝试这样做并做了一个很好的演示系统……但结果失败了。从根本上讲，它不能解决实际问题。为了理解原因，让我们看看实时系统和企业级系统之间的一些重要差异。

实时系统的特点：

•每秒钟可能需要发送多达几百万个消息

•延迟时间在毫秒级

•对冗余和速度必须达到实时分布式系统要求

•需要严格的Qos策略和时间控制并使用快速的二进制数据格式

企业级系统：

•每秒钟通常发送几百或几千个消息

•延迟达数毫秒，甚至几秒钟

•必须集中管理（管理和备份等都在数据中心进行）

•受到很多商业因素的影响

•使用重量级数据格式，比如XML格式

 

基于上面提到的还有其它一些原因，企业级技术无法满足实时系统的要求。比如，ESB使消息标准化，Camel将一切转换成Java对象，然后在转换回去。这对于是实时环境的帮助不大，而且速度缓慢。如果你期望ESB来执行实时系统的重要功能，它可能很快就会崩溃。

因此，通过企业的ESB系统来连接实时系统是无法实现的。它速度缓慢、没有时间控制和有效的QoS策略，并可能造成单点故障和瓶颈。这显然是一个错误的方式，直接通过ESB来连接实时系统是不可能。

3.我们是否可以利用SOA原理来扩展DDS，使其集成实时和企业级系统？ 

我们已经知道，DDS缺少ESB的“路由”功能，但我们能否用一种能够满足实时需求的“路由”方式来实现它呢？这的确是一个有趣的问题。我们并不需要把所有的集成全部交给ESB来完成，正如我们所看到的， DDS模式具有强大的整合基础，具有分布式和快速反应的关键优势。那么，我们是否可以建立一个快速、分布式的“ESB”呢？

实时路由技术

连接DDS中的域

首先让我们考虑最简单的问题：假如我们有两个DDS应用，比如雷达系统和显示系统。很明显，如果能使用单一的DDS虚拟总线将两者设计在一起，并通过共享类型、主题以及QoS参数连接，这无疑是最好的解决方案。那我们就可以以数据为中心这一贯穿整个应用程序的的设计原则来开发一个高性能、高可靠性的平台。

但是，先让我们假定这不可行。首先，这些都是涉及许多应用的大系统，他们最初是为其它目的而开发的。也许我们是从船舶那里“借用”它的显示系统，然后将它与地面反导弹系统中的雷达合并，并且这些系统模块还需要多个应用程序中使用，各种应用还有不同的要求。或许雷达是一个很新的技术，我们正在努力融入我们的船舶中，使它保持一定竞争力。

这里最大的挑战是如何重用那些独立开发的大型模块，这些模块可能由其它团队或公司先期开发，这也是每个项目经理的共同愿望。很少有人知道重用这些模块所需要的成本和难度，遗憾的是，重用通常是一个无法实现的梦想，将两个以前并不是在一起设计的大型系统整合在一起是众所周知的、令人沮丧的工作。

路由服务

我们如何才能有效地连接两个独立的DDS域呢？这样的一个路由服务需要做什么？

如果没有路由服务的话，连接域的唯一的办法是定制一个“桥接”，它知道哪些数据需要通过并订阅这些数据，并以另一端期望的模式和主题发布它。这种方法无疑是可行的，但客户需要为设计和维护付出昂贵代价。

我们的路由服务需要搭建网络间的数据包。但要做到这一点，我们的服务需要在配置形式上具备两个主要功能：监护和转换。而且它还需要连接到两个域，找到正确的数据，然后将它传送到正确的地方。

监护

监护决定我们的子系统将输出什么。很显然，雷达显示系统并不需要雷达系统中的每一个数据。它只需要轨迹（在我们这个简单的例子里）。监护的工作是选择需要的信息而不是全部，如果我们想控制我们的外部系统，它也可以改变输出信息的QoS策略。因此，一个监护类似一个过滤器，它将需要的信息发送给对方。

同样重要的是，监护具有安全性特点。由于路由服务控制所有进出该系统的信息，它提供非常重要的保障。这是至关重要的，但这里我们不展开讨论。

转换

其次，我们还需要在系统之间传输不同的语言。比如雷达和显示都明白“轨迹”的概念，但假设雷达发布的轨迹是以它的位置为基点的X - Y - Z位置，而显示却使用纬度和经度来表示位置（见图5）。

 

 

图5：监护和转换是两个关键的功能

任何系统必须连接独立开发的应用并转换不同的数据类型，它必须知道需要输出什么样的信息。因此唯一的选择是花费巨资重写其中的一个应用。这只是一个很简单的例子。真正的轨迹数据结构可能有数百个域。但道理完全一样，转换时必须与两者的主题名称和模式相匹配。

如何在两端同时发现信息

那么，我们如何才能完成这些功能呢？路由服务必须能够在网络中找到正确的信息并将其发布到另一端。我们的路由服务必须具有自动发现并控制信息的功能，同时也必须能够识别并处理所有的主题和类型。由于DDS对内容预知，这些功能是可实现的。转换功能为每一个需要处理的模式提供简单的脚本或插件，监护提供配置脚本，明确需要传输的主题。除此之外，DDS对内容的可读性还意味着路由服务在运行时检查所有类型，因此该系统可以在模式发生变化的环境下安全工作。 RTI公司已经开发了这样的路由服务，它是通过XML脚本来配置的。

 

图6：RTI公司的路由服务连接两个域

RTI的路由服务连接两个DDS域。它兼有监护和转换的功能。监护将选择哪些数据可以从域输出，转换在域之间匹配主题和模式。它可以通过DDS的发现功能找到所需的数据。

扩展性

现在，假设我们要集成多个DDS域。 类似ESB的做法就是扩大我们的路由服务来处理多个数据流。但是，由于有DDS总线，没有必要使用统一的ESB。我们可以部署多个路由服务，并根据需要将他们分布在系统中，这使得系统更快、更稳定。我们甚至可以在单对域中建立多个路由服务进行冗余处理。

用DDS构建实时ESB

路由服务还为更大的解决方案提供可能。通过DDS协议的路由服务（Routing Service）不仅可以连接各个系统，还可以通过插件协议来扩展它的功能。例如，它可以通过TCP连接DDS域，这可使DDS能便捷穿越防火墙，同时还可以通过插件对信息进行加密，使得信息可以安全跨越广域网。

我们还可以做得更多。路由服务还可以将DDS连接到非DDS系统，利用插件，路由服务成为一个可编程的通向任何协议的桥梁，例如Link16 、STANAG 4586、JMS、C37.118、压缩的DDS流等诸多协议。通过这些插件， 路由服务还可以将另一个协议集成到系统中。所有这些，DDS都可以轻松做到。每一个系统都可以在一个单独的应用上运行。就这样，一个高效的分布式系统就构建成功了。

除了协议，DDS还可以用于集成其它技术。例如，RTI公司拥有的DDS服务可以整合数据库、Web Services以及Excel这样的工具。在中间件上安装JMS API可以便捷地与企业级技术集成。有监护功能的JMS API可以轻松地与类似Camel这样的企业级ESB连接， 而不必通过中间的“标准化”步骤。

以上可通称为一个“实时服务总线”，它能实现企业级服务总线的相同功能和用途，而且具有快速、实时的特性，模块可以在任何应用上集成任何技术。实时服务总线提供了分布式构架中DDS所缺少的集成多个应用的功能。

 

图7：实时服务总线

通过增加协议插件和企业级技术，DDS成为构建类似“分布式ESB”的实时服务总线的基础构架，使得构建的实时SOA弥补了企业级Web Services的不足。

究竟什么是实时SOA？

本文所描述的体系构架无疑是一个名副其实的面向服务的架构（SOA）。有了RTI公司强大的路由服务，设计师可以从许多独立的服务中建立实时系统。

更重要的是，这样的体系构架具有松耦合的特点。各种服务，甚至整个DDS或其它应用都可以由不同团队在不同时间独立设计完成，还可以使用转换功能在后期对各应用进行集成。如果要对其中一个应用进行更新，也只需要调整转换插件即可，这对系统的升级和维护至关重要。

让我们再次重申，我们的创新与许多企业级软件销售商所称的 “实时SOA”截然不同，后者实际上只是提供更快的网络服务，而以DDS为基础的“实时服务总线”是一个真正集成实时系统的SOA。而且它还能满足对性能、可靠性和时间控制等各种苛刻性要求。有了协议插件和其它技术的参与，它还有了更强大的功能。它能帮助开发包括实时和企业级应用的复杂系统，还能集成大型的实时系统，并将实时系统和企业级系统集成。

躺在太平洋底的宙斯盾巡洋舰还在提醒软件设计师们，这是一个惨痛的教训，它说明了系统集成的重要性。合理的系统架构为系统的进一步更新和集成带来可能，实时系统需依赖于实时技术。

新兴的实时技术可以提高系统集成的能力以避免将来可能的浪费。从系统开发第一天起就使用正确的集成设计也许是构建和维护实时分布式系统最重要的考虑。

 

○1Admiral Frick, PEO IWS, at the 2006 ASNE Combat Systems Symposium

○2Figure modified from Raytheon talk at OMG DDS Day seminar

○3本文中的所有性能请参考RTI公司网站 www.rti.com

○4 DDS 还允许多个操作系统、不同编程语言之间进行互通。并不是所有的中间件都能做到这一点，但本文不再展开。