This chapter describes how to send JMS messages using the JMS RA.
The JMS RA is a thin wrapper of WebLogic JMS client. Users can choose to configure their connection client-id to be either RESTRICTED or UNRESTRICTED and their subscriptions to be either Sharable or Exclusive.
The JMS RA provides a number of predefined JMS connection factories. Each JMS connection factory interface has its own <connection-definition> element. Each <connection-definition> defines the classes and interfaces as required by the JCA specification and additional configuration properties.
The JMS RA supports the following connection factories:
WebLogic JMS non-XA ConnectionFactory
WebLogic JMS non-XA QueueConnectionFactory
WebLogic JMS non-XA TopicConnectionFactory
WebLogic JMS XA ConnectionFactory
WebLogic JMS XA QueueConnectionFactory
WebLogic JMS XA TopicConnectionFactory
See the <outbound-resourceadapter> element of the ra.xml file in Example of the JMS RA ra.xml File.
The JMS RA supports additional configuration properties that can be set in the ra.xml file or in the JEE container of the foreign application server where the JMS RA is deployed. See JMS RA Outbound Configuration Properties. The following is an example WebLogic XA Connection Factory with additional configuration properties.
Example 6-1 Example WebLogic XA Connection Factory Connection Definition
. . .
<connection-definition>
<managedconnectionfactory-class>
weblogic.jms.ra.WLManagedXAConnectionFactory
</managedconnectionfactory-class>
<config-property>
<config-property-name>LoggerName</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>weblogic.jms.ra</config-property-value>
</config-property>
<config-property>
<config-property-name>LogLevel</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>FINEST</config-property-value>
</config-property>
<config-property>
<config-property-name>group</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<config-property-name>rpResourceLocation</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>
<config-property>
<config-property-name>autoCloseSession</config-property-name>
<config-property-type>java.lang.Boolean</config-property-type>
<config-property-value>false</config-property-value>
</config-property>
<connectionfactory-interface>
weblogic.jms.ra.WLXAConnectionFactoryInterface
</connectionfactory-interface>
<connectionfactory-impl-class>
weblogic.jms.ra.WLXAConnectionFactory
</connectionfactory-impl-class>
<connection-interface>
weblogic.jms.ra.WLXAConnectionInterface
</connection-interface>
<connection-impl-class>
weblogic.jms.ra.WLXAConnection
</connection-impl-class>
</connection-definition>
. . .
The following are connection management limitations:
The WebLogic Automatic JMS Client Failover feature enables JMS client to automatically reconnect to another live server instance in a cluster if a server or network failure occurs. This feature interferes with a JMS RA's ability to associate the best ITMs for managed connections. The JMS RA automatically disables this feature and throws an exception if application code tries to enable automatic reconnect programmatically.
UP/DOWN events are not currently supported at the WebLogic instance level. You also can not create a connection to a specific WebLogic instance. This may result in repeated use of a bad connection as JMS RA connection purging may not immediately identify bad connections before they are resused.
Because UP are not currently supported at the WebLogic instance level, the JMS RA does not support connection rebalancing.
The JMS RA outbound implementation is not aware of the UP/DOWN events of server instances of a WebLogic cluster that an outbound application is communicating with. Because of this limitation:
You may see the continued use of a bad connection as JMSRA connection purging may not immediately identify a bad connection before it is reused.
JMS RA does not automatically re-balance the connections.
A WebLogic cluster consists of multiple WebLogic server instances running simultaneously and working together to provide increased scalability and reliability. A JMS distributed destination usually has a set of members distributed across multiple server instances, with each member hosted by a separate JMS server instance. See "Understanding WebLogic Server Clustering" in Administering Clusters for Oracle WebLogic Server.
The following sections provide information on how the JMS RA load balances outbound WebLogic JMS communication.
The JMS RA supports RMI object load balancing using WebLogic JMS connection factories to creates connections and sessions that point to different WebLogic server instances. See "Load Balancing in a Cluster" in Administering Clusters for Oracle WebLogic Server.
Load balancing to WebLogic Distributed Destinations (DDs) is automatically supported without additional configuration. DDs appear to the JMS RA as a single, logical destination. Both a distributed destination and its members are advertised in WebLogic JNDI. When messages are load balanced to a member of distributed destination on a WebLogic server instance that is different from the instance that the JMS RA's managed connection points to, the Interposed Transaction Manager (ITM) of the managed connection is able to enlist the messages sent to a different WebLogic instance, transparently relaying XA calls to the corresponding transaction coordinator on that instance if necessary.
Note:
Individual distributed topic members must be referenced when creating, using, and unsubscribing a durable subscription.
JMS RA provides outbound XA capability for applications using WebLogic JMS according to the JCA standard. See Transaction Support for Outbound Communication.
Configure the authentication-mechanism element in the ra.xml file. See JCA Security.