Backstage

[Dieser Artikel ist noch in Bearbeitung und daher unvollständig]

Bei einer traditionellen Anwendung ist es in der Regel so, dass die Applikation selbst für die Darstellung verantwortlich ist. Auch wenn Sie dafür eines Severdienstes wie X bedienen sollte, so obliegt die Steuerung dennoch dem Programm.

Anders bei einer Webapplikation. Hier werden die Daten an einen Browser übergeben, der sich um die Darstellung kümmert. Dazu verpackt der Server den darzustellenden Inhalt in ein (X)HTML-Dokument. Daneben kann der Server noch ein paar Darstellungsinformationen in Form von CSS mitliefern. Alles Weitere ist dann Sache des Browsers. Und so wie es unterschiedliche Browser gibt, kann sich auch die Darstellung unterscheiden. Die stetige Weiterentwicklung der Standards sorgt hier glücklicherweise für eine allmähliche Angleichung. Hält hier der Anwender aber ein lokales CSS vor, so kann die Darstellung wieder anders ausfallen.

Nicht nur, dass eine Webapplikation die Ausgabe an den Browser delegiert; sie wird auch nicht von selbst aktiv! Erst wenn der Anwender via Browser eine Seite anfordert, so liefert die Applikation eine solche aus. Die (scheinbar) aktive Änderung von Inhalten aufgrund von severseitiger Verarbeitung geht nicht ohne weitere Hilfsmittel. Hier lautet das Stichwort AJAX (Asynchronous JavaScript and XML). Womit wir neben (X)HTML und CSS bei einer weiteren browserseitigen Technik angelangt sind: JavaScript. Der Browser fordert zwischendurch mittels JavaScript immer wieder mal mittel pertiellem Request ein paar Daten an und tauscht Teile des Browserinhalts aus. Somit entsteht zumindest zum Teil der Eindruck, der Server aktualisiere den Bildschirm. Tatsächlich geht hier aber immer wieder eine Anfrage vom Client aus (pull). Ein echtes Push, also die vom Server veranlasste aktive Änderung der Darstellung erfordert einen tieferen Griff in die Trickkiste. Hier wird die Antwort an den Client künstlich verzögert, um zu einem späteren noch Informationen übermitteln zu können. Doch dies ist etwas für einen späteren Teil.

Bei einer traditionellen Applikation kann das Programm sofort auf eine Anwendereingabe reagieren. Bei einer Webapplikation bekommt das Programm erst dann etwas von den Anwendereingaben mit, wenn eine neue Seite oder – meist in Verbindung mit AJAX – patriell eine neue Seite angefordert wird. Zu diesem Zeitpunkt können bereits Eingaben in diversen Feldern erfolgt sein. Nicht schwer vorzustellen, dass die Applikation hiermit etwas anders umgehen muss. An dieser Stelle unterstützt JSF den Anwender und löst auf dem Server für die einzelnen Eingaben entsprechende Events aus, so dass sich ein dem Entwickler nicht ganz fremdes Programmiermodell ergibt.

Und noch ein Unterschied: Eine Webapplikation läuft meist in einer Ablaufumgebung, die ihr zahlreiche Dienste zur Verfügung stellt. Eine solche Ablaufumgebung wird als Container beszeichnet, im Falle von JSF ist dies ein sogenannter Servlet-Container. Dies deutet auf die zugrunde liegende Technik der Servlets hin. Auch bei der Entwicklung mit JSF kann die direkte Nutzung von Servlets hier und da angebracht sein. Es kann also nicht schaden, wenn Sie sich auch mit dieser Technik vertraut machen. Mehr dazu in einem späteren Teil.

Der Servlet -Container versorgt die Applikation mit Schnittstellen zu anderen Diensten. Er ist Bestandteil eines Applikations- oder auch Webservers. Zahlreiche Server beinhalten im Wesentlichen einen Container und so werden die Begriffe Container und Applikationsserver häufig synonym genutzt. Tatsächlich kann ein Server jedoch mehrere Container beherrbergen. So z.B., GlassFish, der neben Dem Servlet-Container u.a. Auch einen EJB-Container beherrbergt. Im Folgenden schauen wir von außen auf den Applikationsserver.

Wenn nun ein Anwender die Web-Applikation nutzen möchte, so ruft er in seinem Browser die URL der Anwendung auf. Der Client startet eine Anfrage an den Server. Dieser erkennt anhand der URL, dass er nicht einfach eine statische Seite ausliefern muss, sondern leitet die Anfrage über den Container an die Applikation weiter. Dort wird diese verarbeitet. Die Ausgabe wird als (X)HTML-Dokument genertiert und an den Browser verschickt. Dieser zeigt die Daten an.

<Abbildung fehlt noch>

Bei dieser Sichtweise betrachten wir den ApplicationServer al BlockBox. Interessant ist aber auch, was darin passiert. Erinnern Sie sich kurz an die bisherigen Anwendungen: Hier haben Sie jeweils eine JSF-Seite definiert. Als Seitensprache wurden Facelets eingesetzt. Jede Seite bestand neben HTML auch aus bestimmten Tags, wie beispielsweise “f:InputText”. Im Browser haben jeweils die URL einer solchen Seite angegeben. Entweder direkt oder indirekt als Angabe der Applikations-URL, die aber intern auf eine konkrete Seite verwiesen hat.

Der Server bestimmt anhand der URL die darzustellende Seite, analysiert deren Inhalt und löst die Tags auf. Im einfachsten Fall werden diese durch entsprechende Daten ersetzt. Die so entstandene Seite wird an den Browser geschickt. Dies ist aber lediglich eine vereinfachte Darstellung. Der Browser könnte ja bereits vorher Daten der Aplikation angezeigt haben. Daher prüft JSF als erstes, ob bereits eine Session besteht. Falls ja wird der Komponentenbaum, die logische Abbildung der dazustellenden Inhalte, wieder hergestellt. Eingaben werden validiert und Datenfelder upgedatet. Insgesamt unterscheidet hier JSF sechs verschiedene Phasen.