First you need to set up the CLASSPATH in your environment. Beyond the standard classpath setting, you also need to add the J2EE client jar files to your classpath. The set of J2EE client JARs is vendor specific; refer to the documentation in your application server on how to set up the environment for an EJB client, and add the JAR files specified. For JBoss users, we have included a script to set up the client environment. To run this script, make sure you are in your base WSIF directory (the one that contains the classpath.bat script. Set the variable JBOSS_HOME to point to your JBoss installation. From there, run the command samples\ejb\client\jboss_setup\jboss.bat. This sets up the entire client classpath required to run the sample using JBoss client JAR files.
The WSDL file that describes the service and its EJB binding is vendor-specific in the <ejb:address> element. The initialContextFactory, jndiName and jndiProviderURL attributes will all depend on your specific deployment; refer to your application server documentation on how to write an EJB client to learn more about JNDI and related issues. Make sure these values are all correct before you try running the client.
After you have set up your classpath, to invoke this sample using WSIF's DII, run the Run class located in this directory. This is the logic that uses the generated stub interface to run the sample. So you can run this class, specifying on the command line the location of the WSDL file for the sample. For example,
java ejb.client.stub.Run samples/ejb/AddressBook.wsdl
The sample code will use the stub interface to populate an addressbook with two entries and will then query the addressbook for those two addresses using the corresponding names.
To generate the stub interface, you can use any tool that generates Java interfaces for WSDL services using their port type descriptions, such as WSDL2Java from Axis. WSIF assumes a correspondence between the generated Java interface and the WSDL port type that has its abstract description as specified in the JAX-RPC specification. This particular sample did not use WSDL2Java in a simple way (due to a current bug in WSDL2Java that prevents it from processing WSDLs that do not have a valid SOAP endpoint or binding. We managed to get it to work by commenting out the EJB binding that is currently there, and introducing a binding element that describes a SOAP binding. After doing this, we ran WSDL2Java in the following way:
java org.apache.axis.wsdl.WSDL2Java ../../AddressBook.wsdl
After the tool finished running, we deleted all the generated files except AddressBook.java (this is the java interface corresponding to the port type), Address.java and Phone.java (these two are the java representations of the complex schema types used in the sample).