http://www.servlets.com/ http://java.sun.com/products/servlet/ http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
Siehe auch:
Servlets in Java:
http://www.servlets.com/ http://java.sun.com/products/servlet/ http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
http://webware.sourceforge.net/Papers/IntroToWebware.html http://www.onlamp.com/pub/a/python/2001/03/14/pythonnews.html http://webware.sourceforge.net/
Die Konkurrenzsituation besteht weniger zwischen ServLets und JavaApplets (obwohl dies der Name suggeriert), sondern zwischen ServLets und konventionellen CGI-Programmen (in Perl, C oder anderen Sprachen).
JavaApplets, die eine dynamische Anzeige (z.B. eine Animation) erzeugen, leben von der Prozessorleistung des Client und der hohen Bandbreite zwischen ClientProzessor? und VideoRam?. ServLets und CgiProgramme können damit nicht konkurrieren. Das gleiche gilt in übertragenem Sinn, wenn JavaApplets die Funktionen einer Applikation (mit Dialogen etc.) übernehmen. Die Reaktivität einer Server-seitigen Lösung ist zu gering.
Wenn JavaApplets, so wie in JavaAppletsImWiki (Beispiel 2) eine statische Grafik erzeugen, dann könnten CgiProgramme oder ServLets das auch: die Grafik wird übertragen (egal ob am Server neu erzeugt oder gecached). Technisch hat hier das Applet Vorteile, wenn die Gesamtheit der beim Applet übertragenen Daten (Applet+Produktionsvorschrift) klein ist gegenüber der Größe der grafischen Daten.
Dies ist aber in der Praxis meist nie der Fall. Dem steht der gravierende Nachteil gegenüber, das durch die Verwendung derartiger Techniken die sicherheitsbewussten Internet-Benutzer (siehe BrowserSicherheit) ausgesperrt werden. Da die heute verbreiteten WebBrowser das Aktivieren von Java in der Regel nur global zu lassen, ist die Verwendung der Applet-Technologie selbst in IntraNets? äusserst fragwürdig. Da Applet per HTTP übertragen werden, können damit leider die üblichen Schutztechniken (FireWall) ausgehebelt (untertunnelt) werden.
Wäre JavaServlets vielleicht ein besserer Name für diese Seite?