> 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
This is trivial in Perl. :-) Seriously, we have account importers for a variety of stock brokers. The broker specific code is relatively short. We reuse the logic from our manual accounting pages, so our automatically imported transactions and the Web accounting transaction pages share a lot of common logic. It adds maybe 1MB/server to add this rather complex functionality (see below). The same is true of our e-commerce gateway interface. > 2) Data slowly corrupts Code in Perl, so shared memory breaks down after > awhile. This problem needs to be resolved with appropriate profiling, whether you use Apache as middleware or not. > 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. My experience is just the opposite. If you reuse code, most servers contain that code base and are therefore "large" relative to very specific applications. Most of our mod_perl servers are 15MB minimum, and grow to up to 80MB. > 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. The problem is sharing, routing. load balancing, etc. If you run separate processes, there's no chance to share. If you run separate processes, you need more configuration, documentation thereof, and design for peak load becomes more difficult. > 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. This stuff is handled on the back end. I don't see where proxies would help. > 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. POE and PerlRPC are fatter than the Sabre code, I bet. > 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. Is POE or PerlRPC more secure than Apache? I seriously doubt it. > 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. The cracker will go to the OS. They aren't going to proxy-hop. They'll try a telnet, ssh, dns, etc. exploit once they are on the inside. > 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. If this is a large scale app, there will be front-ends, middle tiers, and databases. If they crack ssh, they're through the system. If they crack Apache, they still have to exploit the specific attack. Middle tiers run mod_perl, but not mod_proxy and mod_ssl. Front ends run mod_proxy and mod_ssl, but not mod_perl. The cracks on Apache have all been on specific modules, not on the Apache core. The weak link is not Apache or the middleware, because the connections as you point out are too complex. We digress. The problem is to build a UI to Sabre. I still haven't seen any numbers which demonstrate the simple solution doesn't work. Connecting to Sabre is no different than connecting to an e-commerce gateway. Both can be done by connecting directly from the Apache child to the remote service and returning a result. Rob
