Remote JMS Server

Using JMS server (topic/queues) is quite common for pub/sub or any other decoupling design patterns, and we tried putting it in completely different dedicated cluster. Having it in dedicated cluster helps decouple SOA restart from JMS unavailability and also JMS can be scaled much easily. We faced some issue while connecting to remote JMS server, and just wanted to provide two solution which worked out well.

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