|
|
When planning an EJB HA solution, in addition to EJB server redundancy, you should also consider EJB client failover and redundancy. EJB client redundancy refers to the automatic failover capability for an EJB request originator. In other words, a 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). You should consider the following scenarios:
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 might bootstrap from its server successfully. By using client redundancy, EJB failover and high availability can be achieved.
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, because the client is not redundant. You should bootstrap the client to as many bootstrap servers as possible.
Example 2-7 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 this example, the EJB client has the information for two bootstrap servers. Therefore, if the request to server host1 fails, the bootstrap engine redirects the bootstrap request to the server on host2 automatically.
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, because the InitialContext is workload-managed and use the simple name in the lookup. The InitialContext being workload-managed means that all the cluster members in the cluster are available in the InitialContext object. This allows the WLM plug-in to send the requests to another server in the cluster if a request to one server fails. 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. This means that if the Node Agent that returns the InitialContext fails then the InitialContext is invalid and will not work, even if you use multiple Node Agents on the CorbaLoc URL. In this option, the Node Agent is a single point of failure.
For J2EE clients, you can specify a bootstrap host and port in the launch command line, and try different hosts or ports if you do not succeed when using the default URL provider.
When the EJB home is location successfully, 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.
