I am designing an application that is going to consist of 3-4 services that run as separate processes and are linked by a suitable IPC. The system is going to have a web interface and I want to use whatever webserver is there.
The web interface should be accessed under some URL that allows to have other URLs on the same webserver doing totally different things. I’m planning to use the path below that URL to specify what the web interface should do. It has facilities for use by other applications over the net and for humans to interact with in a browser.
Off the cuff, I’d work as follows:
- make the webserver fire up a CGI process for every request it receives (like SetHandler in Apache)
- let the CGI connect to the IPC
- let it get whatever it needs from the backend services
- let the CGI return HTML / XML and whatever HTTP Status based on the services’ answers
Now, what I really want is to avoid the first two steps, or if I can’t, avoid the second one, because I’m afraid that I’m wasting performance on unneccesary overhead (the requests coming from other applications might be frequent).
PHP, for example, can open persistent connections to a MySQL database that survive the script’s runtime and don’t need to be recreated next time, though I don’t know how they actually do it. Also, as I understand it, the Apache modules are loaded once when the server starts, so that might remove the first step but would tie me to Apache.
So, what are good ways to hook a handler for specific URLs into different webservers? I don’t want to handle the HTTP, otherwise I might just use a proxy setup to a second server, but it just seems to be so reinventing-the-wheel. If you think, CGI is fine and have examples where it handles large numbers of request of a similar structure, please let me know.
OK, I overlooked this previously. Explaining my question here brought me onto it: