Re: implementing a set of queue-processing servers

Rob Nagler wrote:

>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.
>  
>
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
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.

>  
>
>>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.
>
>  
>
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.

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

>  
>