实时SOA到底是什么（中）

集成系统中的系统

所以，综上所述，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：监护和转换是两个关键的功能

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