Best Practices from Oracle Development's A‑Team

Oracle SOA Suite for HealthCare – Using Remote JMS with Multiple Domains

Oracle SOA Suite for HealthCare – Using Remote JMS with Multiple Domains

As SOA Suite for HealthCare (HC) gains popularity among providers, I have seen the need to separate the SOA Suite (SOA) and SOA Suite for HealthCare into separate Weblogic domains. Generally this is done for performance reasons; more specifically it is done when the customer has a high transaction throughput rate coupled with relatively short and stringent service level agreements. In a multi-domain architecture such as this, you will need to use a method other than the default, in-memory binding to pass messages between your SOA Composite and HealthCare.

SOA Suite for HealthCare can access JMS queues from other domains in one of three ways: you can setup and use Weblogic’s Store and Forward capability for JMS, you can create a foreign JMS server in the domain and use the local jndi references when creating the queues for HC, or you can specify the details of the remote JNDI location in the Destination Provider attribute of an Internal Delivery Channel (IDC) and include the IDC in your endpoint.

For this article, we will be using the later method where the remote JNDI location is defined in the transport details of the Internal Delivery Channel. I think this is the simplest method to use and since HC persists all of its messages in its own repository, you don’t have to worry about losing them if the remote JMS provider is down. Consider the message flow in the following diagram:

Figure 1 - Message flow across separate HC and SOA Domains

Figure 1 - Message flow across separate HC and SOA Domains

Here messages flow from a single endpoint via MLLP to the HealthCare adapter in the HC domain. The HealthCare adapter processes the message and writes it remotely to the queue RMT_ADM_GENERIC_ADT in the SOA domain. The SOA composite reads the message locally from RMT_ADM_GENERIC_ADT, processes the message, and then writes it to another local queue RMT_LAB_GENERIC_ADT. SOA Suite for HealthCare then reads the message remotely from RMT_LAB_GENERIC_ADT, processes it, and sends it to the target endpoint via MLLP. Here is how to configure a remote JMS queue in SOA Suite for HealthCare.

Transport Details

Either create or open an Internal Delivery Channel (IDC) to be used to access the remote JMS queue. Add the remote JNDI details to the transport protocol parameters of the IDC. Both sending and receiving IDCs can access remote JMS queues. In the IDC, click the Transport Details button to open a pop-up window where the details are entered.


Figure 2 - Adding the Destination Name and Connection Factory to the Internal Delivery Channel

In the Basic tab, add the destination name for the remote JMS queue in the Destination Name field. Next enter the name of the remote Connection Factory used to connect to the queue. Now switch to the Advanced tab.


Figure 3 - Adding the Destination Provider Location, Username, and Password to the Internal Delivery Channel

In the Destination Provider field under the Advanced tab, add the following JNDI destination location details for the remote JMS provider. Here is a sample of what the location information will look like:


Provide the hostname and port number for the remote JMS provider. Add a valid username for the remote location along with the password, then save and enable the channel. After enabling the channel, you should see an additional listener on the remote queue when you look at it in the monitoring tab of the WLS console.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content