Helidon 2.0 Messaging with WebLogic JMS
WebLogic JMS is a widely used messaging system for solutions running on Oracle WebLogic Server. But what if you want to access it from a different platform? It’s actually pretty easy with Helidon’s JMS connector for reactive messaging.
In this article, we’ll walk through a comprehensive working example with dockerized Weblogic. The sample files are located in the Helidon Weblogic JMS demo project. To run WebLogic with sample queues as a local docker container, follow the project’s README.md.
To connect to the WebLogic JMS server we will need the WebLogic thin T3 client (wlthint3client.jar), which is not available in the Maven central repository. The easiest way to obtain it is by cannibalizing our local WebLogic Server installation located inWLS_HOME\server\lib directory.
When working with the demo project, use the script extractThinClientLib.sh for extracting the thin client from the docker container and installing it to the local maven repository for you.
The dependencies needed to connect WebLogic JMS with Helidon MP are the MicroProfile messaging, reactive JMS connector and WebLogic thin T3 client.
Configuration is straight forward. We will use JNDI for localizing and configuring of JMS ConnectionFactory. You’ll also notice the destination property which is used to define queue with WebLogic CDI Syntax(CDI stands for Create Destination Identifier).
When configuring destination with WebLogic CDI, the following syntax needs to be applied:
Non-Distributed Destinations:
jms-server-name/jms-module-name!destination-name
In our example we are replacing jms-server-name with “.” as we don’t have to lookup the server we are connected to.
Uniform Distributed Destinations (UDDs):
jms-server-name/jms-module-name!jms-server-name@udd-name
Receiving the messages follows reactive messaging for getting the JMS metadata. Messaging is then able to inject JmsMessage wrapper with all the properties and header values available. In the demo we are verifying that the SSE broadcaster is available and, if so, we are broadcasting the message payload to all connected SSE clients.
When we build and run the demo app, we can try to send and receive to and from the same WebLogic JMS queue TestQueue by opening simple UI page http://localhost:8080 .
To verify that messages are really flowing through the WebLogic queue, you can open your sample WebLogic Administration Console http://localhost:7001/console with credentials admin/Welcome1.
From the console, navigate to Services>Messaging>JMS Modules>TestJMSModule>TestQueue>Monitoring>Show messages(TestJMSModule!TestQueue)>New
Fill in just the body of the message and click OK. When you switch back to the demo app UI, your message should be there.
As you can see, the connection to WebLogic JMS local destination is really easy, but how do we connect to a distributed destination?
Uniform Distributed Destinations (UDDs)
Once we build and run the sample WebLogic container from the demo with JMS resources populated by setupTestJMSQueue.py script, there are two queues available. The first is the simple TestQueue we used in the previous example, and the second is the UDD queue with two member queues load balanced by RoundRobin. To keep the sample domain simple (single node), member queues are on the same admin node(there are no managed nodes ms1 and ms2).
Let’s tweak a demo project to verify load balancing between UDD member queues. We will create two incoming channels for consuming instead of one this time, each targeted to different member queue. Notice the destination for UDD doesn’t have “./” prefix, because distributed destinations can be served by multiple servers within a cluster.
We will enqueue the messages sent by our send button to UDD queue and consume from two member queues via two channels from-wls-1 and from-wls-2.
Now let’s exchange the consuming method used in the demo for two separate methods as shown in the snippet above. Notice that each one is listening to one of the incoming channels, each one is adding a different prefix before broadcasting to SSE clients “Q1: ” and “Q2: ”. Null check for the sseBroadcaster is omitted for simplicity, let’s assume SSE clients always connect before messages arrive.
When we rebuild and start the demo app again, we can see that message prefixes Q1 and Q2 are taking regular turns as expected from RoundRobin load balancing:
What’s Next?
We are planning to add support for looking up destinations with JNDI to the JMS connector as it is being used a lot by WebLogic JMS users as an alternative to the WebLogic CDI syntax in the future release of Helidon.
So stay tuned, more exciting stuff will be coming with future versions of Helidon.
Happy messaging!
For more info about Reactive Messaging in Helidon, check out the following resources:
