过去，我研究并使用了IBM的MQSeries和WebSphere MQ软件。它似乎是在不同位置连接两个公司的两个应用程序的好解决方案：每个公司的应用程序可以与本地机器上的MQSeries发出消息，MQSeries将其运送到另一家公司的机器，并且该应用程序在那一边将在本地接收消息。
快进到今天：我不再为IBM工作，但是我正在尝试解决类似的问题。我的应用程序每天需要发送几条消息，每条几个或以下几个MB或以下的信息，并在远程公司的应用中收到类似数量的较小的答复。
。消息排队中间件仍然是满足这种架构需求的好解决方案吗？我一直在尝试使用RabbitMQ原型，但是上述似乎与RabbitMQ有关。我是在吠叫错误的兔子洞吗？
确保可以 - 如果远程公司打算为他人而不是您提供相同的服务。
也许WMQ低延迟是您需要的，因为没有服务器。
- WebSphere MQ低潜伏期消息与传统的WebSphere产品（例如WebSphere MQ，WebSphere Message Broker和WebSphere Application Server）不同，因为没有安装和配置的产品基础结构，例如队列管理器，消息经纪人，消息经纪人或应用程序服务器。因此，没有要监视，测量和管理的特定产品组件。
http://www-03.ibm.com/software/products/en/wmq-llmhttp://pic.dhe.ibm.com/infocenter/wllm/v2r5/index.jsp?topic=/com.ibm.wllm.doc/introdculttowebspheremqpheremqlowlowlowlatencymessgency.html
html当然，一个简单的安息界面可能能够提供相同的功能。
我不建议编写TCP插座应用程序 - 当那里有这么多产品会为您带来沉重和重量的提升时，为什么所有这些中期举重？您只想轻巧举起 - 发送请求，获取响应-6 2甚至一遍。
您需要征服您的要求列表重新汇总： - 可靠性 - 如果请求或响应丢失，这有多关键？ - 可恢复性 - 如果应用程序崩溃，可以恢复机上消息并讨厌吗？ - 往返时间 - 潜伏期的一侧 - 1：1服务？多对一？
我希望这会有所帮助。dave
WebSphere MQ仍然可以解决您的问题...我认为该方案是指向与请求响应方案的点通信。您可以使用一些相对较新的东西，例如JMS，可以与您的应用程序融为一体。
但是，如果您非常确定它只有2个应用程序可以彼此通信并且没有网络问题会出现，则可以进行简单的套接字通信。
解决问题的另一种方法是在两个应用程序之间共享一个共同的数据库。