比如，正在开发中的新一代空中交通管理（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）
