Gunther Birznieks writes: > Also, I suspect it probably wouldn't be efficient memory wise. mod_perl > processes are large enough with front-end code without randomly having > them share a bunch of middleware/mainframe processing code also. This > middleware code could probably be more tightly shared amongst a smaller > number of processes that just service the mainframe stuff.
The sharing should be identical, esp. if the code is written in C or C++ which most middleware (and probably Sabre) is written in. > In addition, I would advocate middleware prior to talking to a mainframe > because of security. You can have someone break into the web server but > if it is hooked direct to the mainframe, then that person can hop > directly onto the mainframe. Instead, the requests could be mediated and > well-formed by the middleware. The cracker would have to hack the > middleware after hacking the web server in order to get to the mainframe > if you add a layer like this. Of course, maybe this is an Intranet > application, so such things may not matter... Security is always a concern, which is why Apache is a much better solution. It's much like buying security from a company which builds public ATMs and buying security from companies which build corporate laptop security systems. The former is like Apache, the later is like most (if not all) middleware. Apache has proven the test time, because it is being attacked *continuously*. This is why Apache is so much more secure than IIS, which had a much later start and wasn't used for large sites. Rob
