我想以 与经纪人无关的 方式从Java SE应用程序创建JMS连接。
我正在将JDBC与它的URL方案进行数据库连接比较。这会创建与实际实现的独立性。
对于JMS，我没有找到类似的东西。我知道在Java EE中，JNDI将扮演这个角色，但这就是Java SE。
我不想将代码绑定到任何特定的队列代理，因为我的需求是非常简单的JMS 1.1发送/接收文本消息。
我也看过Spring Boot，因为它通常擅长提供某种程度的不可知论性。但是即使使用Spring Boot，我也看不到这种可能性。
答案 0 :(得分：1)
JNDI 是您编写JMS应用程序以与代理无关的方式进行连接的方式。 JNDI客户端类是Java SE的一部分。 Spring和非Spring Java SE应用程序都使用JNDI进行这种集成。
任何JMS实现都应提供可插入您的应用程序的JNDI实现。通常，这是通过在您的类路径上放置一个名为jndi.properties的文件并将您正在使用的JNDI实现的正确配置放入该文件中来完成的。创建空的InitialContext时，将自动读取类路径上的jndi.properties文件。 jndi.properties中的key = value对被放入InitialContext中，这样当您执行查找时，所有内容都可以与您选择的实现一起使用。如果您愿意，也可以通过a constructor向InitialContext提供实现特定的详细信息，从而以编程方式配置它。
通过在Java SE应用程序中使用JMS和JNDI API，并将特定于代理的连接详细信息外部化到jndi.properties文件中，可以有效地将应用程序与特定于代理的代码隔离开，从而可以部署应用程序并进行工作与不同的经纪人一起对属性文件进行一些简单的更改。
JNDI客户端实现将来自提供JMS实现的任何人。 JNDI客户端本质上是以打包在jar中的javax.naming.spi.InitialContextFactory实现的形式出现的，通常会有描述可用属性的文档。
以下是一些示例：
org.apache.activemq.jndi.ActiveMQInitialContextFactory中提供activemq-client-<version>.jar可用。文档可用here。org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory中提供了artemis-jms-client-<version>.jar。文档可用here。需要明确的是，JMS规范并不需要要求使用JNDI来查找管理对象，而是建立了惯例和 expectation < / em> JMS提供者将这样做。 JMS 1.1规范的第4.2节规定：
尽管受管理对象的接口并不明确依赖于JNDI，但JMS建立了约定，即JMS客户端通过使用JNDI在命名空间中查找它们来找到它们。
后来说：
期望JMS提供程序将提供管理员在JNDI名称空间中创建和配置托管对象所需的工具。 JMS 受管理对象的提供程序实现应同时为javax.naming.Referenceable和java.io.Serializable，以便可以将其存储在所有JNDI命名上下文中。
根据我的经验，JMS提供者通常渴望提供JNDI实现，因为没有它，它们将没有竞争力，因为任何替代解决方案都将不符合标准，并且会迫使用户实现不可移植的代码。
如果遇到不提供JNDI实现的提供程序，则可以按照ActiveMQ 5.x，ActiveMQ Artemis和Qpid JMS使用的相同模式来实现自己的提供程序。这3种实现方式仅在客户端，并且仅基于提供给InitialContext的配置实例化管理对象。大部分代码都是样板代码，不是很简单。