Web Presentation Tier

Web Engineering Web Presentation Tier Studienbrief WEB Version 3.2 (Juli 2011) Karl M. Göschka

Inhaltsverzeichnis 0. Übersicht... 4 0.1. Lehrziele... 4 0.2. Lehrstoff... 4 0.3. Aufgaben, Übungen... 4 0.4. Voraussetzungen... 4 0.5. Literatur... 5 1. World Wide Web Grundlagen... 6 1.1. Hypertext Markup Language: HTML und XHTML... 7 1.2. Uniform Resource Identifier... 9 1.3. Das Hypertext Transfer Protocol... 10 1.4. Common Gateway Interface... 11 2. Heterogene Clients... 13 2.1. Web Client... 15 2.1.1. User Interface: HTML und JavaScript... 15 2.1.2. Protokoll: Probleme mit HTTP... 16 2.2. Web-Server-Anbindung... 19 2.2.1. Verbindung von Web-Server und Middleware: CGI und API... 19 2.2.2. Script-basierte Web-Anbindung... 20 2.2.3. Seiten-basierte Web-Anbindung... 22 2.3. Native GUI Clients... 24 2.3.1. Java-Applikation... 25 2.3.2. Applikation und Datenbank auf dem Client... 26 2.4. Mobile Devices und Sprach-/Datenkonvergenz... 27 2.4.1. Clients am Mobiltelefon: WAP und WML... 28 2.4.2. WAP-Protokoll-Stack (*)... 29 2.4.3. Wireless Markup Language WML (*)... 31 2.4.4. WML Scripting Language (*)... 33 2.4.5. Die weitere Entwicklung und WAP und WML... 34 Karl M. Göschka Seite 2 / 63 WEB v3.2

3. MVC und Frameworks... 35 3.1. Model View Controller Pattern... 35 3.2. Das MVC Pattern im Web... 37 3.3. Java Server Faces - JSF... 39 3.3.1. JSF und andere UI Frameworks für das Web... 39 3.3.2. JSF ist Server-seitig... 42 3.3.3. Die Bausteine von JSF in Bezug auf MVC... 43 3.3.4. Die Bearbeitung einer JSF Anfrage... 44 4. Rich Internet Technologien (RIT)... 47 4.1. Java-Applets... 48 4.1.1. Vergleich von Java-Applets und reinem HTML... 50 4.2. DOM Document Object Model... 54 4.3. Client-seitiges Scripting: JavaScript... 56 4.4. Ajax Asynchronous JavaScript and XML... 58 5. Lehrzielorientierte Fragen... 62 Karl M. Göschka Seite 3 / 63 WEB v3.2

0. Übersicht 0.1. Lehrziele Das primäre Lehrziel der Studieneinheit Web Presentation Tier ist, verschiedene Alternativen für die Web-Client-Anbindung an verteilte Systeme zu kennen und bewerten zu können. 0.2. Lehrstoff In diesem Studienbrief werden die Grundlagen des Web wiederholt (Abschnitt 1), bevor in Abschnitt 2 auf die Probleme und Lösungsansaätze eingegangen wird. Dabei wird der Web- Client auch mit dem Native GUI (Desktop) Client sowie mit dem Mobile Client verglichen. Abschnitt 3 zeigt dann, wie die technologische Vielfalt und die mannigfachen Paradigmenbrüche in einem Web UI durch UI Frameworks überwunden werden können, die auf dem Model View Controller (MVC) Pattern beruhen. Als prominenter Vertreter wird Java Server Faces (JSF) etwas genauer erläutert. Abschnitt 4 schließlich konzentriert sich auf den Web Browser und die Möglichkeiten durch verschiedene Erweiterungen (genannt Rich Internet Technologies ) ein dem Desktop ähnlicheres Look and Feel für den Benutzer herzustellen. Abschnitte, die mit einem (*) gekennzeichnet sind, dienen der freiwilligen Stoffergänzung und werden nicht geprüft. 0.3. Aufgaben, Übungen Der letzte Abschnitt enthält eine Sammlung lehrzielorientierter Fragen zur Selbstüberprüfung. Die Beantwortung sollte nach Durcharbeiten des Studienbriefes möglich sein. Treten bei einer Frage Probleme auf, so versuchen Sie diese mit ihren Studienkollegen zu lösen. Ist das nicht möglich, können den Vortragenden per email direkt kontaktieren oder Sie stellen die entsprechende Frage in der nächsten Übungsstunde. 0.4. Voraussetzungen Der vorliegende Kurs setzt Kenntnisse des Software-Engineering und der Netzwerkdienste voraus, sowie Objektorientierte Methoden. Der gegenständliche Studienbrief setzt darüberhinaus ein Verständnis der Komponenten-Technologie voraus. Karl M. Göschka Seite 4 / 63 WEB v3.2

0.5. Literatur [1] Heineman, G.T.; Councill, W.T.: Component-Based Software Engineering, Addison- Wesley, 2001. [2] Bass, L.; Clements, P.; Kazman, R.: Software Architecture in Practice, Addison- Wesley, Reading, 1998. [3] Allen, P.; Frost, S.: Component Based Development for Enterprise Systems: Applying the SELECT Perspective, Cambridge University Press, SIGS Publications, Cambridge, UK, 1998. [4] Falb, J.: A Model-Driven Method for the Development of Nomadic Interactive Systems, Dissertation, TU Wien, 2005. [5] Fowler, M.: Patterns of Enterprise Application Architecture, Addison-Wesley/Pearson, 2003. [6] Mann, K.: Java Server Faces in Action, Manning Verlag, 2005. [7] Walter, T.: Kompendium der Web-Programmierung, Springer, 2008. [8] Sowa, H., Radinger, W., Marinschek M.: Google Web Toolkit, dpunkt, 2008. Karl M. Göschka Seite 5 / 63 WEB v3.2

1. World Wide Web Grundlagen Die Tage des wenig benutzerfreundlichen und auch nur wenigen Benutzern vorbehaltenen Internets als Medium für Computerexperten waren gezählt, als Tim Berners-Lee seine erste Version von HTML (Hypertext Markup Language) im Jahr 1989 1 präsentierte, zunächst allerdings nur, um auf einfache Art verlinkte, statische Dokumente (wissenschaftliche Arbeiten in CERN) verteilt zur Verfügung zu stellen. Die ersten Prototypen der Server und Browser wurden 1990 bis 1992 implementiert. Von diesem Moment an begann das Web ein exponentielles Wachstum des Internets auszulösen: Waren es im Juni 1991 noch ca. 500 000 Knoten weltweit, davon 63 000 in Europa, so waren es im Juni 1998 bereits 35 Mio. Knoten weltweit, davon 6,65 Mio. in Europa. Die monatliche Wachstumsrate im Juni 1998 betrug ca. 1 Mio. weltweit und über 200 000 in Europa. Nach nur sieben Jahren überstieg die monatliche Wachstumsrate den ursprünglichen Bestand. Ein Grund für dieses exponentielle Wachstum ist in der einfachen grafischen Benutzeroberfläche zu sehen, die nach und nach alle relevanten Dienste in einem einzigen Werkzeug vereinte dem Web-Browser. Als mehr und mehr Web-Server entstanden, begannen auch mehr und mehr Benutzer den Web-Browser zu verwenden. Durch diese defacto Standardisierung (und die Firewall- und Internet-taugliche Protokoll-Anbindung) auf Client-Seite entstand der Bedarf den Browser auch für Anwendungen einzusetzen, für die das Web ursprünglich überhaupt nicht konzipiert war, u.a. als abgesetzter (sogenannter remote ) Universal Client für Enterprise Systeme. Die daraus sich ergebende Forderung nach dynamischen Seiten hat zunächst zu Formularen und einem Standard für die Back-End Anbindung geführt. In weiterer Folge jedoch zu einer viele Jahre andauernden (und noch nicht abgeschlossenen) Entwicklung, aus der verschiedene Werkzeuge und Laufzeitumgebungen entstanden sind. Deren vornehmlichster Zweck besteht darin, den Schmerz für Entwickler (und Anwender) zu lindern, der daraus ensteht, dass eine Technologie (Web statischer Dokumente für Informationssysteme) für etwas anderes (remote UI für EAI) eingesetzt wird, wofür sie eigentlich kaum geeignet ist. Bevor diese Client- und Server-seitigen Technologien erläutert werden, erfolgt eine kurze Wiederholung der Grundlagen der Web-Technologien. 1 Obwohl der Begriff Hypertext bereits 1960 erstmals in der Literatur geprägt wurde, hat er sich erst mit der Erfindung des Web verbreiten können. Karl M. Göschka Seite 6 / 63 WEB v3.2

Drei Grundkonzepte sind es im Wesentlichen, die das Web ausmachen: die Hypertext Markup Language HTML, das Hypertext Transfer Protocol HTTP und der Uniform Resource Locator URL. 1.1. Hypertext Markup Language: HTML und XHTML Die Hypertext Markup Language HTML ist eine semantische Markup-Language, also eine Textbeschreibungssprache, wobei Befehle in den Text eingebettet sind, die die Struktur des Textes beschreiben. Leider sind mitunter auch direkte Formatanweisungen enthalten, was dem ursprünglichen Gedanken von HTML widerspricht, weil es sich dabei um physisches Markup handelt. Der Begriff Hyper wird im Wesentlichen von den Links inspiriert, also von der Möglichkeit, von einem Dokument zum nächsten zu traversieren, wobei die Dokumente mitunter von verschiedenen Servern über das Internet geliefert werden. Der ursprüngliche Gedanke von HTML war geprägt von WYSIWYM (What You See Is What You Meant) anstelle von WYSIWYG (What You See Is What You Get). Man wollte also die logische Struktur des Dokumentes und seiner Elemente beschreiben, damit dieses dann in verschiedenen Endgeräten interpretiert werden kann. Das könnte ein Web-Browser sein, aber auch ein Braille-Browser, der den Text blindengerecht auf einem Braille-Terminal wiedergibt oder sogar mittels Text-to-Speech-Synthese vorliest. Die Mehrheit der grafischen Web-Browser und der Wettlauf der Browser-Hersteller um die Gunst der Kunden hat jedoch eine Verschiebung dahingehend bewirkt, dass HTML heute kaum noch für etwas anderes zu gebrauchen ist als für die grafische Wiedergabe auf einem Computerbildschirm. Ein HTML-Dokument besteht aus Elementen (auch Container genannt). Jedes Element wird von einem Beginn- und einem End-Tag eingeschlossen, dazwischen steht der Inhalt des Elementes. Manche Tags werden auch implizit beendet oder besitzen überhaupt kein End- Tag. Weiterhin können im Beginn-Tag auch Attribute enthalten sein, um weitere Angaben über den Inhalt zu tätigen. Elemente dürfen zwar verschachtelt sein, einander aber nicht überkreuzen (d. h. überlappen). Insgesamt besteht ein HTML-Dokument aus einem HTML- Element, welches wiederum ein HEAD-Element mit Metainformation über das Dokument und ein BODY-Element mit dem eigentlichen Inhalt enthält. Die gängigen Browser sind bezüglich der Darstellung fehlerhafter HTML-Dokumente sehr robust, was unter anderem dazu geführt hat, dass viele der heute im Web verfügbaren HTML-Dokumente fehlerhaft sind. Im Sinne von mehr Exaktheit wird daher heute XHTML propagiert, wobei im Wesentlichen die Exaktheit von XML auch in HTML umgesetzt wird. Karl M. Göschka Seite 7 / 63 WEB v3.2

Die exakte Definition von HTML ist mittels SGML 2 erfolgt; die Document Type Definition (DTD) für HTML definiert eindeutig die mögliche Struktur von HTML-Dokumenten. Da diese DTD in den HTML-Standards fixiert ist, ist HTML auch nicht erweiterbar. Das wichtigste Element in HTML ist der Link, in HTML als Anchor bezeichnet, kurz <A>. Das Ziel eines solchen Links wird mit dem HREF-Attribut angegeben, es handelt sich dabei um einen Uniform Resource Locator (siehe folgenden Abschnitt). Wichtig ist auch das Formular-Element <FORM>, mit dem einfache Selektionen oder Texteingaben des Benutzers zum Web-Server hin gereicht werden können. Bild 1.1 zeigt ein einfaches HTML-Dokument, Bild 1.2 die zugehörige Darstellung durch einen Browser. <HTML> <HEAD> <TITLE>Mein Dokument</TITLE> </HEA D> <BODY> <H1>Mein Titel</H1> Das ist mein Text, ich verweise hier auf das <A HREF="http://www.ict.tuwien.ac.at/">Institut für Computertechnik</A> an der TU Wien. Sie können mich gerne per <A HREF="mailto:ecombuch@ict.tuwien.ac.at">Email</A> kontaktieren. </BODY> </HTML> Bild 1.1: Ein einfaches HTML-Dokument Bild 1.2: Typische Browser-Darstellung des HTML-Beipiels aus Bild 1.1 2 Standard Generalized Markup Language Karl M. Göschka Seite 8 / 63 WEB v3.2

Für detaillierte Informationen muss an dieser Stelle auf die verfügbare Literatur zu HTML verwiesen werden. 1.2. Uniform Resource Identifier Der Uniform Resource Identifier (URI) bzw. Uniform Resource Locator (URL) dient der eindeutigen Identifikation einer beliebigen Ressource im Web, z. B. das Ziel eines Hyperlinks oder eines Inline-Bildes. Er besteht aus folgenden Teilen: Das Protokoll üblicherweise HTTP oder oft auch HTTPS (die kryptografisch abgesicherte Variante); es gibt aber auch URLs für FTP, Telnet und News, um nur einige weitere zu nennen. Der DNS-Name des Servers, auf dem sich die gewünschte Ressource befindet, und der Port am Server, über den zugegriffen werden soll: Falls der Port nicht explizit angegeben wird, dann gilt der für das jeweilige Protokoll als well known port bekannte Port als Standard, im Fall von HTTP ist das 80, bei HTTPS 443. Ebenfalls hier können auch Benutzername und Passwort angegeben werden, z. B. für FTP-Zugriffe 3. Der Rest der URL hängt vom Protokoll ab. Bei HTTP folgt nun eine Pfadangabe, die relativ zur so genannten Document Root am Web-Server zu lesen ist. Es kann auch ein Punkt im Dokument mittels fragment identifier gezielt angesprungen werden. Besonders wichtig ist auch die Möglichkeit der Übergabe von Parametern in der URL (als so genannter query string ). Der Beginn des Query String wird durch ein Fragezeichen eingeleitet. Ein vollständiger URL: http://some.where.ac.at:8888/path/resource.cgi?query_string Außerdem unterscheidet man noch zwischen relativen und absoluten URLs. Bei den relativen URLs werden die Teile, die vorne weggelassen wurden, einfach aus der URL des aktuellen Dokumentes ergänzt. Dokumentsammlungen, die untereinander nur relativ verlinkt sind, können auf diese Weise als Gesamtheit einfach woanders hin geschoben werden, wobei alle Links ihre Gültigkeit behalten. 3 Davon wird aber abgeraten, da in diesem Fall das Passwort im Klartext in der URL übertragen wird. Dies ist allenfalls für anonymen FTP-Zugriff akzeptabel. Karl M. Göschka Seite 9 / 63 WEB v3.2

1.3. Das Hypertext Transfer Protocol Das Hypertext Transfer Protocol (HTTP) ist ein verbindungsorientiertes (es baut auf TCP auf), aber zustandsloses Protokoll. Es bildet die Basis für die Übertragung von Dokumenten im WWW, es wird also für die Kommunikation zwischen einem Web-Server und einem Web- Browser verwendet. Der Browser hat dabei die Funktion eines Clients, der nur genau eine Anfrage stellt und darauf vom Server genau eine Antwort in Form einer HTML-Datei erhält 4. Der Ablauf einer HTTP-Sitzung sieht also wie folgt aus: 1. Öffnen der TCP-Verbindung, 2. HTTP-Request vom Client an den Server, 3. HTTP-Antwort vom Server an den Client, i. Allg. wird dabei ein HTML-Dokument übertragen, 4. Schließen der TCP-Verbindung. Das HTTP unterscheidet verschiedene Methoden, je nach Zweck der Nachricht: Neben der GET-Methode, bei deren Beantwortung ein HTML-Dokument vom Server geholt wird, existiert auch die HEAD-Methode, die nur bestimmte Informationen über dieses Dokument als Antwort erhält. Damit kann der Web-Browser unter anderem überprüfen, ob das Dokument verändert wurde und neu geholt werden muss. Die POST-Methode (und mitunter auch die GET Methode selbst) dient der Übertragung von Daten in die entgegengesetzte Richtung, also vom Client zum Server. Dies wird beispielsweise bei HTML-Formularen angewendet. Es gibt auch die Methoden PUT und DELETE, die bei einigen Servern auch implementiert sind und dem Upload oder Löschen eines HTML-Dokumentes dienen. Normalerweise will man das eher nicht tatsächlich gab es jedoch einige Web-Server-Distributionen, bei denen diese Methoden standardmäßig freigegeben waren, was sofort bei einigen findigen Zeitgenossen zum Hacken dieser Web-Server geführt hat, indem die ursprünglichen Dokumente vom Hacker durch mehr oder weniger lustige andere Dokumente ersetzt wurden. HTTP-Nachrichten bestehen immer aus einem Header und einem Body. Im Header sind bestimmte Informationen über den Client bzw. den Server und auch über die im Body enthaltenen Daten angegeben. Zum Beispiel gibt der Client die HTTP-Versionsnummer und eine Liste der von ihm unterstützten Dateitypen an. Der Body ist vom Header stets durch eine 4 Es gibt auch die Möglichkeit, HTTP-Verbindungen für mehrere Interaktionen aufrecht zu erhalten (Keep-Alive). Viele Server ignorieren aber standardmäßig einen vom Browser mittels HTTP-Request dahingehend geäußerten Wunsch. Karl M. Göschka Seite 10 / 63 WEB v3.2

Leerzeile getrennt. Bild 1.3 zeigt einen einfachen GET-Request vom Browser an den Web- Server, Bild 1.4 zeigt die zugehörige Antwort vom Web-Server. Man erkennt, dass als HTTP- Body das HTML-Dokument zurückgeliefert wird. GET /welcome.html HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.msexcel, application/msword, application/vnd.ms-powerpoint, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt) Host: some.where.ac.at:8888 Connection: Keep-Alive Bild 1.3: HTTP-Request vom Client (Web-Browser) an den Server Im Rahmen des HTTP-Protokolls kann auch eine einfache Authentifizierung durchgeführt werden, das so genannte Basic Authentication Scheme. Es soll hier nur betont werden, dass die Passwortinformation in diesem Fall nur UU 5 -codiert wird, also ohne darunter liegende SSL-Verschlüsselung völlig ungesichert über das Netz geht. Die zugehörigen Einstellungen, wer wo zugreifen darf, müssen am Web-Server konfiguriert werden. HTTP/1.1 200 OK Date: Sat, 06 May 2000 22:16:41 GMT Server: Apache/1.3.9 Ben-SSL/1.37 (Unix) mod_perl/1.21 Connection: close Content-Type: text/html <HTML> <HEAD> <TITLE>Mein Dokument</TITLE> </HEAD> <BODY> <H1>Mein Titel</H1> Das ist mein Text, ich verweise hier auf das <A HREF="http://www.ict.tuwien.ac.at/">Institut für Computertechnik</A> an der TU Wien. Sie können mich gerne per <A HREF="mailto:ecombuch@ict.tuwien.ac.at">Email</A> kontaktieren. </BODY> </HTML> Bild 1.4: HTTP-Response vom Web-Server an den Browser 1.4. Common Gateway Interface Das Common Gateway Interface (CGI) ist eine standardisierte Schnittstelle zwischen Web- Server (oft auch als Web-Listener oder HTTP-Daemon bezeichnet) und einem Server-seitigen 5 Ein einfaches Codierverfahren, aber keine Verschlüsselung. Jeder kann die Rückumwandlung ohne irgendwelche weitere Kenntnis durchführen. Karl M. Göschka Seite 11 / 63 WEB v3.2

Programm. Dies kann wiederum ein einfaches Shell-Skript oder Perl-Skript sein, ein ausführbares C-Programm oder aber eine integrierte Anbindung an einen Applikationsserver oder eine Datenbank. Viele Anbindungen sind zwar heute nicht mehr nach dem ursprünglichen CGI-Prinzip gebaut, folgen ihm aber noch der Nomenklatur nach, was eine breite Basis für solche Anwendungen schafft. Das Grundprinzip ist folgendes: Anhand des Pfades, der Extension, oder einer anderen Information im URL (dies muss vorher beim Web-Server konfiguriert werden) erkennt der Web-Server, dass ein eingehender Request nicht durch die Lieferung eines Dokumentes, sondern durch die Ausführung eines Programms beantwortet werden soll. In diesem Fall wird das entsprechende Programm als Prozess gestartet, und die übergebenen Daten (aus dem URL und dem HTTP-Body) werden auf eine von drei Arten übergeben: als Command-Line- Parameter, über den Standard-Input oder über genau definierte Umgebungsvariablen. Das Programm führt nun seine Aufgaben durch und liefert zuletzt seine Ergebnisse auf eine von zwei Arten an den Web-Server zurück: Als HTML-Dokument mit MIME-Type-Angabe oder als fertige HTTP-Antwort. Im ersten Fall muss der Web-Server noch den HTTP-Header ergänzen, in beiden Fällen erfolgt zuletzt die HTTP-Antwort an den Client, der serverseitige Prozess terminiert, nachdem er seine Daten (über den Standard-Output) an den Web-Server geliefert hat. Karl M. Göschka Seite 12 / 63 WEB v3.2

2. Heterogene Clients Clients moderner Enterprise Software Architekturen können auf unterschiedlichste Art unterschieden und kategorisiert werden [4]: Stationary vs. Mobile Clients: Mobile Clients müssen (auch wenn die Protokolle und Zugriffsmöglichkeiten gekapselt sind) unterschiedliche Bandbreiten, Latencies, und Kommunikationskosten berücksichtigen können, und auch auf Ressourcenverbrauch (Akku- Lebensdauer) optimiert werden. Application-specific vs. generic Clients: Während erstere für eine bestimmte Anwendung optimiert werden können, erfordern zweitere eine Beschreibungssprache und Datenstrukturen, unterstützen dann aber eine ganze Klasse von Anwendungen auf eine dem User vertraute Art und Weise. Device-specific vs. Multidevice Clients: Völlige Unabhängigkeit vom Device ist kaum zu erreichen (außer die Abstraktionsebene wird deutlich erhöht), da stets Annahmen hinsichtlich der Ressourcen getroffen werden müssen. Ein vielversprechender Ansatz sind hier die Multidevice Clients, bei denen eine UI Komponente auf verschiedene Zielplattformen abgebildet werden kann (z.b. Windows vs Mac vs Browser vs PocketPC). Widget-based vs. Interaction-based Clients: Stand der Technik sind widget-based Clients, bei denen die Struktur und die Elemente des User Interface definiert sind. Obwohl diese dann noch auf verschiedene konkrete UIs abgebildet werden können, ist die erzielbare Flexibilität doch eingeschränkt dasselbe Widget in ein GUI und in einen Text-to-Speech Synthesizer abzubilden wird nicht immer möglich sein. Bei Interaction-based Clients hingegen, wird eine höhere Abstraktion benutzt und nur die Interaktionen zwischen Benutzer und System beschrieben. Dies auf Kosten eines weiteren Werkzeuges, welches diese Interaktionen dann auf eine konkrete Plattform abbilden muss. Messaging vs. Interactive vs. Rich Call Clients: Hier werden die Clients nach ihrem Kommunikationsverhalten mit dem Server kategorisiert. Messaging Clients (z.b. Email Client) sind nicht zeitkritisch. Interactive Clients dienen dem unmittelbaren Datenaustausch (z.b. Web Browser) inklusive Streaming. Rich Call Clients sind für Delay-sensitive Kommunikation vorgesehen (VoIP Telephonie, Chat, Video Konferenz). Native GUI Clients vs. Web Clients: Auf diese Unterscheidung wird in weiterer Folge noch genauer eingegangen. Karl M. Göschka Seite 13 / 63 WEB v3.2

In diesem Abschnitt wird der Fokus v.a. auf den Web Browser gelegt, wobei ein kurzer Vergleich mit Native GUI Clients angestellt wird. Abschließend werden Mobile Clients vorgestellt um den Unterschied aber auch die aktuellen Integrationsbemühungen mit stationären Web Technologien aufzuzeigen. Als Web-Client kann man jene Clients bezeichnen, die sich des Web-Browsers als Laufzeitumgebung bedienen: Zunächst ist hier HTML gemeint später erweitert um Rich Internet Technologien wie z.b. JavaScript, Java Applets, Ajax, oder Flash. Gliedert man die verschiedenen Varianten in das Gesamt-Konzept der N-Schichten-Architekturen ein, so erkennt man folgenden Unterschied: Java-Applets werden vom Web-Server nur geladen, benötigen diesen danach aber nicht mehr, weil sie i. Allg. nach dem Download eine eigenständige Verbindung zur Geschäftslogik aufbauen. Diese Variante verhält sich technisch also eher wie eine klassische Client-Applikation, wobei einige Einschränkungen zu beachten sind, die in weiterer Folge noch aufgezählt werden. HTML hingegen benötigt den Web-Server während der gesamten Dauer der Session, wobei hinter der HTTP-Protokoll-Maschine (HTTP Daemon) neben statischem Inhalt in Form von HTML-, XHTML- oder XML-Dokumenten bzw. Vorlagen vor allem die Backend- Anbindung relevant ist. In diesem Bereich können z. B. Servlets oder JSP verwendet werden, aber auch Perl, C, PHP oder viele andere. Damit ist aus Sicht der Middleware die gesamte Konstellation bestehend aus Web-Browser, HTTP-Anbindung und Web-Server samt Glue Logic dem Presentation Tier zuzuordnen. Bild 2.1 erläutert diesen Zusammenhang. In den folgenden Abschnitten wird daher zunächst der Web-Client und dessen Probleme genauer betrachtet, danach die Lösungsansätze auf Server-seite und in einem späteren Abschnitt die Erweiterungen, um den Client noch flexibler zu machen. Karl M. Göschka Seite 14 / 63 WEB v3.2

Java Applet Web Browser HTML Client HTTP Windows Application Java Application HTTP Daemon Web Server static content and templates: HTML XHTML XML Presentation Tier Distribution Protocol: IIOP, RMI, or proprietary (e.g. DCE) Glue Logic Servlet JSP Business Tier Session Session Session Session Business Logic Distributed Component Based Infrastructure Transaction Manager Persistence Manager Libraries Wrapper/Connector Data Tier Database Access Protocol: JDBC, SQLJ, or proprietary (e.g. SQL*Net) Legacy System proprietary legacy protocol Database Server proprietary legacy protocol Bild 2.1: Zuordnung verschiedener Clients in der N-Schichten-Architektur 2.1. Web Client Aus Sicht der Enterprise Software Architecture ist also die gesamte Konstellation bestehend aus Web-Browser, HTTP-Anbindung und Web-Server samt Glue Logic dem Presentation Tier zuzuordnen. Daraus (und aus den konkret eingesetzten Technologien) ergeben sich gewisse Probleme und Einschränkungen, deren Lösung die Basis für das Verständnis v.a. der Server-seitigen Web Technologien bildet. Daher werden in diesem Abschnitt zunächst die Probleme von HTML mit und ohne Skript-gesteuertem Event-Handling erwähnt, danach werden einige Probleme mit dem HTTP als Verbindung zwischen Browser und Web-Server aufgezeigt. Im nächsten Abschnitt wird dann gezeigt, wie die Glue Logic (CGI, Servlets, JSP) bei der Lösung dieser Probleme unterstützt. 2.1.1. User Interface: HTML und JavaScript Die Beschränkung auf reines HTML betrifft dabei nicht nur die grafische Darstellung, sondern insbesondere auch die Möglichkeiten der Interaktion: Die einzigen funktionalen Elemente sind der Link (als Text oder Bild), das Formular (bzw. die weitgehend obsolete Karl M. Göschka Seite 15 / 63 WEB v3.2

ISINDEX Query) oder eine Imagemap. Jede dieser Interaktionen resultiert in einer HTTP- Verbindung wobei die nächste Seite als gesamtes neu geladen werden muss, weshalb jegliche Funktionalität Server-seitig (d. h. am Application-Server) angesiedelt sein muss. Das liegt vor allem daran, dass HTML nie als User Interface für verteilte Applikationen konzipiert war, aber dennoch heute dafür eingesetzt wird. An weiteren nachteiligen Eigenschaften sind der Mangel an Erweiterbarkeit zu nennen sowie das Fehlen von Event-Handling, insbesonders auch beim Formular (z.b. um eine Eingabe sofort zu prüfen oder abhängig von der Eingabe unterschiedliche weitere Optionen zur Verfügung zu stellen). Derartiges Event-Handling ist auf die oben beschriebenen Interaktionen (Link, Form, Imagemap) beschränkt und muss durch ein vollständiges Neuladen der Seite simuliert werden. Von all den verschiedenen Ansätzen, den Browser flexibler und interaktiver zu gestalten (siehe Abschnitt 4 zu den Rich Internet Technologien), ist JavaScript eine Möglichkeit, vor allem das fehlende Event-Handling zu ergänzen und Kontext-spezifische Aktionen wie z.b. Eingabe-Überprüfungen durchzuführen. Obwohl sich JavaScript als die Client-seitige Skript- Sprache am Web etabliert hat, gibt es manchmal immer noch Kompatibilitätsprobleme mit verschiedenen Versionen, Dialekten und Browsertypen. Jedenfalls sollte eine gute Web- Applikation auch ohne JavaScript zumindest noch funktionieren, da viele Internet-Benutzer diese Funktion auch schlicht und einfach am Browser deaktiviert haben, um potenzielle Security- bzw. Privacy-Probleme zu vermeiden 6. 2.1.2. Protokoll: Probleme mit HTTP Das Hypertext Transfer Protocol (HTTP) wirft ein weiteres Problem auf: In einer Standard- Client/Server-Applikation enthalten beide Seiten ihren jeweiligen Zustand (z. B. den Zustand der offenen Transaktion auf der Seite der Datenbank oder den Zustand des GUI auf der Seite des Benutzers), wobei ein zustandsorientiertes Protokoll die beiden Seiten verbindet. Da das Web andererseits niemals als Medium für Client/Server-Applikationen entworfen wurde, ist das HTTP zustandslos, und der Browser selbst kann mit HTML allein auch keinen GUI- 6 Wie bereits erwähnt: Im CERT Advisory CA-2000-02 wird empfohlen, aus Sicherheitsgründen auf die Verwendung jeglicher Skript-Sprachen zu verzichten. Karl M. Göschka Seite 16 / 63 WEB v3.2

Zustand speichern 7. Es muss betont werden, dass diese Zustandslosigkeit die Skalierbarkeit des reinen Web-Servers verbessert und daher aus damaliger Sicht auf das ursprünglich gedachte Einsatzgebiet der Web Technologien eine richtige Entscheidung darstellt. Um diesen aus heutiger Sicht Mangel zu überwinden, gibt es zwei Möglichkeiten: Long URL encoding speichert den gesamten Zustand der Sitzung und des GUI in der URL (oder in einem Cookie 8 ). Diese meist codierte Zustandsinformation wird dann bei jeder HTTP- Interaktion zwischen Browser und Server hin- und hergereicht. Für komplexere Anwendungen und insbesonders wenn man persistente Zustandsdaten benötigt ist das aber nicht ideal, in diesem Fall speichert man den Zustand am Server am besten in einer Datenbank und reicht nur noch einen kurzen Identifikator zwischen Browser und Server hin und her (wieder entweder in der URL oder als Cookie). Man nennt diese zweite Methode Short URL encoding. Die zweite Methode zeigt zwar die schlechtere Server-Skalierung, kann aber auch mit Frames benutzt werden. Die erste Methode ist bei Frames problematisch, kann aber dafür mit geringerem Implementierungsaufwand auch ohne Datenbank auf der Server-Seite verwendet werden. Wenn die Zustandsinformation (long oder short) in der URL übergeben wird, bedeutet das weiters, dass in jede HTML-Seite, die vom Server an den Client geschickt wird, in alle Links und alle Formulare diese Information hineincodiert werden muss. Und es bedeutet für den Server, dass er die vollständige Zustandsinformation aller gleichzeitig offenen Sitzungen speichern muss. Egal wie man das Problem der Zustandslosigkeit überwindet einen Nachteil der Verwendung von reinem HTML (und damit HTTP als Protokoll zwischen Browser und Server) muss man dabei in Kauf nehmen: Man kann nie sicher wissen, ob der Benutzer den Geschäftsfall abgebrochen hat (z. B. durch Beendigung des Browsers) oder ob er einfach länger braucht, bevor die nächste Interaktion erfolgt. Man weiß also nie, ob ein Geschäftsfall gewollt oder ungewollt offen ist. Zusätzlich muss man bei Verwendung von reinem HTML Vorkehrungen treffen, um die Übernahme von offenen Verbindungen durch Dritte zu verhindern. Dritte könnten sonst bei 7 Der Browser selbst ist natürlich bezüglich GUI sehr wohl zustandsbehaftet, das erkennt man sofort, wenn man den Back Button benutzt. Der Zustand ist aber für Protokoll und Server unzugänglich. 8 Cookies haben den Nachteil, dass sie vom Benutzer deaktiviert werden können und auch Privacy- Probleme mit sich bringen. Karl M. Göschka Seite 17 / 63 WEB v3.2

Kenntnis der URL die Transaktion fortführen. Dieses Security-Problem kann man durch die Verwendung von SSL und codierten URLs weitgehend lösen. Die Einschränkung von Transaktionen auf den Host, von dem sie gestartet wurden, ist wegen der weit verbreiteten Verwendung von Firewalls mit PAT 9 nicht sinnvoll. Man kann die Sicherheit auch durch gleichzeitige zusätzliche Verwendung von Cookies erhöhen, das System sollte aber auch ohne Cookies noch funktionieren. In den meisten praktischen Fällen kann man sich auch mit einem geeigneten Timeout- Mechanismus behelfen, wobei der begonnene Geschäftsfall in diesem Fall aufgerollt wird. Man kann davon ausgehen, dass ein Benutzer, der mitten in einem Geschäftsfall abbricht, diesen ohnehin nicht durchführen wollte. Umgekehrt kann natürlich auch ein Netzwerkausfall daran schuld sein; in diesem Fall verliert der Benutzer leider den offenen Geschäftsfall. Da typische Internet-Geschäftsfälle aber eher kurz sind bzw. kurz sein sollen, kann dieser Nachteil oft durch organisatorische Begleitmaßnahmen überwunden werden, z. B. durch den Versand einer E-Mail als Bestätigung. Dies bedeutet, dass man seriöserweise klassische Transaktionssicherheit nur von der Datenbank bis zur Middleware garantieren kann. Um dennoch mit HTML-Clients auf transaktionsorientierten Systemen arbeiten zu können, gibt es einen einfachen und sicheren Ansatz: Die Transaktion wird am Application-Server erst dann begonnen, wenn der Geschäftsfall am Client abgeschlossen ist und der Benutzer diesen abschließend bestätigt (single shot transaction). Es wird also am Client gar keine Transaktion geöffnet, sondern die buchungsrelevanten Daten werden in der Zustandsinformation der Session gesammelt. Am Schluss wird dann versucht, im Zuge einer einzigen HTTP-Sitzung die Transaktion am Application-Server zu öffnen und mit den bis dato gesammelten Buchungsdaten durchzuführen. Falls sich in der Zwischenzeit an den zugrunde liegenden Daten etwas geändert hat, muss diese Transaktion natürlich fehlschlagen und der Kunde mit einer entsprechenden Fehlermeldung informiert werden. Dies entspricht im Verhalten einem (sehr) optimistischen Sperrverfahren. Zusammengefasst bedeutet das also keine Bedrohung der Transaktionssicherheit insgesamt, sondern lediglich in manchen Fällen eine etwas andere Handhabung, als das mit zustandsorientierten Protokollen möglich wäre. 9 Port Address Translation Das bedeutet, dass ausgehende Verbindungen über unterschiedliche Ports, manchmal auch über verschiedene IP-Adressen in die Außenwelt geführt werden. Karl M. Göschka Seite 18 / 63 WEB v3.2

2.2. Web-Server-Anbindung Im vorigen Abschnitt wurden die Probleme von HTML (v.a. ohne Script Unterstützung) und HTTP erläutert. In diesem Abschnitt wird nun gezeigt, wie die Glue Logic (CGI, Servlets, JSP) den Entwickler von Web-Anwendungen bei der Lösung dieser Probleme unterstützt. 2.2.1. Verbindung von Web-Server und Middleware: CGI und API Die standardisierte Schnittstelle zwischen einem Web-Server und einer Backend-Applikation ist das Common Gateway Interface, kurz CGI. Für eine Folge von HTTP-Verbindungen ist diese Schnittstelle aber ziemlich ineffektiv, weil jedes Mal ein neuer Prozess erzeugt wird, der seinerseits die Verbindung zur Middleware oder zur Datenbank aufbaut, dann seinen Algorithmus abarbeitet, abschließend alle Verbindungen abbaut und beendet wird. Es gibt grundsätzlich zwei Ansätze, um dieses Problem zu überwinden: 1. Man kann zunächst dafür sorgen, dass mehrere Prozesse auf der Server-Seite aktiv und mit der Middleware bzw. Datenbank verbunden bleiben. Ein Dispatcher ordnet dann die eingehenden HTTP-Requests den aktiven Prozessen zu wie z.b. bei FastCGI 10. 2. Man kann die Anwendungssoftware direkt mit dem Web-Server verbinden bzw. auf den Web-Server (und dessen Informationen vom letzten HTTP Request) zugreifen lassen. Dies kann über proprietäre Schnittstellen passieren (sogenannte Web Server APIs) oder über Standards wie z.b. das Java http Servlet API. Das Verwalten aktiver Prozesse (Punkt 1) ist bei diesen Ansätzen zumeist schon integriert. Arbeitet man mit CGI allein, so muss man folgende Aufgaben als Applikationsentwickler selbst lösen: Lesen der Daten aus Umgebungs-Variablen, Standard-Input, und Command-Line- Parametern. Dekodieren oder Typkonversion der Parameter in geeignete Datenstrukturen. Analog Parsen der benötigten HTTP Header. Session-Handling durch explizites Cookie-Management oder Generierung/Modifikation aller Links durch URL Encoding Erzeugen des Output als Text (entweder nur die HTML Seite oder gleich mit den vollständigen HTTP Headern), der über Standard-Output ausgegeben wird. 10 http://www.fastcgi.com/ Karl M. Göschka Seite 19 / 63 WEB v3.2

Diese Arbeiten sind natürlich hochgradig repetitiv und dennoch (oder gerade deswegen) sehr anfällig für lästige Fehler. Aus diesem Grund liegt es nahe, diese Aufgaben vom Application Server erledigen zu lassen. Diese Aufgaben können grundsätzlich auf zwei verschiedene Arten angegangen werden: Script-orientiert oder Seiten-orientiert. Diese beiden Arten werden in Folge anhand Ihrer prominentesten Vertreter genauer erläutert. 2.2.2. Script-basierte Web-Anbindung Bei der Script-basierten Web-Anbindung stellt die Laufzeitumgebung die Request Parameter sowie Datenstrukturen für das Session-Management zur Verfügung. Der Entwickler übernimmt diese Daten im Programm, ruft ggf. die Geschäftslogik oder Datenbank auf, und erzeugt schließlich die resultierende, neue HTML-Seite durch Ausgabe-Anweisungen von Strings. Wir wollen uns hier Java Servlets exemplarisch ansehen, alternative Techniken sind Scriptsprachen wie Perl 11, Python 12, oder Ruby 13. Java Servlets sind Module zur Erweiterung von Web-Servern (bzw. Application-Servern, wie die Verbindung aus Web-Server und Container für die Glue Logic genannt wird) die entsprechende Schnittstellen (Java Http Servlet API) bereithalten. Sie besitzen keine Benutzerschnittstelle und dienen vom Grundgedanken am ehesten als Ersatz für CGI-Skripts, wobei das Servlet im Unterschied zum CGI Script innerhalb des Web Servers im sogenannten Java Web Container ausgeführt wird. Beim Laden wird das Servlet initialisiert, dabei werden die Konfigurationsdaten geladen und eventuelle Hilfs-Threads gestartet. Ein Servlet kann für mehrere aufeinanderfolgende Requests (Session) verwendet werden. Da Servlets multithreaded sein können, darf nicht auf die Synchronisation vergessen werden. Entfernt wird das Servlet nur durch den Garbage Collector der Umgebung, bis dahin arbeitet es auf dem Request-Response-Paradigma beruhende Service-Anfragen ab. Bild 2.2 zeigt ein Beispiel. Damit hat Sun Microsystems (später von Oracle übernommen) eine Möglichkeit geschaffen, Java-Programme auf dem Web-Server ausführen zu können. Servlets werden am ehesten als Glue Logic für Web-Anwendungen eingesetzt, um sie als Gateway zu verteilten, objektorientierten Systemen (oder objektrelationalen Datenbanken) einzusetzen, insbesondere zu Komponenten-Systemen basierend auf Enterprise Java Beans (EJBs). Bild 2.3 zeigt den 11 http://www.perl.org/ 12 http://www.python.org/ 13 http://www.ruby-lang.org/en/ Karl M. Göschka Seite 20 / 63 WEB v3.2