Perform lookup in a J2EE application client container

The J2EE application client container provides some similar facilities to an EJB or Web container in terms of naming. The client container will do EJB reference lookups so the code in Figure 6-1 would also work here. It uses the application clients deployment descriptor to do the binding of a reference to a real JNDI name.

As the calling code is actually running outside of an appserver process it still needs to be able to resolve the InitialContext object to the correct location to lookup the EJB. Using the J2EE application client container removes the need to hard code the location of the application server that is providing the name service. The code in Figure 6-1 does a call without passing any parameters to the InitialContext. When running in the J2EE application client container this is resolved to the JNDI name server that is specified when launching the client container. For example, using the command:

launchclient ClientApp.ear -CCBootstrapHost=app1 -CCBootstrapPort=2809

will launch the J2EE client contained within the EAR file. When an InitialContext object is created with no parameters the J2EE application client container will resolve this to the name service running on app1 on port 2809.

This means that although the code is written the same as for running in an EJB or Web container, the actual resolution of the correct name service relies on parameters passed to the J2EE application client container at initialization.

When running in this container it is important that the client is able to resolve the process where the name server is running. If it is unable to do this then the client will fail to initialize.

To get around this issue it is possible to use a corbaloc provider URL to specify multiple locations for name servers that can be used to perform the JNDI lookup. This alternative command will run the client:

launchclient ClientApp.ear -CCproviderURL=corbaloc::app1:9813,:app2:9814

When it comes to performing the InitialContext lookup, the container has a choice of name servers, either the appserver on app1 listening on port 9813 or the application server on app2 listening on port 9814.

This list of locations is not processed in any particular order so there is no way to guarantee which server will be used, but remember this is just for looking up the EJB home object. Once that is obtained, normal EJB workload management decides which server in a cluster should actually be used. Should one of these name servers fail to respond then the other will be used, removing the single point of failure.

If the target EJB is running in a cluster then this is the recommended method of looking up EJB homes when running in a J2EE application client container, as it provides failover.

When populating this list remember that whichever name server you point the client at has to be able to resolve the JNDI name the EJB reference resolves to. The possible options for fully qualifying the JNDI name are discussed at the end of Perform lookup in an EJB or Web container in the same cell.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.