Sometimes it's strong needed to deploy JMS resources within an SOA domain, for example, to speed up the server startup, on a different non-SOA cluster. Today I wish to share a short article to explain how to do it.
The starting point is the following set of WebLogic instances: AdminServer, two SOA servers combined in the soa_cluster, and two JMS servers combined in the jms_cluster as well.
In order to demonstrate the approach, a persistent store and JMS Server must be created on every member of the jms_cluster. Our JMS resources will be hosted here.
A JMS Module, which will contain JMS resource definitions, must be created and targeted to the entire jms_cluster. A subdeployment for resource targeting management has to be defined for the module.
Let's define a uniform distributed queue as well as a connection factory inside the module.
The truth is Oracle SOA Suite isn't able to look up any JNDI name defined on another cluster, so the defined before JMS resources aren't available for soa_server1 and soa_server2. The solution is to define a foreign server on the soa_cluster. This server will open access to the JNDI tree of the jms_cluster.
The foreign server must be defined within a JMS Module targeted to the soa_cluster. A connection string to the jms_cluster (t3://server1-host:server1-port,server2-host:server2-port,etc) has to be assigned as the value of the JNDI Connection URL parameter.
The foreign server must contain a pointer on the defined before JMS queue as well as connection factory.
Composite application developers should pick up in JDeveloper a queue, created on the JMS servers JMSServer_1 and JMSServer_2, as they did before. Since the adapter definition file ...JMSAdapter_jms.jca contains only the JNDI name of the queue, and the Local JNDI Name of the defined Foreign Destination is exactly the same as the Remote JNDI Name, developed composite applications still work fine.
In order to get access to the JNDI tree of a different cluster, any composite application must use the defined before connection factory exposed via the foreign server. So, the default JNDI name for the JMS Connection must be replaced.
The JMS JCA adapter, deployed on the SOA cluster, must contain an outbound connection pool with the same name as specified for the JMS Connection in the composite application.
And the JNDI name of the defined before connection factory must be assigned as the value of its ConnectionFactoryLocation attribute.
The testing composite application should be deployed on the SOA Suite cluster. If anyone touches the application, a test instance will be created and successfully executed. A new JMS message will appear in a queue instance of the uniform distributed queue. If send kill -9 to a member of the jms_cluster, messages arrive to another half of the queue.
Well, as we have seen, the SOA Suite domain can be broken into two different parts: processing and message store. If your SOA Suite cluster takes too much time to start, this approach may be considered and implemented.
Would you like to give a 'Like'? Please follow me on Twitter!
The starting point is the following set of WebLogic instances: AdminServer, two SOA servers combined in the soa_cluster, and two JMS servers combined in the jms_cluster as well.
In order to demonstrate the approach, a persistent store and JMS Server must be created on every member of the jms_cluster. Our JMS resources will be hosted here.
A JMS Module, which will contain JMS resource definitions, must be created and targeted to the entire jms_cluster. A subdeployment for resource targeting management has to be defined for the module.
Let's define a uniform distributed queue as well as a connection factory inside the module.
The truth is Oracle SOA Suite isn't able to look up any JNDI name defined on another cluster, so the defined before JMS resources aren't available for soa_server1 and soa_server2. The solution is to define a foreign server on the soa_cluster. This server will open access to the JNDI tree of the jms_cluster.
The foreign server must be defined within a JMS Module targeted to the soa_cluster. A connection string to the jms_cluster (t3://server1-host:server1-port,server2-host:server2-port,etc) has to be assigned as the value of the JNDI Connection URL parameter.
The foreign server must contain a pointer on the defined before JMS queue as well as connection factory.
Composite application developers should pick up in JDeveloper a queue, created on the JMS servers JMSServer_1 and JMSServer_2, as they did before. Since the adapter definition file ...JMSAdapter_jms.jca contains only the JNDI name of the queue, and the Local JNDI Name of the defined Foreign Destination is exactly the same as the Remote JNDI Name, developed composite applications still work fine.
In order to get access to the JNDI tree of a different cluster, any composite application must use the defined before connection factory exposed via the foreign server. So, the default JNDI name for the JMS Connection must be replaced.
The JMS JCA adapter, deployed on the SOA cluster, must contain an outbound connection pool with the same name as specified for the JMS Connection in the composite application.
And the JNDI name of the defined before connection factory must be assigned as the value of its ConnectionFactoryLocation attribute.
The testing composite application should be deployed on the SOA Suite cluster. If anyone touches the application, a test instance will be created and successfully executed. A new JMS message will appear in a queue instance of the uniform distributed queue. If send kill -9 to a member of the jms_cluster, messages arrive to another half of the queue.
Well, as we have seen, the SOA Suite domain can be broken into two different parts: processing and message store. If your SOA Suite cluster takes too much time to start, this approach may be considered and implemented.
Would you like to give a 'Like'? Please follow me on Twitter!
No comments:
Post a Comment