Developing a WebLogic Full Client

For WebLogic Server 10.0 and later releases, client applications need to use the wlfullclient.jar file instead of the weblogic.jar. A WebLogic full client is a Java RMI client that uses BEA’s proprietary T3 protocol to communicate with WebLogic Server, thereby leveraging the Java-to-Java model of distributed computing. For information on developing RMI applications, see Understanding WebLogic RMI. You cannot integrate clients written in languages other than Java.

Requires the wlfullclient.jar in your classpath.
Uses an URL in the form of t3://ip address:port for the initial context.
Is faster and more scalable than IIOP clients.
Supports most WebLogic Server-specific features.
Supports WLS clustering.
Supports most JavaEE features.
Supports WebLogic JMS, JMS SAF clients, and JMS C clients.

Developing a WebLogic Full Client

Generate the wlfullclient.jar file for client applications using the JarBuilder tool. See Using the WebLogic JarBuilder Tool.
Obtain a reference to the remote object.

Get the initial context of the server that hosts the service using a T3 URL.
Obtain an instance of the service object by performing a lookup using the initial context. This instance can then be used just like a local object reference.

Call the remote objects methods.

package examples.rmi.hello;

import java.io.PrintStream;
import weblogic.utils.Debug;
import javax.naming.*;
import java.util.Hashtable;

/**
* This client uses the remote HelloServer methods.
*
* @author Copyright (c) 1999-2004 by BEA Systems, Inc. All Rights Reserved.
*/
public class HelloClient {

private final static boolean debug = true;

/**
* Defines the JNDI context factory.
*/
public final static String JNDI_FACTORY="weblogic.jndi.WLInitialContextFactory";

int port;
String host;

   private static void usage() {
   System.err.println("Usage: java examples.rmi.hello.HelloClient " +
      "<hostname> <port number>");
   System.exit(-1);
   } 

   public HelloClient() {}

   public static void main(String[] argv) throws Exception {
      if (argv.length < 2) {
      usage();
     }
   String host = argv[0];
   int port = 0;
   try {
      port = Integer.parseInt(argv[1]);
      }
   catch (NumberFormatException nfe) {
      usage();
      }
   try {

      InitialContext ic = getInitialContext("t3://" + host + ":" + port);

      Hello obj = 
         (Hello) ic.lookup("HelloServer");
      System.out.println("Successfully connected to HelloServer on " +
         host + " at port " +
         port + ": " + obj.sayHello() );
      }
   catch (Throwable t) {
      t.printStackTrace();
      System.exit(-1);
      }


  }

   private static InitialContext getInitialContext(String url)
      throws NamingException
   {
   Hashtable env = new Hashtable();
   env.put(Context.INITIAL_CONTEXT_FACTORY, JNDI_FACTORY);
   env.put(Context.PROVIDER_URL, url);
   return new InitialContext(env);
   }
}

RMI Communication in WebLogic Server

RMI communications in WebLogic Server use the T3 protocol to transport data between WebLogic Server and other Java programs, including clients and other WebLogic Server instances. A server instance keeps track of each Java Virtual Machine (JVM) with which it connects, and creates a single T3 connection to carry all traffic for a JVM. See Configure T3 protocol in Administration Console Online Help.

For example, if a Java client accesses an enterprise bean and a JDBC connection pool on WebLogic Server, a single network connection is established between the WebLogic Server JVM and the client JVM. The EJB and JDBC services can be written as if they had sole use of a dedicated network connection because the T3 protocol invisibly multiplexes packets on the single connection.

Determining Connection Availability

Any two Java programs with a valid T3 connection—such as two server instances, or a server instance and a Java client—use periodic point-to-point “heartbeats” to announce and determine continued availability. Each end point periodically issues a heartbeat to the peer, and similarly, determines that the peer is still available based on continued receipt of heartbeats from the peer.

The frequency with which a server instance issues heartbeats is determined by the heartbeat interval, which by default is 60 seconds.
The number of missed heartbeats from a peer that a server instance waits before deciding the peer is unavailable is determined by the heartbeat period, which by default, is 4. Hence, each server instance waits up to 240 seconds, or 4 minutes, with no messages—either heartbeats or other communication—from a peer before deciding that the peer is unreachable.
Changing timeout defaults is not recommended.

Communicating with a Server in Admin Mode

To communicate with a server instance that is in admin mode, you need to configure a communication channel by setting the following flag on your client:

Programming Stand-alone Clients

Developing a WebLogic Full Client

Understanding the WebLogic Full Client