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:

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.

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.