Rob Nagler wrote:
Gunther Birznieks writes:1) Likely I would think there will be massaging of data relative to the application at hand, so it wouldn't be a pure C wrapper
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.
2) Data slowly corrupts Code in Perl, so shared memory breaks down after awhile.
For these two reasons, it seems to me, that you won't really get that much shared memory so it would still be better to limit the code to as few engines as possible instead of the universe of engines that the application can access.
so if 30 mod_perl engines are needed for the application, but only 5 at any given time are accessing the reservation system, then only 5 engines should be going to the reservation system.
Maybe this could be segmented using a reverse proxy to make the difference between whether it goes to a mod_perl process that talks to Sabre and one that does other app stuff. But alternatively, splitting it out so that the Perl code that does the logic of talking to Sabre and massaging that for a mod_perl app is stored in POE or PerlRPC, then it would be better to have the 5 middleware processes dealing with the shared memory stuff.
Apache is better than IIS but I would not call it "secure" in an absolute sense. There have been plenty of exploits for Apache over the last year that give me headaches having to patch ASAP when discovered.
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.
If you are a cracker and have hacked someone's Apache, but then your next crack has to find an exploit in a daemon written in Perl like POE before finally getting to the database or backend system, you are still slowing down your attacker. Usually at worst, the attacker will have to figure out something about how POE works.
I believe more script kiddies/casual crackers can probably log into sybase, oracle, mysql databases and trash them than they can figure out how to talk to an RMI engine, EJB server, SOAP, or POE middleware for an application layer prior to accessing the database.
Later,
Gunther
