hi I would like to know how CGI programming is done with java and what is the difference between servlets and CGI scripts.Which one of this is efficient??? Any help would be appreciated Regards, Pradeep.
Servlets are far more efficient. It processes CGI requests faster than C programs. You can write a Java plain CGI program, but it would be very slow. The JVM would be loaded with each request. A plain Java CGI would just be an application reading standard in and writing to standard out. A servlet runs all the time. Each new CGI request activates a method in your Servlet class. The parameters are your "incoming" and "outgoing". You can even handle several CGI requests simultaneously.
To expand a little on Paul's comments: There can be occasions when writing a CGI program in Java makes sense. In particular in cases where the overhead of starting a new JVM is small compared to the benefits gained from the power and flexibility of Java. On a reasonably specified system, starting a Java program should take no more than a second or two (try it out by timing a "hello, world" application). If you need to quickly write, test and deploy some complex (or just slow) Java code which uses a lot of pre-written classes, writing it as a CGI may be the right choice. On the other hand, though, setting up and using an appropriate server and servlets is a much better long-term solution. Typically in such systems all the overhead of starting the JVM and initialising your part of the system (opening database connections, reading initial data, setting preferences and so on) are done just once, when the servlet is loaded by the server. Each normal "hit" does just the actual processing required. This can mean that a servlet system is even faster than a comparable CGI program written in Perl, C++ or any other language. As a concrete example, I put together a simple "requirements capture" system for where I work. The first prototype used CGI and was written in Bourne shell and Perl. To add a new entry took about 6-7 seconds (it's not a fast box that the server runs on - a 25MHz Sparc LX, running Solaris 2.6). Converting that to Java servlets reduced the response time down to about 300 ms. I also find Java easier to write and maintain than Perl, so I was better situated to implement new features when required. Finally, if you have any more servlet questions, may I recommend that you ask them in the "servlets" section of this board, which I have recently taken over as moderator. I hope this has helped.
Well done Frank! So you think that a Java CGI can have it's place? Can you expand a bit more on starting the JVM? That was my biggest concern. You would think by now that there would be a way to keep a JVM going at all times and when you typed Java MyProgram it would use the VM that is already running rather than start a new VM.
Joined: Jan 07, 1999
One of the things I found it difficult to "grok" when I first encountered CGI was the rationale behind it in the first place. And one of the most common questions about servlets (and mod_perl, and FastCGI, and NSAPI, and ...) is "why bother, when we already have CGI, and everyone uses it?" We are all famailiar with CGI programs, we probably use lots every time we access the web, often without even realising, for everything from search engines to bulletin boards, to counters and web rings. But, as far as I can tell, all of this may be considered as "pushing the envelope" of what CGI was originally concieved for. The original intent of CGI was, as its name implies, as a "gateway" interface between web servers and legacy systems. If you think of it in these terms, with the CGI program just acting as a conduit between the web server and another machine, running a completely different, non-web application, many of the original design decisions make more sense. A typical legacy system would have a lot of set up and processing, and may have a long wait for the remote machine or application to reply. The new web/CGI interface would often be considered just a prototype or trial system in which performance is not particularly important, and the number of users and the number of requests would be small. In this context the model chosen (pass parameters as environment settings, i/o using standard input and output, new process for each request) is a sensible one. It matches closely the easiest development route for Unix software. All common development tools and languages support this way of working. Its very tolerant of memory leaks, etc. In this context it also may make sense to use Java as your language of choice for CGI development. If you already have a large body of Java code or development skills, maybe even a complete application which you want to use via a web interface, just consider the original CGI criteria: Does the code being "gatewayed" take a significant time to run? Is your estimated number of users or requests small? Do you use a web server which doesnt't support servlets? If you can't answer "yes" to all these questions, you really should consider one of the many performance-increasing alternatives. I naturally prefer servlets, but I realise that they are not available on all systems. On your other topic of why not a "java" command that passes info to a continually -running jvm. I think this may be one of the aims of the likes of JOS (Java Operating System) and the various Java Shells which are about on the web. I quite like the idea of writing a simple one though. My biggest worry would be what to do about class versioning. Say I have such an infinite VM running. I compile a new little application comprising two classes "TestApp" and "Useful". and run it. test app is now running and doing it's job. Assume it takes a long time. In the meanwhile, I edit Useful to add some more useful features, and compile it and a new class "Test2App". I then try to run "Test2App". What should happen? Test2App picks up the loaded old Useful? TestApp suddenly has its Useful changed under it? The VM has two different Useful classes loaded, one for each application? As you can see, none of these answers are intuitively right. The third is probably the most flexible, but that might mean either a very complex versioning class loader, or a complete independent class collection for each "application". This first might never work, and the second might take nearly as long to start up as a new VM. Hmmm.