I'm familiar with several J2EE vendors methods for connecting their app servers with web servers. For instance, Adobe provides mod_jrun, Tomcat offers mod_ajp, mod_proxy_ajp, & mod_jk, Caucho (Resin) offers mod_caucho, etc... Several of these connectors allow for load balancing functionality. I guess they are communicating with a part of the app server that can function as a cluster controller.
One thing I've noticed is that these connectors are made for use with Apache (and often IIS on Windows). We are considering moving away from Apache to one of the lighter webservers, like Nginx or Cherokee. If I do that, it appears that I won't have the option for using a connectors like I mentioned above. The consistent suggestion in documentation for these servers is to just configure their HTTP reverse proxy capability in order to connect them to your app server (via the app server's HTTP implementation).
I'm interested in your experience with the performance implications of HTTP vs. other protocols used in a connector like I mentioned above. I assumed that those other connectors would function at a much lower level and have higher performance as a result. They obviously can bring new "features" like exposing an app server's load balancing functionality as I mentioned above.
So what do you think? Is the simplicity & flexibility of HTTP for communicating between the web and app tiers more attractive than the additional features of a more customized connector? Are there other issues in planning a multi-tier architecture like this that I haven't considered?