Develop J2EE application client code

A J2EE application client program operates similarly to a standard J2EE program in that it runs its own Java virtual machine (JVM) code and is invoked at its main method.

The Java Virtual Machine application client program differs from a standard Java program because it uses the Java Naming and Directory Interface (JNDI) namespace to access resources. In a standard Java program, the resource information is coded in the program.

Storing the resource information separately from the client application program makes the client application program portable and more flexible.

  1. Write the client application program.Write the J2EE application client program on any development machine. At this stage, you do not require access to the WAS.

    Using the javax.naming.InitialContext class, the client application program uses the look-up operation to access the Java Naming and Directory Interface (JNDI) namespace. The InitialContext class provides the lookup method to locate resources.

    The following example illustrates how a client application program uses the InitialContext class

    import javax.naming.*
    public class myAppClient
        public static void main String(argv[])
            InitialContext initCtx = new InitialContext();
            Object homeObject = initCtx.lookup("java:comp/env/ejb/BasicCalculator");
            BasicCalculatorHome bcHome = (BasicCalculatorHome) 
            javax.rmi.PortableRemoteObject.narrow(homeObject, BasicCalculatorHome.class); 
            BasicCalculatorHome bc = bcHome.create();                              ...
    In this example, the program looks up an enterprise bean called BasicCalculator. The BasicCalculator EJB reference is located in the client JNDI namespace at java:comp/env/ejb/BasicCalculator . Since the actual Enterprise Java Bean run on the server, the application client run time returns a reference to the BasicCalculator home interface.

    If the client application program lookup was for a resource reference or an environment entry, then the look up function returns an instance of the configured type as defined by the client application deployment descriptor. For example, if the program lookup was a JDBC data source, the lookup would return an instance of javax.sql.DataSource. Although you can edit deployment descriptor files, do not use the administrative console to modify them.

  2. Assemble the application client using the Assembly Toolkit.

    The JNDI namespace knows what to return on a lookup because of the information assembled by the assembly tool.

    Assemble the J2EE application client on any development machine with the assembly tool installed.

    When you assemble your application client, provide the application client run time with the required information to initialize the execution environment for your client application program.

    Remember following when you configure resources used by your client application program...

    • Resource environment references are different than resource references. Resource environment references allow your application client to use a logical name to look-up a resource bound into the server JNDI namespace. A resource reference allows your application to use a logical name to look up a local J2EE resource. The J2EE specification does not specify a particular implementation of a resource. The following table contains supported resource types and identifies the resources to which the WAS provides a client implementation.

      Resource Type Client Configuration Notes Client implementation provided by WebSphere Application Server
      javax.sql.DataSource Supports specification of any data source implementation class No Supports specification of custom protocol handlers Provided by Java Runtime Environment files
      javax.mail.Session Supports custom protocol configuration Yes - POP3, SMTP, IMAP
      javax.jms.QueueConnectionFactory, javax.jms.TopicConnectionFactory, javax.jms.Queue, javax.jms.Topic Supports configuration of WebSphere embedded messaging, IBM MQ Series and other JMS providers Yes - WebSphere embedded messaging

  3. Assemble the EAR file.

    The application is contained in an enterprise archive or .ear file. The .ear file is composed of...

    • Enterprise bean, application client, and user-defined modules or .jar files

    • Webapplications or .war files

    • Metadata describing the applications or application .xml files

    You must assemble the .ear file on the server machine.

  4. Distribute the EAR file.

    The client machines configured to run this client must have access to the .ear file.

    If all the machines in your environment share the same image and platform, run the ACRCT on one machine to configure the external resources, and then distribute the configured .ear file to the other machines.

    If your environment is set up with a variety of client installations and platforms, run the ACRCT for each unique configuration.

    You can either distribute the .ear files to the correct client machines, or make them available on a network drive.

    Distributing the .ear files is the responsibility of the system and network administrator.

  5. Deploy the application client.

  6. Configure the application client resources.

    If the client application defines the local resources, run the ACRCT (clientConfig command) on the local machine to reconfigure the .ear file. Use the ACRCT to change the configuration. For example, the .ear file can contain a DB2 resource, configured as C:\DB2. If, however, you installed DB2 in the D:\Program Files\DB2 directory, use the ACRCT to create a local version of the .ear file.

After developing the J2EE application client code, launch the application client.


See Also

J2EE application client class loading