>I am trying to think about a structure for our connectors:
>
>
> From httpd From httpd
> | |
>+++++++++++++++++++++++++++++++++++++++++++++++++ |
>+ AP1.3 | AP2.0 | NETSCAPE | DOMINO | others | |
>+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++
>+ core mod_jk + + mod_backhand +
>+++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++
>+ ajp12 | ajp13 | apj14 | warp | new protocols + |
>+++++++++++++++++++++++++++++++++++++++++++++++++ |
> | |
> To JVM To JVM
> | |
>+++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++
>+ ajp12 | ajp13 | apj14 | warp | new protocols + + HTTP +
>+++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++
>+ Tomcat layers + + +
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>+ .......... +
>
>That would means that if we are writting a warp connector we
>should only be
>worried by the protocol and have 2 sets of routines one to
>get/send information
>from/to a core module, one to send/get information to/from a Tomcat.
On the Servlet Engine side, Coyote is a good starting point of
reflexion. Basically how to see an HTTP service ?
We could be ambtious here and goes farther than just how to
handle HTTP GET/POST.
>In a configuration like that the Apache 2.0 specialist would
>write the AP2.0
>part, the Apache1-3 the AP1.3 and so on.
>
>Having a defined interface to Tomcat there should be not
>problem to get a
>protocol supported by all Tomcat versions.
mod_jk and its worker concept is a good framework.
But there is still lacks in it :
* The original worker in mod_jk from Tomcat 3.3 didn't
passed to workers validate/init functions information
about web-server (ie the URI to WORKER map). The autoconf
features found in AJP14/WARP need that. I updated that in
J-T-C mod_jk.
* The original worker have no provision on how
to handle real-time information from servlet-engine to web-server.
On the web-server, the connector task (which is
basically a redirect) only goes to life when a client
request arrive.
What about change on the servlet-side ? ie: a servlet
context is make down by admin staff ? We should handle at that
time the context down information by rerouting the request to another
worker (another servlet-engine). May be better to be informed of that
in real-time to be able to update the URIs to WORKER table accordingly.
That's a problem today, since we have many OS to support and many
web-server
and a common solution is hard to find.
We should have new thread handling the real-time updates.
It's must be easy in Apache 2.0 and IIS (what about Netscape/Domino ?)
But it's a problem in at least Apache 1.3/Linux where we could have
problem using DSO and libpthread.
Also what about forked configurations (AP1.3) ?
Should we have 1 thread by forked child or did there is a way to share
data between all forked (shared-meme/MM)
* Could we think also about the web-server acting as an intelligent cache
system ? Many pages (or part of pages) may not change so often (JSP) and
if the web-servlet / servlet-engine could share a sort of ID/BYTES pool,
we could again reduce network-traffic between them.
>* mod_backhand is not (yet) ours.
The mod_backhand license is a no way for Apache at this time. Jon Stevens
tried to do some lobbying with backhand authors but what the current status
of this action ?
Could we think using Java API like JINI to be an alternative ?
JINI support autoconf/discovery and also fault-tolerance built-in.
Also we manily use TCP protocol in AJPxx/WARP. What about using UDP
(with securisation stuff ?)
Regards
