比如，正在开发中的新一代空中交通管理（Air Traffic Management）系统，是为了调整日益繁忙的航线，并连接各客户端（比如美国联邦航空管理局、国防部及国土安全部）的工作。这些系统需要更高的信息带宽用于追踪更多的飞行器和更复杂的“自由飞行”轨迹，同时需要更快的信息响应速度以更快地检测飞行异常。其它方面也有类似的需求，比如医疗保健系统、数据采集与监控（SCADA）系统、网络监控系统、能源分布系统、运输系统，以及其它关键基础设施系统。
SOA组件的最佳组合
实时应用程序需要面向服务的基础组件的最佳组合。SOA系统有三种基础组件：消息总线、信息转换/处理引擎和数据存储库（见图1）。一般来说，这些组件会集成到企业服务总线中（ESB），并使用J2EE应用程序服务器。
图1
而在这些基础组件中，消息总线是最重要的，因为它是所有其它组件交互的中介。
低性能的SOA系统或许会使用HTTP协议作为“消息总线”实现各组件间的消息交换。这种方案只适用于非实时应用程序。HTTP协议缺乏可靠性、带宽有限、延迟大，并且在系统暂时无法使用时不能提供缓冲或消息队列以延时递交。
解决方案是采用高性能的消息中间件，比如RTI Data-Distribution Service、IBM WebSphere MQ、TIBCO或SonicMQ等。这些中间件平台在开发时充分考虑了可扩展性和表现性能。而且，它们为不同的应用方案采用不同的优化架构。
为什么消息性能很重要？
这是计算机实时超越人类实时的需求与期望。若系统中存在人类这一环节，实时即指信息可以在一秒到几秒反应时间内随时可取；而在计算机到计算机环境中，却必须以毫秒甚至微秒级别的速度处理信息。
计算机实时对消息基础设施的要求更为严格：每个处理组件和存储组件每秒都会收到几十万的消息或事件，延迟不能超过微秒级别，最差不能超过毫秒级别。这意味着消息中间件必须可以在系统范围内每秒传送几百万的消息。
消息总线的负载能力也必须满足基础硬件设施的负载要求，并且不能在基础硬件设施的限制（中央处理器速度、核心、速度和网络带宽）外再有其它限制。随着中央处理器和网络速度的提升，那些可以因硬件升级而提升性能的系统将获得更大的竞争优势。比如，在一个自动交易系统中，决定性因素并不是判定交易所用的绝对时间，而是要在竞争交易发生前做出判定并执行。
关于计算机实时，SOA系统的最后一个问题是，它们的“反向性能负载效应曲线”，也就是系统在高负载下运作时的及时响应能力非常重要。一般的效应曲线，比如人类实时系统，由于负载的加重而使性能有所下降是可以接受的。这是因为人类的期望与耐性是随情况改变的，比如，人们明白在度假高峰期预定机票必须忍受较长的等待时间。而对计算机实时系统的要求却与此相反。高负载时期正是“最关键业务”发生的时期，也是需要系统表现最佳性能的关键时期。比如，业务繁忙时必须更快地处理交易判定。
人类实时系统与计算机度实时系统的区别在表1中做了概要说明。
表1
为实时SOA选择消息中间件
消息中间件是实时SOA系统的实现关键。虽然如此，仍然有许多问题需要考虑。如何为实时SOA系统选择最佳的消息中间件呢？可以从架构、服务质量（QoS）控制与过滤器、性能提升技术、实时判定机制和度量指标五个方面考虑。
1. 架构
消息中间件有四种基本架构：星型拓扑（hub-and-spoke）架构、集群拓扑架构、联合架构和对等架构（peer-to-peer）。（见图2）
图2
星型拓扑架构用一个服务器作为消息交换的路由，实现包含所有消息队列的消息“服务”。
集群拓扑架构使用一组服务器，分别处理不同种类的消息（比如消息队列或主题所有权）。每条消息通过一个服务器，但不是所有消息都用同一个服务器。
联合架构也使用一组服务器，但这组服务器是作为“资源库”使用。比如，消息队列可以出现在多个服务器中。消息可能只经过一个服务器代理，也可能经过多个服务器代理。
对等架构不在传输路径中使用任何代理。消息直接从发送方传向接收方。
各种架构都有其优缺点。星型拓扑型容易管理，便于操作，但表现性能、容错率和可扩展性比较差。集群架构可扩展性比星型架构好，但容错性同样较差，并且只能在网格范围内为附近的客户端提供较好的表现性能。联合架构的扩展性更好一些，但其延迟更大，因为每条消息都要经过至少两个服务器的代理。对等架构提供了最好的可扩展性、表现性能，最低的延迟和最高的容错率，但实现起来很困难，并且对业务的支持有限。
随着需求越来越具实时性，对性能、可预见性和平衡的要求越来越倾向于对等架构。这就是为什么像IP语音通信和IP视频传播（比如Skype）之类的需求网络会采用对等的设计方案
服务质量控制与过滤器
服务质量控制是以低延迟、高处理能力提供及时数据的关键。中央处理器、内存和网络带宽资源必须在所有通信过程中共享。然而，并不是所有的通信都需要相同的带宽或有相同的紧急性和重要性。如果没有服务质量控制，应用程序就无法分辨不同的信息类别和反应需求。这会导致中间件不能灵活地做出判定，对信息进行优化处理或满足应用需求。
比如，使用TCP协议（传输控制协议）的传统网络环境中，一个小而紧急的警告消息可能在TCP连接中被排在一个较大的文件传输后面。因为TCP无视消息源，并稳定有序地传输每一个字节。这个警告消息只有在传完整个文件之后才能被成功接收到。可以假想在广域网（WAN）中转播直播节目的情况。网络阻塞可能会造成图像丢失；由于没有服务质量控制，中间件就会继续查找丢失的图像，而不是选择传送最新的图像。这样就不只是丢失几张图片的问题，极有可能图像会冻结，直到成功取得丢失的图像。所以，即使硬件可以提供不错的表现性能，系统的整体性能仍然大打折扣。
为实现计算机速度的实时性能，消息中间件必须至少满足以下服务质量控制要求：稳定性、缓冲计算、流量控制、生命周期、历史记录和传输优先级。（见表2）
表2
过滤功能是系统扩展性与表现性能的关键。支持过滤的中间件可以只为各组件传送最重要的内容，这可以节省大量网络带宽和CPU资源，使系统可以处理更多的信息。比如，事件处理引擎可能会查找关系到某些计算机或网络单元，或者属于某种协议的网络活动。中间件并不会将所有网络事件都传送到引擎，并让引擎过滤掉不相关数据，而是先进行过滤处理，然后再发送相关数据，这样可为事件处理引擎节省网络带宽与CPU资源。
主要有两种过滤器：一种是基于时间的，另一种是基于内容的。基于时间的过滤器会限制信息频率，比如每秒最多允许发送10次更新信息。基于时间的过滤器对应用程序非常有用，例如以人为本的仪表板，只需要获得走向与概要信息即可。
基于内容的过滤器从内容上对信息进行简化处理。举例来说，一个显示程序可能只关心接近机场的飞机位置。基于内容的过滤器就会筛选出所有离机场很远的飞机。
3. 性能提升技术
一辆无论构造多么合理的汽车，如果没有强力的引擎就不可能发挥出优良的性能。同样，消息中间件也需要一些特征与技术以获得最佳性能。其中以下方面最为重要：组播技术、消息批处理功能、消息分段技术、异步远程拷贝和传送过程中的零拷贝访问。
4. 实时判定机制
实时并不是简单的速度快而已。为实现稳定的实时，系统必须同时稳定而高速。实时判定机制决定了每次系统运算时的稳定性。一个实时判定系统必须在每个运算上花费同样的时间。
然而，并不是你做的那些事决定实时操作能力，而是你不做的那些事决定了实时操作能力。因此，实时的满足需要处理器、资源定位和管理上的稳定性与一致性。内存分配、等待周期、关闭中断或者其它的任何程序操作都会引发无法预料的行为。为保证稳定性，每个操作必须以同样的方式同样的时间进行。对于一个包含多个步骤的操作，每一步都必须是可靠的，因为其中可能包含不可靠的信息。如果某一步是不可靠的，那整个操作链都会变为不可靠的。
因为基础硬件设施一般都是非常稳定的，因此系统的不确定因素源一般在操作系统、中间件或应用逻辑/代码中。实时操作系统是一项大受好评的技术。应用程序必须本着传送稳定结果的理念进行设计。然而，在许多系统中，中间件是实时运算的关键。
这意味着在实际应用中消息中间件必须：
- 使用异步操作技术而非阻塞操作。多线程技术为并发和多核架构提供了机会。
使用多线程技术并发处理紧急任务。仔细挑选架构与优先技术以避免线程冲突，并使用看门狗（watchdogs）和延时设定（timeouts）监控和维持应用程序正常运行。
在稳定的基础设施上执行（实时操作系统、实时Java虚拟机，实时中间件组件）。
谨慎地控制资源。控制动态内存的使用，限制关键路径外的内存分配。
进行任何存储访问时尽量使用内存缓存而非直接进行磁盘操作。
为中间件的可编程应用扩展提供“进程内（in-process）”机制，比如加载DLL文件或Java类。
5. 度量指标
可以认为，优秀的度量指标是决定中间件最终性能的唯一条件。然而，定义消息中间件的特征远比看起来复杂得多。
大多厂商只提供一些关于消息处理能力的信息，类似每秒处理多少消息或字节等。还有少数厂商提供关于延迟的测试数据（从发送方到接收方的端对端延迟）。几乎没有厂商会提供关于可扩展性和不稳定同步的度量指标，包括随着系统发展性能的变化、负载增加，或者消息之间的变更。并且，这些结果很大程度上依赖于计算机和网络硬件设施，以及测试方案。
比如，厂商可能会提供关于执行时间和处理能力的数据，声称他们的产品可以以低于0.5毫秒的时间完成一条消息的传送，并可以每秒传送1000000条消息，但并不会指出是否可以用一个应用程序同时完成这两项任务。甚至，都不会指明这个执行时间是否代表理想情况下的最佳性能，是平均时间还是可以保证大部分消息（比如99.99%）在这个时间内传送等。消息容量和内容类型（不透明的字节、字符串或复合类型）都有极大的影响。比如，如果指的是没有实际意义的四个字节的消息，“条/秒”也就没多少参考价值。如果不考虑类型转换（marshaling，一种称为列集转换方式），每秒多少字节的数据也没有意义。比如，传送raw XML字符串的低效率数据转换方式可以每秒传送许多字节。然而，使用经过压缩处理的XML语言或二进制格式的高效转换方式在传送实际消息时要快得多。这种例子数不胜数。
既然不存在标准的实时中间件性能的测试程序，我们就只有以下选择：依靠厂商给的数据，开发自己的度量标准，以及通过使用中间件的应用程序来进行判断。第一个过于模糊，第二个费时且成本高，而第三个是主观判断。
通过上面的说明，了解以下指标可能会有助于评估中间件的性能，并可最低限度地从提供实时SOA系统的厂商处获得如下信息：基于消息容量的处理能力、基于CPU使用情况的处理能力、消息批处理能力和基于稳定性的最佳表现；基于消息内容的执行时间、基于处理能力的执行时间等。
比如，图3到图7显示了两种不同中间件架构处理能力与执行时间的比较图：一个星型构架（JMS）和一个对等结构的网络（DDS）。
可以参考由RTI Data Distribution Service(运行环境数据分发服务)提供的更多详细的数据。运行平台是使用2GHz双核AMD皓龙的计算机，操作系统是红帽Linux4.0企业版。
图3
图4
图5
图6
图7
总结
要想赢，就必须给赛车安装最好的组件。同样，性能关键的SOA系统也必须建立在消息处理、事件处理引擎和数据库的最佳组合上。在这些SOA基础组件中，消息中间件是最重要的，因为它是所有其它组件的交互中介。
如何确定最好的中间件呢？
首先，考虑架构。选择最符合需求的架构。架构不合适，系统就不可能有优良的表现性能。
其次，选择满足需求的服务质量控制。对网络和数据传送的有效控制将极大地影响到所有组件的工作效率。
第三，选择适合应用程序的、包含性能提升技术的中间件。比如组播技术，就可以在同等负载下极大地提高网络的“扇出(fan out)”能力。
第四，如果系统必须在一定状况下保持性能稳定，那就在设计方案中保证至少关键组件可以在这些实时环境中稳定运行。没有其它可以保证系统稳定响应的途径。
最后，基于以上了解，选择包含对应用程序最为重要的指标的中间件。
明白了以上所有因素，你就离建立最佳性能的SOA系统更接近了一步。
