>>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 ;)
