EJB WLM routing

The implementation of the routing pattern for IIOP requests to an appserver is a combination of the two client routing patterns: client and client with advisor. This implementation is to support both those clients with the distributed platform WebSphere code and also those clients that support the IIOP interface without the WebSphere extensions.

It is expected that the non-WebSphere distributed clients will consist of WebSphere for z/OS®, CORBA C++, or non-IBM ORBs. The WebSphere distributed clients are cluster aware and have WLM support built into the client.

Note: We are using the terms "cluster aware" and "cluster unaware" clients here. However, when looking at a trace, such as shown in Example 9-7, you will see the term "serverGroup" instead of "cluster".

This support has knowledge of the servers in the cluster and implements the routing policy resulting in the client making the routing decision and directing the request to a specific server. The non-WebSphere distributed clients are cluster unaware clients and do not have any WLM routing or cluster knowledge and must be given a specific server to direct the client's request to. In this case we employ a Location Service Daemon (LSD), which acts as an advisor to a client, directing incoming requests to the appropriate server.

Within the LSD approach, a client obtains an indirect IOR (possibly from a lookup in JNDI, or as a return argument) which contains routing information to the LSD rather than to the appserver. The client request is then sent to the LSD to determine a direct IOR to be used for the object request. As part of the resolution of the IOR, some WLM logic is added to the LSD. The LSD's ORB will contain hooks that will be used in the WLM code to determine how to handle the request. The following sections describe the different functions based on the client type.

 

Cluster aware

If the client contains the distributed WebSphere WLM code and has yet to obtain the initial routing information, the initial request will flow to the LSD. The WLM director code in the LSD will determine the correct server and return the direct IOR to the client. This direct IOR will then be used to route the request to the specific server. However, since this client contains the distributed WebSphere WLM code, the request to the server will contain WLM service context data, and the WLM code on the server will look at this context data to determine whether the client has back-level cluster information. If required, the WLM code on the server adds cluster information into the service context list on the response back to the client. The WLM code on the client then updates its cluster information (if newer data was available). From this point on, the WLM code on the client has updated cluster information. Thus for all subsequent requests the client has the capability to choose the specific server to handle the request. This client-based routing is basically how our current Java EJB clients work in WebSphere today.

 

Cluster unaware

If the client does not have the distributed WLM code active, the LSD will invoke the WLM director where it is the director's responsibility to handle all of the WLM policy and affinity decisions that need to be made. The client does not have any knowledge of the cluster, so the LSD must determine the specific server the request will be sent to. This direct IOR will then be returned to the client and be used to invoke all requests on the object. What this means is that every request the client makes on this object will go to the server that the LSD determined. This is different from cluster aware clients, which will determine what server to use for every request. For cluster unaware clients, a load balancing mechanism would be added to the server that would detect when it was getting overloaded and would stop a request by returning an error to the client. This error would trigger the client to return to the LSD again to determine another direct IOR to use. In addition, if a server being used by a cluster unaware client goes down or is disconnected, an error will be returned and the client will return to the LSD and start the process over.

 

Location Service Daemon (LSD)

If only one LSD is configured for each cluster, the potential for a single point of failure exists. To prevent the single point of failure, a set of LSDs per cluster will be configured and if an LSD fails, one of the other LSDs in the group will be used.

  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.