>>Daniel Lopez at [EMAIL PROTECTED] wrote: >> I understand your concern with easy configuration. What I am advocating is >> adding all those features but still use HTTP as the transport (like >> subversion does for cvs). This eliminates the need to develop and maintain >> your own protocol, allows you to take advantage of things like SSL and any >> improvements that you make to reverse proxy, like load balancing, can be >> used by other modules or setups with any backend server, not only tomcat.
>Pier wrote >And you keep missing my point when I say that you can already do that with >Tomcat 4.x, and WARP/WebApp are an addition to that method in terms of >performance and ease of use... We already have and use the functionality >provided by an HTTP-based reverse proxy (TC4.0/4.1, Tomcat HTTP/1.1 >connector and mod_proxy in Apache), but we need more :) Hi Pier and Daniel, Some points here : Using reverse-proxy seems to be 'à la mode' since I've been told that the latest WebSphere use today such relaying instead of it's own previous protocol. BTW, using it's own protocol between a webserver and a servlet engine has some advantage : 1) HTTP is pretty verbose and text based, and dialog could be speeded-up by make it more 'binary' (stuff done by mod_jk/ajp13-ajp14 and mod_webapp/warp) 2) There is thing which lies to servlet world which didn't feet well in HTTP, for example forwarding serialised session data from servlet engine to webserver for future reuse (mod_jk/ajp14 W.I.P) 3) We must be clear here, HTTP protocol, Apache HTTP server and Servlet API didn't match very well often (welcome files, mime mappings, etc) it's a nightmare to support all web.xml features ;) 4) mod_jk support Session Afinity, ie is able to forward all request to a known tomcat, in a tomcat farm, by taking a look at SessionId. A mandatory stuff for load-balancing configuration. But it's still nice to have more features in mod_proxy ;)