Weblogic配置jms服务文档，是自己总结网上搜集到的资料以及自己亲自动手配置测试的总结。

weblogic提供jms消息服务的中间件，功能性能都说得过去，下面是在配置jms服务中注意的问题，以及详细步骤，仅供参考：

单机配置

一、基于点对点的方式配置（QUEUE）

1.先配置持久化存储：例如：c:\sss(必须提前建好该目录)

2. 配置JMS服务器

3. 配置JMS模块

4. 配置子部署

5. 创建队列（JNDI唯一程序段靠JNDI NAME 来获取工厂类和队列）

6. 创建工厂

注：在同一个JMS Module中创建不同的subdeployment，然后ConnectionFactory和Queue要配给不同的subdeployment，ConnectionFactorytarget到你的server，Queue target到JMS Server。

二、基于发布者/订阅者方式的配置（TOPIC）

步骤基本同上，只不过配置jms模块的时候添加topic资源。

注：

消息类型：简单文本 (TextMessage)、可序列化的对象 (ObjectMessage)、属性集合 (MapMessage)、字节流 (BytesMessage)、原始值流 (StreamMessage)，还有无有效负载的消息 (Message)。

注：1.订阅模式接受消息时分为两种情况，一种是同步接收，用receive（）方法来接收消息，即阻塞式接收消息；第二种是异步接收消息，用setMessageListener(TopicSubscriber)方法来给监听消息，同时改接收类实现MessageListener接口，实现其中的onMessage方法来处理接收的消息。整个接收消息的过程是非阻塞的。

2. 发布/订阅模型在可靠性上提供的2种方式：持久订阅模式和非持久订阅模式

非持久订阅模式：只有当客户端处于激活状态，也就是和JMS 服务器保持连接的状态下，才能接收到发送到某个Topic的消息，而当客户端处于离线状态时，则这个时间段发到Topic的消息将会永远接收不到。

持久订阅模式：客户端向JMS 注册一个识别自己身份的ID，当这个客户端处于离线时，JMS 服务器会为这个ID 保存所有发送到主题的消息，当客户再次连接到JMS 服务器时，会根据自己的ID 得到所有当自己处于离线时发送到主题的消息，即消息永远能接收到。

三、配置持久化的发布/订阅模式,能够接受离线消息。

注：1、要支持持久订阅，必须为该连接定义客户端标识符（客户端 ID）。

配置唯一clientID的两种方式：
第一种方法是使用该客户端 ID 配置连接工厂。对于 WebLogic JMS，这就意味着在每个客户端 ID 的配置期间都要添加一个单独的连接工厂。然后应用程序会在 JNDI 中查找它们自己的主题连接工厂，并使用它们来创建包含其自己客户端 ID 的连接。有关使用客户端 ID 配置连接工厂的详细信息。
另外，首选的方法是用于下列情形的，即应用程序可以通过调用下列连接方法，在创建了连接之后在该连接中设置其客户端 ID：

public void setClientID(
String clientID
) throws JMSException

2、为持久订阅创建订阅者

使用下列 TopicSession 方法可以为持久订阅创建订阅者：

public TopicSubscribercreateDurableSubscriber(
Topic topic,
String name
) throws JMSException

public TopicSubscribercreateDurableSubscriber(
Topic topic,
String name,
String messageSelector,
boolean noLocal
) throws JMSException

必须指定正在为其创建订阅者的主题的名称，以及持久订阅的名称。

3、删除持久订阅

要删除持久订阅，请使用下列 TopicSession 方法：

public void unsubscribe(
String name
) throws JMSException

必须指定要删除的持久订阅的名称。

如果出现下列任意情形，则不能删除持久订阅：

TopicSubscriber 在该会话上仍然处于活动状态。

持久订阅收到的消息属于事务，或者尚未在该会话中确认。

还可以在管理控制台中删除持久订阅

四、关于接收消息的反馈模式

1）非事务模式会话：

在非事务处理会话中，创建会话的应用程序会在下表中定义的五个确认模式中任选其一。

表 2-7 用于非事务处理会话的确认模式

确认模式

描述

AUTO_ACKNOWLEDGE

一旦消息处理中返回了应用程序接收方法，Session 对象即确认消息接收。

CLIENT_ACKNOWLEDGE

Session对象依赖于应用程序对已收到的消息调用确认方法。一旦调用该方法，会话将确认所有自上次确认后收到的消息。

该方法允许应用程序通过一次调用接收、处理和确认一批消息。

注意：

在管理控制台中，如果连接工厂的“确认策略”特性设置为Previous，但您希望确认给定会话的所有已接收消息，则请使用最后一条消息调用确认方法。

有关确认策略特性的详细信息，请参阅“管理控制台联机帮助”中的 JDBC 连接工厂: 配置: 常规。

DUPS_OK_ACKNOWLEDGE

一旦消息处理中返回了应用程序接收方法，Session对象即确认消息接收，允许重复确认。

就资源利用情况而言，此模式最高效。

注意：

如果您的应用程序无法处理重复消息，则应避免使用此模式。如果第一次尝试传递消息失败，则可能会发送重复消息。

NO_ACKNOWLEDGE

不需要确认。发送至 NO_ACKNOWLEDGE 会话的消息将立即从服务器中删除。此模式下接收的消息不可恢复，因此，消息可能会丢失，也可能在第一次传递消息失败后传递重复消息。

支持将此模式用于不需要由会话确认确保服务质量且不希望引发关联开销的应用程序。

注意：

如果您的应用程序无法处理丢失或重复消息，则应避免使用此模式。如果第一次尝试传递消息失败，则可能会发送重复消息。

MULTICAST_NO_ACKNOWLEDGE

多播模式且不需要确认。

发送到 MULTICAST_NO_ACKNOWLEDGE 会话的消息与 NO_ACKNOWLEDGE 模式具有相同特征，如前所述。

支持此模式用于希望支持多播但不需要由会话确认来确保服务质量的应用程序。有关多播的详细信息，请参阅在 WebLogic Server 中使用多播。

注意：

仅用于主题。如果您的应用程序无法处理丢失或重复消息，则应避免使用此模式。如果第一次尝试传递消息失败，则可能会发送重复消息。

2）事务模式会话：

在事务处理会话中，在任意给定时刻，只有一个事务处于活动状态。事务期间发送或接收的任意数量的消息将视为原子单元。创建事务处理会话时，将忽略确认模式。应用程序提交事务时，应用程序在事务期间接收的所有消息将由消息传递系统进行确认，应用程序发送的消息也将被接收以进行传递。如果应用程序发生事务回滚，则应用程序在该事务期间接收的消息不会经过确认，其发送的消息也将被放弃。

集群配置

在 WebLogic集群中，可以将普通队列和主题配置成由许多分散在物理机器中的物理目的地组成的分布目的地，从而创建一个高可用性的消息层。连接工厂也可是分布式的。它让WebLogic负载平衡来自JMS客户的连接请求，并透明地将消息流量指向预期的目的地，或是在目的地失效事件中重定向消息。

分布式队列：

分布式队列代表一组物理队列。如果QueueSender是利用分布式队列的JNDI名创建的，那么从QueueSender发送的任何消息都只分发给一个物理队列目的地。每次发送一条消息，通知哪个成员将得到该消息的时候，才进行决策。该决策基于由WebLogic提供的负载平衡算法。默认负载平衡方案是轮询，但是也可以使用随机负载平衡方案来随机将消息分发给目的地成员。

当使用分布式队列名创建QueueReceiver时，它会连接到物理队列成员，而且与QueueSender不同，它会保留到该目的地的连接，直到QueueReceiver失去连接为止。

图1描述了JMS如何在WebLogic集群内与分布式队列交互。在图中，分布式队列（DQ，Distributed Queue）有两个物理队列成员：MQ1和MQ2，它们分别驻留在服务器实例1和实例2上。队列接收者（QR，Queue Receiver）从MQ1得到消息，并在该连接关闭之前一直保留到MQ1的连接。队列发送者（QS，Queue Sender）向分布式队列DQ发送消息。只有一个物理队列成员得到发送给分布式队列的消息，而且如图所示，QS发送的第一条消息，即Message 1，是经过负载平衡的，并被发送给MQ1。下一条消息，即Message 2也经过负载平衡，并被发送给序列中的下一个队列成员MQ2。图示使用了轮询负载平衡策略，该策略按照顺序选取服务器实例。

当消息发送到没有消费者的分布式队列成员时，在消费者可用之前，该消息将一直保留在队列中。而且，如果该队列成员失效，那么该队列中挂起的所有消息在队列成员重新可用之前均不可用。在分布式队列的每个成员上配置转发延迟（Forward Delay）可防止这种情况发生。该选项自动将来自无活跃消费者队列成员的消息转发给有活跃消费者的队列成员。默认情况下，转发延迟是禁止的。我们将在下面讨论如何配置这个目的地参数。

如果某个物理队列成员失效，那么JMSException将通知连接它的所有消费者，这些消费者实际上将失去它们与队列的连接。对于同步消费者，直接将异常返回给客户。对于异步消费者，其队列会话是使用ExceptionListener配置的，所以它将发送一个 ConsumerClosedException。在任何一种情况下，假定失效只限于该物理队列成员，那么JMS连接和会话仍然有效。客户应用程序仅关闭队列接收者，并用同一JMS会话再创建它。

分布式主题

分布式主题代表一组物理主题。JMS客户应用程序可使用分布式主题名创建主题消息生产者和消费者。应用程序不知道分布式主题中有多少个物理目的地成员，所以，在使用这类集群JMS资源时，这消除了任何特定编程考虑。

当以分布式主题名创建的TopicPublisher发布消息时，该消息被自动发送给分布式主题的所有成员，因此所有订户都将收到该消息。即使使用物理主题目的地的JNDI名，而不是使用分布式主题的JNDI名来创建TopicPublisher，也会将消息转发给所有主题成员目的地。

发布到分布式主题的非持久性消息只发送给可用的主题目的地。如果应用程序使用持久性消息，那么使用一个持久存储器来配置每个主题成员目的地是一个不错的主意。当发布一条关于分布式主题的持久性消息来避免丢失消息时，WebLogic偏爱使用持久存储器配置的主题目的地。如果发布持久性消息时有任何主题成员不可用，那么消息将会保存在有持久存储器的主题成员上，并在其余主题成员可用时再转发给它们。

用分布式主题名创建的 TopicSubscriber与分布式主题的一个物理主题成员连接。在目的主题成员失效之前，连接一直有效。如果在这种情况发生时，会向主题订户发送一个JMSException，该异常与目的地队列成员失效时发送的异常一样。如果有活跃订户的主题目的地成员失效，那么在该主题目的地成员可再次获得消息之前，失效之后发送给该分布式主题的任何持久消息都不会分发给断开连接的订户。相反，失去与分布式主题成员连接的订户永远不会获得非持久消息。

图2举例说明了在WebLogic集群中JMS客户如何与分布式主题交互。图中分布式主题（DT，Distributed Topic）由两个物理主题成员T1和T2组成，它们分别驻留在服务器实例1和实例2上。主题订户（TS，Topic Subscriber）从T1获得消息，并且在该连接关闭或丢失之前保持与该主题成员的连接。主题发布者（TP，Topic Publisher）将消息发送给分布式主题（DT，Distributed Topic）。所有物理主题成员都获得发送给该分布式主题的消息。如图所示，TP将消息1发布给分布式主题DT，而DT又将它发送给主题成员T1和T2。下一条消息Message 2也都发送给两个主题成员。

集群连接工厂

连接工厂也可利用JMS集群的能力来提供负载平衡、高可用性和对JMS客户的故障转移。

连接工厂可以以集群为目标，或是以集群中的单个WebLogic实例为目标，而不管那些WebLogic实例是否驻留在一台JMS服务器上。从架构师的角度来看，在决定连接工厂以什么为目标之前，需要考虑应用程序中JMS客户机的物理位置以及它们要访问的目的地。比如，如果外部客户机使用以集群中多个 WebLogic实例为目标的连接工厂，那么关于使用哪个连接工厂以及JMS连接驻留在哪一台JMS服务器的决定是负载平衡的。

如果新的JMS连接以及本地JMS服务器在同一物理机器上，那么连接路由的效率可能会很低。为了避免不必要的连接路由，要确保JMS应用程序中每个连接工厂的Server Affinity参数都被启用。可以通过导航到“Services/JMS/Connection Factories”节点，从WebLogic管理控制台修改该设置。然后从列表中选择连接工厂，滚动到“General”选项卡的底部就可找到“Server Affinity”参数。

相反，如果连接工厂在物理上处于和所期望的目的地驻留的JMS服务器相同的WebLogic 实例上，那么试图定位连接工厂并创建JMS连接的内部JMS客户机就不会招致浪费的远程连接。连接工厂对内部JMS客户机使用的默认负载平衡策略是预防性的，因为WebLogic优先选择配置的连接工厂和JMS服务器，以避免创建远程连接。

配置过程:

一、创建集群。

参考集群创建说明文档创建集群。

二、创建持久化文件。

集群下每一个对应的ManagedServer创建一个相应的持久化文件。

三、创建JMSServer。

每一个对应的ManagedServer创建一个对应的JMSServer并且使用对应的持久化文件。

四、创建分布式连接工厂，主题，队列。

例如：队列

新建一个分布式队列，创建一个对应的子部署目标指向集群。创建成功后查看该队列的子成员出现

集群下的每个Server都创建一个对应的队列说明分布式队列创建成功。

注：具体到每一个太ManagedServer下的队列才是具体的物理队里，分布式队列只是逻辑上的。