I've worked with app. servers for some time, starting with WebLogic and ATG. I have a nagging question for everyone.. Why cluster EJBs if we can cluster Http sessions based on Tomcat (or JBoss of course)?
Let me detail: When users connect to a business app (server side), JSP engine picks up the processing request. Now, we must cluster, replicate, load balance this guy. Inside our servlets and JSPs, we can do any processing we need, use JDO, run JDBC, number cranck, whatever.
But then people say, we need EJBs.. Where? Adding EJBs (statless, or stateful) into this architecture would just complicate matters wouldn't it? Becuse it would be another set of components (technologies) to replicate, load balance, etc..etc.. Or so it seems to me.
One way for servlets/JSPs to co-exist (a guess) could be if EJBs are on a different machine. In this case, all heavy lifting would have to be done on this seperate EJB cluster, not on the servlet/JSP cluster. The EJB cluster would have more hardware, resources, so JSP/servlet cluster delegates to this cluster to get its work done.
My question for the last case is: Would it be hard to synchronize replicated sessions, both on servlets and EJB clusters if the servlet machine handling request XYZ went down?
Thanks in advance..
It makes sense to replicate/cluster EJB (and not use replicated HTTPSessions) if... you don't have HTTP clients for example. You have a specific scenario which may not requires clustered EJB but other may have other scenarios.
In your case, I agree, replicating the HttpSessions may be totally enough.