Using CGI, here’s how it might work for a dynamic web page that has the current server date.
Listen in as our two black belts discuss the pros and cons of CGI and Servlets.
CGI is better than Servlets. We write CGI scripts in Perl at our shop, because everybody knows Perl.
I doubt everybody knows Perl. I like Perl, but we’re all Java programmers in our shop so we prefer Java.
I guess that’s fine if you use Java, since you know it. But it’s certainly not worth it for us to switch to Java. There’s no advantage.
With much respect, master, there are many advantages to using Java over Perl for the things you want to do with CGI.
You challenge me? On what grounds?
Performance, for one thing. With Perl, the server has to launch a heavy-weight process for each and every request for that resource!
This is no different from Java... what do you callthe JVM? Is not every instance of the JVM a heavy-weight process?
Ah, yes, but you see Servlets stay loaded and client requests for a Servlet resource are handled as separate threads of a single running Servlet. There’s no overhead of starting the JVM, loading the class, and all that...
I see you have forgotten much. Web servers now are able to keep a single Perl program running between client requests. So the additional overhead argument is worthless.
I have not forgotten, master. But it is not all web servers that can do that. You are talking about a special case which does not apply to all Perl CGI programs. But Servlets will always be more efficient in that way. And let’s not forget that a Servlet can be a J2EE client, while a Perl CGI program cannot.
What are you talking about? Any CORBA-compliant thing can be a J2EE client.
I do not mean a client to a J2EE program, I mean a client that is J2EE. A Servlet running in a J2EE web container can participate in security and transactions right along with enterprise beans and there are—
to be continued...
Stop—I’m late for my Pilates class. But this is not over. We’ll have to finish it later.