Hi Karthik
I guess I can configure weblogic proxy to route client requests to any of the servers in the cluster. But one request will be addressed by one managed server in the cluster. If that server fails, the request will go unsatisfied as well because that server is not even aware of existance of others.
Not quite true. Weblogic uses a primary and secondary backup to provide failover capabilities. Basically the addresses of these servers are encrypted into session (or cookie) and when the primary failes it will redirect the request to the secondary server. Next weblogic will make the secondary primary and pick another secondary, etc.
So coming back to the original configuration, the client might have to re-issue the request and the proxy at that time might redirect it to another server in the cluster recongnizing that the other guy is down?
So I will have some amount of fail-over capability.
EJBs are replicated in a different way than web components. Like I said for web components weblogic uses a primary-secondary peering approach. For ejbs, as you mentioned weblogic uses cluster-aware stubs. What this means is that client stubs maintain a list of address of all servers in the cluster. Hence if a client request fails, the stub is capable to transparently failover (if the method is declared idempotent) to another instance. In your case, since your clients talk to the web server that calls collocated session ejbs, then you right: your client requests will stick with that server instance. Although you�ll access your session fa�ade through the remote interfaces, rather than the local interfaces, you�re not able to leave the current server instance, because weblogic optimizes the request for collocated ejb objects. You might gain failover benefits though, but I personally like using local interfaces although weblogic allows passing by reference even for remote calls as you�ve mentioned (consider portability, for example).
Bottom line is that with your architecture there are still plenty of benefits for using a cluster, because you can load balance requests at the web server level, either using a hardware load-balancer or configuring the server proxy.
I guess I can still have HttpSession replicated between the servers in the cluster.
As wilth SFSB Weblogic always replicates the session information across the cluster. However for httpSession object it can track the changes made to the session object (looking at the setAttribute method) and therefore weblogic is capable to replicate only those attributes that were changed. On the other hand for SFSBs weblogic will replicate the whole session information, no matter if only one attribute or all of them got changed.
Regards.