7.6.1 EJB client redundancy and bootstrap failover support
When planning an EJB HA solution, not only is EJB server redundancy needed, but EJB client failover and redundancy should also be considered. EJB client redundancy refers to the automatic failover capability for an EJB request originator. In other words, an end user that initiated an EJB request can recover from the failure of a particular EJB client instance.
The first task for any EJB client is to look up the home of the bean (except MDB). The following two scenarios need to be considered:
| - | EJB requests coming from a clustered environment |
Examples could be Web clients from Web containers that are workload-managed, EJB clients from another EJB container server cluster, or EJB clients from their own server cluster. In this case, EJB clients can use their own server to bootstrap with the default provider URL. If the bootstrap fails, the EJB client fails. This failure should be handled by the previous server, for example the Web server plug-in. Another version of the same client in a different container may bootstrap from its server successfully. By using client redundancy, EJB failover and high availability can be achieved.
| - | EJB requests coming from a non-clustered environment |
Examples could be a Java client, J2EE client, C++ client, or third-party ORB client. In this case, if the client is bootstrapping to only one server, the client fails if the server fails, since the client is not redundant. You should bootstrap the client to as many bootstrap servers as possible. This can be achieved by using the bootstrapping workload management as discussed in 7.3, EJB bootstrapping.
Example 7-5 Lookup with more than one bootstrap server
prop.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
prop.put(Context.PROVIDER_URL, "corbaloc::host1:9810,:host2:9810");
Context initialContext = new InitialContext(prop);
try { java.lang.Object myHome = initialContext.lookup("MyEJB");
From the above example, the EJB client has the information for two bootstrap servers. Therefore, if the request to server host1 fails, the bootstrap engine will automatically redirect the bootstrap request to the server on host2.
WAS V6 uses the CORBA CosNaming as a naming solution. It is often convenient to use multiple bootstrap addresses for automatic retries. Every WebSphere server process contains a naming service, and the client application can bootstrap to any combination of servers. It is a good practice to bootstrap to the servers in a cluster since the InitialContext is workload-managed and use the simple name in the lookup. The other option is to get the InitialContext directly from the Node Agent using the default port (usually 2809) and use the fully qualified name in the lookup. This option, however, is not recommended, because the Node Agent is not workload-managed and has no failover capability.
For J2EE clients, you can specify a bootstrap host and port in the launch command line, and try different hosts/ports if you do not succeed when using the default URL provider.
Once the EJB home is sucessfully looked up, the naming server returns an indirect IOR, LSD, and routing table, and the WLM plug-in redirects the client to one of the clustered EJB containers.