It wouldn't be a full flown HTTP server . . . SNIP . . . It would not
> be contacted by clients directly (or so I thought). Isn't it the
> server's ASP page logic which would be asking me for the data then
> building the page to present to the client?
In that case, yes, the ASP interpreter would be the client (rather than
a browser, or whatever) that connects to you. I guess that simplifies
things somewhat.
If I have to dela with clients directly, than by all means yes. And
if that lets me use SSL easily but there is no easy way for me to do
SSL or equivalent otherwise, than that argues for using Apache too.
You don't need Apache to do SSL -- on i5/OS, Apache uses a module called
"mod_ibm_ssl" that IBM supplies with i5/OS. This module lets Apache
call the i5/OS APIs for SSL (called "Global Secure Tool Kit", or GSKit
for short... despite the fancy name, it's included in the OS).
Your RPG (or any ILE language) program can call the GSKit APIs directly
to get SSL support, if you decide to go that route. I wrote an article
for System iNEWS magazine about these APIs, I can dig up a link if
you're interested.
I just figured running Apache would take many more resources than a
relatively simple socket program such as those in your tutorials.
That may be true? I imagine that Apache uses quite a bit of storage,
but does that matter if you have a single-level store system, where disk
is used for stuff that's infrequently used?
Also, Apache is multi-threaded. RPG programs are not. If you want to
handle multiple simultaneous connections, the RPG solution can either
multiplex them (one activation of the program handling multiple sockets
by reading from each one in a loop) or it can submit a new job for each
instance. By contrast, Apache can handle multiple connections all in
one job, because it's multi-threaded. Does the Apache still use more
resources, then? Hard to say without actually writing them both and
doing a comparison.
Of course, Apache would still have to run an RPG program as a CGI, which
means communicating with another job, so then again, you might end up
back at the multiple jobs approach anyway...
Like I said, it's hard to say without really comparing them.
If you decide to write your own, I'd be happy to point you at various
resources or answer questions to help you out.
midrange.com
