Erste Gehversuche mit JSP und Servlets [Part2]

Ich möchte wieder einige Ergebnisse meiner Recherchen präsentieren, die heute eher allgemeiner Art sind. Es wird zuerst um die Unterscheidung zwischen Servlets und Java Server Pages gehen. Anschließend stelle ich mir die Frage, welche Architektur-Muster es gibt, welche für uns wichtig sind. Wichtig heißt in diesem Zusammenhang:

• Die Architektur soll genauso abstrakt sein , wie es unser Projekt erfordert. Es hilft nichts, wenn wir die halbe Zeit brauchen, das Architektur-Muster zu verstehen, während die Funktionalitäten, um die es ja beim Programmieren immer noch geht, zuweit in den Hintergrund gelangen. Eine tolle Trennung von bspsw. Programmlogik und Design hilft uns nichts, wenn wir ewig brauchen, sie zu verstehen.
• Die Architektur soll es uns erlauben, bestimmte Code-Segmente wiederzuverwenden.
• Die Architektur sollte es einfach machen, das Design relativ unabhängig von der Programmlogik zu machen. Zumindest sollte die Kopplung so lose sein, dass man ohne viel Mehraufwand das Design ändern kann und dass man ohne die Programmlogik in allen Einzelheiten zu verstehen Dinge am Design ändern kann.

Zum Schluss werde ich noch ein Argument bringen, warum Bierspenden von Seiten des LV-Leiters (= des Auftraggebers) unsere Motivation erhöhen können. Zunächst zu Servlets und JSPs.

Der Nachteil von Servlets – Die Wendung zu JSPs

Das folgende Argument, warum man sich mit JSPs beschäftigen und nicht nur rein Servlets machen sollte, habe ich wieder (wie nahezu alles in diesem Teil incl. der Grafiken) im JSP-Tutorial gefunden und sieht folgendermaßen aus:

[Bei Servlets] ist die Verwendung mehrerer out.println()-Statements zur Generierung der HTML-Antwortseite extrem aufwändig und nicht sehr übersichtlich. [...] Die Trennung zwischen Webdesign und Programmierung der dynamischen Inhaltsanforderungen ist [bei Servlets] nicht sauber möglich.
An dieser Stelle setzen nun die JSPs ein, die genau diese Trennung versprechen einzulösen. Dazu werden reine HTML-Seiten genommen und um spezifische Tags und JSP-Angaben erweitert.³ Diese JSP-Seiten werden nun genommen und im Laufe ihres [...] Lebenszyklus in Servlets umgewandelt, die dann bei HTTP-Anfragen zur Ausführung kommen.

Einfach gesagt kann man bei JSPs in HTML-Code Java-Code einbinden, während man bei Servlets umständlich mit out.println()-Befehlen den HTML-Code genereieren muss. Server Pages bringen Einiges an Übersichtlichkeit und das ist eigentlich auch die Kritik am Servlet-Only-Architekturmodell 1, das ich jetzt erklären will.

Model 1: Servlet-only

Das markante an diesem Modell:

• für fast jede Seite gibt es eine JSP oder ein Servlet
• Links zu anderen Seiten der Applikation sind meistens „hard-coded“ (also statisch vorgegeben)
• Die Geschäftslogik ist von den JSPs/Servlets getrennt, wird aber von ihnen aus aufgerufen.

JSP-Tutorial betont:

Für einfachere Anwendungen ist das Model1 auch heute noch völlig ausreichend.

Doch das Problem, das man halt noch immer hat ist:

• Trotz Trennung zwischen View-basiertem Code (JSPs/Servlets) und Geschäftslogik gibt es bei Servlets immer noch das Problem, dass man HTML-Output hat, den man nur mit unschönen out.println()-Aufrufen erzeugen kann. Das schaut besch***en aus und ist auch schwer zu warten, weil man die Übersicht verliert.

Model 1: JSP-basiert

Hier hat man es wieder mit einer seitenzentrierten Architektur zu tun – das heißt, dass es pro Seite ein JSP gibt. Was JSPs nun zulassen:

Zumeist [..] läuft der Prozess so, dass die Webseiten von der Designerin kommen und von der Programmiererin anschließend der Programm-Code in die Seite eingebettet wird. Anstelle von HTML-Ausgaben im Java-Code hat man nun Java-Code in HTML eingebettet.

Da aber nun der Designer sowenig Details wie möglich vom Programmcode sehen will, musste man sich überlegen, wie man diesen verstecken konnte. Hier kommen Beans, Custom Tags und die Expression Language ins Spiel:

Damit wurde der Java-Anteil (wenn man denn vernünftigen Gebrauch von Custom Tags machte) erheblich gesenkt.

Model 2: Abwandlung von MVC für die Eigenheiten des HTTP-Protokolls

TODO: Evt. Kurz auf Struts und JavaServer Faces eingehen

Das Grundprinzip lässt sich folgendermaßen kurz erklären:

• Controller = Dispatcher-Servlet: Nimmt alle Anfragen und Eingaben des Nutzers entgegen und verteilt diese dann – je nach Art der Anfrage – an sog. Handler-Servlets.
• Handler-Servlet: liest die Daten der Anfrage/Eingabe aus dem Request aus und wandelt sie in die richtigen Datentypen für das Modell.
• Modell beherbergt die Applikationslogik und den aktuellen Zustand. (Benachrichtigungen an Observer-Objekte, normalerweise Views, können beim HTTP-Protokoll nicht erfolgen)
• View gibt den aktuellen Zustand des Modells wieder und stellt diese dar.

Struts und JavaServer Faces sind Ausprägungen dieser Architektur. Es wird genau beschrieben, wie diese beiden Frameworks arbeiten, auf den ersten Blick ist es aber doch recht komplex und man fragt sich, ob wir das in unserem Projekt brauchen oder ob nicht ein JSP-basiertes Model 1 ausreicht?

Doch das ist noch nicht alles – jetzt kommt erst die Pointe, die ich in diesem JSP-Tutorial-Kapitel über Architekturprinzipien erfahren habe: Architektur ist nicht alles…

Wie frisch gewaschene Handtücher Projekte optimieren

Natürlich ist eine gute Architektur toll, doch sie ist nicht alles, um Projekte erfolgreich bewältigen zu können. Man braucht auch ein tolles Team, das sich untereinander versteht und das sich motiviert fühlt, das Projekt anzupacken:

Wenn die Chemie im Team und zwischen dem Team und seiner Umgebung nicht stimmt, ist ein Projekt auch mit einer durchdachten Architektur kaum zu retten.[...] Wer nun denkt, dass dies lediglich Kleinigkeiten seien, der sollte sich mal mit den Problemen vertraut machen, die Microsoft sich durch die Kürzung der Benefits eingehandelt hat. Bekannt wurde hierbei vor allem der Towel-Service: Das erneute kostenlose Waschen von Handtüchern in den Microsoft-Umkleidekabinen wurde auf einer Mitarbeiterversammlung bei der Vorstellung diverser Neuigkeiten am stärksten gefeiert. Hier geht es um die implizit mit solchen Maßnahmen ausgedrückte Wertschätzung, bzw. die mit dem Streichen oder Schaffen solcher kleinen Maßnahmen verbundene Veränderung der Wertschätzung. Die psychologische Wirkung, die durch die Schaffung einer angenehmen Arbeitsumgebung und kleiner Anreize, erzielt wird, sollte nicht unterschätzt werden. Wenn die weichen Faktoren nicht stimmen, hat man ein gravierenderes Problem, als wenn die Architektur nicht ganz sauber eingehalten wird.

Wer motivierte Studenten und gute Projekte haben will, sollte sich analog zu Microsoft Anreize überlegen. Wir wären schon mit einer kleinen alkoholischen Spende zufrieden.

Das nächste mal wird weniger auf Geschwafel – mehr auf Ausprobieren der Möglichkeiten von JSP+Servlets gezielt.