Until this point, we have only used modules deployed to WebLogic Server to exchange information, mostly relying on the HTTP protocol using RESTful or SOAP based web services, but there are scenarios when you need some other functionalities on your messaging layer, such as transparent persistence, ways to send messages to multiple clients, and recovery alternatives for lost messages. Well, there are numerous features that can be leveraged by servers and clients depending on specific messaging needs. In this chapter, we are going to focus on a situation when you don't have the necessary infrastructure—or business demand—to run an application server instance on both sides. When this is the case, we can create a standalone Java client and use some of the features made available by WebLogic to enable remote communication between the server and the standalone module, which in this context is called a remote client.
In this chapter we will:
Before we dive into the details of JMS, let's take a quick look at some of the client modules that are available for use when creating applications that access WebLogic Server's features but are attached to JVMs that aren't running a WebLogic Server instance. A client module library is just a JAR library that enables a set of WebLogic features such as access to EJBs, JMS components, and others. While developing an application that will access WebLogic, you must choose a client that's best for your scenario and distribute it along with your binaries.
In the following sections, we will see the most commonly adopted client libraries, along with their description.
T3 is the proprietary transport protocol used by WebLogic Server to carry data between its nodes, and can also be used by clients to communicate with the server. With this library attached to your project, you can execute the most common EJB-related actions such as JNDI lookup, transaction participation and queuing and consuming JMS messages.
This should be the preferred way to connect to a server, as it implements some features that greatly improve communication - for example, it keeps an open connection between two points by sending regular heartbeats, and uses packet multiplexing to increase network efficiency.
Only when you need very specific features, such as administrative operations (to shut down an instance, or deploy a package, for instance), or when the scope of features you need is very narrow (for example, just to post or consume a JMS message) should you resort to other client libraries.
The RMI thin client doesn't use the T3 protocol, leaving all RMI-related work to the Java SE where the application is running, so you have a smaller set of functionalities than the one exposed by the Thin T3 client and a not-so-optimized channel of communication. The RMI-related work is done by the Java SE's Java Remote Method Protocol (JRMP) protocol.
The most common need that justifies the RMI client over the T3 one is when you have to use SSL over an HTTP channel to communicate with the server, as the T3 client doesn't support this configuration.
The JMS thin client is an add-on to the
RMI client, wlclient.jar
, which adds JMS features on top of it, again, using the JSE's RMI stack.
To use this client, you must add a reference to the wljmsclient.jar
file. This library depends on another one, wlclient.jar
, but you don't need to explicitly reference the latter as the former has a classpath
link to it. By default, they are located at the same location inside the WebLogic Server installation - /server/lib
, so the reference is automatically satisfied. If this is not the case, you must reference both manually.
When using a JMS remote client, a direct connection to WebLogic must be present in order to publish messages to a queue or topic; if this is not the case, the client application must deal with this scenario, probably storing the messages locally until the connection is available again, inserting an unnecessary development overhead.
To help developers deal with this problem, WebLogic Server has a feature called Store-and-Forward (SAF) that takes care of the messages when a connection is not available, and automatically transmits them when communication is back online.
To enable this feature, the client must use a specific library, wlsafclient.jar
; it is an add-on to the JMS thin client described earlier that enables the SAF client feature. So, in order to use it, you also have to package the wljmsclient.jar
and wlclient.jar
libraries along with your code. Again, the libraries have internal references to each other, so if you add a reference to wlsafclient.jar
from its original folder, the dependencies are automatically satisfied.
We will see how to implement a SAF client later in this chapter.
The JMS T3 SAF client's role is exactly the same as that of the previous one, that is, the JMS SAF client, wlsafclient.jar
, the difference being that it adds the SAF client features to the T3 thin client.
The full client has the most complete set of features you can wish for. It actually has most of the modules that compose the WebLogic Server packaged as a single library. There are some exceptions; for instance, the cryptoj.jar
library has a self-integrity check that would fail if changed.
If you have any prior experience with WebLogic client development, you probably attached the weblogic.jar
library to your client package. This library is still available, but the official recommendation is to generate and use the wlfullclient.jar
file if none of the other clients fit your needs.
When you install WebLogic Server, this library doesn't exist, so you have to run a utility in order to create it:
$MW_HOME/ wlserver/server/lib
.java –jar wljarbuilder.jar
wlfullclient.jar
file with 60 MB of binary code.It is indeed a large file, so you may want to double-check your needs to see if any of the other clients works for you—if you need to create an applet, for instance, this client is most definitely not the best way to go, due to its size. To its advantage, the full client is more scalable than its little brothers and covers more WebLogic features, although you will seldom need all its power.
The JMX client is the last client module and is a very specific one as it is targeted to clients that want to access WebLogic's MBeans. MBeans are components that expose information about the application server and its components and allow the consumer to change some of them.
An MBean is a Java framework to expose components that can be used to manage Java platform resources. To give you an idea of the potential of this client, think about what you can accomplish using WebLogic's administration console. There's a lot of functionality there, right? The console is just a frontend to the same MBeans we can access and manage using JMX.
Here's a sample code showing how to use this client library to open a connection to a WebLogic instance, and to query the name and state of the servers of the domain it connected to:
void run() throws Exception { JMXConnector connector; MBeanServerConnection conn; // Create the appropriate context parameters Hashtable<String, String> env = new Hashtable<>(); env.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote"); env.put(Context.SECURITY_PRINCIPAL, "weblogic"); env.put(Context.SECURITY_CREDENTIALS, "welcome1"); // Create a JMX connection JMXServiceURL url = new JMXServiceURL("t3", "localhost", 7001, "/jndi/weblogic.management.mbeanservers.domainruntime"); // Open the connection connector = JMXConnectorFactory.connect(url, env); conn = connector.getMBeanServerConnection(); // Query and print objects ObjectName drs = new ObjectName( "com.bea:Name=DomainRuntimeService," + "Type=weblogic.management.mbeanservers.domainruntime." + "DomainRuntimeServiceMBean"); ObjectName[] servers = (ObjectName[]) conn.getAttribute(drs, "ServerRuntimes"); for(ObjectName server: servers) { System.out.print("Instance " + conn.getAttribute(server, "Name")); System.out.println(" is " + conn.getAttribute(server,"State")); } // Shutdown connector.close(); }
Most of the code deals with the opening of a properly configured connection to the server, then we query MBean objects and its values using the getAttribute
method, and finally close the connection. Remember that T3 uses heartbeats to keep a connection alive, so it's a good practice to always release it at the end of your process.
As it happens with the JMS client module, this one also needs the wlclient.jar
library explicitly referenced or available in the same folder of wljmxclient.jar
in order to function properly.