|
On 5/12/06, web400@xxxxxxxxxxxxxxxx <web400@xxxxxxxxxxxxxxxx> wrote:
> CGI - Pros: > You probably already know RPG. > Easy to start with. If you change "CGI" to "CGIDEV2" then I'll agree with that! Getting started with CGI when you aren't using CGIDEV2 (or a comparable toolkit) is not easier.
I figured that if he's doing RPG-CGI, he's using a framework like CGIDEV2, or Cozzi's XTOOLS, Brad Stone's stuff, etc.
> CGI - Cons: > Doesn't always scale well. > Locks you into using iSeries as your webserver and as your back-end. > HTTP server and web application must be in same tier. > Tough to hire people that know anything about RPG-CGI. These are more the cons of RPG than they are of CGI. Most of your restrictions come from the fact that RPG really only runs on iSeries systems. It doesn't really lock you into using the iSeries as both the web server and back-end... The web server does need to be iSeries to run RPG, but an RPG program can talk to other computers to get the data. You could have a back-end computer running DB2 and query it from RPG. Or RPG could run a web service on another computer, or communicate with another computer using data queues or sockets.
Very true. Hadn't thought about it that way.
Like I said, your restrictions are really because of RPG, not CGI. The major cons of CGI itself are: a) It requires starting up a separate process outside of the web server. On most platforms this is very expensive. It'd be like submitting a new job for every RPG program you run, waiting for it to finish before doing the next step. The overhead of submitting the job is significant. However, on the iSeries it isn't such a big problem because the CGI jobs remain active and are re-used. You don't have to start new ones over and over. Plus, iSeries programs can remain in memory with their files open and variables intact so that they can be called again very quickly. In RPG we think of this as ending with *INLR = *OFF, but it's available via activation groups in other ILE languages as well. Since no other platform has this functionality, and iSeries is such a tiny niche of the market, this is still considered a huge blemish on CGI in general.
I'm going off of memory on this one, from posts by Andrew Borts on the ignite400.org list. He had (has?) an extremely active site and was complaining about the expense of upgrading his systems to do the webserving. Now this was a few years ago, so maybe the less expensive boxes have enough horsepower to handle even the most active of sites.
> JSP Pros: > Easy to find people who know it. > Can run web app tier on just about any platform. > Can connect to multiple back-end databases. > Can separate HTTP server tier from web app tier. > Lots of open-source resources. I actually haven't had much problem findint people familiar with CGIDEV2 programming.
I can't even find "regular" RPG developers in Richmond, VA, much less ones who know anything like CGIDEV2. If you know any, send them my way ;-)
And drastically more open source resources, since 95% of the iSeries community still doesn't understand open source.
Which is a huge hindrance to us.
However, there's even more PHP open source out there. PHP is also extremely widely used, at least as widely used as Java.
That's why I think people may want to consider PHP as an alternative. I can't speak to how it scales, but I'm sure it's a pretty viable alternative, at least for sites that are not getting millions of hits daily.
Another Pro of using Java that you didn't list is that there's lots and lots of functionality available. By that, I mean routines that assist you with writing web applications. Far more tools than CGIDEV2 provides. (Though, again, .NET and PHP have most of the same tools as Java)
That's what I was referring to in open source resources.
Also, for a small shop, performance can be a big problem with Java. That's my biggest gripe about it.
Are you talking about Java, or WAS? Because if you don't have a nice new box loaded with memory, I'd probably recommend using Tomcat over WAS. Again, I'm lucky, I have lots of nice boxes to play with. Mike E.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.