Web Presentation Tier - Distributed Systems Group
Werbung
Web Engineering Web Presentation Tier Studienbrief WEB Version 3.2 (Juli 2011) Karl M. Göschka Web Presentation Tier 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. 2.1. Heterogene Clients.......................................................................................................... 13 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 Web Presentation Tier 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. 4.1. 4.1.1. Rich Internet Technologien (RIT) .................................................................................. 47 Java-Applets............................................................................................................... 48 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 Web Presentation Tier 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 WebClient 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 Web Presentation Tier 0.5. [1] Literatur Heineman, G.T.; Councill, W.T.: „Component-Based Software Engineering“, AddisonWesley, 2001. [2] Bass, L.; Clements, P.; Kazman, R.: “Software Architecture in Practice”, AddisonWesley, 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 Web Presentation Tier 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 Web Presentation Tier 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 EndTag. 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 HTMLElement, 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 Web Presentation Tier 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</TITL E> </HEA D> <BODY> <H1>Mein Titel </H1> Das ist mei n Text, ich ve rwe ise hier auf das <A HREF="http://www.ict.tuwien.ac.a t/">Institut f&uuml;r Computertechnik</A> an der TU Wien . Sie k&o uml;nne n mich gerne per <A HREF="ma ilto :[email protected]">E ma il</A> kon taktieren. </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 Web Presentation Tier 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 Web Presentation Tier 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 WebBrowser 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 Web Presentation Tier Leerzeile getrennt. Bild 1.3 zeigt einen einfachen GET-Request vom Browser an den WebServer, Bild 1.4 zeigt die zugehörige Antwort vom Web-Server. Man erkennt, dass als HTTPBody 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&uuml;r Computertechnik</A> an der TU Wien. Sie k&ouml;nnen mich gerne per <A HREF="mailto:[email protected]">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 WebServer (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 Web Presentation Tier 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-LineParameter, ü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 Web Presentation Tier 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 (AkkuLebensdauer) 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 Web Presentation Tier 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 BackendAnbindung 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 Web Presentation Tier Java Applet Web Browser HTML Client HTTP Windows Application Java Application HTTP Daemon Web Server Distribution Protocol: IIOP, RMI, or proprietary (e.g. DCE) Presentation Tier Business Tier Session Business Logic Session Session Distributed Component Based Infrastructure Persistence Manager Data Tier Libraries Glue Logic Servlet static content and templates: HTML XHTML XML JSP Session Transaction Manager Wrapper/Connector proprietary legacy protocol Database Access Protocol: JDBC, SQLJ, or proprietary (e.g. SQL*Net) Legacy System 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 Web Presentation Tier ISINDEX Query) oder eine Imagemap. Jede dieser Interaktionen resultiert in einer HTTPVerbindung 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 SkriptSprache am Web etabliert hat, gibt es manchmal immer noch Kompatibilitätsprobleme mit verschiedenen Versionen, Dialekten und Browsertypen. Jedenfalls sollte eine gute WebApplikation 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 StandardClient/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 Web Presentation Tier 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 HTTPInteraktion 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 Web Presentation Tier 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 TimeoutMechanismus 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 Web Presentation Tier 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-LineParametern. 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 Web Presentation Tier 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 Web Presentation Tier Aufbau dieser Architektur. Die Technik kann mit so ziemlich allen gängigen Web-Servern realisiert werden. Die Servlets benutzen dazu ein spezielles API, das es ermöglicht, Programme auf der Seite des Servers zu starten. Diesen Programmen können aus einer HTML-Seite Parameter übergeben werden, die dann in weiterer Folge verarbeitet werden. Auch die Information aus den Http-Protokoll-Headern steht im Servlet zur Verfügung. Als Ausgabe liefern Servlets wieder HTML-Seiten, die an den Client zurückgegeben werden. Auch die Manipulation der Http-Protokoll-Header des Response ist möglich. Dabei erlaubt – entsprechend dem HTTP – Java unter anderem die folgenden Methoden, um Parameter an das Servlet weiterzugeben: GET: Bei dieser Methode werden alle Daten, die in einem HTML-Formular angeführt sind, direkt in der URL codiert bzw. im HTTP Nachrichten-Header übergeben und sind daher für den Benutzer unmittelbar sichtbar. POST: Bei dieser Methode sind die Parameter nicht direkt in der URL codiert sondern werden als HTTP Nachrichteninhalt übergeben. Die Parameter werden aber in beiden Fällen unverschlüsselt übertragen. public class SimpleServlet extends HttpServlet { // Handle the HTTP GET method by building a simple web page. public void doGet (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { PrintWriter out; String title = "Simple Servlet Output"; // set content type and other response header fields response.setContentType("text/html"); // then write the data of the response out = response.getWriter(); out.println("<HTML><HEAD><TITLE>” + title ); out.println("</TITLE></HEAD><BODY>"); out.println("<H1>" + title + "</H1>"); out.println("<P>This is output from SimpleServlet."); out.println("</BODY></HTML>"); out.close(); } } Bild 2.2: Java Servlet Die Vorteile von Servlets sind: Effizienz: Anstelle wie bei CGI jedes Mal einen neuen Prozess zu starten, werden die Anfragen bei Servlets von einem Thread beantwortet, der von dem einzigen Servlet- Karl M. Göschka Seite 21 / 63 WEB v3.2 Web Presentation Tier Prozess gestartet wird, der dauerhaft läuft. Damit kann auch z. B. eine dauerhafte Verbindung zu Datenbanken mittels JDBC aufrecht erhalten werden. Komfort: Eine Reihe an vordefinierten Funktionen gestattet die einfache Handhabung der HTTP-Protokoll-Header sowie der HTML-Daten. Weitere Funktionen erleichtern die Handhabung von Cookies und Sessions. Portabilität: Aufgrund von Java gegeben, und von den meisten Application-Servern unterstützt. Sicherheit: Während „klassische“ CGI-Scripts einige Sicherheitslücken aufweisen, bietet Java ein Sicherheitsmodell auf. Server Clients HT TP Servlet Server HTTP T HT P ed nt ie r t-o ec l bj O co to o Pr O bj ec t-o Pr ot rie oc nt ol ed Bild 2.3: Mit dieser Architektur kann mit Servlets ein Gateway zu anderen objektorientierten Anwendungen geschaffen werden 2.2.3. Seiten-basierte Web-Anbindung Hat man relativ statische Seiten, also Schablonen (Templates), in denen nur wenig dynamischer Inhalt vorkommt, ist die Script-basierte Variante mühsam und unübersichtlich. In diesem Fall ist es günstiger, die HTML Schablone selbst zu verwenden und die wenigen dynamischen Elemente dann als Code-Snippets einzubetten. Genau das ist die Idee der Seiten-basierten Ansätze, deren Vorläufer als „Server-Side-Include“ (SSI 14) bezeichnet wird. Dabei wird eine normale Web-Seite mit zusätzlichen Tags angereichert. Diese werden vor der 14 http://de.selfhtml.org/servercgi/server/ssi.htm Karl M. Göschka Seite 22 / 63 WEB v3.2 Web Presentation Tier Zustellung an den Client vom SSI-Prozessor interpretiert. Meist führt das zum Aufruf von Scripts, deren Output dann wiederum anstelle des SSI-Tags in die HTML Seite inkludiert wird. Wir werden uns hier Java Server Pages (JSP) als Beispiel ansehen, alternative Techniken sind ColdFusion 15, PHP 16, und ASP.NET 17. Bei Java Server Pages werden XML-artige Tags und so genannte „Scriptlets“ für die Implementierung der Logik verwendet und in eine HTML-Seite eingebettet, welche dann als JSP Seite bezeichnet wird. Dabei ist ein grundsätzlicher Dualismus zu erkennen: Während Servlets Programme sind und HTML mittels println Statements erzeugen, sind JSPs HTML-Seiten, in die Programmcode eingebettet ist. Wenig überraschend wird daher beim ersten Aufruf (und nach Änderungen) im Application Server die JSP Seite in ein Servlet compiliert, indem alle statischen HTML-Teile in println Anweisungen „verpackt“ werden, während die dazwischen liegenden Deklarationen und Code-Stücke zu einem ganzen Servlet zusammengebaut werden. Daher ist es zum Verständnis von JSPs manchmal hilfreich, sich das später entstehende Servlet vorzustellen. Bild 2.4 zeigt ein Beispiel. <HTML> <HEAD><TITLE> Calendar: A JSP APPLICATION </TITLE></HEAD> <BODY BGCOLOR="white"> <%@ page language="java" import="cal.*" %> <jsp: jsp:useBean id="table" scope="session" class="cal. class="cal.TableBean TableBean"" /> <% table.processRequest table. processRequest(request); (request); if (table.getProcessError (table. getProcessError() () == false) { %> <!-<!-- html table goes here ---> >... Bild 2.4: Beispiel für Java Server Pages Generell haben Servlets Vorteile bei hochdynamischen Seiten, während JSPs angenehmer sind, wenn die Masse der Seite statisch ist, weil umfangreicher Programmcode in den JSPSeiten unübersichtlich wird und dadurch fehleranfällig und schlecht wartbar ist. Die Übersichtlichkeit kann weiter verbessert werden, wenn man den Code in Helper Klassen auslagert – dann können diese Helper völlig ohne Scriplets durch bestimmte JSP-Tags aufgerufen werden, wodurch die JSP Seite Code-frei wird und sich dem Nicht-Programmierer 15 http://www.adobe.com/products/coldfusion/ 16 http://php.net/ 17 http://www.asp.net/ Karl M. Göschka Seite 23 / 63 WEB v3.2 Web Presentation Tier (z.B. dem Web Designer) viel besser erschließt 18. Dadurch kann letztendlich „Separation of Concern“ zwischen Darstellung und Geschäftslogik erzielt werden. Insgesamt wird man feststellen, dass die beiden einander eher ergänzen als ausschließen: Während die JSP Seiten gut geeignet sind, die Darstellung der Seite zu übernehmen, eignen sich Servlets gut dazu, den HTTP request entgegenzunehmen. Wir werden diese „Arbeitsaufteilung“ in Abschnitt 3 beim Model View Controller Pattern noch deutlicher erkennen. 2.3. Native GUI Clients Clients basierend auf Native GUIs werden üblicherweise mithilfe von GUI Frameworks erstellt. Dazu gehören die Java Foundation Classes (JFC), heute unter der Bezeichnung Java SE Desktop 19 eine Sammlung mehrer Technologien inklusive Swing, die Microsoft Foundation Classes (MFC) 20, Qt 21, GIMP-Toolkit (GTK+) 22 oder früher Motif 23. Diese Frameworks unterstützen die Erstellung von komplexen UIs aus vordefinierten und erweiterbaren „Widgets“ wie die Komponenten graphischer Oberflächen genannt werden. Vorteile von Native GUIs liegen in der Performance und in der tieferen (und mitunter spezifischen und daher optimierten) Integration mit der Anwendung. Nachteile sind der größere Ressourcenbedarf am Client, größerer Wartungsaufwand, und geringere Flexibilität und insbesonders die Schwierigkeit das UI während der Laufzeit zu verändern (da es ja compiliert ist und keine deskriptive Beschreibung vorliegt). Eine Verbesserung hinsichtlich Wartbarkeit stellen dabei die plattformneutralen Sprachen C# und Java dar, wir wollen uns hier exemplarisch in Java vertiefen. 18 Wenn man exzessiven Einsatz der Control Flow Tags der JSP Standard Tag Library (JSTL) vermeidet, wodurch der Template View wiederum wie eine Programmier-Sprache verwendet würde. 19 http://java.sun.com/javase/technologies/desktop/ 20 http://msdn.microsoft.com/en-us/library/d06h2x6e.aspx 21 http://qt.nokia.com/ 22 http://www.gtk.org/ 23 http://www.motifzone.net/ Karl M. Göschka Seite 24 / 63 WEB v3.2 Web Presentation Tier 2.3.1. Java-Applikation In diesem Fall muss am Client das Java Runtime Environment JRE installiert sein, davon abgesehen bleibt der Vorteil der Plattformunabhängigkeit erhalten. Außerdem wird der Zugriff auf lokale Ressourcen erleichtert. Zwei Varianten sind hier noch vom Grundgedanken her zu unterscheiden: Die erste Variante – Netzwerk-ClassLoader – folgt zum Teil dem Applet-Grundprinzip, ermöglicht aber zusätzlich den Offline-Betrieb. Die zweite Variante hingegen besteht aus einer vollständigen Applikation am Client. Applikation mit Netzwerk-ClassLoader Diese Variante verfolgt ein ähnliches Konzept wie Applets, basiert jedoch auf einer Minimalapplikation, die automatisch Updates vornimmt, indem die Versionen aller Klassen mit jenen auf einem Middleware-Server verglichen werden. Im Fall von neueren Versionen werden diese automatisch heruntergeladen. Diese Version eignet sich sowohl für Online- als auch für Offline-Betrieb. Dadurch erreicht man ein automatisches Update aller Clients ohne großen Aufwand durch einfaches Ersetzen der Klassen auf den Middleware-Servern. Man erhält damit einen Thick-Client mit sehr geringem Administrationsaufwand. Vorteile: Sehr kleine Client-Applikation notwendig, die nur den ClassLoader beinhaltet und daher kaum gewartet werden muss. Außerdem ist es durch das automatische Update nicht notwendig, dass mehrere Softwareversionen parallel laufen müssen. Daraus folgt ein sehr geringer Administrationsaufwand. Im Gegensatz zu Applets ist die Verbindung zu jedem beliebigen Server möglich. Dies führt zu einer erhöhten Ausfallssicherheit im Online-Betrieb. Dadurch, dass die Applikation lokal gestartet wird, wird auch der Offline-Betrieb ermöglicht. Weiter ist es erlaubt, auf lokale Ressourcen zuzugreifen. Dies ist zum Beispiel für das Drucken oder für den Zugriff auf lokale Spezialhardware wichtig. Java erfordert keine Lizenzgebühren für das Java Runtime Environment (JRE). Nachteile: Man muss die Minimalapplikation und das JRE installieren, allerdings ist der Aufwand dafür eher gering. Karl M. Göschka Seite 25 / 63 WEB v3.2 Web Presentation Tier Die Updates der Klassen benötigen Netzwerkbandbreite im laufenden Betrieb. Diese Variante ist also vor allem für solche Clients zu empfehlen, die entweder auf lokale Ressourcen zugreifen müssen oder für die der Offline-Betrieb unbedingt möglich sein muss. Vollständige Applikation auf dem Client Dieser Ansatz kann im Extremfall sogar ohne Middleware-Server auskommen: Die Applikationslogik befindet sich – zumindest teilweise – auf dem Client. Dadurch erhält man einen Thick-Client, ähnlich zur PC-Welt. Vorteile: Es sind weniger Downloads notwendig als bei ClassLoader, das Netzwerk wird weniger belastet. Der Offline-Betrieb ist möglich. Die Performance ist höher, da die Latenzzeiten des Netzwerkes wegfallen. Es werden weniger Ressourcen im Bereich der Server benötigt, die Middleware wird entlastet – oder sogar ganz ersetzt. Nachteile: Es ergibt sich ein erhöhter administrativer Aufwand der Thick-Clients, wobei im Gegensatz zur heterogenen PC-Welt immerhin noch der Vorteil der Plattformunabhängigkeit bestehen bleibt. Zeitweise muss mit mehreren Versionen parallel gearbeitet werden (Versionsmanagement). Der Ressourcenbedarf am Client-Rechner steigt. Auch im Fall der horizontalen Konzentration der kompletten Logik am Client ist grundsätzlich eine logische vertikale Verteilung vorzunehmen, da dies einerseits den Austausch der einzelnen Schichten erleichtert und andererseits bei Einsatz von verteilten Architekturen dann später jederzeit eine horizontale Verteilung ohne großen Aufwand vorgenommen werden kann. 2.3.2. Applikation und Datenbank auf dem Client Diese Variante stellt den „schwersten“ Client dar – sie ist nur möglich mit verteilten Datenbanken oder in Peer to Peer Systemen. Notwendig kann diese Variante werden, wenn der Offline-Betrieb über lange Zeit oder mit hoher Ausfallssicherheit gefordert ist. Auch hier Karl M. Göschka Seite 26 / 63 WEB v3.2 Web Presentation Tier ist es ratsam, eine vertikale Verteilung durchzuführen. Damit eröffnet sich die Möglichkeit des automatischen Wechsels zwischen Offline- und Online-Betrieb. Der administrative Aufwand wird durch die lokale Datenbank allerdings sehr groß – auch mit Fernwartung. Vorteile: hohe Daten- und Ausfallssicherheit durch Netzwerkunabhängigkeit, Online-Redundanz möglich, Zugriff auf lokale Ressourcen möglich, beliebige Netzwerkverbindungen möglich. Nachteile: sehr hoher administrativer Aufwand, die Client-Hardware muss sehr leistungsfähig sein, da sowohl die Applikation als auch die Datenbank am Rechner laufen muss, und zeitweise muss mit mehreren Releases gearbeitet werden. 2.4. Mobile Devices und Sprach-/Datenkonvergenz Der zunehmende Wunsch nach Mobilität hat neben Laptop und Mobiltelefon eine ganz neue Klasse von Geräten hervorgebracht – zuerst den PDA (Personal Digital Assistant) und darauf aufbauend das SmartPhone, welches eine Integration von PDA und Mobiltelephon darstellt. Somit vereint das SmartPhone die Sprach- und Datenkommunikation in einem einzigen mobilen Endgerät. Da alle diese Endgeräte ihre jeweiligen Vor- und Nachteile besitzen, ist nicht abzusehen, dass ein einziges alle anderen wird ersetzen können. Dies führt heute zu einer Vielzahl von Endgeräten, die berücksichtigt werden müssen und neben der Darstellungstechnologie (HTML, Java u. a.) und dem Betriebssystem (Linux, Windows u. a.) zu einer weiteren Betrachtungsschicht, dem Device. Natürlich gibt es reduzierte Portierungen der Betriebssysteme für diese Devices. Aber neben den beschränkten Ressourcen sind i. Allg. auch eine sehr beschränkte Darstellungsfläche (Auflösung) sowie beschränkte oder veränderte Eingabemöglichkeiten (keine Tastatur 24, Stick statt Maus) zu berücksichtigen. Dies führt dazu, dass auch die Applikation selbst auf das jeweilige Device „maßgeschneidert“ werden muss, was letztendlich dazu führt, dass heute für Karl M. Göschka Seite 27 / 63 WEB v3.2 Web Presentation Tier eine einzige Applikation eine Vielzahl an User Interfaces entwickelt und über die Lebenszeit der Applikation gepflegt werden muss. Als Lösungsansatz bietet sich hier zunächst an, „virtuelle Endgeräte“ zu definieren – Betriebssystem und Applikation werden nur einmal an das virtuelle Endgerät angepasst, welches seinerseits auf verschiedenen „physischen Endgeräten“ beheimatet sein kann. Dieser Ansatz kann z. B. mit Software-Agent-Technologie implementiert werden und eignet sich auch für Sprach-/Daten-konvergente Anwendungen. Als Nachteil muss sich das „virtual device“ aber auf die Gemeinsamkeiten (kleinster gemeinsamer Nenner) der bestehenden Endgeräte beschränken. Will man die Merkmale bestimmter physischer Endgeräte (z. B. hohe Auflösung am Laptop) ausnutzen, verliert man den Vorteil des einen einzigen Gerätes sofort wieder. Außerdem ist fraglich, wie sich das virtual device auf einem zukünftigen physischen Gerät behaupten kann. Aus diesen Gründen wird in der Forschung derzeit untersucht, wie man die Interaktion zwischen Mensch und System oder zwischen Menschen via System gänzlich von den physischen Geräten abstrahieren kann. Als Beispiel für „abgespeckte“ Kommunikation soll nun das Mobiltelefon mit WAP (Wireless Application Protocol) und WML (Wireless Markup Language) herhalten. Obwohl als eigenständige Technologie nicht sehr erfolgreich, kann man das Grundprinzip reduzierter Devices sehr gut erkennen. 2.4.1. Clients am Mobiltelefon: WAP und WML Das Wireless Application Protocol WAP ist ein offener Standard, der auf anderen offenen Standards wie XML oder IP basiert. Netzwerkbetreiber mit insgesamt über 100 Mio. Teilnehmern und Mobiltelefonhersteller mit insgesamt über 90 % Marktanteil arbeiten auf der Basis dieses Standards. Damit wird Unabhängigkeit vom Endgerät und von der zugrunde liegenden Protokoll-Technik (GSM, SMS, GPRS usw.) garantiert. Dies führt zu weitgehender Interoperabilität zwischen den verschiedenen Mobiltelefonen und den unterschiedlichen Netzen zum Nutzen des Endkunden. 24 Zwar gibt es „Vitual Keyboards“ als Abhilfe, die mit einiger Übung recht hilfreich sein können, aber gegenüber einer physischen Tastatur dennoch geringere Usability aufweisen. Karl M. Göschka Seite 28 / 63 WEB v3.2 Web Presentation Tier Der Client am Mobiltelefon unterscheidet sich allerdings massiv von den bisher angeführten Clients in Hinblick auf das Endgerät. Das Netzwerk und auch die Erwartungen der Kunden sind in diesem Bereich anders: Im Unterschied zu den bisherigen Varianten, die letztendlich alle auf einem Computer zur Ausführung gebracht werden, wird dieser Client auf einem Mobiltelefon ausgeführt. Das bedeutet beschränkte Ressourcen (CPU, Speicher) und eine sehr kleine Fläche für das GUI 25. Das Netzwerk selbst ist durch Begrenzungen in der Leistung und im Frequenzband sehr restriktiv bezüglich Bandbreite. Außerdem ist die Stabilität der Verbindung nicht immer gegeben. Außerdem bedeutet größerer Bandbreitenbedarf eine kürzere Lebensdauer des Akkus und ist nicht zuletzt deshalb zu vermeiden. Die Kundenerwartungen schließlich orientierten sich zunächst eher am gewohnten Komfort und an der Einfachheit eines Telefons. Dies ist allerdings mit zunehmender Leistungsfähigkeit der Geräte und Netzwerke einem allmählichen Wandel unterworfen, da neue Möglichkeiten die Gewohnheiten der Benutzer verändern und in der Folge auch neue Bedürfnisse schaffen. 2.4.2. WAP-Protokoll-Stack (*) Die zwei wichtigsten Bestandteile der WAP-Spezifikation sind das Wireless Application Environment WAE und der Protokoll-Stack inklusive Wireless Network Interface Definition. WAE besteht aus folgenden Teilen: Wireless Markup Language (WML) Microbrowser, WMLScript Virtual Machine, WMLScript Standard Library, Wireless Telephony Application Interface (WTAI), WAP Content Type Definitions. Bild 2.5 zeigt den Protokoll-Stack inklusive der Assoziation zum Internet-Protokoll-Stack. Der WAP-Protokoll-Stack ist für drahtlose Anwendungen optimiert, läuft aber auf allen Netzwerken, auch auf IP und sogar über SMS. Die einzelnen Protokolle sind: 25 Die Smartphones stellen bezüglich Ressourcen ein Mittelding zwischen klassischem Mobiltelefon und Notebook dar. Eine weitere Mischform stellen die Netbooks dar, auf maximale Mobilität hin optimierte Notebooks. Karl M. Göschka Seite 29 / 63 WEB v3.2 Web Presentation Tier Wireless Datagram Protocol (WDP): Diese Schicht stellt einen verbindungslosen Datagramm-Service zur Verfügung – ähnlich wie UDP. Wird WAP über IP verwendet, wird gleich UDP statt WDP verwendet. Internet Wireless Application Protocol Other Services and Applications Wireless Application Environment (WAE) HTML JavaScript Session Layer (WSP) HTTP Transaction Layer (WTP) TLS - SSL Security Layer (WTLS) Transport Layer (WDP) TCP/IP UDP/IP Bearers: SMS USSD CSD IS-136 CDMA CDPD PDC-P Etc... Bild 2.5: WAP: Protokoll-Stack Wireless Transport Layer Security (WTLS): Diese Schicht funktioniert ähnlich wie SSL und sorgt für Datenintegrität, Abhörsicherheit, Authentifizierung und auch für die Verweigerung bestimmter Services (Zugriffskontrolle). Wireless Transaction Protocol (WTP): Von dieser Schicht wird zuverlässiger Datentransfer zur Verfügung gestellt. Es sind drei Typen von Services definiert: „Undependable one-way call“, „Dependable one-way call“ und „Dependable two-way call response“. Wireless Session Protocol (WSP): Diese Schicht ermöglicht es, verbindungsorientiert zu arbeiten. Es werden Sessions aufgebaut, dann können Daten hin- und hertransportiert werden, und zuletzt wird die Session wieder abgebaut. Im Unterschied zum klassischen HTTP steht also hier ein verbindungsorientiertes Protokoll zur Verfügung, das im Prinzip Transaktionssicherheit bis in das Mobiltelefon ermöglicht. Da im Mobilteil selbst in Form der SIM-Karte bereits eine SmartCard vorhanden ist, bietet es sich geradezu an, diese in die Transaktionssicherheit einzubauen und damit im Mobiltelefon völlige End-zu-End-Sicherheit zu realisieren. Client WAP Gateway WSP/WTP Internet Web Server HTTP DB Bild 2.6: WAP: Architektur und Prozess Karl M. Göschka Seite 30 / 63 WEB v3.2 Web Presentation Tier Bild 2.6 zeigt die Architektur und den Ablauf eines typischen WAP-Requests: 1. Der Benutzer setzt von seinem Mobiltelefon einen Request ab. 2. Der User Agent setzt einen Request an das WAP-Gateway. 3. Das Gateway setzt einen HTTP-Request an den Web-Server ab. 4. Der Web-Server hat nun entweder WML-Decks (siehe Abschnitt 2.4.3) in seinem Dateisystem liegen, die er zurückliefert. Oder es wird über eine Schnittstelle (CGI oder andere) eine Applikation aufgerufen, die z. B. einen Datenbankzugriff ausführt und die WML-Decks dynamisch generiert. 5. Der Web-Server liefert über HTTP dieses WML-Deck (noch im ASCII-Format) an das Gateway zurück. Das Gateway beinhaltet einen WML-Encoder und einen WML-ScriptCompiler und erzeugt die entsprechenden Binärfiles. Außerdem beinhaltet das WAPGateway auch die benötigten Protokoll-Adapter. 6. Das WAP-Gatway liefert nun über WSP/WTP den binär codierten Inhalt über die Luftschnittstelle an das Device. 7. Die Software im Mobilteil interpretiert das Binärformat und bringt es für den Benutzer zur Anzeige (WML) bzw. zur Ausführung (WML Script). Alternativ zu der hier gezeigten Architektur kann das WAP-Gateway auch mit dem WebServer zu einem einzigen WAP-Application-Server verschmelzen, der dann neben dem WMLEncoder, dem Script Encoder und den Protokoll-Adaptern auch die statischen WML-Decks und die Applikationslogik zur Generierung der dynamischen WML-Decks beinhaltet. Auffällig an dieser Struktur ist vor allem, dass die WML-Decks über die Luftschnittstelle in komprimiert codierter Form übertragen werden, wie in Bild 2.7 nochmals dargestellt wird. 2.4.3. Wireless Markup Language WML (*) Wie HTML ist WML eine Markup Language, also eine tag-basierte Sprache. Wie HTML ermöglicht auch WML die Anordnung von Text und Bildern (hier allerdings nur schwarzweiß), die Eingabe von Daten (Text, Selektionslisten) und Unterstützung für die Navigation mittels Hyperlinks. WML ist eine XML-basierte Sprache und mittels einer Document Type Definition DTD vom World Wide Web Consortium W3C definiert. Karl M. Göschka Seite 31 / 63 WEB v3.2 Web Presentation Tier Wireless network Internet WAP HTTP/HTML <wml> <template> <do type="prev"> <noop/> </do> </template> <card id="init“ newcontext="true"> <do type="options" label="Copyright"> <HTML> <HEAD> <TITLE></TITLE> </HEAD> <BODY bgcolor="white"> <CENTER> <P><IMG SRC="pictures/images/ictlogo.gi f" ALT="logo"></P> <BR> <HTML> <HEAD> <TITLE></ TITLE> </HEAD> <BODY bgcolor=" white"> <CENTER>< P>< Content encoding 010011000 000001111 111000000 110011110 110010011 011011011 101010010 011010 Bild 2.7: WML wird codiert übertragen, um an der Luftschnittstelle Bandbreite zu sparen Variables Input Elements <WML> <CARD> <DO TYPE=“ACCEPT”> <GO URL=“#eCard”/> </DO Welcome! </CARD> <CARD NAME=“eCard”> <DO TYPE=“ACCEPT”> <GO URL=“/submit?N=$(N)&S=$(S)”/> </DO> Enter name: <INPUT NAME=“N”/> Choose speed: <SELECT NAME=“S”> <OPTION VALUE=“0”>Fast</OPTION> <OPTION VALUE=“1”>Slow</OPTION> <SELECT> </CARD> </WML> Card Bild 2.8: Ein WML-Deck besteht aus Cards mit expliziter Inter-Card-Navigation WML unterscheidet sich aber doch in einigen Punkten wesentlich von HTML: Ein so genanntes WML-Deck (das geschlossen transportiert wird) besteht aus mehreren Cards. Eine Card ist dabei die Einheit für eine User-Interaktion. Es gibt ein explizites Modell für die Navigation zwischen den Cards, was die Navigation viel definierter und geordneter erscheinen lässt als bei HTML. Dieses Navigationsmodell beinhaltet neben den Hyperlinks auch UI Event Handling und eine History. Darüber hinaus steht eine explizite Zustandsverwaltung mit Variablen zur Verfügung, die zusätzlich hilft, das Caching zu verbessern und den Netzwerkverkehr gering zu halten. Bild 2.8 zeigt die WML-Struktur an einem Beispiel, während Bild 2.9 den typischen Ablauf der Navigation zwischen den Cards Karl M. Göschka Seite 32 / 63 WEB v3.2 Web Presentation Tier darstellt. Da beide Technologien nur exemplarisch gezeigt werden, wird auf eine detaillierte Beschreibung der einzelnen Elemente verzichtet. Bild 2.9: Ablauf der Inter-Card-Navigation an einem Beispiel 2.4.4. WML Scripting Language (*) WMLScript basiert auf prozeduraler Logik, wie Schleifen, Verzweigungen usw. WML-Script ist optimiert für geringen Speicherbedarf und geringe CPU-Leistung. Vom Prinzip her ist WMLScript abgeleitet von ECMA Script (siehe Abschnitt 4.3). WMLScript ist effizient mit WML integriert und bietet einen Mechanismus, um den Netzwerkverkehr weiter zu reduzieren. Der WMLScript-Compiler am WAP-Gateway oder WAP-Application-Server erzeugt den Bytecode, der dann im Mobilteil von einem stack-orientierten BytecodeInterpreter (virtual machine) interpretiert wird. Bild 2.10 zeigt ein einfaches Beispiel für die grundlegende Struktur von WMLScript ohne auf Details einzugehen. Functions Variables Programming Constructs function currencyConvertor(currency, exchRate) { return currency*exchangeRate; } function myDay(sunShines) { var myDay; if (sunShines) { myDay = “Good”; } else { myDay = “Not so good”; }; return myDay; } Bild 2.10: WMLScript Karl M. Göschka Seite 33 / 63 WEB v3.2 Web Presentation Tier 2.4.5. Die weitere Entwicklung und WAP und WML Während WAP 1.x auf Mobilität optimiert war und eigenständige Protokolle und Formate hervorgebracht hat (WML mit Cards und Decks, WSP, WTP, WTLS, WDP), war die weitere Entwicklung – auch aufgrund der Verbreitung der SmartPhones – von einem Trend “zurück” zum “normalen” Browser gekennzeichnet: WAP2.x hat WML bereits durch XHTML Mobile Profile (Cards, Decks, aber auch schon Web Seiten) ersetzt und als Protokoll wahlweise “Wireless Profiled” HTTP und TCP vorgesehen. Moderne Geräte unterstützen die Web Protokolle direkt, wobei jedoch immer noch auf die Rahmenbedingungen eines mobilen Gerätes Rücksicht genommen werden muss (Ressourcen wie CPU, Speicher, AkkuLebensdauer, Bildschirmgröße, Bandbreite, Latency/Delay, Netzwerkkosten, andere/kleinere Tastatur und Pointing Devices, etc.), wobei aus Kompatibilitätsgründen WML und WAP noch nicht gänzlich von der Bildfläche verschwunden sind. Da die mobilen Geräte für den Benutzer eine Reihe von Vorteilen bringen, v.a. umfassende Verfügbarkeit und Kontext-spezifische Information, werden Sie immer besser unterstützt. Im Idealfall soll der Ansatz “Design for one Web” verfolgt werden, wobei jedoch das Erstellen für Mobilität und Device-Unabhängigkeit eigene Regeln und Richtlinien hervorgebracht hat. Aktuelle Initiativen des W3C sprechen vom “Mobile Web 26” welches von der Mobile Web Initiative 27 unterstützt wird und folgende Technologien speziell für mobile Geräte hervorgebracht hat: CSS Mobile (Cascading Style Sheets) SVG Tiny (Scalable Vector Graphics) XHTML For Mobile Die jüngste Generation mobiler Browser unterstützt (tlw.) HTML5, CSS3, und viele JavaScript APIs. 26 http://www.w3.org/standards/webdesign/mobilweb 27 http://www.w3.org/Mobile/ Karl M. Göschka Seite 34 / 63 WEB v3.2 Web Presentation Tier 3. MVC und Frameworks Wie bei den Native GUI Clients erläutert, werden solche Clients üblicherweise mithilfe von GUI Frameworks, Entwicklungswerkzeugen und Komponenten- bzw. Klassen-Bibliotheken erstellt. Demgegenüber steht bei der Web-Entwicklung mit Script- oder Seiten-basierter WebAnbindung das Request-Response Paradigma des HTTP immer noch im Vordergrund: Zwar ist der Entwickler befreit von der Aufbereitung der Parameter und der Verwaltung der Sessions, er muss aber immer noch in Anfragen (Requests) und „Seiten“ als Antworten (Response) denken und dabei auch das Markup berücksichtigen (i.Allg. HTML). Und er muss sich selbst darum kümmern, Formulare richtig zu bearbeiten, die Referenzierung und Navigation aller Objekte einer großen Anwendung im Auge behalten, den hierarchisch strukturierten Aufbau einer Seite, Internationalisierung/Lokalisierung, Fehlerbehandlung, Typenkonversion – diese Aufgaben müssen trotz Servlet und JSP jedesmal eigens implementiert werden. Es ist daher wünschenswert, die Abstraktion in Widgets (UI Bausteine bzw. Komponenten) und Events (Ereignisse, auf die sich sogenannte „Listener“ registrieren, die dann auf die Geschäftslogik zugreifen und/oder die Darstellung der Widgets verändern) auch im Bereich der Web-Anwendung einzusetzen. Durch diese weitere Abstraktion wird die Anzahl der repetitiven Tasks reduziert und die Wiederverwendung von UI Bausteinen sowie die Wartbarkeit und Evolution komplexer UIs verbessert. Als Basis für derartige Architekuren und Werkzeuge dient das Model View Controller Pattern, welches wir im folgenden Abschnitt kurz erläutern werden. Danach werden wir die Anwendung des MVC Patterns auf den Web Presentation Tier zeigen und schließlich anhand von Java Server Faces (JSF) darlegen, wie auf Basis dieses Patterns ein Komponentenorientiertes UI Framework aussehen kann. 3.1. Model – View – Controller Pattern Die meisten UI Frameworks folgen dem Model-View-Control-Pattern, einem grundlegenden Pattern, welches die drei Rollen View, Model und Controller klar trennt und miteinander geordnet in Bezug setzt: Das Model repräsentiert jene Komponenten, die die Geschäftslogik beinhalten. Es repräsentiert die Domäne der Anwendung und enthält die von der Darstellung unabhängigen Daten und Methoden für den Geschäftsablauf. Karl M. Göschka Seite 35 / 63 WEB v3.2 Web Presentation Tier Der View repräsentiert die Darstellung des Model in einem bestimmten UI (auf einem bestimmten Device). Dies kann ein Fenster mit seinen Widgets sein, oder eine HTML Seite. Der View muss daher in der Lage sein, auf das Model zuzugreifen. Der Controller schließlich nimmt die Benutzereingaben entgegen, ändert ggf. das Model und passt schließlich den View an. Das UI insgesamt ist daher i.Allg. eine Kombination aus View und Controller, da ein Widget einerseits dargestellt wird (View), andererseits aber auch oft einen User Input entgegen nehmen kann (Controller). Bild 3.1 (aus [5]) zeigt das Model View Controller Pattern, wobei besonders darauf hingewiesen werden soll, dass der View und der Controller zwar das Model kennen (also Daten aus dem Model auslesen und via Methodenaufruf ändern können), das Model aber weder View noch Controller kennt. Bild 3.1: Model View Controller Pattern [5] In diesem Pattern kann man in Anwendung des Prinzips von „Separation of Concern“ zwei Trennlinien erkennen, die zwischen View/Controller und Model einerseits und die zwischen View und Controller andererseits. Die Trennung zwischen UI und Model ist die wichtigere der beiden und hat sich unzählige Male bewährt, und insbesonders ist es wichtig, dass das Model gar nicht merkt, dass ein UI auf es zugreift, da es weder View noch Controller kennt. Nur in seltensten Fällen wird es sinnvoll sein, diese Trennung aufzuheben (z.B. bei sehr kleinen Anwendungen, die praktisch keine Geschäftslogik enthalten). Die Trennung ermöglicht auch die Spezialisierung: Usability Engineering hat den Fokus auf dem UI, dem Layout, der Sichtbarkeit und dem Ablauf der Fenster. Klassisches Software Karl M. Göschka Seite 36 / 63 WEB v3.2 Web Presentation Tier Engineering hingegen hat den Fokus auf dem Model, der Geschäftslogik inklusive Transaktionen und Datenbankzugriffen. Desweiteren können verschiedene UIs auf dasselbe Model zugreifen. Einerseits können das unterschiedliche UIs auf verschiedenen Devices sein, andererseits aber auch einfach nur verschiedene Fenster in einer Anwendung. Wenn immer mehrere UIs auf ein Model gleichzeitig zugreifen (lokal oder verteilt), dann muss man weiter überlegen, ob bzw. wie schnell eine Änderung des Models ausgehend von einem UI in den anderen UIs angezeigt werden soll. Die zweite Trennung zwischen View und Controller ist von geringerer praktischer Bedeutung und ist in der Tat in vielen praktischen Systemen etwas verschwommen. Wenn wir von „dem UI“ sprechen, meinen wir oft View und Controller. In mancher Fachliteratur werden die drei auch als Layer dargestellt, wobei der Controller zwischen View und Model liegt. Diese Darstellung hat manchmal zu Verwechslungen mit anderen Patterns geführt (z.B. Application Controller, der die Navigation zwischen den Fenstern und damit den UI Ablauf der Applikation bestimmt). 3.2. Das MVC Pattern im Web Bild 3.2: Das MVC Pattern im Web [6] Wenn wir das MVC Pattern auf Web Applikationen anwenden (siehe Bild 3.2), sehen wir, dass der Controller (z.B. ein Servlet) den Request (und dessen Parameter und SessionInformation) entgegennimmt und die Geschäftslogik aufruft. Das Model (z.B. ein JavaBean) wird ggf. einen Datenbankzugriff durchführen oder eine entfernte Anwendung kontaktieren und schließlich ein Ergebnis produzieren. Auf dessen Basis wird der Controller sich für einen Karl M. Göschka Seite 37 / 63 WEB v3.2 Web Presentation Tier bestimmten View entscheiden und diesen aufrufen, wobei dabei auch die Datenweitergabe zwischen Controller und View geregelt werden muss, meist durch gemeinsamen Zugriff auf ein Daten Objekt. Der View (z.B. eine JSP Seite) wird unter Nutzung der Daten des Models die resultierende HTML Seite erzeugen. An diesem Beispiel sehen wir auch, wie man Servlet und JSP sinnvoll gemeinsam einsetzen kann: Das Servlet (aufgrund seiner Vorteile beim Programmieren) eignet sich besser als Controller, hingegen eignet sich die JSP Seite recht gut um den View darzustellen. Da die beiden letztendlich äquivalent sind, ist dies lediglich eine sinnvolle Konvention, und keine notwendige Aufteilung. Für die einzelnen Rollen (Model, View, und Control) im MVC Pattern gibt es wiederum Unterpattern nach denen diese Rollen aufgebaut sein können. Wir wollen hier den View und den Controller noch etwas genauer betrachten. Folgende Varianten ergeben sich für die View Patterns: Template View: Dabei erfolgt die Darstellung in der Struktur der zu erzeugenden Seite mit eingebetteten Befehlen, wie eben z.B. in JSP. Der Template View konzentriert sich also primär auf die Struktur der Seite. Transform View: Dabei wird auf die Daten vom Model eine Transformation angewandt, z.B. XSLT (eXtensible Stylesheet Language Transformations) auf XML Daten wie in Apache Cocoon 28. Two Step View: Dieses Pattern kann auf beide obige Patterns angewandt werden. Dabei wird zuerst ein „logischer“ View erzeugt und dieser in einem zweiten Schritt auf das „physische“ Device (z.B. HTML) „gerendert“. Diese Anpassung funktioniert natürlich nur, wenn die logische Darstellung den kleinsten gemeinsamen Nenner der zu unterstützenden Devices nutzt, was wiederum nur dann sinnvoll sein wird, wenn die Devices einander ausreichend ähnlich sind. Am besten eignet es sich z.B. zur Darstellung verschiedener „Corporate Identities“ oder zur Anpassung an Benutzerbedürfnisse. Zwei Varianten ergeben sich für den Controller: Page Controller: Hier gibt es einen Controller pro Seite 29. Das kann z.B. die JSP Seite selbst sein, oder der Controller wird von einem separaten Servlet implementiert. 28 http://cocoon.apache.org/ 29 Genau genommen gibt es einen Controller pro „Action“, also pro Link oder Button der genutzt wird. Dadurch ist die Zuordnung zwischen Seiten und Controller nicht exakt 1:1. Karl M. Göschka Seite 38 / 63 WEB v3.2 Web Presentation Tier Front Controller: Hier gibt es nur einen Controller für alle hereinkommenden Requests (wie das z.B. beim JSF-Faces Servlet der Fall ist), der sich um die Gemeinsamkeiten aller Anfragen kümmert 30, wie z.B. Internationalisierung, Customization oder Security. Weitere Details zu den Patterns können in [5] nachgelesen werden. 3.3. Java Server Faces - JSF Ein gutes Buch zu JSF ist [6], dem auch einige der hier angeführten Bilder und Auszüge entnommen wurden. 3.3.1. JSF und andere UI Frameworks für das Web Grundidee von JSF ist, die Vorteile der GUI Frameworks basierend auf dem MVC Pattern auch für Web-Anwendungen nutzbar zu machen. Das Request/Response-Verhalten und das Seiten-Markup sollen also hinter wiederverwendbaren, interaktiven UI Komponenten (Widgets) und Events/Listeners „versteckt“ werden, sodass ein Web-Client genauso entworfen werden kann wie ein Native GUI Client. Die besondere Stärke von JSF ist aber nicht technologisch, sondern liegt in der Tatsache der defacto-Standardisierung (durch die Eingliederung in J2EE) und in der dadurch breiten Industrieunterstützung. Die Idee der UI Frameworks geht zurück auf die damals als „Rapid Application Development“ oder auch „Rapid Prototyping“ bezeichneten Ansätze, welche eine Komponenten-Architektur, eine Menge von Widgets, eine Laufzeitumgebung, und ein Entwicklungstool definiert haben. JSF definiert alles analog, abgesehen vom Tool: Dieses kann – dem offenen Java Konzept folgend – von jedem Drittanbieter hergestellt werden und tatsächlich gibt es Tools bzw. Ergänzungen der Web-Entwicklungsumgebungen wie z.B. IBM’s WebSphere Application Developer, Oracle’s JDeveloper, oder Sun’s Java Studio Creator (mittlerweile auch Oracle). Natürlich gibt es auch andere Web-Frameworks. Ein relativ „altes“ System sind die WebObjects die in Steve Jobs’ NextStep entstanden sind und mit der „Rückkehr“ von Steve Jobs zu Apple gekommen sind 31. Apache Struts 32 und WebWork 33 sind Frameworks, die 30 Weitere „Helper“ oder „Command“ Objekte sowie „Intercepting Filters“ werden dann aufgerufen, um die Anfrage weiter zu verarbeiten. 31 http://www.apple.com/ca/webobjects/ Karl M. Göschka Seite 39 / 63 WEB v3.2 Web Presentation Tier einerseits von der Funktionalität über ein reines UI Framework hinausgehen, andererseits aber nicht den Abstraktionsgrad von JSF erreichen (Maskierung des Request/ResponseVerhaltens). Andere Frameworks konzentrieren sich genauso wie JSF v.a. auf das UI, man kann sie daher als Komponenten-basierte UI Frameworks bezeichnen, wie z.B. Tapestry 34, Echo 35 oder Oracle’s Application Development Framework ADF 36. Natürlich dürfen auch Microsoft’s WebForms 37 und – aktueller – ASP 38 MVC 39 nicht vergessen werden. Daneben gibt es noch eine Reihe älterer Frameworks, die die Schwächen reiner Script- oder Seitenbasierter Web-Anbindung mehr oder weniger umfangreich überwinden und oft auf bestimmte Technologien (siehe auch Abschnitte 2.2.2, 2.2.3, und 4) zugeschnitten sind: Tiles 40, Rails – vor allem aber nicht ausschließlich für Ruby als Ruby on Rails 41, Mozilla’s XUL 42 für XBL, Microsoft’s HTC 43 für DHTML, Pear 44 für PHP, oder Django 45 für Python. Völlig außer Acht lassen wollen wir hier jedoch Content-Mangement Systeme wie z.B. TYPO3 46, die sich v.a. mit dem redaktionellen Aspekt von Web-Applikationen als Informationssysteme beschäftigen, während wir uns hier für Enterprise Software Architekturen beschäftigen. Diese Auflistung ist – wie bei allen Web Technologien – nicht vollständig sondern lediglich exemplarisch. 32 http://struts.apache.org/ 33 http://www.opensymphony.com/webwork/ 34 http://tapestry.apache.org/ 35 http://echo.nextapp.com/site/ 36 http://www.oracle.com/technology/products/adf/index.html 37 http://www.asp.net/web-forms 38 Active Server Pages 39 http://www.asp.net/mvc 40 http://tiles.apache.org/ 41 http://rubyonrails.org/ 42 XML User Interface Language, siehe https://developer.mozilla.org/en/xul 43 HTML Componentes, siehe http://msdn.microsoft.com/en-us/library/ms531018(v=VS.85).aspx 44 http://pear.php.net/ 45 http://www.djangoproject.com/ 46 http://typo3.org/ Karl M. Göschka Seite 40 / 63 WEB v3.2 Web Presentation Tier Bild 3.3 zeigt die benötigten Services in einem UI Framework anhand derer man die Überlappung, Gemeinsamkeiten und Unterschiede zwischen verschiedenen Frameworks selbst jeweils genauer analysieren kann. Obwohl die Frameworks teilweise überlappende Funktionalität besitzen, lassen sie sich dennoch kombinieren, so wie etwa z.B. XUL, HTC, und Struts mit JSF integriert werden können. Bild 3.3: Services für Web Frameworks [6] Einen recht interessanten Ansatz stellt auch das Google Web Toolkit (GWT 47) dar. Von der Idee her ist es ein Komponenten-basiertes UI Framework auf derselben Abstraktionsebene wie JSF, wobei das gesamte UI in Java 48 entwickelt wird. Dadurch können – wie bei einer Desktop-Anwendung – Presentation Tier und Business Tier homogen in Java entwickelt werden. Der UI Teil wird danach in JavaScript Code (plus HTML, CSS, Ajax-Requests, etc.) übersetzt und natürlich wird auch die erforderliche Server-seitige Logik des UI generiert 47 http://code.google.com/intl/de/webtoolkit/ 48 Um das Java in JavaScript übersetzen zu können, wurde der Sprachumfang allerdings eingeschränkt. Karl M. Göschka Seite 41 / 63 WEB v3.2 Web Presentation Tier (Servlets), die sich dann homogen mit der Geschäftslogik integriert. Details können z.B. in [8] nachgelesen werden. 3.3.2. JSF ist Server-seitig JSF ist eine klassische Server-seitige Technologie 49: Der Browser zeigt reines HTML an und bekommt nicht mit, dass dieses von der JSF Laufzeitumgebung dynamisch erzeugt wurde. Diese wiederum läuft in einem Standard Java Web Container (im sogenannten JSF Servlet, welches gleich auch als FrontController fungiert). Dies sieht man in Bild 3.4. Bild 3.4: Web Anwendung mit JSF [6] Das Request/Response Verhalten und das Markup werden vom Framework gekapselt: Wenn der Benutzer im Browser einen Request auslöst, wird dieser Server-seitig vom Framework in einen Event umgewandelt, der dann mit einem Listener (Event Handler) abgefangen und verarbeitet werden kann, genauso wie man das auch in einem Desktop UI (z.B. mit Swing Komponenten) implementieren würde. Weiters können die UI Komponenten mit Java Objekten synchronisiert werden (sog. „Backing Beans“, im wesentlichen für den Controller Karl M. Göschka Seite 42 / 63 WEB v3.2 Web Presentation Tier im MVC zuständig) und werden automatisch in eine geeignete HTML-Darstellung für den Browser übersetzt. Der Entwickler konzentriert sich also auf UI Komponenten, Events und Listener, Backing Beans, und deren Interaktionen untereinander und mit den Geschäftsobjekten wie in jedem anderen UI Framework auch. Durch diese Kapselung des Request/Response-Verhaltens sowie des Seiten-Markups (i.Allg. HTML) hinter wiederverwendbaren, interaktiven UI Komponenten soll die Web-UI Entwicklung durch Re-Use effizienter und durch verbesserte Wartbarkeit billiger werden. Das ist das ultimative Ziel von JSF. 3.3.3. Die Bausteine von JSF in Bezug auf MVC JSF umfasst im Wesentlichen folgende Bestandteile, wobei auch die Zuordnung zum MVC Pattern hergestellt wird: UI Komponente (auch „Widget“ und leider auch „Control“ genannt): Diese hierarchisch organisierten Bausteine bilden das UI. Jeder Baustein ist mit einer bestimmten Darstellung und mit einer möglichen Funktionalität assoziiert. UI Komponenten sind vollwertige, zustandsbehaftete, Server-seitige JavaBeans. Bezüglich MVC gehören die UI Komponenten v.a. zum View, die Funktionalität des User-Input jedoch zum Controller. Renderer: Zuständig für die Darstellung einer Komponente (View), aber auch für die Umwandlung der Benutzereingaben in den Zustand der Komponente (Controller). Renderers sind in Form von Render Kits organisiert, welche neben HTML auch für andere Technologien wie WML oder SVG (Scalable Vector Graphics) zuständig sein können. Validator: Realisiert die Überprüfung der Gültigkeit von Eingabewerten (Controller im MVC). Zu einer UI Komponente können mehrere Validators assoziiert werden. Backing Beans: Nehmen Werte aus den UI Komponenten auf und implementieren die Event Listener Methoden. Backing Beans können auch Referenzen zu UI Komponenten enthalten, wodurch sie in die Lage versetzt werden, den View zu verändern. Bzgl. MVC gehören sie folglich zum Controller 50. 49 Man kann JSF natürlich auch mit Rich Internet Technologien wie JavaScript oder Ajax kombinieren. JSF benötigt diese Technologien jedoch nicht und funktioniert auch mit reinem HTML. 50 In der Literatur werden Backing Beans tlw. mit Managed Beans verwechselt: Managed Beans sind jene Beans, die durch Konfiguration dem JSF Framework bekannt sind. Dabei kann es sich um Komponenten des Models handeln (dann als Model Beans bezeichnet) oder eben um Backing Beans. Model Beans gehören zur Karl M. Göschka Seite 43 / 63 WEB v3.2 Web Presentation Tier Converter: Erledigen die Umwandlung von String zu Typ und vice-versa. Gehören daher – je nach Konversionsrichtung – zum View oder zum Controller. Events und Listeners: UI Komponenten (und auch andere Quellen) generieren Events, die von Listenern abgefangen und verarbeitet werden. Listener werden in der Regel in Backing Beans implementiert und gehören zum Controller. Messages: Dient der Darstellung von Informations- und Fehlermeldungen, die von den anderen Bausteinen (Backing Beans, Validators, Converter, ...) erzeugt wurden. Gehört bzgl. MVC daher zum View. Navigation: Beschreibt die Navigation zwischen den JSF Seiten durch einfache und übersichtliche Regeln. Ist nicht Bestandteil des MVC, sondern gehört zum Application Controller Pattern [5]. Wie man aus dieser Auflistung sieht, ist die Trennlinie zwischen View und Controller zwar gegeben, zieht sich aber oft mitten durch Bausteine und Komponenten und ist daher bei der praktischen Arbeit mit dem Framework nicht dominant: Zum View gehören die JSF Seiten (UI Komponenten), die Messages, und ein Teil der Renderer und Converter. Zum Controller gehören die Backing Beans mit den Listenern, jener Teil der UI Komponenten der das Binding regelt, die Validators, und ein Teil der Renderer und Converter. Sinnvollerweise ist die Trennung zwischen UI (View und Controller) und Model deutlich gegeben: Ein Model Bean kann zwar als Managed Bean vom Controller (Backing Bean Listener) oder vom View (JSF Seite) gelesen und geschrieben werden, das Model Bean selbst darf gemäß MVC keine Referenz auf das UI besitzen. Weitere Details zu den einzelnen Bausteinen können in [6] nachgelesen werden. 3.3.4. Die Bearbeitung einer JSF Anfrage An dieser Stelle soll der komplette Ablauf eines JSF Requests dargestellt werden, wodurch das dynamische Zusammenwirken der vorhin aufgezählten Bausteine verdeutlicht wird. Bild 3.5 zeigt den gesamten Ablauf. Geschäftslogik und kennen das UI nicht. Backing Beans sind folglich jene Managed Beans, die keine Model Beans sind. Ein Model Bean sollte gem. MVC nur „assoziiert“ (value-Expression) werden und keine Referenz auf das UI enthalten, während ein Backing Bean auch „gebunden“ (binding-Expression) werden kann und dann auf das UI (den View) zugreifen kann. Letzteres ist nicht zwingend notwendig und auch fraglich ob das guter Stil ist: Besser ist es, wenn der View seine Darstellung aus Model- und Helper-Daten selbst modifiziert. Karl M. Göschka Seite 44 / 63 WEB v3.2 Web Presentation Tier Bild 3.5: JSF Request Processing Lifecycle [6] Karl M. Göschka Seite 45 / 63 WEB v3.2 Web Presentation Tier Wie man erkennen kann, werden nach den meisten Phasen die generierten Events verteilt, was auch zu einem Überspringen einzelner Phasen führen kann. Weiters kann eine Phase Ihren Output entweder selbst erzeugen oder den Renderer dafür benutzen. Der wichtigste Punkt in diesem Ablauf ist vor der Phase „Invoke Application“, da unmittelbar danach die Geschäftslogik aufgerufen wird. Bis dahin hilft das JSF Framework den Komponenten-Baum aufzubauen und mit Daten aus dem UI zu befüllen, Validations waren zu diesem Zeitpunkt erfolgreich, und Backing Beans sowie Model Beans haben die neusten Daten aus der laufenden Benutzerinteraktion erhalten. Kurz gesagt, alle Detailinformationen des Requests sind auf der Abstraktionsebene des Komponenten-Frameworks verfügbar und können dort bearbeitet werden. Zuletzt noch eine Auflistung der Phasen im einzelnen: Restore View: Der aktuelle View (die hierarchische Komponentenstruktur) wird gefunden (oder erzeugt), um den aktuellen User-Input darauf anzuwenden, dahinter verbirgt sich auch das Session-Management. Dabei werden auch durch die binding-Expression angebundene Backing Beans mit der Komponenten-Hierarchie des Views synchronisiert. Apply Request Values: In dieser Phase werden die Server-seitigen Komponenten-Instanzen mit den Werten der übergebenen Parameter (Cookies, HTTP Header) befüllt. Nach Bedarf werden Konverter und Renderer bemüht um das Dekodieren und die Typenkonversion zu unterstützen. Dabei können auch Fehlermeldungen und Events erzeugt werden. Process Validations: Die Validierung der eingegebenen Daten wird durchgeführt, ggf. werden Fehlermeldungen und Events erzeugt, wie in fast jeder Phase. Update Model Values: Die Werte der Server-seitigen UI Komponenten werden in die durch die value-Expression assoziierten Managed Beans (Model Beans oder Backing Beans) übernommen. Invoke Application: Nun werden die Events zu den zugehörigen Listenern verteilt und dort (i.Allg. in den Backing Beans) abgearbeitet. Dabei werden Model Beans und View verändert, Messages und ggf. Events erzeugt und schließlich der Output für das Navigationssystem generiert, sodass auf Basis der Navigationsregeln der nächste View ausgewählt werden kann. Render Response: Der ausgewählte View wird (mit Convertern) gerendert, dabei Model Bean Daten, Backing Bean Daten und Messages eingebaut. Zuletzt wird der View gespeichert, damit er für zukünftige Fortsetzungen der Session bereit steht. Weitere Details zu diesem Ablauf können in [6] nachgelesen werden. Karl M. Göschka Seite 46 / 63 WEB v3.2 Web Presentation Tier 4. Rich Internet Technologien (RIT) Rich Internet Technologien sind Client-seitige Technologien, die versuchen Schwächen von reinem HTML in Kombination mit HTTP v.a. durch Erweiterung der Browser-Funktionalität zu überwinden. Das ultimative Ziel der RIT ist es, sogenannte „Rich Internet Applications“ (RIAs) zu ermöglichen, das sind Web-Anwendungen, welche dem Benutzer dieselben Möglichkeiten bieten wie eine Desktop-Anwendung, insbesonders hinsichtlich der Interaktivität, den Antwortzeiten, der Multi-Media Integration, und den „Community Features“ wie Blogs, Forums, Voting, etc. Rich Internet Technologien lassen sich mit Web Frameworks durchaus kombinieren – statt Server-seitig reines HTML zu generieren, kann man auch HTML mit eingebetteten Rich Internet Technologien generieren und auf diese Weise die UI Funktionalität zur Laufzeit zum Teil in den Browser auslagern. Eine der ersten dieser Technologien war das Java Applet, welches sich aber letztendlich nicht durchsetzen konnte (Abschnitt 4.1). Erwähnt werden sollen auch Active-X Controls als proprietäre Applet-Alternative von Microsoft, die im Internet Explorer bis heute noch da und dort Verwendung findet. Active-X gehört zur Familie der Microsoft Component Object Model (COM) Technologien und ist sowohl Browser- als auch Betriebssystem-spezifisch. Active-X Controls haben vollen Zugriff auf das Betriebssystem und sind daher nicht ganz unproblematisch, u.a. hinsichtlich Dependability und Security 51. Von der Verbreitung her erfolgreicher als Applets ist das Client-seitige Scripting, v.a. in Kombination mit dem Document Object Model, welches es dem Script gestattet, auf die aktuell angezeigte Seite aus dem Script-Programm heraus zuzugreifen. Einen weiteren signifikanten Schritt hat Ajax (Asynchronous JavaScript and XML) gemacht, eine Technik die es in Kombination mit DOM und Scripting gestattet durch RPC 52-artige Zugriffe auf den Web-Server Teile der angezeigten Seite zu aktualisieren. Diese Technologien werden in den folgenden Abschnitten exemplarisch kurz vorgestellt. Auch Browser-Plugins stellen eine Möglichkeit dar, sind jedoch spezifische und lokal zu installierende Erweiterungen der Browserfunktionalität und daher auf den jeweiligen Browser 51 http://www.microsoft.com/protect/terms/ActiveX.aspx 52 Remote Procedure Call Karl M. Göschka Seite 47 / 63 WEB v3.2 Web Presentation Tier zugeschnitten. Um diese Browser-Abhängigkeit zu überwinden, bieten etliche Hersteller ihre Plugins einfach in verschiedenen Varianten für die gängigen Browser an, siehe z.B. das Google Earth Plugin 53. Alle Rich Internet Technologien hier aufzuzählen würde den Rahmen sprengen und wäre auch bald obsolet, da sich in diesem Bereich immer noch viel verändert. Für den interessierten Leser lediglich erwähnen wollen wir an dieser Stelle Adobe’s (Macromedia’s) Flash 54 (der Flash Player ist als Cross-Plattform Plugin realisiert) und Flex 55 (das Framework zu Flash), oder Microsoft’s Antwort auf Flash – Microsoft Silverlight 56, oder Sun’s/Oracle’s Antwort auf Flash – JavaFX 57. Weiters Mozilla’s XBL 58, sowie Microsoft’s DHTML Behaviours 59 (DHTML – Dynamic HTML – selbst ist eher ein Marketing-Begriff und als solcher ein Vorläufer von „Richt Internet Technologies“. DHTML bezeichnet dabei i.Allg. die Kombination aus CSS, DOM und Client-seitigem Scripting 60). 4.1. Java-Applets Java-Applets enthalten Klassen, die von einem Web-Browser ausgeführt werden können. Applets werden mit dem applet-Tag oder dem object-Tag in HTML-Seiten eingebettet und besitzen prinzipiell eine grafische Benutzeroberfläche. Applets unterliegen besonders restriktiven Einschränkungen, um die Sicherheit zu gewährleisten: Es gibt keinen Zugriff auf lokale Ressourcen, und Netzwerkzugriff ist nur auf jenen Server gestattet, von dem das Applet geladen wurde. Daher können Datenbankzugriffe oder Socket-Kommunikationen nur über diesen Wirts-Server abgewickelt werden. Diese Restriktionen können zwar auf ClientSeite gelockert werden (für signierte bzw. „trusted“ Applets), was aber mit Zertifizierungsund Authentifizierungsvorgängen verbunden ist. Dies ist aber nur für Anwendungen im Intranet oder zumindest im Rahmen des Virtual Private Network VPN eines Unternehmens 53 http://earth.google.com/plugin/ 54 http://www.adobe.com/de/flashplatform/ 55 http://www.adobe.com/de/products/flex/ 56 http://www.microsoft.com/silverlight/ 57 http://javafx.com/ 58 XML Binding Language, siehe https://developer.mozilla.org/en/XBL 59 http://msdn.microsoft.com/en-us/library/ms531078 60 http://msdn.microsoft.com/en-us/library/ms533044 oder https://developer.mozilla.org/en/DHTML Karl M. Göschka Seite 48 / 63 WEB v3.2 Web Presentation Tier sinnvoll, da man die gelockerte Sicherheit ja nur dann als Applet-Entwickler ausnutzen kann, wenn man die Freigaben garantiert auf allen Clients zur Verfügung hat. Bild 4.1 zeigt ein einfaches Applet sowie eine Möglichkeit der Einbettung in eine HTML-Seite. import java.applet.Applet; import java.awt.Graphics; public class HelloWorld extends Applet { public void paint(Graphics g) { g.drawString("Hello world!", 50, 25); } } <html> <head><title> A Simple Program </title> </head><body> <p>Here is the output of my program: <applet code="HelloWorld.class" align="baseline" width="150" height="25"> </applet> </p></body></html> Bild 4.1: Java-Applet und umgebende HTML-Seite Damit bietet sich die Möglichkeit, nicht nur das GUI sondern auch einen Teil der Anwendungslogik am Client auszuführen, wodurch die Softwarearchitektur unter Verwendung von Applets etwas anders aussieht (vergleiche Bild 2.1 auf Seite 15). Speziell für Intranet-Anwendungen ergibt sich auch der Vorteil des Thicker Client mit mehr Funktionalität am Client ohne den administrativen Nachteil, weil das Applet zentral am Server verwaltet wird: Allerdings hat man dadurch einen größeren Bandbreitenbedarf beim Starten (Laden) des Applet, wobei intelligente Cache-Verfahren diese Problem nachhaltig lindern können: Java Web Start (JWS) bietet in diesem Zusammenhang folgende Möglichkeit: Der JavaCode wird ebenfalls dynamisch zum Client geladen, dort aber auf Basis eines Cache-Mechanismus mit der Arbeitsplatzoberfläche dauerhaft verknüpft, wobei ein automatisches Update stattfindet. Die einzige Voraussetzung für den Einsatz von Java-Applets am Client ist ein Java-fähiger Browser – und war lange Zeit in Hinblick auf die verschiedenen Versionen von Java und der Browser in keinster Weise trivial. Der Offline-Betrieb ist in diesem Fall nicht möglich – zumindest am Beginn braucht man eine Verbindung, um das Applet zu laden. Die Vor- und Nachteile des Applet gegenüber eine Java-Desktop-Applikation stellen sich wie folgt dar: Karl M. Göschka Seite 49 / 63 WEB v3.2 Web Presentation Tier Vorteile: Keine Installation oder Administration am Client notwendig61, einfache Administration am Server. Immer nur eine Version zu einer Zeit im Einsatz (keine Interaktionen zwischen verschiedensten Versionen). Nachteile: Zugriff auf lokale Ressourcen ist zwar möglich (signierte Applets), dann aber etwas aufwändiger, weil lokale Administration am Client benötigt wird. Offline-Betrieb ist nicht möglich, bei Beenden des Browsers geht der Zustand des Applets verloren. Die Flexibilität ist verringert, da eine Verbindung auf andere Server nicht möglich ist ohne das Applet von diesem neu zu laden. Kompatibilitäts- und Versionsprobleme mit den Browsern. Java-Applets können v.a. im Intranet eingesetzt werden und sind dort im Vergleich zu JavaApplikationen am Client beim Administrationsaufwand wesentlich günstiger. Im Gegensatz dazu ist im Internet der Null-Installationsaufwand am Client überhaupt Voraussetzung dafür, einen beliebigen Internetkunden ansprechen zu können. In diesem Bereich ist HTML als Konkurrenz zu Java zu sehen, weshalb dem Vergleich zwischen HTML und Java-Applets der nächste Abschnitt gewidmet ist. 4.1.1. Vergleich von Java-Applets und reinem HTML Java-Applets können dazu dienen, mehr Funktionalität am Client zur Verfügung zu haben und damit das Netzwerk zu entlasten. Damit sind Applets tendenziell effizienter für länger andauernde Interaktionen mit dem Benutzer. Außerdem kann das GUI aufwändiger und komfortabler gestaltet werden. Ein Nachteil von Applets ist die Download-Zeit am Beginn, dafür verursacht das Applet danach weniger Netzwerkverkehr, weil nur die benötigten Daten anstatt ganzer HTML-Seiten ausgetauscht werden 62. Eine quantitative Analyse anhand einiger realer Implementierungen hat ergeben, dass die reine HTML-Implementierung für viele typische Internet-Anwendungen nicht nur die kürzere Antwortzeit bringt, sondern auch 61 Wenn man von potenziellen Versionsproblemen absieht, ist diese Aussage richtig. 62 Dieser Vorteil wird mittlerweile auch von Ajax erzielt. Karl M. Göschka Seite 50 / 63 WEB v3.2 Web Presentation Tier insgesamt effizienter ist, weil viele typische Geschäftsfälle im Internet aus relativ wenigen Interaktionen bestehen. Es ist auch kein Zufall, dass die meisten großen Anbieter im Internet schon lange eine HTML-basierte Lösung verwenden. Gute Beispiele dafür sind der Versand von Büchern, CDs, Videos, usw., sowie Internet-Reisebüros mit der Möglichkeit der Reservierung, Buchung und Bezahlung von Flügen, Hotels und Mietwagen. Bild 4.2 liefert eine Möglichkeit abzuschätzen, ab welcher Anzahl von User-Interaktionen die Java-Variante die HTML-Variante übertrifft. Wie man in der Grafik erkennt, muss man dazu lediglich die Summe aus Applet-Größe und initialem Daten-Preload durch die Differenz aus der durchschnittlichen HTML-Seitengröße und der durchschnittlichen Datenmenge pro Interaktion mit Java dividieren. Date n Durch sch nittlich e Datenm enge, die pr o User- Intera ktion ausge taus cht w ird Daten Preload Durch sch nittlich e Größ e eine r H TML Seite Applet D ow nload HT ML Bild er Java Us er Interaktionen Bild 4.2: Quantitativer Vergleich von Java und HTML Wenn man es ganz genau wissen will, kann man auch mithilfe von Netzwerk-Analysewerkzeugen Messungen im realen Betrieb durchführen. Bild 4.3 zeigt die gute Übereinstimmung der gemessenen Ergebnisse mit der theoretischen Abschätzung anhand eines solchen Analysewerkzeuges. Der qualitative Vergleich zwischen Java und reinem HTML als Interface für Web-basierte Anwendungen hat folgende Ergebnisse aus der Praxis gebracht: User Interface: Mit reinem HTML besteht keine Möglichkeit des Event-Handlings im User Interface. Eine HTTP-Verbindung ist notwendig, bevor funktionale Abhängigkeiten oder Einschränkungen die nachfolgende Eingabe beeinflussen können. Zu diesem Zweck muss aber erst ein Link explizit angeklickt werden, es genügt nicht, einfach ein Feld auszufüllen. JavaScript (und insbesonders in der Kombination mit Ajax) bietet hier eine Möglichkeit, diese Karl M. Göschka Seite 51 / 63 WEB v3.2 Web Presentation Tier Schwäche des HTML-Interface zu überwinden. Der Vorteil von HTML hingegen liegt in der einfachen Gestaltung einer grafisch anspruchsvollen Seite. Performance: Mit reinem HTML resultiert jede einzelne User-Interaktion in einer HTTPVerbindung, wobei wiederum eine ganze HTML-Seite zurückgeliefert werden muss und nicht etwa nur jene Daten, die sich geändert haben (hier bietet Ajax mittlerweile eine Alternative). Daher werden mit Java nicht nur weniger Verbindungen benötigt, sondern außerdem pro Verbindung weniger Daten übertragen. Leider muss das Applet zuerst geladen werden, was einen großen Aufwand am Beginn mit sich bringt und die Akzeptanz der Benutzer herabsetzt. Zudem benötigt der Browser eine Java Virtual Machine (JVM), die ggf. erst nachgeladen werden muss, zumindest aber lokal gestartet werden muss, was auch einige Zeit dauern kann und keinesfalls eine flüssige Interation gestattet. Daher ist die Java-Variante vor allem für länger andauernde oder komplexere Interaktionen von Vorteil, während kurze, einfache Interaktionen mit reinem HTML effizienter zu implementieren sind. Ein gutes System sollte diese Wahl dem Benutzer überlassen und beide Varianten anbieten. Bild 4.3: Analysewerkzeug zum Vergleich von Java und HTML Karl M. Göschka Seite 52 / 63 WEB v3.2 Web Presentation Tier Server-Auslastung: Reines HTML benötigt mehr Ressourcen des Servers, weil auch die gesamte GUI-Information in Form dynamischer Zustandsinformation auf dem Server gespeichert und verwaltet werden muss. Kompatibilitätsprobleme: Sind bei der HTML-Variante wesentlich geringer als mit Java. Während zu Beginn das Problem eher daran lag, einen Browser mit einer aktuellen JVM zu finden, benötigen heute umgekehrt viele (noch) verfügbare Applets spezielle ältere JVM Versionen, die oft nicht mehr verfügbar sind. Design-Methoden: Die Java-Variante kann sich die objektorientierten Design-Methoden zunutze machen, während bei der HTML-Variante die Tendenz zu einem Designbruch besteht. Wartbarkeit und Erweiterbarkeit sind daher bei der HTML-Variante zunächst stärker eingeschränkt gewesen als bei der Java-Variante, was aber durch moderne Frameworks wie JSF mittlerweile relativiert wird. Integration von Multimedia-Inhalten: Bilder können bei beiden Varianten leicht implementiert werden, jedoch ist Java überlegen bei der Wiedergabe komplexer MultimediaInhalte, z. B. Video-Sequenzen. HTML ist hier auf Erweiterungen durch Rich Internet Technologien angewiesen. Barriere-Freiheit: Umgekehrt ist HTML aufgrund der deskriptiven Natur wieder besser in Hinblick auf Barriere-Freiheit, die von Applets kaum geeignet unterstützt wird. Suchmaschinen: Während die Inhalte von HTML (auch mit den meisten Rich Internet Technologies) für Suchmaschinen gut zugänglich sind, gilt dies nicht für Java Applets, die allenfalls durch die umgebende HTML Seite (indirekt) gefunden werden können. Upload von Dateien auf den Server: Relativ einfach mit HTML. Bei Java aufgrund des restriktiven Sicherheitsmodells sehr aufwändig und nur mit signierten Applets und Anpassungern der Sicherheitseinstellungen möglich. Aktiver Server und Groupware: In der HTML-Variante sind aktive Elemente nur durch aktuelle Rich Internet Technologien wie Ajax möglich, während dies kein Problem für Java darstellt. Datenbank-Transaktionen: Mit reinem HTML (selbst unter der Verwendung von Cookies) erfordert die zustandslose HTTP-Verbindung eine komplexe Zustandsverwaltung und entsprechende Time-Out-Mechanismen. Die eigentliche Datenbank-Transaktion wird also erst geöffnet, wenn der User den Vorgang endgültig freigibt (Single Shot Transaction). Dabei kann es aber passieren, dass die Transaktion nicht durchgeführt werden kann, weil sich an den Karl M. Göschka Seite 53 / 63 WEB v3.2 Web Presentation Tier zugrunde liegenden Daten in der Zwischenzeit etwas geändert hat. Ergo bedeutet die HTMLVariante letztendlich keine Unsicherheit bei den Transaktionen, aber möglicherweise geringeren Komfort beim Endbenutzer während der Durchführung von Transaktionen. Umgekehrt bieten JDBC und RMI alle Möglichkeiten, um sichere Transaktionen bis zum User Interface durchführen zu können. Sicherheit: Applets bieten hier aufgrund der Sandbox ein hohes Maß an Sicherheit. Reines HTML birgt auch kaum Sicherheitsrisiken, aber HTML erweitert um Rich Internet Technologien (und hier v.a. das Scripting) hat in der Vergangenheit immer wieder zur Sicherheitslücken geführt. Umgekehrt hat das restriktive Sicherheitsmodell von Java bei Applet-Entwicklern immer wieder zu Kopfzerbrechen geführt, da bestimmte Funktionalität dann eben nicht oder nur aufwändig zu implementieren ist. Summa summarum hat sich das Applet nicht durchgesetzt und ist weitgehend in der Versenkung verschwunden. Moderne Rich Internet Technologien (und hier insbesonders Ajax) in Kombination mit modernen UI Frameworks wie JSF können in Kombination mit HTML dieselben Vorteile wie Applets bieten, als einziger Nachteil bleibt allenfalls die größere Anfälligkeit für Security-Probleme. Zu den übrig gebliebenen Einsatzbereichen gehören komplexe, interaktive Visualisierungsaufgaben wie z.B. wissenschaftliche Darstellungen oder Car-Konfiguratoren, bei denen aber auch allmählich Applets von Ajax abgelöst werden [7]. 4.2. DOM – Document Object Model Das Document Object Model DOM geht aus einer Standardisierungstätigkeit des W3C hervor 63. Dabei wird eine interoperable Menge von Klassen und Methoden definiert, die dazu dienen, XML-Dokumente (und damit auch HTML- oder WML-Dokumente) aus Programmiersprachen wie Java, C++, oder Scriptsprachen heraus zu manipulieren. Es handelt sich dabei um ein API für Dokumente, es spezifiziert nur die Interfaces, nicht aber die Implementierung. Um eine wirklich präzise und sprachunabhängige Spezifikation des DOMInterface zu erreichen, hat sich das W3C dazu entschlossen, die Spezifikation in OMG IDL zu beschreiben. Die grundsätzliche Arbeitsweise mit DOM gestaltet sich wie folgt: Aus dem Dokument wird eine Objekthierarchie aufgebaut, sozusagen ein Spiegel des Dokumentes in Form einer Menge 63 http://www.w3.org/standards/techs/dom Karl M. Göschka Seite 54 / 63 WEB v3.2 Web Presentation Tier assoziierter Objekte gleicher Struktur – man könnte in diesem Sinne umgekehrt das XMLDokument auch als strukturierte Serialisierung der Objektstruktur ansehen. Dies ermöglicht den wahlfreien Zugriff auf alle Elemente des Dokumentes. Bild 4.4 zeigt die DOMGrundstruktur. 0..n NamedNodeMap <<interface>> Node <<interface>> 1 attributes Data <<interface>> Attribute <<interface>> Text <<interface>> Comment <<interface>> 0..n 1 childNodes Element <<interface>> NodeList <<interface>> DocumentFragment <<interface>> Document <<interface>> masterDoc CDATASection <<interface>> Bild 4.4: Ein DOM besitzt vom Grundprinzip her Baumstruktur Das DOM stellt nun APIs zur Verfügung, die es gestatten, einzelne Knoten im Baum einzufügen, zu verändern, zu löschen oder neu anzuordnen. Obwohl die Level-1-Spezifikation von DOM nichts über den Vorgang der Konversion zwischen XML-Dokument und DOM aussagt, bieten die meisten Anbieter von DOM-Implementierungen einen einfachen Weg für diese Umformung, meist in Form eines einzigen Methodenaufrufes pro Umwandlungsrichtung, also einen Aufruf für das Einlesen eines XML-Dokumentes in einen DOM-Baum und einen zweiten Aufruf für das Serialisieren 64 des DOM-Baumes in ein XMLDokument. Das von den Browsern für Client-seitige Script-Sprachen zur Verfügung gestellte DOM API ist ein wichtiger Baustein für Rich Internet Technologien: Es ermöglicht das momentan angezeigte Dokument zu lesen und auf nahezu beliebige Art zu steuern und zu verändern. Jedes HTML-Element ist im DOM Baum verfügbar, wodurch dessen Eigenschaften aus Programmen heraus durch simplen Aufruf von get() und set() Methoden gelesen und manipuliert werden können. Darüber hinaus bieten die DOM Implementierungen im Browser auch Zugriff auf Benutzeraktionen wie das Betätigen einer Taste oder das Steuern mit der 64 Der Begriff „Serialisieren“ ist hier nicht ganz zutreffend, weil die Struktur ja im XML-Dokument erhalten bleibt. Man kann von Serialisierung also nur insoweit sprechen, als die Datei insgesamt einen Bytestrom darstellt. Karl M. Göschka Seite 55 / 63 WEB v3.2 Web Presentation Tier Maus. Für diese Events können Event Handler geschrieben werden, welche wiederum via DOM das Dokument modifizieren können. Mehr dazu anhand von JavaScript im nächsten Abschnitt. 4.3. Client-seitiges Scripting: JavaScript JavaScript wurde ursprünglich als „LiveScript“ von Netscape aus der Taufe gehoben und lediglich aus Marketing-Gründen in JavaScript umbenannt. Trotz einiger syntaktischer Ähnlichkeiten (u.a. bei den Kontrollstrukturen) hat JavaScript somit mit Java nichts zu tun, Bild 4.5 wiederholt die wichtigsten Unterschiede mit Fokus auf das Java Applet als möglichen Konkurrenten bezüglich der Erweiterung der Client-seitigen Funktionalität. JavaScript Java (v.a. Applet) Als Teil der HTML Seite (oder Kompilierter Bytecode wird geladen und auf indirekt) geladen und interpretiert vom dem Client (JVM als Plugin im Browser) Client (Browser). ausgeführt. Objektbasiert: keine Unterscheidung Klassenbasiert: Objekte werden eingeteilt in zwischen Objekttypen; Methoden und Klassen und Instanzen; Vererbung durch die Eigenschaften können dynamisch Klassenhierarchie; hinzugefügt werden. Methoden und Eigenschaften können nicht dynamisch hinzugefügt werden. Datentypen nicht deklariert. Datentypen müssen deklariert werden. Kein Sicherheitsmodell, läuft mit Java Sicherheitsmodell, Applet zusätzlich in Browser-Rechten. Sandbox. Bild 4.5: Vergleich von Java und JavaScript In weiterer Folge hat die European Computer Manufacturers Association (ECMA) unter ECMA-262 einen Standard für Scriptsprachen geschaffen, an den sich JavaScript 65 mittlerweile recht gut hält und der von den meisten Browsern gut unterstützt wird. Ursprünglich war JavaScript auch für den Server-seitigen Einsatz vorgesehen (ähnlich einem Server Side Include), dies hat sich jedoch nicht durchgesetzt. Etwa zeitgleich mit dem Aufkommen von JavaScript hat Microsoft unter JScript 66 eine Alternative angeboten, die zunächst proprietär und JavaScript recht ähnlich war und dieses v.a. erweitert hat. Auch JScript hat sich mehr oder weniger an den ECMA-262 Standard 65 https://developer.mozilla.org/en/JavaScript 66 http://msdn.microsoft.com/de-de/library/72bd815a Karl M. Göschka Seite 56 / 63 WEB v3.2 Web Presentation Tier angepasst und mittlerweile werden die von JScript eingeführten Erweiterungen auch von anderen Browsern unterstützt. Von Microsoft wird Visual Basic Script, kurz VBScript 67, als weitere Scripting-Sprache für den MS Internet Explorer angeboten. VBScript ist als Client-seitiges Scripting nicht sehr verbreitet und wird im Wesentlichen in Kombination mit Active-X Controls verwendet, da VBScript auf Component Object Model (COM) Komponenten zugreifen kann. JavaScript. JavaScript ist eine objektbasierte Skriptsprache, der Sourcecode wird also während der Laufzeit interpretiert. Es wird mit dem <script> Tag ins HTML eingebunden und ist entweder eingebettet oder wird indirekt durch eine URL im HTML nachgeladen. JavaScript verfügt über sinnvolle Standardklassen wie String, Array, Date, Math, etc. Wichtiger ist jedoch der Zugriff auf die dargestellte HTML-Seite und den Browser, u.a. mit den DOM Objekten navigator, screen und window, welche für JavaScript vom Browser bereitgestellt werden 68. Das navigator Objekt dient der Verwaltung des Browsers und ermöglicht den Zugriff auf Name und Version des Browsers, sowie die Information ob im Browser Java Applets ausgeführt werden können bzw. welche Browser Plugins zur Verfügung stehen. Damit kann man sogenannte „Browser-Weichen“ implementieren, mit denen je nach Browser-Hersteller und Version die optimale Script-Variante gewählt werden kann. Das screen Objekt bietet Informationen über den Bildschirm wie Pixelgröße und Farbtiefe. Das windows Objekt ermöglicht Zugriff auf das aktuelle Fenster und enthält insbesonders das document Objekt, hinter dem sich die DOM Version der aktuell im Browser angezeigten HTML Seite verbirgt. Durch Zugriff z.B. auf jene Elemente die ein Formular repräsentieren, kann die unten angesprochene Prüfung von Formulareingaben erfolgen, indem der Klick auf den Submit Button auf das Script umgeleitet wird. Ebenso wichtig wie der Zugriff auf die DOM Objekte ist das Event Handling, welches JavaScript mit Ereignissen im Browser verbinden kann. Typische Ereignisse sind onChange, onClick, onFocus, onKeypress, onMouseover, und viele weitere mehr. Mittlerweile sind diese JavaScript Event-Handles zu einem Bestandteil von HTML geworden. Damit kann Client-seitig auf Ereignisse reagiert werden, was mit rein Server-seitig generiertem HTML ohne Scripting nicht möglich wäre. 67 http://msdn.microsoft.com/en-us/library/t0aew7h6 68 https://developer.mozilla.org/en/DOM Karl M. Göschka Seite 57 / 63 WEB v3.2 Web Presentation Tier JSON. Die JavaScript Object Notation 69 soll an dieser Stelle ebenfalls kurz erwähnt werden. Sie bietet eine einfachere Alternative zu XML als reines Textformat für den Datenaustausch, wodurch der Datenaustausch zwischen Client-seitigem Scripting und Server-seitiger Funktionalität erleichtert werden kann. Möglich sind Key-Value Paare und verkettete Listen in einer recht einfachen Syntax. Fazit. Zusammenfassend kann JavaScript verwendet werden um dem UI im Browser jene Dynamik zu verleihen, die durch reine Request/Response-Interaktionen zwischen Client und Server allein nicht möglich sind, also z.B. unmittelbare Reaktionen auf UI Events, sofortige Überprüfung der Eingaben in Formularen, oder Steuerung des Browser-Verhaltens. Für den Service-Anbieter, der seine Seiten mit JavaScript mit entsprechender Funktionalität anreichern möchte ist dennoch zu bedenken, dass der Browser die richtige Version der Scriptsprache unterstützen muss und der Benutzer diese auch gestatten muss, was keineswegs selbstverständlich ist. Jedenfalls sollte eine gute Web-Applikation auch ohne JavaScript zumindest noch funktionieren, da viele Internet-Benutzer diese Funktion auch schlicht und einfach im Browser deaktiviert haben, um potenzielle Security- beziehungsweise Privacy-Probleme zu vermeiden 70. 4.4. Ajax – Asynchronous JavaScript and XML Mit all den bisherigen Ansätzen bleibt doch ein Problem, welches unmittelbar mit dem ursprünglichen Zusammenspiel von HTML und HTTP verbunden ist: Wenn – trotz aller Rich Internet Technologien auf Client-seite – Information vom Server nachgeladen werden muss, dann kann dies nur in Form einer vollständigen neuen Seite geschehen. Und genau hier setzt Asynchronous JavaScript und XML – kurz Ajax 71 – an. Ajax ist keine gänzlich neue Technologie, sondern kombiniert JavaScript, DOM und XML um durch eine Art RPC 69 http://www.json.org/ 70 Im CERT Advisory CA-2000-02 wird empfohlen, aus Sicherheitsgründen auf die Verwendung jeglicher Skript-Sprachen zu verzichten. Der Grund liegt darin, dass Scriptsprachen das Browser-Verhalten verändern können und schon allein dadurch den Benutzer täuschen können. Desweiteren kann ein Script bereits während des Ladens der HTML Seite ausgeführt werden oder im Hintergrund eine Kommunikation aufbauen. Moderne Browser fangen derartiges Verhalten ab (je nach Sicherheitseinstellungen) und lassen dem Benutzer die Wahl. Dennoch bringen neue Features in diesem Bereich auch immer wieder neue Sicherheitslücken. Karl M. Göschka Seite 58 / 63 WEB v3.2 Web Presentation Tier (Remote Procedure Call) einen kleinen Teil einer Web Seite nachladen zu können ohne die Seite insgesamt nachladen zu müssen. In Bild 4.6 wird die grundlegende Funktionsweise dargestellt: Ausgelöst z.B. durch einen Event wird über einen Event Handler der JavaScript Code aufgerufen, der den Ajax-Request durchführen soll. Dieser führt den Request durch, wobei die Wahl zwischen synchron oder asynchron besteht: Asynchron bedeutet hier, dass der JavaScript Code nicht blockiert wird bis die Antwort da ist, sondern stattdessen das Eintreffen der Antwort über einen „Completion Handler“ (entspricht von der Funktionsweise her einem Call-Back) weiter verarbeitet wird. Der Completion Handler greift dann z.B. via DOM auf die aktuelle HTML Seite zu, um z.B. einen Teil dieser Seite durch den gerade neu geladenen Teil („Page Fragment“) zu ersetzen. Als Datenaustauschformat kann entweder XML oder JSON verwendet werden. Der Request kann auf einen Web Server (HTTP) oder ein Web Service (SOAP 72 oder REST 73) erfolgen. Web Page Updates page fragment Page fragment 1 JavaScript update code AJAX HTTP request Completion handler AJAX HTTP response Web Server Page fragment 2 Page fragment 3 Bild 4.6: Grundprinzip eines Ajax Requests Technisch gesehen, muss vor dem Ajax Request ein XMLHttpRequest Objekt erzeugt werden. Bild 4.7 zeigt anhand dieses Vorganges eine typische „Browser-Weiche“, wobei in diesem Fall auch noch proprietäre Active-X Controls zum Einsatz kommen. Das ist typisch für Client-seitiges Scripting, wo man immer wieder mit verschiedenen Browsertypen und Browser-Versionen konfrontiert wird. 71 http://www.ajax.org/ 72 http://www.w3.org/TR/soap/ 73 Representational State Transfer, eine Alternative zu SOAP Karl M. Göschka Seite 59 / 63 WEB v3.2 Web Presentation Tier if (window.XMLHttpRequest) { // Firefox, Opera, and IE >= 7 req = new XMLHttpRequest(); } else { // Older Internet Explorer try { // latest ActiveX req = new ActiveXObject('MSXML2.XMLHTTP.6.0'); } catch (e) { try { // older ActiveX req = new ActiveXObject('Microsoft.XMLHTTP'); } catch (e) {req = false;} } } Bild 4.7: Das XMLHttpRequest Objekt in verschiedenen Browsern Im nächsten Schritt wird mit der open-Methode eine Verbindung zum Server hergestellt und der Completion Handler mit jener Funktion verbunden, die aufgerufen werden soll, wenn die Antwort (asynchron) zurückgeliefert wurde. Im Bild 4.8 ist das die Funktion processResult(). JavaScript var req; function processResult() { if (req.readyState == 4) { alert("AJAX call completed with response code: " + req.status); } } function execRequest() { req = new XMLHttpRequest(); // Firefox and IE >= 7 //"true" means asynchronous (AJAX) call req.open("GET", "http://www.mydomain.com/", true); //Register event handler req.onreadystatechange = processResult; req.send(null); } HTML <button onclick="execRequest()">AJAX call</button> Bild 4.8: Ajax Request und Completion Handler Schließlich wird der Antwortcode abgefragt („4“ bedeutet quasi „alles fertig“) und das Ergebnis steht im responseText zur Verfügung und kann via DOM im aktuellen HTML Karl M. Göschka Seite 60 / 63 WEB v3.2 Web Presentation Tier Dokument eingebaut werden. Im obigen Beispiel wird stattdessen nur der HTTP Status Code ausgegeben. Fazit. Ajax hat aus Benutzersicht sicherlich den größten Schritt in Richtung DesktopVerhalten für Web-Anwendungen gebracht: Durch das Ereignis-gesteuerte Nachladen von Server-Information wird die Responsiveness enorm gesteigert und die Netzwerkauslastung insgesamt reduziert. Dies alles wird ohne Plugin oder Applet erreicht. Aus Entwicklersicht ist Ajax mittlerweile gut in die Web-Frameworks (z.B. JBoss RichFaces 74 für JSF) eingebunden und in die Entwicklungsumgebungen integriert, sodass nun insgesamt sowohl für den Entwickler (MVC) als auch für den Benutzer (hier v.a. durch JavaScript und Ajax) eine starke Annäherung des Web UI an das gewohnte Desktop UI stattgefunden hat. Dies hat allerdings auch einen Preis: Back-Button, History und Lesezeichen können nicht wie gewohnt verwendet werden und Suchmaschinen müssen sich an Ajax auch erst „gewöhnen“. Nichtsdestotrotz hat Ajax eine derart rasante Entwicklung genommen, dass man davon ausgehen kann, dass diese Technologie in der einen oder anderen Art weitere Verwendung finden wird. 74 http://www.jboss.org/richfaces Karl M. Göschka Seite 61 / 63 WEB v3.2 Web Presentation Tier 5. Lehrzielorientierte Fragen 1. Wiederholen Sie die Basistechnologien des Web (HTML, HTTP, URI, CGI) und bewerten Sie diese in Hinblick auf ihre Anwendung als „Universal Client“ in Enterprise Software Systemen. 2. Zählen Sie verschiedene Client-Arten und Client-Anbindungsmöglichkeiten für verteilte Systeme auf (inkl. Web) und ordnen Sie diese den N-Schichten zu (bildliche Darstellung der N-Schichten mit Client-Anbindungen). 3. Welche Vorteile und welche Probleme besitzt ein Web-Client mit HTML, HTTP und CGI und wodurch sind die Probleme eigentlich entstanden? 4. Wie können Sie trotz Einsatzes von HTTP Zustandsorientierung bewirken? 5. Was sind Cookies? 6. Wie kann man mit Web-Clients Transaktionssicherheit erhalten? Was sind die möglichen Nachteile dieses Ansatzes? 7. Wie funktioniert die Web-Server Anbindung grundsätzlich? Welche Probleme gab es dabei mit CGI? 8. Wie funktionieren Servlets und JSP (Java Server Pages)? 9. Welche Probleme verstecken Script- und Seiten-basierte Anbindungen wie Servlet und JSP (Java Server Pages) und welche bleiben bestehen? 10. Welche Vor- und Nachteile haben Java Applikationen mit Netzwerk-Class-Loader? 11. Welche Vor- und Nachteile haben vollwertige Java-Applikationen? 12. Welche technologischen Herausforderungen kennzeichnen mobile Deivces für die UI Entwicklung? 13. Wozu braucht man GUI-Frameworks? 14. Erklären Sie das Model View Controller (MVC) Pattern. 15. Wenden Sie das MVC Pattern auf Web Applikationen mit Script- und Seiten-basierter Web-Anbindung an. 16. Erläutern Sie das Grundprinzip MVC-basierter UI Frameworks für das Web anhand von JSF. 17. Ordnen Sie die Bausteine von JSF dem MVC Pattern zu. 18. Erläutern Sie den Ablauf der Bearbeitung einer JSF Anfrage. Karl M. Göschka Seite 62 / 63 WEB v3.2 Web Presentation Tier 19. Was sind Rich Internet Technologien? 20. Wie funktionieren Java Applets und welche Probleme gibt es dabei? 21. Wie kann man Java Applets und HTML hinsichtlich Web-Applikationen quantitativ und qualitativ vergleichen? 22. Was ist das Document Object Model (DOM) und wozu wird es benötigt? 23. Erläutern Sie die Möglichkeiten und Probleme von Client-seitigem Scripting anhand von JavaScript. 24. Was ist eine „Browser-Weiche“? 25. Wie funktioniert Ajax? Karl M. Göschka Seite 63 / 63 WEB v3.2
