Serverseitiges Java für Lotus Entwickler

[Axel_Janssen]

Viele Leute hier sehen Java aus der Apflets-Brille.
Wenn ich IBM richtig verstehe, wollen sie Domino zunehmend mit Java verheiraten.
Dafür sind aber nicht Apflets, sondern serverseitiges Java Thema.
Ich versuche nun in loser Folge Texte über serverseitiges Java zu veröffentlichen, die sich erstmal darum bemühen, die Grundlagen verständlich zu machen. Und ich sage. Ja. Verständlich.  

Der spezifische Charakter von Java bewirkt, dass Produkte eigentlich nicht mehr sooo wichtig sind. Das eine läßt sich problemlos mit dem anderen ersetzen. Zentral für serverseitiges Java ist der open-Source Server Tomcat. Er funktioniert in wichtigen Teilbereichen genau gleich wie Websphere, braucht deutlich weniger CPU und ist leichter zu bedienen.  
Zudem hat Tomcat als Referenzimplementierung (wird später erklärt) eine besondere Rolle in der Weiterentwicklung von serverseitigen Java.
 
Serverseitiges Java ist modular-schichtenmässig aufgebaut. Eins basiert auf dem anderen. JSPs aus Sicht des Java-Server technisch Servlets. Auch Portlets basieren auf Servlets. (näheres zu diesen verwirrenden Aussagen später).

1. Teil: Die Entstehung von serverseitigen Java und Tomcat

1996 erschienen die ersten Servlet Container. Der Begriff Container ist vereinfachend als Laufzeitumgebung zu verstehen. Ähnlich wie - sagen wir als Beispiel - Lotus Web Agenten einen Domino Server als Laufzeitumgebung benötigen, brauchen Servlets eben einen Servlet-Container. Ein Servlet Container ist immer Bestandteil eines (Web-)-Servers.

LotusScript Web-Agenten sind bekanntlich eine spezielle Art von LotusScript-Scripts. Genauso verhält es sich mit Servlets in Verhältnis zu Java. Das sind normale Java-Klassen, die von einer bestimmten Klasse erben (wie ja Applets auch).  
Die Servlets leben also im Container und warten auf einkommende (http-)Requests. Machen etwas damit und senden wieder eine (http-)Response an den Browser zurück.

Gut. Wir haben also bis jetzt 2 Mitspieler:
1.   Servlet-Container
- Produkt von Server-Hersteller programmiert
- Teil eines Servers
2.   Servlets
- Teil einer Anwendung. Werden von Anwendungsentwickler programmiert
- leben im Servlet-Container.

Ersetzt man Servlet Container mit Domino, Servlets mit Notes Gestaltungselementen, müsst ihr jetzt endlich einsehen, dass das auch nicht anders als bei Domino ist.

Zurück zu 1996. Ohne mich jetzt in historische Studien zu stürzen, stelle ich mal die Behauptung auf, dass die ersten Servlet-Container von den Herstellern einfach mal so programmiert wurden. Da gab es natürlich unterschiedliche Vorstellungen darüber, wie ein Servlet (und seine Laufzeitumgebung, der Servlet-Container/Server) zu reagieren hat.

Sun erstellte dann eine Servlet-Spezifikation. Dort wird klar festgelegt, wie ein Servlet zu funktionieren hat. Die Hersteller von Servlet-Containern konnten diese bauen, wie sie wollten. Sie müssen nur garantieren, dass Servlets nach den vereinbarten Spezifikationen funktionieren.

Eine Spezifikation ist wie der Turmbau von Babel rückwärts.

Nach der Spezifikation sprechen alle die selbe Sprache. Deshalb kann ich noch heute meine Servlets in Tomcat, Bea Weblogic, Oracle AppServer, vermutlich mySAP oder natürlich auch Websphere packen und das Servlet und der Servlet-Container verstehen sich (wg. Turmbau von Babel rückwärts).
IRIS hat nie den Kern von Domino als Spezifikation dokumentiert, nach der auch andere Hersteller ihr eigenes Domino entwickeln könnten.
Trotzdem ist uns der Begriff „Spezifikation“ aus der Notes-Welt bekannt. Nämlich im Kontext der „Öffnung gegenüber den Standards“. LotusScript unterstützt heute die (sprachenunabhängigen) DOM/SAX-XML-APIs. Lotus Objekte erfüllen die MS-COM-Spezifikation. Lotus Gestaltungselemente werden mit der http-Engine in mehr oder weniger standard-konformes html3.2 umgewandelt, der Notes-Client versteht teilweise JavaScript, etc. pp.

Moment. Ist es nicht ungewöhnlich, dass der Kapitalismus unterschiedliche Firmen das gleiche Produkt herstellen lässt. Nein. Der Servlet Container ist nämlich aus Sicht des Kapitalismus kein Produkt, sondern Infrastruktur. Für Straßen gibt es ja schliesslich auch relativ enge Normen. Sie erfüllen die gleiche Funktionalität, sind aber hinsichtlich der Teerbeschichtung, der Fähigkeit Verkehr aufzunehmen, etc. verschieden. Genauso ist es mit den Servlet-Containern. Die Unterschiede liegen in Performance, Admin-Tools, spezifischen Entwicklungstools, proprietären Erweiterungen, etc. Wir reden dabei nicht um Kleinigkeiten. Es ist aber in keinem Fall so, dass ein sehr teures Produkt unbedingt performanter ist als ein Gratis-Produkt. Die Unterschiede liegen in vielen Details verborgen.
 
Wichtig ist, dass man den Servlet-Container wechseln kann, ohne die Servlets neu programmieren zu müssen.

Natürlich gibt es noch heute Leute, die der Meinung sind, dass sie eine Sprache gefunden haben, die besser als der Standard ist. Ein Beispiel ist Brendon Upson, der mit seinem Puakma-Server versucht einen Java-Server zu vertreiben für die er seine eigenen Spezifikationen hat. Er ist eigentlich ein sympathischer Mensch. Er argumentiert mit dem „puakma is about choice“-Argument http://www.codestore.net/store.nsf/unid/BLOG-20030820?OpenDocument (die letzten Beiträge). Ich halte davon nix. Was ist, wenn ein großes Känguruh auf Brendon springt? Warum sollen 2 Australier eine bessere Lösung entwickeln, als Tausende von openSource, IBM, Oracle, Sun, etc. Entwicklern, die täglich dem Gemecker der Java-Community ausgesetzt sind?

[Axel_Janssen]

Sun brachte dann 1997 eine Referenz-Implementierung für die Spezifikation heraus. Dies war ein Server-Produkt, dass einen Servlet-Container nach der Servlet-Spezifikation enthielt. Da konnten die anderen Hersteller nicht nur lesen, sondern aus sehen und testen, wie die Servlets nach der Spezifikation funktionieren sollen. Dieses Referenz-Implementierung-Produkt wurde JSDK genannt (Java Servlet Development Kit). Um der Menschheit die Vergänglichkeit von Abkürzungen zu beweisen, gab Sun später dem Standard Java Paket genau den gleichen Namen JSDK (Java Standard Development Kit), hatte aber vorher die Referenzimplementierung in Java Web Server Development Kit JWSDK umbenannt.  
Kurioses am Rande: Die Firma IRIS wurde mit dieser Namensumbenennung intelektuell überfordert. In Domino6 sind die Servlet-Klassen von Domino immer noch in einem Paket jsdk.jar (fehlt w). Ihr könnt das im Programmverzeichnis von Domino (Client und Server) suchen und mit Winzip öffnen.  

IBM hatte damals schon ein (auch) serverseitiges Java-Framework namens San Francisco. Davon habe ich aber keine Ahnung. Jedenfalls näherte sich IBM von seinen San Francisco Geschichten immer mehr dem Standard an.

Standards wurden nicht von Sun diktiert. Vielmehr bildete sich ein aristokratischer Java Community Process, an dem alle großen Hersteller, die was mit Java zu tun hatten (Sun, IBM, Oracle, SAP, BEA, etc.) teilnahmen. In unserem Zeitalter (2003) wurde dieser Prozess basisdemokratischer. Individuelle Entwickler werden zunehmend Mitglieder der Standardisierungsgremien.
Das ganze ist genau wie Krieg der Sterne. Alle gegen dem Imperator Bill Gates, der aber (noch) genug Geld und Macht hat, um sich seine Sklaven und Roboterarmee zu halten.
 
1998 brachte dann Sun die Java Server Pages Spezifikation heraus. Dies war eine Übernahme des erfolgreichen Microsoft-Konzepts der Active Server Pages (ASP). JSPs bauen völlig auf Servlets auf. Das ist ähnlich wie bei Dune der Wüstenplanet. Das Spice ist der Wurm und der Wurm ist das Spice. D.h. eigentlich ist nur das JSP ein Servlet und das Servlet eben nicht ein JSP, aber mehr dazu später. Motivation hinter JSP war Rapid Application Development.
 
1998 kam auch die zweite Referenzimplementierung des Java Web Server Development Kit, das in Java Web Server Development Kit genannt wurde (JWSDK). Dieses implementierte (erfüllte, hielt sich an) eine neue Version der Servlet Spezifikation(Version 2.0).
Bei Spezifikationen gibt es wie bei Domino und auch LotusScript unterschiedliche Releases (Notes4, Domino5, Domino6, Lotus-Script 3.0, etc).
Dieses JWSDK enthielt wieder einen Server mit Servlet Container und ein paar goodies. Neu war eine JSP-Engine namens Tomcat. Der Sun Entwickler Duncan Davidson hoffte durch den Namen Tomcat den Buchverlag O’Reilly zu bewegen, eine Katze für das O’Reilly Cover über die neue Technologie zu erhalten. Das hat nicht funktioniert. Auf dem ersten Servlet-O’Reilly Buch war dafür ein Teekessel und für JSP eine Juke-Box.

Um mehr Entwickler-Support zu bekommen, schenkte SUN Tomcat der OpenSource Organisation Apache, die mit dem gleichnamigen Web-Server viel Erfolg hatte. Apache gründete daraufhin Jakarta für Java-Projekte und benutzte die JSP-Engine direkt auch als Servlet-Container (wie gesagt, JSP und Servlets sehen verschieden aus, sind aber technisch sehr ähnlich bis gleich). Jakarta wuchs sehr schnell. Immer mehr Projekte kamen hinzu. Die ersten bildeten sich um Tomcat.
Die meisten von den Jakarta Projekten sind dafür da, dass der Entwickler nicht so viel Arbeit hat. Sie erfüllen bestimmte Funktionalitäten und man tut die entsprechenden Jar-Pakete in die Projekte.( Jar-Pakete sind eine Art File-System für Java Klassen, quasi ein Paket aus (Zusatz-Java-Klassen)). Zum Angucken kann man .jar Dateien mit WinZip öffnen.

Tomcat wurde dann zur neuen Referenzimplementierung der Folge-Spezifikationen für Servlets und JSPs.
Referenzimplementierung bedeutet, dass neue Releases der Servlet- und JSP-Spezifikationen auf Tomcat implementiert werden und das ist dann der Standard. Die erste fertige Version war 3. Später kam 4 und heute haben wir 5 in einer sehr späten beta.
Apache.jakarta darf man sich nicht als revolutionäre Organisation vorstellen, wo Leute T-Shirts von Massenmördern wie Ernesto "Che" Guevara tragen. IBM, Oracle, Sun etc. stellen Entwickler für apache.jakarta Projekte frei. Im Source-code stehen die email-Adressen der Entwickler und da sind extrem viele Adressen von eben den großen Herstellern. @Microsoft.com fehlt natürlich.

[Axel_Janssen]

Warum stellen die großen Hersteller Leute für die Programmierung eines Produktes bereit, das inklusive Source-Code verschenkt wird  

IBM, Oracle, BEA hofften eher mit Enterprise Java Bean (EJB)-Containern wie sie in Websphere oder Weblogic enthalten sind Geld zu machen. Die Servlet und JSP-Engine stellen dafür die Infrastruktur bereit. Die großen Hersteller haben in ihren Produkten zwar eigene Servlet und JSP-Engines. Jedoch lassen sie sich bei der Entwicklung durch den Tomcat Source Code „inspirieren“.

Marketing-technisch funktionierte die Servlets-umsonst-EJBs-für-viel-Geld-Strategie  sehr gut. Viele Unternehmen kauften sich direkt die Komplettlösung mit EJB-Container für fettes Geld, obwohl sie den gar nicht brauchten. EJBs entwickeln sich weiter. Es hat aber in vielen Projekten auch nicht funktioniert (inperformant, zu wenig flexibel). Eigentlich ein bischen wie Lisa. Nur das eben in EJB viel mehr Geld reingesteckt wird. EJB lernen ist aber trotzdem nicht schlecht, weil man da viel über typisches „Java Enterprise Computing“ lernt (transaktionaler Zugriff auf Datenbanken, Naming and Directory Services, Security, Objekt-Verteilung, asynchrone Verarbeitung von Aufrufen). Immer die gleichen Sachen also, die man im Unternehmen eben oft braucht.


In den Zeitaltern zwischen 1999 (Beginn von EJB) und heute, kam es zur langsamen evolutionären Entwicklung von EJB-Konkurrenz-Lösungen, die sich in der Zukunft unter Umständen durchsetzen werden. Zwar gibt es in Tomcat keine EJBs, jedoch können diese Konkurrenzlösungen benutzt werden.
Das erscheint mir so ähnlich wie in der Domino Web-Programmierung. Da stellte ja Lotus die Apflets zur Verfügung und jeder, der seine 5 Sinne beisammen hatte, entwickelte DHTML Lösungen für Domino Web-Programmierung. Im Gegensatz zu Apflets in Domino existieren aber Bereiche, für die EJBs Sinn machen.

Zurück zu Tomcat. Tomcat war seit der ersten Version 3.0 (ja) als standalone Webserver zu betreiben. Bei Domino kann man ja auch html-Files ins Html Verzeichnis tun und die werden direkt angezeigt und nicht durch den domino-http-task und verwandtes weiterverarbeitet. So ist es hier auch. Der Webserver schaut sich erst mal die einkommende URL an und entscheidet dann, ob er den Request an den Servlet-Container weiterleiten oder direkt ein html file zurückliefern soll.

Der Servlet Container in Tomcat ist also ein Zusatzprodukt für den Webserver in Tomcat. Zwar ist der Webserver in Tomcat nicht schlecht. Trotzdem sind Spezial-Webserver wie z.B. apache besser. Für die Einbindung von Tomcat in irgendeinen Webserver gibt es in der Regel plug-in Lösungen. Das ist oft friklig. Wenn es dann aber mal läuft, dann läuft es eben.

Tomcat ist nicht nur Spiel-Server für Entwickler. Er ist mittlerweile so gut, dass er oft auch produktiv eingesetzt wird.

Die nächste Folge beschäftigt sich mit der höchst komplexen Installation von Tomcat. Es handelt sich ja hier schliesslich um ein openSource Produkt und da gibt es nicht die Weisheit eines wirklichen Herstellers. Nächste Folge also: Die gefürchteteten schwierigen Schritte:
- Download
-   Installations-exe anklicken, laufen lassen und dann auch noch ein Installations-Verzeichnis aus einem Dialog wählen.
-   Systemvariablen setzen (nicht 1, nein direkt 2)
-   -feste auf das Start-Icon drücken.
- Zum testen in den Browser eine äußerst kryptische Zahlenkombination eingeben (http://127.0.0.1:8080)

Gruß Axel

[Rob Green]

cool, freu mich schon auf den nächsten Part

Megdank für das geile Intro zur serverseitigen Java.

[Axel Janssen temp]

Zwischen-Hinweis:
Diese Woche wird auf Javaranch die neue Version des führenden Standardwerk für Servlet/JSP Programmierung von Marty Hall diskutiert und verlost:
 "Core Servlets and JavaServer Pages, Vol. 1: Core Technologies, Second Edition"
beinhaltet:
- JSP 2.0
- servlets 2.4
- JSTL
- Java 1.4

Vielleicht ist es für Interessierte interessant da mal in die Diskussionen reinzuschauen.
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=forum&f=7