The iSeries: The Once and Future King
1. Security. You can offload the web access to a cheap PC in the DMZ, thus preventing DoS attacks on your priary machine. To do this with RPG-CGI would require a second iSeries. Response. Not accurate. You can set up a firewall to allow access to standard port 80, and test inside the firewall on the same iSeries with a different port and web server instance. FACT- we do this ALL the time. 2. Scalability. Java supports multi-threading. RPG does not. As your workload grows, synchronization costs in RPG can get quite high. Also, JSPs are compiled classes and RPG-CGI requires constant re-interpretation of templates. This cost gets dramatic as your number of users increases. RESPONSE - Multi-threading comes at a high cost- the Java web server has to handle it, which is why most people have to buy a huge iSeries/i5 just to serve pages to a very few clients. RPG-CGI is just as compiled as JSP's - depending on implementation. In our implementation, HTML is embedded in the compiled object- there is no more 'interpretation' than a JSP would require to extract HTML from coding logic. 3. Flexibility. Changing a logo on a JSP is as quick as editing a text file. You may be able to do that in RPG, but it requires updating a template file with whatever non-standard template language is being used. And if the templates are pre-parsed for performance, you need to somehow let the server know a template has changed. RESPONSE - Not accurate. Changing a logo in CGI is just the same - you do NOT necessarily have to update a 'non-standard' (whatever that means) template file - you can change a text file on the IFS just the same way. 4. Cost. If cost is truly your issue, you can completely offload the web serving to a cheap (under $1000) Unix box, while keeping your business logic on the iSeries. RESPONSE - Now the issue of scaleability really comes up!!!! Joe- would you seriously want to run your enterprise like this? Are you advocating moving off the iSeries/i5 platform in favor of: compromised security/database integration/scaleability/operating system maintenance and failure possibilities/ hardware failure! This is really a specious argument, and detracts from the whole TCO value proposition of the i5. As in my earler post- a 'UI' is NOT in Java (unless you are talking about Java applets- which is not thin, and which I don't think is your intention). Compiled, native ILE objects delivering web pages through the CGI protocol are just as 'thin' (using your apparent definition) as Java servlets. Duncan Kenzie
1. Security. You can offload the web access to a cheap PC in the DMZ, thus preventing DoS attacks on your priary machine. To do this with RPG-CGI would require a second iSeries. Response. Not accurate. You can set up a firewall to allow access to standard port 80, and test inside the firewall on the same iSeries with a different port and web server instance. FACT- we do this ALL the time. 2. Scalability. Java supports multi-threading. RPG does not. As your workload grows, synchronization costs in RPG can get quite high. Also, JSPs are compiled classes and RPG-CGI requires constant re-interpretation of templates. This cost gets dramatic as your number of users increases. RESPONSE - Multi-threading comes at a high cost- the Java web server has to handle it, which is why most people have to buy a huge iSeries/i5 just to serve pages to a very few clients. RPG-CGI is just as compiled as JSP's - depending on implementation. In our implementation, HTML is embedded in the compiled object- there is no more 'interpretation' than a JSP would require to extract HTML from coding logic. 3. Flexibility. Changing a logo on a JSP is as quick as editing a text file. You may be able to do that in RPG, but it requires updating a template file with whatever non-standard template language is being used. And if the templates are pre-parsed for performance, you need to somehow let the server know a template has changed. RESPONSE - Not accurate. Changing a logo in CGI is just the same - you do NOT necessarily have to update a 'non-standard' (whatever that means) template file - you can change a text file on the IFS just the same way. 4. Cost. If cost is truly your issue, you can completely offload the web serving to a cheap (under $1000) Unix box, while keeping your business logic on the iSeries. RESPONSE - Now the issue of scaleability really comes up!!!! Joe- would you seriously want to run your enterprise like this? Are you advocating moving off the iSeries/i5 platform in favor of: compromised security/database integration/scaleability/operating system maintenance and failure possibilities/ hardware failure! This is really a specious argument, and detracts from the whole TCO value proposition of the i5. As in my earler post- a 'UI' is NOT in Java (unless you are talking about Java applets- which is not thin, and which I don't think is your intention). Compiled, native ILE objects delivering web pages through the CGI protocol are just as 'thin' (using your apparent definition) as Java servlets. Duncan Kenzie
Comment