Configure Oracle SOA JMSAdatper to Work with WLS JMS Topics

The WebLogic JMS Topic are typically running in a WLS cluster. So as your SOA composites that receive these Topic messages. In some situation, the two clusters are the same while in others they are sepearate. The composites in SOA cluster are subscribers to the JMS Topic in WebLogic cluster. As nature of JMS Topic is meant to distribute the same copy of messages to all its subscribers, two questions arise immediately when it comes to load balancing the JMS Topic messages against the SOA composites:

  1. How to assure all of the SOA cluster members receive different messages instead of the same (duplicate) messages, even though the SOA cluster members are all subscribers to the Topic?
  2. How to make sure the messages are evenly distributed (load balanced) to SOA cluster members?

Here we will walk through how to configure the JMS Topic, the JmsAdapter connection factory, as well as the composite so that the JMS Topic messages will be evenly distributed to same composite running off different SOA cluster nodes without causing duplication.

2. The typical configuration

In this typical configuration, we achieve the load balancing of JMS Topic messages to JmsAdapters by configuring a partitioned distributed topic along with sharable subscriptions. You can reference the documentation for explanation of PDT. And this blog posting does a very good job to visually explain how this combination of configurations would message load balancing among clients of JMS Topics.

Our job is to apply this configuration in the context of SOA JMS Adapters. To do so would involve the following steps:
  • Step A. Configure JMS Topic to be UDD and PDT, at the WebLogic cluster that house the JMS Topic
  • Step B. Configure JCA Connection Factory with proper ServerProperties at the SOA cluster
  • Step C. Reference the JCA Connection Factory and define a durable subscriber name, at composite's JmsAdapter (or the *.jca file)

Here are more details of each step:

Step A. Configure JMS Topic to be UDD and PDT,

You do this at the WebLogic cluster that house the JMS Topic.

You can follow the instructions at Administration Console Online Help to create a Uniform Distributed Topic. If you use WebLogic Console, then at the same administration screen you can specify "Distribution Type" to be "Uniform", and the Forwarding policy to "Partitioned", which would make the JMS Topic Uniform Distributed Destination and a Partitioned Distributed Topic, respectively

Step B: Configure ServerProperties of JCA Connection Factory

You do this step at the SOA cluster.

This step is to make the JmsAdapter that connect to the JMS Topic through this JCA Connection Factory as a certain type of "client".

When you configure the JCA Connection Factory for the JmsAdapter, you define the list of properties in FactoryProperties field, in a semi colon separated list:


You can refer to Chapter 8.4.10 Accessing Distributed Destinations (Queues and Topics) on the WebLogic Server JMS of the Adapter User Guide for the meaning of these properties.

Please note:
  • Except for ClientID, other properties such as the ClientIDPolicy=UNRESTRICTED, SubscriptionSharingPolicy=SHARABLE and TopicMessageDistributionAll=false are all default settings for the JmsAdapter's connection factory. Therefore you do NOT have to explicitly specify them explicitly. All you need to do is the specify the ClientID.
  • The ClientID is different from the subscriber ID that we are to discuss in the later steps. To make it simple, you just need to remember you need to specify the client ID and make it unique per connection factory.
Here is the example setting:

Step C. Reference the JCA Connection Factory and define a durable subscriber name, at composite's JmsAdapter (or the *.jca file)

In the following example, the value 'MySubscriberID-1' was given as the value of property 'DurableSubscriber':
    <adapter-config name="subscribe" adapter="JMS Adapter" wsdlLocation="subscribe.wsdl" xmlns="">
      <connection-factory location="eis/wls/MyTestUDDTopic" UIJmsProvider="WLSJMS" UIConnectionName="ateam-hq24b"/>
      <endpoint-activation portType="Consume_Message_ptt" operation="Consume_Message">
        <activation-spec className="oracle.tip.adapter.jms.inbound.JmsConsumeActivationSpec">
          <property name="DurableSubscriber" value="MySubscriberID-1"/>
          <property name="PayloadType" value="TextMessage"/>
          <property name="UseMessageListener" value="false"/>
          <property name="DestinationName" value="jms/MyTestUDDTopic"/>

You can set the durable subscriber name either at composite's JmsAdapter wizard,or by directly editing the JmsAdapter's *.jca file within the Composite project.

2.The "atypical" configurations:

For some systems, there may be restrictions that do not allow the afore mentioned "typical" configurations be applied. For examples, some deployments may be required to configure the JMS Topic to be Replicated Distributed Topic rather than Partition Distributed Topic. We would like to discuss those scenarios here:

Configuration A: The JMS Topic is NOT PDT

In this case, you need to define the message selector 'NOT JMS_WL_DDForwarded' in the adapter's *.jca file, to filter out those "replicated" messages.

Configuration B. The ClientIDPolicy=RESTRICTED

In this case, you need separate factories for different composites. More accurately, you need separate factories for different *.jca file of JmsAdapter.



Nice Article.

Can you please let me know how to configure the durable subscribers for AQJMS provider. Here the topics resides on a different weblogic server and we have used Foreign destinations to establish the connectivity via AQJMS CF. Can you suggest how to create durable subscribers?

Posted by guest on January 28, 2013 at 01:33 AM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.


« July 2016