Yes, I do have some reasons ;)
The customer's constraints are that:- the server must be a standalone Windows executable
- the *same* executable must be capable of running as a Windows NT service executable
- the server should not depend on other software
*My* constraint is that the same codebase (or close to) runs on Linux, so that I may eventually convince the customer to move off Windows.
More background:
Basically, this thing is a "Webservice Toolkit" specialised for this particular customer. The service listens on a single port for HTTPS requests in SOAP or JSONRPC format.
An authentication module is configured to take information from the request headers, body or SSL peer certificate attributes in order to check whether the client may proceed. The authentication information is then used to retieve "user context" from a database for the current client. That context is visible from exposed "service classes".
An (Apache-like) chain of Handler modules is configured for the service such that certain urls are mapped to a combination of an exposed "service class" and a service "handler type". (eg: https://service:2222/WholesaleBillingSOAP is configured to expose the Wholesale::Billing class via SOAP.)
Additional handler types exist for non-programatic access to the service. For this customer, the main *user* interface is a Macromedia Flex application (browser-based) which is served from the service at https://service:2222/sample/Wholesale.html. That Flex application reads an XML configuration file (also served by the service) to find out where the service is running, then talks to the service via SOAP.
Finally, the service includes asynchronous functionality that can be requested by a SOAP or JSONRPC client, which will run for a potentially long time (ie: reports which take minutes to run). Those clients can request a progress report or the final results of the long-running job.
I hope that clears up some of my motivation.
-David.
| [reply] |
These requirements seem pretty arbitrary. Is your server, which depends on perl, SSL libs, and a bunch of modules, really more "standalone" than Apache and some perl code? I suspect the real meaning is something like "must be easy to install and not have any licensing fees." There are some nice click-and-drool installers that will put Apache, mod_perl, and mod_ssl on a Windows machine, and you could add more to them.
Maybe I'm just overestimating the difficulty of writing a reliable HTTP server. If this is a controlled environment with specific client browsers, it may be easier than usual. You could look at some of the existing non-blocking servers like AxKit2 for help. I haven't seen a working SSL plugin for it though. There's also some POE stuff that I believe does work with SSL.
Is it really that important to use non-blocking I/O? There are simple, well-established techniques for handling long-running processes from CGI that can be used for most forking/threading situations. You essentially spawn a thread to handle the job and have it write progress updates somewhere that you can grab them for display.
| [reply] |
These requirements seem pretty arbitrary. Is your server, which depends on perl, SSL libs, and a bunch of modules, really more "standalone" than Apache and some perl code? I suspect the real meaning is something like "must be easy to install and not have any licensing fees."
Unfortunately, those requirements are almost word for word from the Aceptance Criteria document, written by someone who is not me :(
Is it really that important to use non-blocking I/O
Not at all. What is important is that all requests:
- are quickly, reliably accepted and serviced
- are done over SSL with peer cert auth
Additionally, this must work on Windows.
-David.
| [reply] |
