Prior to Oracle's acquisition of BEA, the underlying application server for Oracle SOA Suite and many Oracle applications such as E-Business Suite, JD Edwards was Oracle Internet Application Server (aka OC4J).
As a result, it is a common requirement for Oracle Service Bus to consume messages that have been published to OC4J. In this recipe, we will configure a proxy service on Oracle Service Bus to consume messages published to a JMS provider running on OC4J.
The core of this recipe requires us to configure Oracle Service Bus and its Java Naming and Directory Interface (JNDI) provider in the WebLogic server to access a remote JNDI provider (on OC4J). Once configured, we can then implement a proxy service to consume JMS messages as if it was on a local queue.
For this recipe, we have assumed you have a working knowledge of the OC4J JMS provider, WebLogic server, and JMS itself.
To prepare for this recipe, make sure you have access to the OSB server's console and the console of your JMS provider, as you'll need access to the required Java libraries.
To configure OSB to connect to OC4J, you will need to have the JNDI details of a connection factory and queue (or topic) on OC4J.
You need to ensure that Oracle Service Bus has access to the same Java client libraries as any normal JMS client would. For OC4J, you will need the following JAR files:
oc4j-internal.jar
optic.jar
These are located in the [OC4JHOME]/j2ee/home/lib
directory.
lib
directory of your OSB domain; this should be located at the following location:[ORACLE_HOME]/user_projects/domains/[OSB DOMAIN]/lib
setDomainEnv.sh
(or .cmd
for Windows) file in the following location:[ORACLE_HOME]/user_projects/domains/[OSB DOMAIN]/bin
setDomainEnv.sh
or setDomainEnv.cmd
file (all in one line):export CLASSPATH=$CLASSPATH${CLASSPATHSEP}${DOMAIN_HOME}/lib/optic.jar${CLASSPATHSEP}${DOMAIN_HOME}/lib/oc4j-internal.jar
setDomainEnv.cmd
with a line like the following:set CLASSPATH=%CLASSPATH%%CLASSPATHSEP%%DOMAIN_HOME%/lib/optic.jar%CLASSPATHSEP%%DOMAIN_HOME%/lib/oc4j-internal.jar
Click on New and give it a descriptive name (IAS in the following example), click on Next where you should target this to the OSB server or cluster, and click on Finish.
This will take you to the JNDI configuration window; here we need to specify the JNDI client details of our OC4J JMS provider, as shown in the following table:
Property |
Value |
---|---|
Initial Context Factory |
|
Provider URL |
|
User |
Username of an account with privileges to access these JMS resources on your OC4J server |
Password/Confirm Password |
The password for the user |
Your foreign JNDI provider should look somewhat like the following screenshot:
Click on the Links tab of the foreign JNDI provider you created previously, and click on New. Give the link a descriptive name for the queue or topic that you're going to link into your OSB's JNDI tree.
For Local JNDI Name, enter a JNDI name for which this resource will appear in OSB's JNDI tree.
For Remote JNDI Name, enter the JNDI name of the resource in your JMS provider's JNDI tree. Once this is done, click on OK.
Repeat this process to create a link for the connection factory of the queue or topic. Once completed, our Foreign JNDI Links window should look somewhat like the screenshot, shown as follows:
Where LINKCF
and LINKQUEUE
are the local JNDI names of the connection factory and queue respectively, which you have defined in the previous step.
Ensure the correct Destination Type is selected in the next screen and continue with the wizard as usual. For testing purposes, add a simple log or report action step to the pipeline to write out the content of the JMS message.
You an now deploy and test your OSB proxy service; once you have validated that the proxy service is successfully consuming a message from the OC4J JMQ queue, you can then implement the remainder of your proxy service as required.
The foreign JNDI provider and the links work by linking the local names in our JNDI tree to the remote ones we've configured. The important thing to note is that you need to include the classes normally required by this remote JNDI provider to Oracle Service Bus because, even though it's locating the JNDI reference locally, it is still acting as a remote client to the JMS provider. It will make JMS server connections directly to the providing server via the connection factory.
Once configured, the OSB proxy service thinks it's accessing the JMS destination as a local resource.
For those readers more experienced with the WebLogic server, you might note that we had to add the classes to the classpath and not just drop them into the domain's lib
folder; this is because of the WebLogic server's (and Java's) class loading hierarchy. When the WebLogic server loads the JARs in the lib
directory, it loads them as a child to the system class loader for all J2EE applications. We need these classes loaded in the system class loader to be available for the server itself, and so we had to adjust the classpath.
For those readers who have used Oracle's JD Edwards (JDE) product and are not on the WebLogic server yet, this solution would give your OSB installation access to JDE Realtime Events (RTE) and provide a gateway to SOA Suite for performing business logic based on the events in JDE.