Daniel Lopez at [EMAIL PROTECTED] wrote:
> Graham Leggett at [EMAIL PROTECTED] wrote:
>> Daniel Lopez wrote:
>>>
>>> While the idea is the same (passing request information to an external
>>> program) in these cases you are modifying the incoming headers, because
>>> there is no additional external HTTP request.
>>
>> In the case of both mod_jk and mod_webapp, there is an HTTP-like request
>> to a Java servlet server. Both modules are very similar in function to
>> proxy.
They look similar, and they somehow do more or less the same thing
(forwarding an HTTP request to an entity outside the scope of the
web-server), but they do it in a kinda of a different way...
> This is just what I said :) In fact, I do not undersand why mod_jk or
> mod_webapp had to invent yet another little protocol and are not implemented
> as a reverse proxy, like BEA weblogic connector does.
There are several because to that why :) First of all TC40 is also
implemented as a reverse proxy (using HTTP), the advantages of using a
protocol such as WARP, used in mod_webapp (instead of HTTP) are different:
First of all you have a permanent connection between the server and the
client, of course, you can do that also with HTTP and KeepAlive and
chunking, but the whole idea behind a WARP connection is that you fire up
your socket when the HTTP server starts, and you never close it until that
process goes down.
Second, tighter integration. On WARP, for example, we're able to pass things
like configuration informations, so, using a directive in httpd.conf, you
can actually deploy web-applications on the servlet container without having
to tweak your configurations in two places.
This (passing deployment information over the socket), allows
web-applications context to be shared across the two servers, tomcat and
apache, and for instance, apache can easily serve static content on its own,
given the deployment information stored in your web applcation WAR file
(WEB-INF/web.xml). Using this I don't have to use mod_rewrite to share a
context between tomcat and apache.
Third is parsing. I mean, you guys spent ages optimizing and making sure
that your HTTP stack is 100% compliant and fast-as-hell (don't tell me that
I can parse HTTP headers faster in Java than in C! :), and the WARP protocol
is optimized for that, it is designed so that the Java side of things
doesn't have to parse stuff at all, all the HTTP protocol parsing is done by
Apache, and doesn't need to be reparsed in Java, since all data is passed
along on the socket with all its parsing information (packets and string
lengths, we don't have to iterate thru char arrays in Java at all, just
construct strings when those are required).
Fourth is load balancing done how it should be to be compliant with the
server spec (sessions generated by a certain tomcat engine are guaranteed to
return to that specific engine, integration with mod_ssl session,
yadayadayada)...
And fifth is the possibility to include the JVM directly into the Apache
process (multithreaded, 1.3 on Win32 and 2.0 everywhere), via JNI... Without
even thinking about opening sockets :)
Is it enough??? :) :) :)
Pier
