"ObjectMessage usage is generally discouraged"，用什么代替？
"ObjectMessage usage is generally discouraged", what to use instead?
ActiveMQ 文档state:
Although ObjectMessage usage is generally discouraged, as it
introduces coupling of class paths between producers and consumers,
ActiveMQ supports them as part of the JMS specification
由于对消息总线没有太多经验，我一直认为它们在概念上类似于 SOAP Web 服务，您可以在其中为消费者指定服务接口契约，然后消费者构建等效的 class 代理。
我想要实现的是：
- 发布者以某种方式指示消息的架构
- 订户以某种方式知道消息的架构
ObjectMessage 解决了这个问题，尽管考虑到著名的 class 路径耦合，这不是最好的方式。据我所知，其他消息类型为消费者提供了关于预期消息格式的最少指导（例如，消费者必须假设 MapMessage 包含具有特定值类型的特定键）。
是否有另一种合理的方法来实现这一目标，或者这甚至不是我应该追求的目标？
因为这个想法是为了 publishers/subscribers 了解架构。第一步是使用 JSON/protobuf 确定有效负载的结构。 （个人不是 XML 的忠实粉丝）。然后我们将数据作为 TextMessage / BytesMessage 传递。
虽然这个想法是为了 publishers/subscribers 传达架构。实现此目的的几种方法：
- 订阅者通过发布者的 javadoc 或示例调用了解架构。 （对于简单的用例来说听起来不错）
- 有一个集中的配置来发布发布者和订阅者以从中获取。此配置可能位于提供配置的数据库/应用程序中。有效的实施将确保 publisher/subscriber 不会在有修改时中断。
此方法相对于对象消息方法的优点：
- 有效负载没有紧密耦合（即 jar upgrades/attribute 更改等）
- 显着的性能改进 - 这是一个 example，其中 Java class 与字符串和 int 比直接将 int 和字符串存储为字节多 3.7 倍。
ActiveMQ 文档state:
Although ObjectMessage usage is generally discouraged, as it introduces coupling of class paths between producers and consumers, ActiveMQ supports them as part of the JMS specification
由于对消息总线没有太多经验，我一直认为它们在概念上类似于 SOAP Web 服务，您可以在其中为消费者指定服务接口契约，然后消费者构建等效的 class 代理。
我想要实现的是：
- 发布者以某种方式指示消息的架构
- 订户以某种方式知道消息的架构
ObjectMessage 解决了这个问题，尽管考虑到著名的 class 路径耦合，这不是最好的方式。据我所知，其他消息类型为消费者提供了关于预期消息格式的最少指导（例如，消费者必须假设 MapMessage 包含具有特定值类型的特定键）。
是否有另一种合理的方法来实现这一目标，或者这甚至不是我应该追求的目标？
因为这个想法是为了 publishers/subscribers 了解架构。第一步是使用 JSON/protobuf 确定有效负载的结构。 （个人不是 XML 的忠实粉丝）。然后我们将数据作为 TextMessage / BytesMessage 传递。
虽然这个想法是为了 publishers/subscribers 传达架构。实现此目的的几种方法：
- 订阅者通过发布者的 javadoc 或示例调用了解架构。 （对于简单的用例来说听起来不错）
- 有一个集中的配置来发布发布者和订阅者以从中获取。此配置可能位于提供配置的数据库/应用程序中。有效的实施将确保 publisher/subscriber 不会在有修改时中断。
此方法相对于对象消息方法的优点：
- 有效负载没有紧密耦合（即 jar upgrades/attribute 更改等）
- 显着的性能改进 - 这是一个 example，其中 Java class 与字符串和 int 比直接将 int 和字符串存储为字节多 3.7 倍。