背景
在思考消息传递解决方案时，您可能会想到一个通过远程消息调用机制来集成两个不同应用程序的系统。一般来讲，对于不常通信的分布式实体以及数据传输量不是很多这样的情况，常常使用这种耦合。较经典的示例是，连接到异构后端和入口的同构接口，这些后端和入口指派进行用户请求的后端处理，然后为最终用户表示而对那些请求进行重新格式化。
消息传递方法中的公共线程一直有这样的假定：虽然消息传递解决方案在系统之间提供健壮、高度可用的通信，但它基本上效率很低，只用来作为在无法避免与外部系统通信时的最后一种手段。在出现远程方法调用（RMC）时关于消息传递的这种观点就开始流行一直到出现了更现代的象 CORBA 和 DCOM 那样的消息传递解决方案，而且，通常所应用的消息传递只局限于解决几类问题。
目标
在过去的十年中，人们对分布式系统需求有了更深入的理解。新兴技术（象 Java 和 .NET）已经包含了代码分布来作为它们基本编程模型的一部分。通过这样做，这些技术已将高度可用性和容错性融入到消息传递中，同时鼓励那些提供解决方案的供应商交付一些系统，这些系统在更广范围的问题上考虑性能。
近来我们公司被要求实现文件分布和复制的解决方案，在以前这样的方案需要集成安全的 FTP、数据库复制和其它一次性解决方案的定制系统。我们没有一味地埋头按照定制开发的道路前进，而是研究了将最新的消息传递解决方案应用到这个问题的可能性。我们发现 JMS 不仅为信息传送提供必要的基础结构，而且它还能处理我们客户要求的、与服务质量、安全性、可靠性和性能有关的所有基础结构问题。本文描述了我们团队面临的挑战，以及 JMS（以 MQSeries 的形式）如何让我们满足并超越客户的要求。
问题
我们的客户面临一个重大的分布式数据难题，在全国范围内有许多呼叫中心，在全国各地的呼叫中心里接线员要记录与客户之间的交互。必须快速可靠地在远程数据中心为这些记录建立索引并存档。建立索引和存档的存储过程不能影响接线员的系统记录和存储接线员正在与客户交互的信息的能力。该客户已经有了一个包含组合起来的代码、VPN 和其它技术的系统。但是，现有的解决方案远远达不到性能和可靠性上的目标，并且它是一种拙劣的技术，难以理解并且维护费用很高。
在开发替代客户原有系统时，我们考虑了 JMS 和多种非 JMS 的解决方案，尤其是那些基于 FTP 和安全复制（SCP）的解决方案。然而，非 JMS 解决方案有两个主要缺点：
它们对于安全性方面的缺陷一筹莫展。
它们提供的基础结构只适用于实际的数据传送，而对于处理可靠性、容错性、安全性、平台独立性以及性能优化等问题，需要定制开发来解决。
我们团队最后得出结论，对于添加这些额外的特性所需的开发工作是让人望而却步的，因此我们决定选用 JMS 解决方案，它可以摆脱这些问题。
解决方案
我们开发了一个基于 JMS 的系统，它：
为已记录的多媒体文件提供可靠存档
支持可扩展性，可以使多个数据中心接收文件
支持对其它数据类型进行存档
我们这里正讨论的文件比以前那些涉及消息传递解决方案的项目中传送的数据还要大（50K - 500K）。我们第一个任务是确保数据大小不会影响 JMS 解决方案。通过测试系统传递各种大小的消息有效负载时的性能，我们评估了包括 IBM MQSeries 在内的许多 JMS 解决方案。结果显示：经过适当配置，大小达到 1 兆的消息不会对整个系统性能产生显著影响。因为常识认为消息传递解决方案只适用于定期的、小的有效负载，所以我们的结果是一个重大发现。我们继续分析系统的体系结构（图 1 中概述了此体系结构），它可以提供客户需要的安全性、高可用性和可靠性。
图 1. 高级系统体系结构
现有的基础结构在每个客户机上有一个系统，当接线员与用户之间进行交互时，它创建多媒体文件，以此作为响应。此外，还需对这些文件进行存档。我们的系统启动一个进程（运行在每个机器上）并在已知目录中查找这些文件。当检测到新文件时，进程将它们打包成 JMS 有效负载并发送到其中一个数据中心的 JMS 服务器以便传递。一旦 JMS 服务器确认收到，则除去发送方中的这些文件。JMS 服务器将该数据传送到数据中心内的一个可用处理程序上，进行存档。