Step 5: coding the test client

n EJB on its own is no use; we will need at least a simple client to use its services. A user of EJBs may be another EJB, and ordinary JavaBean, a JSP page, and applet, or a stand-alone application. In this example, for simplicity, we will code a simple application. This application will create an object of class Interest, and execute its one method.
I should point out straight away that the test client I will present below does not illustrate how you should code this sort of thing in practice; I've done it this way to show exactly what's going on. In reality, you will probably want to separate out the RMI-specific stuff into a separate class to divide the important functionality from the technical details. This class is sometimes called a `stub'. Some EJB products will generate stubs automatically; jBoss doesn't do this, so you'll have to code the stubs yourself (it isn't difficult).
Here is the test client:

Test client: InterestClient.java

import javax.naming.*;
import com.web_tomorrow.interest.*;
import java.util.Hashtable;
import javax.rmi.PortableRemoteObject; 
import com.web_tomorrow.interest.*; 

/**
This simple application tests the `Interest' Enterprise JavaBean which is
implemented in the package `com.web_tomorrow.interest'. For this to work, the
Bean must be deployed on an EJB server.

IMPORTANT If you want to test this in a real client-server
configuration, this class goes on the client; the URL of the naming provider
specifed in the class must be changed from `localhost:1099' to the URL of the
naming service on the server
*/

class InterestClient
{
/**
This method does all the work. It creates an instance of the Interest EJB on
the EJB server, and calls its `calculateCompoundInterest()' method, then prints
the result of the calculation.
*/
public static void main(String[] args)
	{
	// Set up the naming provider; this may not always be necessary, depending
	// on how your Java system is configured.
	System.setProperty("java.naming.factory.initial", 
		"org.jnp.interfaces.NamingContextFactory");
	System.setProperty("java.naming.provider.url", 
		"localhost:1099");

	// Enclosing the whole process in a single `try' block is not an ideal way
	// to do exception handling, but I don't want to clutter the program up
	// with catch blocks
	try
		{
		// Get a naming context
   		InitialContext jndiContext = new InitialContext();
		System.out.println("Got context");

		// Get a reference to the Interest Bean
		Object ref  = jndiContext.lookup("interest/Interest");
		System.out.println("Got reference");

		// Get a reference from this to the Bean's Home interface
		InterestHome home = (InterestHome) 
			PortableRemoteObject.narrow (ref, InterestHome.class);

		// Create an Interest object from the Home interface
		Interest interest = home.create();
	
		// call the calculateCompoundInterest() method to do the calculation
		System.out.println 
			("Interest on 1000 units, at 10% per period, compounded over 2 periods is:");
		System.out.println (interest.calculateCompoundInterest (1000, 0.10, 2));
		}
	catch(Exception e)
		{
		System.out.println(e.toString());
		}
	}
}

It's important to understand that in reality this client will be running on a different computer to the Bean server. For testing you will probably run them on the same computer, but it will still be using a network connection. So the first part of the program indicates how to find the server.

	System.setProperty("java.naming.factory.initial", 
		"org.jnp.interfaces.NamingContextFactory");
	System.setProperty("java.naming.provider.url", 
		"localhost:1099");

There are several other ways to do this, which you may see described in other articles. In this case, the server is on the same machine as the client (`localhost') and the default naming port is `1099' for jBoss (other servers may use different port numbers). If you run the client and the server on different machines, you will need to change these settings.
The comments in the program should describe how it works; one point that requires mention is that the recommended way to get a reference to the home interface on the server is like this:

InterestHome home = (InterestHome) 
	PortableRemoteObject.narrow (ref, InterestHome.class);

which ensures compatibility with different RMI servers (e.g., CORBA). `narrow' ensures that the object returned in `ref' really can be converted to an object of class `InterestHome'.
The test client doesn't need to be in the same package as the EJB classes, and in practice it probably won't be. So it needs to import the EJB classes using their fully-qualified class name, like this:

import com.web_tomorrow.interest.*;

You will also need to pay attention to the CLASSPATH when compiling. Even though the EJB classes will run on the server, they need to be identified to the client so that the compiler can do the appropriate type checking. In the example program I have put the client at the top level of the directory hierachy, so if the CLASSPATH includes the current directory it will correctly find the EJB classes which are in the directories beneath it.

javac -classpath usr/lib/jboss/lib/ext/ejb.jar:. InterestClient.java

This generates InterestClient.class in the current directory.