🚀 go-pugleaf

Acid Steve <acidsteve@hempseed.com> wrote:

>Hi,
>The question is what can servlet do, what it is? Is it practically the
>same as server application that u write for some client applet, or smth
>that uses CGI scripts. If it is, what the advantages of using servlet
>instead of server application?
>Really appreciated your answer,
>                                     Acid Steve
>
>PS: I'm asking this question because couldn't get enough information on
>Web sites and in documentation.


Soundbite answer: An applet runs  inside  a web-browser and allows it
to do clever things of all kinds. A servlet runs inside a web server
and allows _that_ to do clever things of all kinds.


Better answer:

Back in the mists of time, web-pages had text and graphics on and that
was it - they just sat there, and so all the web-server had to do was
accept incoming connections, analyse the header, grab the file in
question and fire it back down the wire.

Then ppl said, "wouldn't it be cool if we could use this to interact
with the server?" and so forms and CGI scripting were invented. Forms
allowed the user to fire data, in a fairly limited way, back to the
server. The server then shoveled that into a specified CGI script. A
CGI script is a standard program that accepts in the form or whatever
from its "standard input" (i.e. as though somebody was typing it in)
and produces a reposnse on its "standard output" (i.e. normally the
console window - DOS box to windows ppl).

However, CGI has some problems:

1. Duff integration. A CGI program can't interact very well with the
server, so things like error handling are crude.

2. Iffy security. CGI scripts can be written in anything, including
langages like C which are susceptible to things like buffer-overrun
attacks. Also, web-servers often ship with CGI scripts that a newbie
admin doesn't know about and fails to configure properly. This can
leave his system wide open.

3. Efficiency. CGI scripts are written in whatever the writer
preferred, and usually started life as experimental lashups which grew
organically and are now totally unmaintainable. Some common CGI
languages are interpreted and simply can't cope with the workload a
server places on them - they were never intended to. Also, even a
well-designed script needs a separate process, and 1 extra process per
connection adds up to a lot of overhead on a big server.


Cue servlets. Java would like these to replace CGI scripts entirely
(and so would I). Basically they do they same kind of job, but better:

1. Tight integration. The servlet is tightly connected to the server
and has access to all the info about the client that the server has.
This gives it much more control over how the server behaves, and
allows it to do a better job.

2. Good security. Java checks everything so buffer-overrun attacks 
can't happen. And since Java was designed from the ground up to be
secure, amongst other things. Most other languages weren't. Also, you
know exactly what language a servlet is written in and what that
languages characteristics are. A new servlet can be written in
anything (including, perhaps, some bizarre language that only 3 people
in the world can read, let alone analyse).

3. Efficiency. No interpreting, because the servlet will get JIT'ed
into machine-code when the server starts. And no multiple-process
overhead. Or so claims Sun's white paper, which I've been quoting in
spirit for the whole of this post. Actually, If all your scripts are
written in properly-optimised, well-written C then Java will probably
be a bit slower. However, most ppl's are written in interpreting
scripting langauges which are about as efficient as glass hammers, so
you'll probably win here too.

4. Persistence. CGI scripts are created to process a single
transaction, they do that, produce output and then die - in theory,
the whole thing is instantaneous,  everything logically happens at a
single point in time. However, some apps (e.g. a secure server, where
you want to log in, do privileiged stuff and then log out again) need
the idea of a "session", which spans a finite period of time and many
transactions. Since servlets stay up until the server manager kills
them (and hence stops the service) they can relate to this easily.


To finally answer your questions:

Yes, you can use a servlet as the server end of an applet. E.g. you
could have an applet that showed a quake level, and a centeral servlet
that kept track of many of these client-applets, and allowed them to
co-ordinate where everybody was - hey presto, browser-fronted
deathmatch. (I know this sounds crazy but there's actually a project
underway to do just this!) The web-server handles the low-level TCP/IP
and HTTP crud for you (and there's _plenty_ of that!).

And yes, you could (should!) use a servlet in place of a CGI script,
reasons as above.


Hope this helps


Will Dickson.