Workload management considerations for stand-alone application clients

Both types of stand-alone application clients use the WebSphere Object Request Broker (ORB), which contains a WLM plugin. The WLM plugin works with clustered EJB containers to provide load balancing and failover for enterprise bean application servers.

EJB Containers

In workload management for EJB containers, application servers are clustered so that if one server is not available another server processes client requests. In WebSphere Application Server Network Deployment Version 5, workload management for enterprise beans is enabled automatically when a cluster is created within a cell. Workload management uses a WLM plugin within the ORB to route requests to one of the EJB containers in a cluster and to provide failover support.

This graphic illustrates communication between a Java application client and clustered EJB containers:

The cluster members (Server1, Server2 and Server3) are on separate machines or logical partitions. The Java client initially connects to the name space for one of the clustered application servers. The client's WLM plugin is updated with information about the clustered EJB container. With this information, the plugin can use load balancing and failover to route subsequent client requests to the EJB container. For information on clustering enterprise beans, see Workload management for enterprise beans and application servers.

Naming and name spaces

Java clients use the Java Naming Directory Interface (JNDI) to obtain references to objects within an EJB container, such as enterprise bean homes. Within the application server these objects are bound in a hierarchical structure called a name space. A Java client uses an InitialContext to acquire access to objects within the name space. To connect to a name space, the client must supply a host name and port. If the host name and port are not specified, the default values are localhost and 2809, respectively.

Considerations for an application client connecting to clustered application server's name space

WebSphere Application Server Network Deployment Version 5 sets up separate name spaces for the cell, each node agent, each application server, and the deployment manager. Because node agents are not clustered, it is recommended that the client connect, or "bootstrap" to a clustered enterprise bean application server instead of a node agent.

Use the administrative console to edit the bootstrap host and port for the application server. For information on configuring the hosts and port numbers for your application server, see End Point settings.

InitalContext requests participate in workload management when the provider URL is a clustered resource. When the InitialContext is created, URLs (iiop, corbaloc, and corbaname URLs) and other properties are set. These properties control access to the name space and the position of the JNDI InitialContext. To eliminate the application server as a single point of failure, the URLs that identify the server can contain multiple host and port addresses.

The application client can use multiple hosts and ports or IIOP to look up the initial context. For examples of these two types of InitialContext lookups, see Sample: Look up InitialContext with multiple hosts and ports and Sample: Look up InitialContext with an IIOP URL.

Considerations when looking up the home interface for an enterprise bean

The process of looking up the home interface for an enterprise bean differs between thin clients and J2EE application clients.

• Thin Java client
  Thin clients do not run in an EJB container and the path of the short name must be identical to the name in the application server name space. This example illustrates a lookup of a home interface for an enterprise bean that runs in the cluster EJBcluster. The name can be resolved if any one of the cluster members is running.

  // Connect to application server name space - See previous section
  // Look up the home interface using the JNDI name BeenThere. Note the path
  // "cells/clusters/EJBcluster". In this scenario EJBcluster has 
  // three cluster members (Server1, Server2 and Server3).
  
  try {
    java.lang.Object ejbhome = initialContext.lookup(
      "cell/clusters/EJBcluster/BeenThere");
    beenThereHome = (BeenThereHome)javax.rmi.PortableRemoteObject.narrow(
      (org.omg.CORBA.Object) ejbhome,  BeenThereHome.class);
   // Proceed to call methods on object's remote interface.
   }
    catch (NamingException e) { // Error getting home interface 
       .....
  }
  

• J2EE application client
  Applications that run in a client container can use JNDI. JNDI allows the short name to be independent of the object's name as it is bound in the server's name space. The deployment descriptors for the application provide the mapping from the JNDI name and the name server short name. The client container sets up the JNDI name space based on the deployment descriptor information so that the JNDI name is correctly mapped to the corresponding object.

  Use the administrative console to change the JNDI mapping in the deployment descriptor during or after application deployment. To change a JNDI, follow these steps:

  1. Start the administrative console.
  2. In the topology tree, expand Applications and click Enterprise Applications.
  3. Click the name of the application for which you want to edit enterprise bean references.
  4. Click Map EJB references to beans.
  5. In the JNDI Name field, specify the JNDI name of your enterprise bean. For example, to map the BeenThere bean, specify Cell/clusters/EJBcluster/BeenThere. In this example the cluster name is EJBcluster.
  6. Click Apply.
  7. Save the configuration.
  8. Stop and restart the application server that contains the application client.

This example illustrates a lookup from the perspective of a deployed J2EE client application.

// Get the initial context as previously described
try {
  java.lang.Object ejbhome = 
 InitialContext.lookup("java:comp/env/BeenThere");

 //  Note the BeenThere is mapped to JNDI name
 // Cell/clusters/EJBcluster/BeenThere - this will enable WLM
 // failover

beenThereHome = (BeenThereHome)javax.rmi.PortableRemoteObject.narrow(
    (org.omg.CORBA.OBJECT)  ejbHome, BeenThereHome.class);

catch  (NamingException e) {Error getting the home interface}