我试图解决设计意见分歧，而我们两个人都没有JMS经验。
当发生新事件时，我们希望使用JMS在j2ee应用程序和独立应用程序之间进行通信。我们将使用单个点对点队列。双方都是基于Java的。问题是是在JMS消息正文中发送事件数据本身还是发送指向数据的指针，以便独立程序可以检索它。详细信息如下。
我有一个j2ee应用程序，它支持新的和更新的人员以及相关事件的数据输入。人员记录和相关事件将被写入Oracle数据库。还有一些独立的独立程序，这些新程序将新人员和事件记录添加到数据库中。当通过5-10个不同的应用程序功能中的任何一个发生新事件时，我需要使用特定于行业的标准消息传递协议通过出站接口通知远程系统。出站接口已设计为独立应用程序，可通过异步操作并将其移至单独的服务器来支持可伸缩性。
输入事件时，j2ee应用程序当前在内存中存储了大多数数据。数据将由大约6个不同的对象组成；一个人对象，一些对象具有多个实例，平均大小在3000到20,000字节之间。一些特殊情况可能是这个数量的很多倍。
从性能和可靠性的角度来看，我应该对JMS消息进行建模以传递创建接口消息所需的所有数据，还是对JMS消息进行建模以使其包含数据的记录键，并让独立的Java应用程序检索要创建的数据接口消息？
最佳答案
我不仅会专注于决策的性能，而且还会关注其他非功能性的考虑因素。
我一直在一个系统上工作，我们决定不发送消息中的数据，而是发送数据库中数据的PK。我们的方法更接近command message模式。我们的选择是出于以下原因：
数据大小：我们会将数据存储在BLOB中，因为它可能会出错。在您的情况下，数据的大小可能适合消息发送。
信息丢失：我们计划更糟。如果消息丢失，我们可以恢复数据，并且有恢复过程可以重新提交消息。看起来可能有些偏执，但是有两种情况可能导致某些消息丢失：（1）错误清除了队列（2）发生错误并且长时间无法传递消息。它们进入无效消息队列（DMQ），如果没有正确配置，该队列最终将达到其限制并开始丢弃消息。
监视：不同的消息/命令可以更新数据库中的同一行。这很容易监视和解决。
但是，使用JMS +数据库确实会使设计变得复杂：
分布式事务：这会增加一些复杂性，有时会some problems。分布式事务与“常规”事务有细微的差异，例如分布式超时。
持久性：代码不太直观。必须首先将数据持久化为具有PK，如果使用ORM，则会导致代码复杂。
我猜这两种方法都行得通。我已经描述了导致我们不发送消息中数据的原因，但是您的系统和要求可能有所不同，因此，根据您的情况，发送消息中的数据可能仍然更加容易。我无法提供确切的答案，但希望它能帮助您做出决定。