JMS 2.0规范说
所述
JMSMessageID报头字段包含唯一标识由提供商发送的每个消息的值.
...和...
唯一性的确切范围是提供者定义的.它应该至少涵盖特定安装提供程序的所有消息,其中安装是一组连接的消息路由器.
规范没有明确声明JMSMessageID从发布API调用返回的内容必须与消息中消息中存在的内容匹配.关于在回复请求时移动JMSMessageID到规范的规范中的讨论JMSCorrelationID意味着两者将是相同的.如果在发布和使用之间更改了消息ID,则此样式的请求/回复将失败.
当然,在JMS 1.1和现在2.0的统一域模型中,JMSMessageID根据目标是队列还是主题,改变行为是没有意义的.在统一的模式下,人们会期望所有目的地在这方面都采取相同的行动.
此外,如果第一段中使用的"提供者"指的是发送消息的内容,那么散布到具有相同JMSMessageID值的10条相同消息的发布将符合规范,因为在发送方测量唯一性.
不幸的是,规范在使用术语"提供者"来描述发送消息的事物与使用它来描述JMS传输的供应商之间切换.这在上面两个引用的段落中很明显.这种模棱两可并不重要.
至少有一个实现(IBM的MQ)采用的方法是,一个发布到10条消息的发布已经创建了10条唯一的新消息,因此每个消息都具有唯一JMSMessageID值.这可以说与第二个引用的段落一致,该段落需要作用于提供者的唯一性,其中"提供者"似乎是指供应商实现而不是发送消息的事物.
我相信,当发布的消息向多个订阅者扇出时,正确的行为将是JMSMessageID在消息的每个实例中保留,以便可以按预期关联回复.换句话说,我认为IBM的实施是不合规的.由于规范在这个问题上是模棱两可的,我正在寻找一个权威的来源,要么直接或强烈地暗示规范所预期的行为,不管是哪种方式.根据响应,我要么退出,要么将IBM的问题作为合规性缺陷提出.
小智 7
这里的术语"提供者"仅仅是对正在使用的特定消息产品的引用,并且涵盖了客户端和服务器端组件.为避免混淆,我将在此处使用JMS产品供应商一词.
JMS规范的目的是定义由该消息传递产品实现的Java API.它使用松散的术语,如"提供者",因为JMS规范没有定义产品的架构方式,并且试图避免建议如何在客户端和服务器端组件之间共享实现,或者甚至是否有服务器(或者服务器集群).您会注意到规范从未(好,几乎从不)说"服务器执行此操作"或"服务器执行此操作".
关于"确切唯一性范围"的句子是为了使JMS产品供应商能够轻松实现生成JMSMessageID值的代码.它说生成JMSMessageID值的代码不需要担心确保生成的值在整个Universe中是唯一的.确保它们对于特定产品安装是唯一的就足够了.
您说"规范没有明确声明JMSMessageID从发布API调用返回的内容必须与消息中消息中存在的内容匹配."
我认为这在第4.4.11节"如何设置消息头值"中说明.这表明它JMSMessageID是由"JMS提供者发送方法"设置的.同一部分继续说"定义为由'JMS提供者发送方法'设置的消息头字段将在发送客户端和接收客户端上可用".
这意味着在返回send()或publish()调用之后,发送应用程序可以使用该方法getJMSMessageID()查找分配给该消息的消息ID.收到此消息后,接收应用程序可以使用相同的方法,并获得相同的值.
发送给主题的每条消息都会传递给该主题的每个订阅者.这些订阅者将收到相同消息的单独副本,具有相同的正文,属性和标题,包括JMSMessageID值.
随意争辩; JMS规范并非没有歧义.