JMSMessageID是否应该在发布和订阅之间更改? [英] Should the JMSMessageID change between publish and subscribe?

问题描述

JMS 2.0规范说

The JMS 2.0 specification says

JMSMessageID标头字段包含一个唯一的值 标识提供者发送的每条消息.

The JMSMessageID header field contains a value that uniquely identifies each message sent by a provider.

...和...

唯一性的确切范围由提供者定义.至少应该 涵盖有关提供商的特定安装的所有消息，其中 安装是一组连接的消息路由器.

The exact scope of uniqueness is provider defined. It should at least cover all messages for a specific installation of a provider where an installation is some connected set of message routers.

规范未明确声明从发布API调用返回的JMSMessageID必须与消息中使用的消息中的JMSMessageID相匹配.规范中有关在回复请求时将JMSMessageID移至JMSCorrelationID的讨论意味着两者将是相同的.如果在发布和使用之间更改了消息ID，则这种请求/答复样式将失败.

The specification does not explicitly state that the JMSMessageID returned from the publish API call must match the one present in the message when it is consumed. The discussion in the spec about moving the JMSMessageID to the JMSCorrelationID when replying to a request implies that the two would be the same. If the message ID was changed between publication and consumption, this style of request/reply would fail.

当然，在JMS 1.1和现在的2.0的统一域模型中，JMSMessageID的行为根据目的地是队列还是主题而改变是没有意义的.在统一模式下，人们希望所有目的地在这方面都采取相同的行动.

Certainly in the unified domain model of JMS 1.1 and now 2.0, it would not make sense for the behavior of the JMSMessageID to change depending on whether the destination is a queue or a topic. Under the unified model, one would expect all destinations to act alike in this regard.

此外，如果在第一段中使用的提供者"是指正在发送消息的事物，那么由于测量了唯一性，因此将扇出成10个具有相同JMSMessageID值的相同消息的出版物将符合规范.在发送方.

Also, if "provider" as used in the first paragraph refers to the thing that is sending messages, then a publication that fanned out to 10 identical messages, with identical JMSMessageID values, would meet the spec since uniqueness is measured at the sending side.

不幸的是，该规范在使用术语提供者"来描述发送消息的事物与使用它来描述JMS传输的卖方之间自由地进行了切换.这在上面两个引用的段落中很明显.这种歧义无济于事.

Unfortunately, the specification liberally switches between using the term "provider" to describe the thing sending messages versus using it to describe the vendor of the JMS transport. This is evident in the two quoted passages above. This ambiguity doesn't help matters any.

至少有一个实现(IBM的MQ)采用的方法是，发布成10条消息的出版物创建了10条唯一的新消息，因此，每个消息都有唯一的JMSMessageID值.可以说这与第二个引用的段落是一致的，该段落要求在提供者范围内具有唯一性，其中提供者"似乎是指卖方实现，而不是指发送消息的事物.

At least one implementation (IBM's MQ) takes the approach that a publication fanning out to 10 messages has created 10 unique, new messages, and therefore each of these has a unique JMSMessageID value. This is arguably consistent with the second quoted passage which requires uniqueness scoped to the provider, where "provider" appears to refer to the vendor implementation and not the thing sending messages.

我相信，当发布的消息散发给多个订户时，正确的行为将是JMSMessageID将保留在消息的每个实例中，以便可以按预期将回复相关.换句话说，我相信IBM的实现是不合规的.由于规范在此问题上含糊不清，因此我正在寻找一种权威性的来源，该来源要么明确说明要么强烈暗示规范所预期的行为(一种方式或另一种方式).根据响应，我要么袖手旁观，要么提出IBM作为合规性缺陷的问题.

It is my belief that when a published message fans out to multiple subscribers the correct behavior would be that the JMSMessageID would be preserved in each instance of the message so that replies can be correlated as expected. In other words, I believe IBM's implementation to be non-compliant. Since the specification is ambiguous on the matter, I'm looking for an authoritative source which either states outright or strongly implies the behavior as intended by the spec, one way or the other. Depending on the response, I'll either stand down, or else raise the issue with IBM as a compliance defect.

推荐答案

此处的提供者"一词只是对所使用的特定消息传递产品的引用，涵盖了客户端和服务器端组件.为避免混淆，我将在此处使用"JMS产品供应商"一词.

The term "provider" here is simply a reference to the specific messaging product being used, and covers both client-side and server-side components. To avoid confusion, I'll use the word JMS product vendor here.

JMS规范的目的是定义由该消息传递产品实现的Java API.它使用诸如"provider"之类的宽松术语，因为JMS规范未定义产品的架构，并且正在尝试避免建议应如何在客户端和服务器端组件之间共享实现，甚至是否建议使用服务器(或服务器群集).您会注意到该规范永远不会(嗯，几乎永远不会)说服务器执行此操作"或服务器执行该操作".

The purpose of the JMS specification is to define a Java API implemented by that messaging product. It uses loose terms like "provider" because the JMS spec does not define how the product is architected and is trying to avoid suggesting how the implementation should be shared between client-side and server-side components, or even whether there is a server (or cluster of servers) at all. You'll notice the spec never (well, almost never) says "the server does this" or "the server does that".

这里有关于唯一性的确切范围"的句子，使JMS产品供应商可以轻松实现生成JMSMessageID值的代码.就是说，生成JMSMessageID值的代码无需担心确保所生成的值在整个Universe中是唯一的.确保它们对于特定的产品安装是唯一的就足够了.

The sentence about the "exact scope of uniqueness" is there to make it easy for the JMS product vendor to implement the code that generates JMSMessageID values. It's saying that the code that generates JMSMessageID values doesn't need to worry about ensuring that the values generated are unique across the entire universe. It's sufficient to ensure that they are unique to that particular product installation.

您说规范没有明确声明从发布API调用返回的JMSMessageID必须与消息中使用的消息中的JMSMessageID相匹配".

You say that "The specification does not explicitly state that the JMSMessageID returned from the publish API call must match the one present in the message when it is consumed."

我认为这在第4.4.11节如何设置消息头值"中进行了说明.这表明JMSMessageID由"JMS提供程序发送方法"设置.同一部分继续说:定义为'JMS提供者send方法设置的消息头字段将在发送客户端和接收客户端上都可用."

I think this is stated in Section 4.4.11 "How message header values are set". This states that the JMSMessageID is set by the "JMS provider send method". The same section goes on to say that "Message header fields that are defined as being set by the 'JMS provider send method' will be available on the sending client as well as on the receiving client."

这意味着在返回对send()或publish()的调用之后，发送应用程序可以使用方法getJMSMessageID()查找分配给该消息的消息ID.收到此消息后，接收应用程序可以使用相同的方法，并获得相同的值.

This means that after the call to send() or publish() has returned, the sending application can use the method getJMSMessageID() to find the message ID that was assigned to that message. When this message is received, the receiving application can use the same method, and get the same value.

发送到主题的每条消息都传递给该主题的每个订户.这些订阅者将收到具有相同正文，属性和标头(包括JMSMessageID值)的同一封邮件的单独副本.

Each message sent to a topic is delivered to every subscriber on that topic. These subscribers will receive a separate copy of the same message, with the same body, properties and headers, including JMSMessageID value.

可以自由辩论； JMS规范并非没有歧义.

Feel free to argue; the JMS spec is not free of ambiguities.

这篇关于JMSMessageID是否应该在发布和订阅之间更改?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！