Basic layout: Below diagram describes separate SOA and JMS servers. Topic and Connection Factories are created on JMS server. Composite and JMS adapters are running on SOA servers.
Solution 1:Configure JMS adapter (eis/jms/DemoJMSAdapter) with remote server settings as below (Note: Exactly the same settings will be applied if you would be using stand alone JMS java client).
e.g. java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://host1:port1,host2:port2;java.naming.security.principal=weblogic;java.naming.security.credentials=welcome1
- Factory properties, username and password remains blank if connection factory and topic are locally available to SOA cluster, but in our case, we have to provide Factory Properties so that it can lookup jms/DemoTopicCF in remote JMS server (jms_server1)
- JCA file inside the composite will have no extra settings. It will point to eis/jms/DemoJMSAdapter and jms/DemoTopic
Solution 2:
Configure Foreign JNDI provider for soa_server1, so topic and connection factory can be used just like local resources inside soa_server1.
a) configure Foreign JNDI provider (target it to soa_server1) and provide the connection detail for jms_server1 as below.
b) configure link for jms/DemoTopic and jms/DemoTopicCF
Note: in my case, jms_server1 and soa_server1 are still in same domain so somehow it didn't let me reuse JNDI name, but if they are in different domain same name can be used.
c) Configure JMS Adapter and Composite JCA as local resource
JCA file will point to eis/jms/DemoJMSAdapter and jms/local/DemoTopic.
Comparison:
- Solution 1 is easier and straight forward to configure. Solution 2 requires extra set of configuration
- In long term, if you are using multiple topic and queues, solution 2 might provide better solution with centralized authentication details
- If you are in same domain, solution 2 has another problem of duplicate JNDI, so extra set of JNDI is required
