File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes custering and  co-located web and server tier Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "custering and  co-located web and server tier" Watch "custering and  co-located web and server tier" New topic
Author

custering and co-located web and server tier

Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
I wanted to have your thoughts on this scenario.

My web tier (upto business delegate) and server tier (session facade onwards) are co-located. I mean say am using only local interfaces for the beans. If i still go ahead and deploy similar configurations on a cluster, what does it buy me?
I guess there is no help from cluster wide jndi tree / cluster aware stubs (they w'dnt exist since there are no remote beans in the first place)

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.

(If it had been a cluster aware session facade stub, probably the request would have been satisfied)

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.

I guess I can still have HttpSession replicated between the servers in the cluster.

Is such a deployment strategy encouraged? Would this even qualify as a 'cluster' given that server peers dont really recongize each other.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
My firm belief is that you can certainly use local interfaces in a WLS cluster. What is important is that the web and EJB code is packaged in the same EAR file.

Bear in mind that, as far as WebLogic Server 8.1 is concerned, just about everything can be clustered. The main exceptions are File services and Time services.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
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.


I think, therefore I exist -- Rene Descartes
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
thanks Valentin and Roger.
 
Don't get me started about those stupid light bulbs.
 
subject: custering and co-located web and server tier