7.4.1 Initial request
When accessing an EJB, there are two groups of clients: cluster aware and cluster unaware. Cluster aware clients are those that are using an IBM ORB and therefore have access to the WLM information about WAS clusters. For more information about cluster aware and cluster unaware clients, see 7.5, EJB workload management routing policy.
These steps describe what happens when a cluster aware client accesses an EJB:
1. First, the client has to retrieve the initial context during the bootstrap process. This varies between client types as discussed in 7.3.1, Bootstrapping within WebSphere containers.
2. Next, the client needs to look up the EJB home based on the JNDI name, for example: Object home = initContext.lookup("java:comp/env/BeenThere");
BeenThereHome beentherehome =
(BeenThereHome) narrow(home, BeenThereHome.class);
This example uses an EJB reference, java:comp/env/BeenThere. As discussed in Performing a lookup in an EJB or Web container in the same cell, this EJB reference must be bound to the fully qualified JNDI name of the deployed EJB, for example:
cell/clusters/EJBcluster/BeenThereUsing EJB references would not be possible in a stand-alone EJB client since it is not running in a container.
3. The client needs to create or retrieve an EJB object, using the create method or finders of the home interface, for example: BeenThere beenThere = beentherehome.create();
4. Once the EJB object has been created, you can invoke methods from the remote interface, for example: Hashtable envInfo = beenThere.getRuntimeEnvInfo();
We call these four steps the initial request from the EJB client. Let us see in detail what is happening from a workload management's point of view, using Figure 7-5:
1. The new InitialContext request goes through the ORB (Object Request Broker). This returns a JNDI context object which has the information of the server naming service.
2. The lookup on the context returns a home object of the BeenThere bean. This is an indirect IOR (Interoperable Object Reference), that is, it points to the Location Service Daemon (LSD) on the local Node Agent.
3. The first request goes to the LSD and the LSD selects one of the cluster members by using the WLM plug-in in the LSD.
4. The LSD returns a direct IOR to the specific cluster member.
5. The request is forwarded to the cluster member that the LSD selected.
6. Upon successful completion of the request, the response contains the cluster configuration information. The client WLM plug-in stores the cluster configuration information and uses it for subsequent requests.
![]()
Figure 7-5 EJB workload management