> 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.
You can do this with an Apache module as well, keeping the HTTP backend
connection open for multiple front end requests (even of different front end
clients). Additionally, you can keep a pool of connections that can be
shared by the children.
> 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.
Apache could pass this information in an HTTP request, no need for a special
protocol.
> 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).
Um... maybe :) I would like to see some numbers on how slow parsing the
headers is in comparison with the time it takes to process the request or
deal with the warp protocol
> 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)...
This can be done with an HTTP reverse proxy. BEA does load balancing ,
failover, sticky sessions, etc.
> 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 :)
I see the value of warp for hiding the underlying transmission protocol, but
in the case of embedding the JVM directly it may be worth to do it on its own.
> Is it enough??? :) :) :)
No :) I think a lot of the stuff you are trying to do is very useful
but they could be implemented using HTTP as the transport and as
enhancements of the reverse proxy. This allows you to take advantange of
many other things (like SSL for free, etc.)
My point is that if it is good enough for weblogic and IBM (they have an
HTTP based protocol for Websphere 4.0) it may be good enough for us :)
Best regards
Daniel
