J2EE Master Class. Einstieg für Anspruchsvolle

J2EE MASTER CLASS Æ Thomas Stark J2EE Æ Einstieg für Anspruchsvolle ADDISON-WESLEY [ in Kooperation mit ] Biblio...

Author: Thomas Stark

79 downloads 1078 Views 9MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

J2EE

MASTER CLASS

Æ Thomas Stark

J2EE Æ Einstieg für Anspruchsvolle

ADDISON-WESLEY

[ in Kooperation mit ]

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar. Die Informationen in diesem Buch werden ohne Rücksicht auf einen eventuellen Patentschutz veröffentlicht. Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt. Bei der Zusammenstellung von Texten und Abbildungen wurde mit größter Sorgfalt vorgegangen. Trotzdem können Fehler nicht ausgeschlossen werden. Verlag, Herausgeber und Autoren können für fehlerhafte Angaben und deren Folgen weder eine juristische Verantwortung noch irgendeine Haftung übernehmen. Für Verbesserungsvorschläge und Hinweise auf Fehler sind Verlag und Herausgeber dankbar. Alle Rechte vorbehalten, auch die der fotomechanischen Wiedergabe und der Speicherung in elektronischen Medien. Die gewerbliche Nutzung der in diesem Produkt gezeigten Modelle und Arbeiten ist nicht zulässig. Fast alle Hardware- und Softwarebezeichnungen, die in diesem Buch erwähnt werden, sind gleichzeitig auch eingetragene Warenzeichen oder sollten als solche betrachtet werden. Umwelthinweis: Dieses Produkt wurde auf chlorfrei gebleichtem Papier gedruckt.

10 9 8 7 6 5 4 3 2 1 08 07 06 05

ISBN 3-8273-2184-0

© 2005 Pearson Studium, ein Imprint der Pearson Education Deutschland GmbH, Martin-Kollar-Straße 10–12, D-81829 München/Germany Alle Rechte vorbehalten www.pearson-studium.de Lektorat: Frank Eller, [email protected] Einbandgestaltung: Marco Lindenbeck, webwo GmbH ([email protected]) Herstellung: Elisabeth Prümm, [email protected] Satz: mediaService, Siegen (www.media-service.tv) Druck und Verarbeitung: Kösel, Krugzell (www.KoeselBuch.de) Printed in Germany

Inhaltsverzeichnis Vorwort

13

Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Kapitel 1 Einleitung 1.1 Das Client/Server-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 Application Programming Interface und Service Provider . . . . . . . . . . . . . . . . . 1.2 Aufbau dieses Buches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Darstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Business-Logik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.3 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.4 Plattformübergreifende Kommunikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Ziele dieses Buches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4 An wen richtet sich dieses Buch? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Welche Voraussetzungen müssen Sie mitbringen? . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Disclaimer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5 Bezug und Installation der Basis-Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 Java 2 Plattform Enterprise Edition (J2EE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Die Wahl der „richtigen“ Entwicklungsumgebung (IDE) . . . . . . . . . . . . . . . . . . . 1.5.3 Ant – Jeder Aufgabe ihre Ameise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 Apaches Tomcat – Ein Kater erobert das Netz . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.5 JBoss – Einer für alles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 2 Java Server Pages 2.1 2.2 2.3 2.4 2.5

Web-Applikationen gestern und heute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Einrichten unserer Web-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Statisches HTML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die erste dynamische HTML-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Die Bausteine einer JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 JSP-Ausdrücke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 JSP-Scriptlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3 JSP-Deklarationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.4 Kommentare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Die vordefinierten Variablen einer JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Die verschiedenen Kontexte des Webservers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Acht Helfer zur Kontrolle unserer JSPs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15 15 16 17 17 18 20 21 21 22 23 24 24 24 24 25 25 25 27 27 32 34 35 36 36 39 43 45 46 46 48

5

Inhaltsverzeichnis

2.7 Direktiven – Eigenschaften einer JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.1 page – die Seitendirektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.2 Ein Beispiel für die Verwendung von page-Direktiven . . . . . . . . . . . . . . . . . . . 2.7.3 Die include-Direktive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8 JSPs und JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.1 Grundlagen von JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.2 Verwendung von JavaBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.3 JavaBeans gemeinsam nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.4 JavaBeans erzeugen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.5 Vorteile von JavaBeans gegenüber Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 3 Servlets

75

3.1 Von JSPs zu Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Die Vergangenheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Ein einfaches Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Servlets verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Der Lebenszyklus eines Servlets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3 Instanzen und Threads – Parallele Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.4 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Auf den Client hören: HTTP-Request-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Die Hauptzeile lesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Request-Header lesen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Ein Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Mit dem Client sprechen: HTTP-Response-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Die Statuszeile erzeugen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Response-Header setzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Was Sie mit JSPs nicht machen können . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Ein einfacher Chatroom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1 Die UserBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.2 Die UserRegistry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.3 Der Gesprächsspeicher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.4 Die Anmeldung am Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.5 Das Chat-Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.6 Die Darstellung des Chats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Filtern von Formulardaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 4 Tag-Bibliotheken 4.1 Ein eigenes Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Erstellen der Java-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Der Tag Library Descriptor. . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 Verwendung in JSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

50 51 58 66 67 68 69 72 73 74

75 78 78 80 87 92 93 94 95 95 98 101 101 102 104 107 107 108 110 111 113 121 122 123 125 127

..... ..... ..... .....

............ ............ ............ ............

127 128 130 132

Inhaltsverzeichnis

4.2 4.3 4.4 4.5

Attribute verwenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vordefinierte Variablen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Den Rumpf manipulieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mit dem Kontext arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Entscheidungen (if-else) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

133 135 137 140 140 146

Kapitel 5 Struts

147

5.1 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Struts-Komponenten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Was wir zusätzlich benötigen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Ein Adressbuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Unsere Business-Objekte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 JSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.4 Taglibs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.5 Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.6 ActionForms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.7 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.8 Konfiguration der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.9 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Die Datenbank-Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 6 Java Naming and Directory Interface 6.1 Was ist JNDI?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Naming Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.2 Directory Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 API und SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Download der API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Einige SPI-Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Arbeiten mit der JNDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Erzeugen eines Kontextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Mit dem Kontext arbeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.3 Datenquellen im Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 7 Enterprise JavaBeans 7.1 Vom Einschicht- zum Dreischichtsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Einsatz eines Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Aufbau eines Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Portabilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.3 Unterstützte APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.4 Aufgaben eines EJB-Containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

147 149 150 152 152 152 156 157 161 161 163 166 169 172 172 173 177 179 181 183 185 185 186 187 188 190 194 199 199 200 201 202 203 203

7

Inhaltsverzeichnis

7.3 Kurzer Überblick über EJB-Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Beans, Beans, Beans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.2 Methodenfernaufrufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.3 Objektserialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4 Die verschiedenen Bean-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1 Bestandteile einer Enterprise JavaBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.2 Entity-Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.3 Stateless Session-Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.4 Stateful Session-Beans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.5 Message Driven Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.6 Remote-Client-View vs. Local-Client-View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.5 Persistenz-Typen (BMP vs. CMP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Bean Managed Persistence (BMP) am Beispiel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.2 Das Remote-Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.3 Eine Ausnahme bei Kontoüberziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.4 Das Home-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.5 Die Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.6 Der Deployment Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7 Container Managed Persitence (CMP) am Beispiel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.1 Der Deployment Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.7.2 Der Persistence Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8 Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8.1 Beziehungen zwischen Entity-Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8.2 Kardinaliät der Beziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8.3 Implementierung von Relationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8.4 Die Konfiguration im Deployment Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8.5 Die Konfiguration im Persistence Descriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.8.6 EJB Query Language (EJB-QL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 8 Persistenz (JDO, Hibernate und Co.) 8.1 Java Data Objects (JDO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Die Technik dahinter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.2 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1.3 Verwendung der Referenzimplementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Ein Beispiel für JDO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 Konfiguration der Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 Verwendung eines Primary Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.3 Herunterladen, übersetzen und anreichern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.4 Ausprobieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 JDO Query Language (JDOQL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.2 Definition von Bedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.3 Sortieren der Ergebnismenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.4 Tausend weitere Möglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

204 205 206 208 208 209 210 210 211 212 212 213 214 214 216 216 217 217 228 231 235 237 238 239 240 241 242 244 245 249 250 251 252 252 253 254 256 257 258 267 268 268 269 270

Inhaltsverzeichnis

8.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.1 Unterschiede zum JDO-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.2 Das Datenbank-Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.3 Unsere Adressverwaltung via Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.5.4 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 9 Java Message Service 9.1 Das Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Partner im System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.2 Messaging-Konzepte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.3 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Bestandteile der API. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 Zusammenfassung API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Senden einer Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.1 JNDI-Lookup-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.2 Der schematische Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3.3 Die Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4 Empfangen einer Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.1 Pull – manuelles Abholen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.2 Push – Wenn der Postmann zweimal klingelt. . . . . . . . . . . . . . . . . . . . . . . . . . . 9.4.3 Topic vs. Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5 Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5.1 Reihenfolge der Nachrichten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5.2 Auslieferungsmodus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5.3 Das Verfallsdatum unserer Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.5.4 Korrelation und Identifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6 Filtern einer Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.1 Setzen und Auslesen von Eigenschaften. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.2 Ausgabe von Attribut-Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.3 Filtern anhand von Attributen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.6.4 Filterelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7 Transaktionen und Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.1 Transaktionen beim Senden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.2 Transaktion beim Nachrichtenempfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.7.3 Empfangsbestätigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8 Hin und zurück . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8.1 Der QueueRequestor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8.2 Ein Empfänger mit Antwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.8.3 Request-Reply vs. klassischem Remote Procedure Call . . . . . . . . . . . . . . . . . . . . 9.9 Ein Blick über den Tellerrand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.9.1 Message Driven Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

270 271 272 272 273 276 277 281 284 284 285 286 286 291 292 292 292 294 295 296 297 299 300 301 301 302 303 303 303 304 305 307 308 309 309 310 311 312 313 315 315 315 321

9

Inhaltsverzeichnis

Kapitel 10 eXtensible Markup Language 10.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.1 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.2 Auftritt für die eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.3 Einige XML-basierende Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.1.4 Vorteile von XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 XML-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.1 Prolog und XML-Anweisungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.2 Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 Zeichenketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.4 Kommentare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.5 Namensräume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.6 CData-Rohdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.7 Syntaxüberprüfung per Document Type Definition (DTD) . . . . . . . . . . . . . . . . . 10.2.8 Syntax-Schema-Definitionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Mit XML-Dokumenten arbeiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Das Document Object Model des W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.2 Das Java Document Object Model (JDOM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.3 Erzeugen eines XML-Dokuments von Grund auf . . . . . . . . . . . . . . . . . . . . . . . . 10.3.4 Einlesen eines XML-Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.5 Verarbeiten eines XML-Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.6 Erzeugen eines XML-Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4 Mit XML-Events arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1 Callback-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.2 XML lesen mit SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.3 XML verarbeiten mit SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.4 Zusätzliche Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.5 Einer für alles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.6 Zusammenfassung SAX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 11 XPath, XSL & Co. 11.1 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.1 Referenzieren von Elementen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Erweiterte Pfade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.3 Operationen und Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.4 XPath-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.5 Zusammenfassung XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 eXtensible Stylesheet Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.1 Ein einfaches Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.2 eXtensible Stylesheet Language Transformation (XSLT) . . . . . . . . . . . . . . . . . . 11.2.3 Aufbau eines Stylesheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

323 323 324 325 329 331 332 332 333 335 336 337 338 338 344 349 350 350 351 352 357 358 362 364 365 366 370 377 378 379 380 381 381 382 385 386 387 390 391 392 394 401

Inhaltsverzeichnis

11.2.4 Ein Beispieldokument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.5 Eine alternative Implementierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.6 Erweiterungsfunktionen für XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2.7 Zusammenfassung XSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 XSL Formatting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.1 Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.2 Grundlagen und Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.3 Aufbau eines Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Von XML zum PDF – ein Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.1 Das Stylesheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.2 Das Rendering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4.3 Das Ergebnis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Kapitel 12 Web Services 12.1 XML-Remote Procedure Calls (XML-RPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.1 Das Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.2 Aufbau eines XML-RPC Dokuments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.3 Übergabe der Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.4 Fehlerbehandlung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.1.5 Zusammenfassung XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Simple Object Access Protocol (SOAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.1 Die Idee hinter SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.2 SOAP und Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.3 Erstellen einer SOAP-Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.4 Verschicken unserer SOAP-Nachricht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2.5 Empfangen einer SOAP-Nachricht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 JAX-Remote Procedure Call (JAX-RPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.1 Das Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.2 Die Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.3 Die Konfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3.4 Der Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4 ... und darüber hinaus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.1 Web Service Description Language (WSDL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.4.2 Universal Description and Discovery Interface (UDDI) . . . . . . . . . . . . . . . . . . . . 12.4.3 eXtensible Interaction System (Axis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

403 408 410 410 411 411 412 413 418 418 422 423 424 425 425 426 427 427 428 429 430 430 430 431 434 435 436 437 437 437 439 439 439 440 440 441

Kapitel A Weiterführende Quellen und Literatur

443

Kapitel B Apache Software License

445

Kapitel C J2EE Software License

449

Stichwortverzeichnis

455

11

Vorwort Sie kennen Java und wollen ins Netz? Ihre Softwarekomponenten sollen genauso portabel und mobil wie Ihre Daten sein? Dann kann Ihnen dieses Buch vielleicht weiterhelfen. Wenn wir mit unseren Java Applikationen den klassischen Appletbereich verlassen und uns serverseitigen Anwendungen zuwenden, ändert sich die Perspektive: Während wir uns zuvor auf das Anliegen eines einzelnen Benutzers konzentriert haben, gilt es jetzt die Wünsche von vielen Anwendern gleichzeitig zu erfüllen. Dabei unterstützt uns Sun durch verschiedene, auf der Programmiersprache Java basierende Technologien, die unter dem Begriff Java 2 Enterprise Edition (J2EE) zusammengefasst werden. Mit diesem Buch möchte ich Sie in die J2EE - Technologien einführen und Sie beim Perspektivenwechsel vom „Desktop Java“ zu „Java Server Side Solutions“ begleiten.

Danksagung Wie jedes Buch verdankt auch dieses Werk sein Entstehen neben dem Autor vielen anderen Menschen, denen ich an dieser Stelle danken möchte. Zunächst einmal meiner süßen Freundin Ulli: Ich liebe Dich. Du hast die größten Entbehrungen hinnehmen müssen und mich trotzdem immer wieder aufgebaut und unterstützt, wenn der Stress allzu groß werden drohte. Dir widme ich dieses Buch. Meinem Freund und Mentor Christian Gleich: Ohne Deine Kommentare hätte ich beim Schreiben wesentlich weniger zu lachen gehabt ;-). Meinen Eltern und Geschwistern, dass Ihr einfach da seid. Meinem Lektor Frank Eller, sowie Karsten Samaschke für Euer Vertrauen und die Möglichkeit dieses Buch zu Schreiben. Ich habe mich bei Euch stets gut aufgehoben gefühlt. Meinen Freunden für Euer Verständnis, wenn ihr mich diesen Sommer nicht häufig zu Gesicht bekommen habt. Und den vielen anderen Personen, die hier ungenannt blieben und die trotzdem ihr Scherflein dazu beigetragen haben.

13

Vorwort

Dieses Buch hat mir viel Spaß bereitet und für den Verlag Addison-Wesley zu schreiben ist sicherlich nicht nur für mich eine große Ehre. Natürlich bin ich nun an Ihrer Meinung zu diesem Buch interessiert: Anregungen und Kritiken nehme ich unter [email protected] gern entgegen. Thomas Stark, Berlin im September 2004

14

1 Einleitung J2EE, was ist das eigentlich? Wollten wir uns bei der Antwort auf einen einzigen Satz beschränken, könnte sie lauten: „J2EE ist das am weitesten verbreitete „Betriebssystem“ für Webanwendungen.“ Lässt man sich mit der Antwort dagegen etwas mehr Zeit, kommt vielleicht so etwas wie dieses Buch dabei heraus. Hinter Suns Java 2 Plattform Enterprise Edition (J2EE) steht im Wesentlichen kein Produkt, sondern ein Satz von Spezifikationen und Technologien, die die Entwicklung von sicheren, stabilen und portablen Business-Anwendungen ermöglichen sollen. Ausgefüllt werden diese Spezifikationen dann durch Implementierungen verschiedener Anbieter, zwischen denen wir als Programmierer wählen können. Neben namhaften Firmen wie IBM, Oracle oder SAP, die für verschiedene fest etablierte Standards stehen, wird die J2EE-Plattform aber auch von einer großen Gemeinde freier Entwickler in Form von vielen Open Source-Projekten unterstützt. Den Kern der Spezifikation bildet dabei ein modulares, komponentenbasiertes Modell, dessen Bestandteile über standardisierte Schnittstellen miteinander kommunizieren und zusammenarbeiten. Dies ermöglicht auch bei komplexen Systemen die nachträgliche Integration von neuen Komponenten und Services und stellt für viele Business-Anwendungen einen Garant für Zukunftssicherheit dar.

1.1

Das Client/Server-Modell

Die Idee hinter vielen Spezifikationen imInternet ist das Client/Server-Modell. Ob nun der Browser mit dem Webserver oder dieser mit dem dahinter liegenden Application Server kommuniziert: In der Regel bittet der Client einen Server um die Erbringung eines bestimmten Dienstes, um seinerseits weiterarbeiten zu können. Wie der Server den Dienst schließlich erbringt, bleibt für den Client vollkommen transparent.

15

1 Einleitung

Abbildung 1.1 Client/Server-Modell

Wie Sie sehen können, sind unsere Anwendungen häufig in Darstellung, Geschäftslogik und Datenhaltung aufgeteilt, bei der ein Server gegenüber dem Server einer weiteren Schicht wiederum als Client auftritt. Und so werden wir uns in diesem Buch einfach von Schicht zu Schicht durch das Client/ServerModell arbeiten, mit dem Ziel, die Konzepte und Ideen dahinter zu verstehen.

1.1.1 Application Programming Interface und Service Provider Ein in der J2EE-Spezifikation immer wiederkehrendes Konzept ist das API/SPI. Dabei wird ein von Sun in Form einer API vorgeschlagener Standard durch Implementierungen verschiedener Anbieter, die so genannte Service Provider Implementation (SPI), ausgefüllt. Abbildung 1.2 API/SPI -Konzept

Der Vorteil dieser Architektur besteht in der großen Modularität der Software, denn wenn wir unsere Anwendungen nur auf Basis der abstrakten Klassen und Interfaces aufbauen, können wir die jeweilige Implementierung auch im Nachhinein noch austauschen, ohne unsere Software anpassen zu müssen. Auch muss Sun bei diesem Konzept nicht einmal Referenz-Implementierungen anbieten, sondern kann es anderen Anbietern überlassen, die von ihr vorgeschlagenen Standards zu unterstützen. Deshalb ist die J2EE-Spezifikation kein Produkt im eigentlichen Sinne, sondern besteht aus einer Menge von Schnittstellen, die dazu gedacht sind, gut zusammenzuarbeiten. Die Einhaltung dieser Standards sichern Sun dabei umfangreiche Tests, nach deren Bestehen die jeweilige Implementierung die Java Compatible Enterprise Edition-Zertifizierung erlangt, welche belegen soll, dass dieses Produkt problemlos mit anderen zusammenarbeitet und so das Wiederverwendbarkeitsparadigma von Sun, „Write Once, Run Anywhere“, erfüllt.

16

Aufbau dieses Buches

1.2


Die mit der Größe und Komplexität unserer Applikationen ansteigenden Anforderungen ziehen sich wie ein roter Faden durch das gesamte Buch. So lässt sich dieses, auch im Hinblick auf das eben beschriebene Client/Server-Modell, grob in folgende vier Kategorien einteilen.

1.2.1 Darstellung Die Darstellungsschicht bildet häufig den Einstiegspunkt in unsere Anwendung und kaum ein System kommt ohne sie aus. Unsere Schnittstelle zum Endanwender nimmt dessen Eingaben, wertet diese aus und übermittelt ihm dann die oft grafisch aufbereitete Antwort. Als Grundlage für den Client dienen dabei häufig Webbrowser wie Microsofts Internet Explorer (IE) oder der inzwischen von einem Open Source-Projekt weiterentwickelte Mozilla. Diese sind inzwischen auf (fast) jeder Plattform verfügbar und machten die so genannten webbasierten Applikationen so populär. Neben dem Browser können Anwender aber auch über andere Clients, etwa in Form von Java-Applets, mit unserem Server kommunizieren. Diese kommen vor allem dann zum Einsatz, wenn z.B. Eingaben schon vor der Übertragung auf Benutzerseite überprüft werden sollen. Mit den Erweiterungen der Hypertext Markup Language (HTML) sind diese Validierungen allerdings auch direkt im Browser möglich sein, so dass abzuwarten bleibt, ob der IE, Mozilla und Co. bald auch diese Nische besetzen werden.

Als webbasierte Applikationen bezeichnen wir Anwendungen, bei denen Server und Client über das Inter- oder Intranet miteinander kommunizieren. Die Basis bildet hierbei häufig das im Internet verwendete Hypertext Transfer Protocol (HTTP). Abbildung 1.3 Aufbau webbasierter Anwendungen

J2EE beinhaltet eine Reihe von Technologien, die die Entwicklung von webbasierten Applikationen ermöglichen. Kapitel 2 – Java Server Pages (JSP) In diesem Kapitel werden wir lernen, wie wir statische HTML-Seiten und JavaCode kombinieren, um dynamische Dokumente zu erzeugen, deren Aussehen und Inhalt je nach Zustand der Anwendung variiert.

17

1 Einleitung

Kapitel 3 – Servlets Auch mit Servlets können wir auf Anfrage HTML-Dokumente erzeugen und an den Client ausliefern. JSPs und Servlets stehen dabei in gewisser Konkurrenz, wobei wir lernen werden, wie wir beide sinnvoll miteinander kombinieren, um die jeweiligen Stärken der Technologien miteinander zu verbinden. Kapitel 4 – Tag-Bibliotheken (Taglibs) Über Tag-Bibliotheken werden wir in die Lage versetzt, den beschränkten Vorrat an HTML-Elementen um eigene Tags mit speziellen Funktionen zu erweitern und diese anschließend in unseren Dokumenten zu verwenden. Kapitel 5 – Struts Die Entwicklung komplexer Web-Applikationen kann zu einem Abenteuer ausarten, besonders wenn bestimmte Komponenten und Services erst nachträglich hinzugefügt werden. Häufigstes Problem ist die Dopplung von identischem Code (Copy&Paste), was den Aufwand für Anpassungen in astronomische Höhen schießen lässt. Application Frameworks bilden einen Rahmen für unsere Anwendung. Genau wie uns ein API vorgefertigte Methoden zur Verfügung stellt, unterstützen uns Application Frameworks, indem sie uns die Implementierung von Standardaufgaben abnehmen, so dass wir uns auf das Wichtigste, also unseren Code, konzentrieren können.

An dieser Stelle helfen uns Application Frameworks weiter. Diese sind kein Bestandteil der J2EE-Spezifikation, können uns aber dabei helfen, gute Anwendungen zu entwickeln, da sie für immer wiederkehrende Aufgaben, wie z.B. das Auslesen von Benutzereingaben, bereits Standardverfahren zur Verfügung stellen. Welche Vorteile die Verwendung eines Application Frameworks hat und wie wir es einsetzen können, zeigen wir in diesem Kapitel anhand von Struts.

In kleineren Anwendungen sind Darstellung und Logik oft miteinander verwoben, wodurch eine Wiederverwendung der einzelnen Komponenten erschwert wird. Wir werden verschiedene Techniken kennen lernen, um diese beiden Schichten klar zu trennen und einen modularen Aufbau unserer Applikation zu ermöglichen, unabhängig davon, ob sich die Komponenten nun auf einem einzigen Server befinden oder auf verschiedene Systeme verteilt sind.

Mit unserem Struts-Kapitel wollen wir die Darstellung abschließen, um uns nun der eigentlichen Anwendungsschicht, der so genannten Business-Logik, zuzuwenden. Diese kann sich in Form von JavaBeans im Webcontainer befinden oder auf einen anderen Server ausgelagert sein, wodurch verteilte Applikationen entstehen.

18

Verwendete Umgebung Damit unsere JSPs, Servlets und Taglibs funktionieren und die darauf aufbauenden Frameworks arbeiten können, benötigen wir natürlich noch eine entsprechende Umgebung (die Java Virtual Machine), in der diese Anwendungen laufen. Bei webbasierten Applikationen wird diese Umgebung als Web-Container oder Webserver bezeichnet, die von verschiedenen Anbietern vertrieben werden. In diesem Buch verwenden wir hierfür den frei verfügbaren Apache Tomcat, wobei alle Beispiele auch auf anderen J2EE-konformen Servern ausgeführt werden können.

1.2.2 Business-Logik Der zweite Teil des Buches dreht sich also um die Business-Logik und damit um den Kern unserer Anwendungen. Denn egal, wie Daten abgelegt oder dargestellt werden, hier wird der Grundstein für Geschwindigkeit und Komfort gesetzt (von der Korrektheit der Ergebnisse ganz zu schweigen).


Die Logikschicht liegt für den Anwender hinter der Darstellungsschicht verborgen und kann nur über diese manipuliert werden. Sie ist der Träger der Geschäftsgeheimnisse und damit der interessanteste Teil der ganzen Applikation, denn die Webseiten, die z.B. die bekannte Suchmaschine Google ausliefert, können wir sehen und analysieren. Auch die Tatsache, dass die Daten in irgendeiner Form von Datenbank gespeichert sind ist dabei kein großes Geheimnis. Doch welche Verknüpfungen zwischen ihnen bestehen und nach welchen Kriterien die Suchmaschine eine Seite indiziert, darüber gibt es nur Spekulationen.

Google ist eine sehr populäre Suchmaschine, die uns das gezielte Suchen nach Dokumenten mit bestimmten Inhalten im Internet ermöglicht.

Kapitel 6 – Java Naming and Directory Interface (JNDI) Damit unsere verteilten Komponenten einander überhaupt erst finden und miteinander kommunizieren können, benötigen sie zunächst einen Vermittler, der mal „Fräulein vom Amt“ und mal „Postbote“ spielt. Diesen Vermittler bildet das Java Naming and Directory Interface (JNDI), das unseren Anwendungen den Zugriff auf Namens- und Verzeichnisdienste ermöglicht.

In einem Namens-/Verzeichnisdienst können Applikationen sich und ihre Dienste (Services) registrieren und Objekte ablegen, um diese anderen Anwendungen verfügbar zu machen.

Kapitel 7 – Enterprise JavaBeans (EJB) An diese Komponente denken Java-Entwickler bei der Nennung von J2EE häufig zuerst und in der Tat bildet sie einen Grundpfeiler für das gesamte Framework. Enterprise JavaBeans (EJB) sind dazu gedacht, die Anwendungslogik aufzunehmen und verschiedene Komponenten zur Verfügung zu stellen. Außerdem beinhaltet die Spezifikation Mechanismen zu Lastverteilung und ermöglicht sehr gut skalierende Anwendungen. Verwendete Umgebung Während die JSPs und Servlets einen Web-Container benötigen, befinden sich die EJBs in einem EJB-Container. Genau wie der Web-Container steuert der EJB-Container den Lebenszyklus (Lifecycle) der enthaltenen Komponenten und ermöglicht den Zugriff auf diese.

Als Lebenszyklus oder Lifecycle bezeichnen wir alle Zustände, die unsere Software-Komponenten durchlaufen. Dazu gehören neben der Erzeugung und Zerstörung beispielsweise auch verschiedene aktive und passive Phasen. Abbildung 1.4 Zugriff auf den EJB-Container

Web- und EJB-Container zusammen bilden einen so genannten J2EE Application Server, der laut Spezifikation unter anderem verschiedene der hier besprochenen Dienste, wie beispielsweise einen Namensdienst, zur Verfügung stellen

19

1 Einleitung

muss. Als Grundlage für die hier besprochenen Beispiele dient der ebenfalls frei verfügbare JBoss Application Server der gleichnamigen Gruppe, der kostenlos von der Homepage heruntergeladen werden kann.

1.2.3 Datenhaltung Datenhaltung, Zugriff auf Datenbanken und JDBC – dies sind Themen, die heute in keinem guten Java-Buch mehr fehlen und eben weil dies schon zum Basiswissen über Java dazugehört, gibt es in diesem Buch eben kein Kapitel über die Java Database Connectivity (JDBC). Kapitel 8 – Java Data Objects (JDO) und Hibernate Die Abbildung von Objekten auf relationale Datenbanken und zurück (O/RMapping) gehören zu den aufwändigsten Fleißaufgaben im Leben eines JavaProgrammierers. Da es sich dabei um Standardverfahren handelt (Properties lesen und auf Attribute schreiben), können wir diese eigentlich auch gleich dem Rechner überlassen. Mit den Java Data Objects (JDO) existiert eine Technologie, mit der wir nie wieder SQL-Statements schreiben müssen, sondern uns ganz auf die Manipulation von Objekten konzentrieren können. Da es neben Suns JDO-Spezifikation verschiedene unabhängige Ansätze für das gleiche Problem gibt und wir uns stets einen Blick über den Tellerrand bewahren wollen, lernen wir auch das Open Source Framework Hibernate kennen, das uns mit ähnlichen Konzepten, aber anderen Techniken ebenfalls von den Last, ResultSets zu verarbeiten, befreit. Abbildung 1.5 Persistenz durch JDO und Hibernate

Als Persistenz bezeichnen wir in der Informatik die Fähigkeit, Objekte in nichtflüchtigen Speichern wie Datenbanken oder Dateien abzulegen. Eine Persistenzschicht oder ein Persistenz-Framework übernimmt dann die Aufgabe der Speicherung und Reinstanziierung dieser Objekte.

20

Verwendete Umgebung Weder JDO noch Hibernate benötigen für ihren Service einen speziellen Dienst oder Container und können daher in jeder beliebigen VM zum Einsatz gebracht werden. Das schließt kleine eigenständige Applikationen der Java 2 Standard Edition (J2SE) mit ein. Man möchte meinen, dass wir für den Betrieb wenigstens eine Datenbank benötigen, doch auch auf diese können wir verzichten: Ein einfaches Dateisystem genügt.

Ziele dieses Buches

1.2.4 Plattformübergreifende Kommunikation Im vierten Teil dieses Buches widmen wir uns schließlich der Kommunikation, denn diese ist oftmals die Voraussetzung für die Integration unserer Software in bestehende Systeme, besonders wenn diese auf anderen Technologien basieren. Kapitel 9 – Java Message Service (JMS) Das Java Message Service-Interface (JMS) ermöglicht unseren Anwendungskomponenten die asynchrone Kommunikation über Nachrichtenkanäle. Dieses Konzept einer Message-oriented Middleware reicht bis in die achtziger Jahre zurück und ist vergleichbar mit einem E-Mail-System für Applikationen. Kapitel 10 – eXtensible Markup Language (XML) XML, das Schlagwort dieses Jahrzehnts, wenn nicht Jahrhunderts, darf natürlich in einem Buch über J2EE nicht fehlen. In diesem Kapitel werden wir lernen, was sich dahinter verbirgt und wie wir XML-Dokumente in Java erzeugen und manipulieren können. Kapitel 11 – XPath, XSL und Co. Mit unserem erworbenen Wissen um XML werden wir in diesem Kapitel drei der wichtigsten darauf aufbauenden Technologien kennen lernen. Während uns XPath die Navigation in unseren Dokumenten ermöglicht, können wir diese mit der eXtensible Stylesheet Language (XSL) in andere Dokumente umwandeln und mithilfe der Formatting Objects schließlich auch in Druckformate wie PDF oder PostScript rendern. Kapitel 12 – Web Services Mit den Web Services widmen wir uns im letzten Kapitel schließlich einer der jüngsten und derzeit aktivsten Spezifikationen. Sie ermöglicht es Systemen unterschiedlichster Plattformen auf einfache Art und Weise, Dienste und Daten miteinander zu teilen, und stellt somit einen Höhepunkt plattformübergreifender Kommunikation dar.

1.3

Ziele dieses Buches

Natürlich bilden die in diesem Buch besprochenen Technologien nur einen Teil der J2EE-Spezifikation, und eine umfassende Einführung in alle beinhalteten und darauf aufsetzenden Technologien würde mit Sicherheit leicht zehn Bände vom Umfang dieses Buches füllen, genauso wie es zu jedem einzelnen hier besprochenen Kapitel wiederum eigene Bücher gleicher Stärke gibt. Am wichtigsten ist jedoch die sinnvolle Kombination vieler Techniken, um die Vorteile aller nutzen zu können, und so werde ich versuchen, Ihnen die Grundkonzepte und Ideen hinter den hier angesprochenen Themen zu vermitteln und

21

1 Einleitung

es Ihnen ermöglichen, mit diesen zu arbeiten. Im Kommunikationszeitalter mit seinen sich schnell weiterentwickelnden Technologien haben gedruckte Lehrmedien wohl kaum eine Chance, mit dem Fortschritt und der Weiterentwicklung mitzuhalten, und so werde ich Sie an den entsprechenden Stellen auf weiterführende Quellen im Internet verweisen, wo Sie Ihr Wissen vertiefen und den augenblicklichen Stand der Technik verfolgen können. Meiner Meinung nach ist „Learning by doing“ die Methode, die am ehesten zum Erfolg führt. Denn nur wenn Sie selbst Fehler machen (und hinterher bemerken, dass dieser vielleicht nur auf einen Schreibfehler in der Konfigurationsdatei zurückgeht), werden Sie ein Gefühl dafür entwickeln, worauf wir beim Einsatz und der Kombination verschiedener Technologien achten müssen. Wenn Sie die einzelnen Beispiele unserer Kapitel durchgearbeitet haben und mit den Grundkonzepten vertraut sind, werde ich Sie deshalb auch hier auf Tutorials im Internet hinweisen, in denen Sie Beispiele für fast jede Aufgabe finden werden, die Sie mit Ihrem Wissen anschließend an Ihre Bedürfnisse anpassen können. Mein erster und vielleicht wichtigster Tipp an dieser Stelle: Wenn Sie vor einer neuen Herausforderung stehen und ein großes Projekt beginnen wollen, nehmen Sie sich die Zeit und schauen Sie, ob andere vielleicht schon erprobte Lösungen gefunden haben, die Sie weiterentwickeln können. Auf diese Weise müssen wir nicht immer wieder das Rad aufs Neue erfinden, sondern können uns gleich um die Verbesserung des Antriebs kümmern und nehmen somit aktiv an der Entwicklung besserer Standards teil. Gute Startpunkte für die Suche nach bereits existierenden Lösungen sind dabei die Webseiten der Apache Group (http://www.apache.org) und SourceForge (http://sourceforge.net). Diese Empfehlung soll Sie jedoch nicht davon abhalten, eigene Ideen zu verfolgen und neue Standards zu etablieren.

Wie Sie sehen, werden wir uns in diesem Buch aber nicht nur auf die in der Spezifikation genannten Technologien beschränken, sondern diese bei Bedarf um angrenzende Themen erweitern. So sind unsere Web-Applikationen, bestehend aus Java Server Pages, Servlets und Tag-Bibliotheken immer nur so gut wie der Rahmen (das Framework), in dem sie sich bewegen. Und egal, ob Sie diesen nun selbst entwickeln und damit den Informationsfluss ihrer Anwendung von Grund auf bestimmen wollen oder auf ein bestehendes Framework zurückgreifen wollen, werden wir anhand des sehr populären Struts-Frameworks sehen, welche Vorteile gute Frameworks uns bringen und wie sie uns helfen können, „gute“ Anwendungen zu entwickeln. Manchmal gibt es jedoch auch interessante Alternativen zu den von Sun und begleitenden Gremien vorgeschlagenen Techniken, die wir ebenfalls nicht unter den Tisch fallen lassen wollen. Denn nur weil ein Konzept das Produkt einer freien Entwicklergemeinde und nicht das eines Gremiums ist, muss es nicht weniger gut sein. Deshalb werden wir in den Kapiteln über Persistenz und XML auch auf die Produkte solcher freien Entwicklergemeinden eingehen, die vielleicht weniger standardisiert, aber dennoch nicht weniger leistungsstark sind.

1.4

An wen richtet sich dieses Buch?

Vornehmlich richtet sich dieses Buch an den ambitionierten Entwickler, der bereits erste Erfahrungen mit der Programmiersprache Java gesammelt hat und mit deren Elementen und Syntax vertraut ist. Sie haben ja sicherlich schon einige Applets oder kleinere Applikationen geschrieben und wollen nun die Unterschiede serverbasierter Java-Programmierung kennen lernen. Eventuell kommen Sie auch aus einer anderen Programmiersprache und sind bereits mit einigen der hier beschriebenen Konzepte vertraut. In diesem Fall können Sie dieses Buch verwenden, um die Java-Sicht der Dinge zu erfassen und so Ihr bestehendes Wissen zu erweitern.

22

An wen richtet sich dieses Buch?

Oder Sie sind bereits mit einer oder mehreren der hier besprochenen Technologien und Standards vertraut und wollen nun das Zusammenspiel ihrer Komponenten mit anderen Teilen des Frameworks erlernen, um beispielsweise den Datenaustausch Ihrer Web-Applikation mit anderen Systemen zu ermöglichen oder den Zugriff auf Ihre Daten zu optimieren. Damit soll dieses Buch nicht als umfassende Referenz, sondern vielmehr als Lehrbuch dienen, das Sie in die verschiedenen Techniken einführt und auf weiteres Fortbildungsmaterial verweist. Die einzelnen Kapitel bauen dabei zwar logisch aufeinander auf, bilden aber dennoch in sich geschlossene Einheiten und können somit auch einzeln durchgearbeitet werden, etwa wenn Sie bereits über ein entsprechendes Grundwissen in bestimmten Bereichen verfügen oder sich gezielt in ein bestimmtes Gebiet einarbeiten möchten. Neben den bereits oben erwähnten externen Quellen bilden Praxisbücher wie die Codebook-Reihe von Addison Wesley eine interessante Alternative zu den meist in englischer Sprache verfassten Internet-Tutorials. Beide dienen weniger der Vermittlung von Konzepten und Ideen, sondern zeigen an einfachen und erweiterbaren Praxisbeispielen, wie die besprochenen Technologien einzusetzen sind.

1.4.1 Welche Voraussetzungen müssen Sie mitbringen? Wie gesagt, soll es sich bei dem vorliegenden Buch vornehmlich um ein Lehrbuch handeln, das kein Vorwissen zu den hier besprochenen Themen voraussetzt. Ich werde versuchen, alle neu eingeführten Begriffe anhand eines kleinen Beispiels oder einer Analogie aus dem Alltag zu erklären, um Ihnen eine anschauliche Vorstellung zu vermitteln. Nichtsdestotrotz ist dies kein Buch über das Programmieren im eigentlichen Sinne und da J2EE auf der Java 2 Standard Edition aufsetzt, werde ich die Kenntnis ihrer Elemente und der Konzepte objektorientierter Programmierung voraussetzen. (Wenn Sie nicht über diese verfügen, hat ihr favorisierter Buchhändler bestimmt etwas Passendes im Angebot.) Auch das für die Entwicklung dynamischer Webseiten benötigte Wissen über HTML werden wir als bekannt voraussetzen, wobei die Beispiele in dieser Sprache sehr einfach gehalten sind und nicht mehr als einige Grundkenntnisse erfordern. Schließlich wollen wir neue Technologien kennen lernen und uns nicht im Interpretieren von Webseiten üben. Ebenso sollte XML zumindest in den Grundzügen bekannt sein.

Obwohl wir das Wissen um die Konzepte objektkorientierter Programmierung voraussetzen, werden wir diese natürlich an gegebener Stelle um neue Aspekte erweitern und unsere Sichtweise auf diese ausdehnen.

Ich möchte Sie an dieser Stelle ermutigen: Nutzen Sie die zur Verfügung gestellten JavaDocs, um mehr über die verwendeten Klassen und Ihre Möglichkeiten zu erfahren. Denn während wir hier über Standardverfahren sprechen werden, die Ihnen zwar auch den Weg zu Ziel ermöglichen, bieten viele Klassen und Interfaces zusätzliche Methoden an, die oftmals eine schnellere und elegantere Lösung für konkrete Anforderungen bieten. Aus diesem Grund werde ich bei allen verwendeten Klassen und Interfaces eine Angabe zum Package machen.

23

1 Einleitung

1.4.2 Disclaimer Wie gesagt werde ich versuchen, Sie auf verschiedene externe Quellen wie das Internet zu verweisen, durch die Sie Ihr Wissen erweitern und vertiefen können. Da das Internet einen stetigen Wandel unterzogen ist, ist es nicht möglich, zu garantieren, dass die angegebenen Verweise stets aktuell sind. Mitunter kommt es auch vor, dass eine Adresse überhaupt nicht mehr auffindbar ist. Wenn Sie sich für die verschiedenen Open SourceLizenzen und ihre Bestimmungen interessieren, empfehle ich Ihnen die Webseite http:// www.opensource.org/licenses/ der Open Source-Initiative (OSI).

Und noch einen Punkt möchte ich kurz erwähnen (um auch in Zukunft ruhig schlafen zu können): Dies ist kein Lehrbuch für Juristen, sondern eine praktische Einführung für Programmierer. Da ich den Einsatz von Open Source-Technologien stark befürworte und deshalb auch verschiedene dafür vorgesehene Lizenzen beschreibe und vergleiche, möchte ich darauf hinweisen, dass diese Ausführungen und Vergleiche keinen Anspruch auf Richtig- oder Vollständigkeit erheben, sondern lediglich den Dschungel aus Abkürzungen und Begriffen etwas lichten sollen. In jedem Fall gilt die der jeweiligen Software beiliegende Lizenz und wie heißt es doch so schön: Fehler und Irrtümer sind nicht ausgeschlossen.

1.5

Bezug und Installation der Basis-Software

Bevor wir uns aber ins Vergnügen stürzen, wollen wir uns kurz dem Bezug und der Installation der Basis-Software für dieses Buch widmen. Denn während wir einige Software-Komponenten nur für bestimmte Kapitel benötigen und deren Installation verständlicherweise auch nur dort besprechen, tauchen andere an vielen Stellen auf. Deren Installation wollen wir hier besprechen und damit für alle beteiligten Kapitel gemeinsam abhandeln.

1.5.1 Java 2 Plattform Enterprise Edition (J2EE) Die aktuelle Version der Enterprise Edition lautet J2EE 1.4 Standard Development Kit (SDK). Da Sun die Versionsbezeichnung mit der gerade neu erscheinenden Standard Edition 5 ändert, bleibt abzuwarten, welche Versionsnummer die meist ein halbes Jahr später folgende Enterprise Version trägt.

Dieses API bildet natürlich den Grundstein für (fast) alles. Wir können dieses Produkt von der Homepage http://java.sun.com/j2ee/ für viele Plattformen herunterladen und in der Regel problemlos installieren. Hier finden wir auch die ersten weiterführenden Tutorials sowie die Dokumentation, die wir der Unabhängigkeit halber am besten gleich mit installieren. Die nach der Installation auf unserem System existierende Bibliothek j2ee.jar muss anschließend nur noch in unseren ClassPath eingebunden werden und schon können wir loslegen.

1.5.2 Die Wahl der „richtigen“ Entwicklungsumgebung (IDE) Um sich bei der Entwicklung ihrer Applikation unterstützen zu lassen, verwenden viele Programmierer statt eines einfachen Editors eine integrierte Entwicklungsumgebung (engl. Integrated Development Environment, IDE). Die Empfehlung einer solchen kommt für einen Autor dem Lauf über ein Minenfeld gleich, denn die Wahl der „richtigen“ IDE rangiert auf der Rangliste von Programmierern

24

Bezug und Installation der Basis-Software

geführter Flame Wars gleich hinter „dem einzig richtigen Betriebssystem“ oder „der einzig richtigen Programmiersprache“. Meine Devise zu diesem Thema lautet „Jedem das Seine“ und wenn Sie bereits Ihre ultimative Programmier-Umgebung gefunden haben, dann meinen allerherzlichsten Glückwunsch dazu. Sollte hingegen der unwahrscheinliche Fall eintreten, dass sie noch keinen Favoriten haben, schauen sie doch mal bei der Eclipse Foundation (http://www.eclipse.org) vorbei. Die gleichnamige, aus einem IBM-Projekt hervorgegangene Entwicklungsumgebung unterstützt viele Programmiersprachen und ist obendrein als Open Source verfügbar.

1.5.3 Ant – Jeder Aufgabe ihre Ameise Ein weiteres interessantes und empfehlenswertes Projekt ist Apaches Ant (http:/ /ant.apache.org). Hinter Ant (engl. für Ameise) verbirgt sich ein nahezu allmächtiges Übersetzungswerkzeug, das wir unter anderem zum Kompilieren unserer Projekte verwenden können. Zu jedem Beispiel der beiliegenden CD werden sie ein Ant-Konfigurationsfile (build.xml) finden, welches das Übersetzen dieses auf den Aufruf:

Als Flame War (engl. to flame, aufflammen) bezeichnet man eine kontroverse Diskussion, bei der die Teilnehmer ihre Meinungen und Einstellungen zu bestimmten Dingen oft auf eine unsachliche oder beleidigende Weise als gegebene „Tatsachen“ darstellen. Ort für diese sind häufig einschlägige Chatforen und Newsgroups, obwohl inzwischen sogar eine eigens dafür geschaffene Newsgroup existiert. Wer also richtig Lust auf sinnlosen Streit über Computer und andere Dinge hat, wird unter de.alt.flame fündig.

,39

im lokalen Ordner reduziert. Da auch Ant vollständig in Java geschrieben ist, beschränkt sich die Installation auch hier auf die Schritte Herunterladen, Auspacken und Starten.

1.5.4 Apaches Tomcat – Ein Kater erobert das Netz Auch bei unserem Webserver greifen wir auf ein Apache-Projekt zurück: Der Tomcat (http://jakarta.apache.org/tomcat/) ist einer der populärsten Webserver und soll uns dazu dienen, das Ergebnis unserer Servlets und JSPs zu demonstrieren. Er wird über die Datei server.xml konfiguriert, deren vorkonfigurierte Minimalversion ebenfalls auf der CD enthalten ist.

1.5.5 JBoss – Einer für alles Während wir für den ersten Teil dieses Buches lediglich einen Webserver benötigen, brauchen wir für die Demonstration unserer Enterprise JavaBeans sowie des Java Message Services einen vollwertigen Application Server. Die Wahl ist dabei auf den ebenfalls sehr populären und frei verfügbaren JBoss (http:// www.jboss.org) gefallen. Dieses aus einem SourceForge-Projekt hervorgegangene Produkt enthält einen integrierten Apache Tomcat, über den es in der Lage ist, Servlets und JSPs auszuliefern, und kann ebenso wie dieser über verschiedene XML-Dateien konfiguriert werden. Auch er ist auf der beiliegenden CD enthalten.

25

2 Java Server Pages Dieses Kapitel soll sie in die Lage versetzen, Ihre statischen HTML-Seiten in dynamische Java Server Pages zu verwandeln. Wir werden Java-Elemente ähnlich einer Scriptsprache in unsere Dokumente integrieren, um etwa das Aussehen oder das Verhalten dieser von äußeren Bedingungen abhängig zu machen. Java Server Pages sind eine von Sun Microsystems entwickelte Technologie, um Java-Code zwischen HTML-Elementen einzubetten und zum Zeitpunkt der Benutzeranfrage auf dem Server auszuführen. Wir können JSPs somit als Suns Alternative zum Common Gateway Interface (CGI), PHP oder den Active Server Pages von Microsoft verstehen. Um Inhalt im Internet verfügbar zu machen, benötigen wir einen so genannten Webserver. Das ist ein Programm, das auf einem am Internet angeschlossenen Computer läuft und Dateien, wie Webseiten und Bilder, zur Verfügung stellt. Ein einfacher Webserver ist dabei zunächst nur in der Lage, von ihm verwaltete Dateien auf Anfrage auszuliefern. Damit unser Webserver auch den Java-Code unserer Webseite zur Ausführung bringen kann, müssen wir ihn mit einer Java Virtual Machine (JVM), dem so genannten Servlet-Container ausstatten. Ein solches Gespann aus Webserver und Servlet-Container ist beispielsweise der Apache Tomcat, den wir aber nachfolgend der Kürze wegen nur noch als Webserver bezeichnen werden. Bevor wir jedoch eigene Web-Applikationen entwickeln können, müssen wir das Zusammenspiel von Browser, Internet und Webserver verstehen.

2.1

Web-Applikationen gestern und heute

Was ist eigentlich das Internet? Was wir unter dem Begriff Internet in der Regel verstehen, ist der weltweit größte Zusammenschluss von Computern, welche all die von uns inzwischen für unverzichtbar gehaltenen Dienste wie das World Wide Web (WWW) oder E-Mail anbieten. Jeder ans Internet angeschlossene Computer, egal ob Server oder Privat-PC, ist dabei im gesamten Internet unter

27

2 Java Server Pages

einer eindeutigen Nummer bekannt und kommuniziert mit den anderen Rechnern über das TCP/IP-Protokoll. Über die Geburtsstunde des Internets gibt es verschiedene Auffassungen: Basierend auf dem ARPANet des amerikanischen Militärs Ende der 60er Jahre wurde es 1973 mit der Einführung des heute noch verwendeten TCP/IP-Protokolls auf seine Füße gestellt.

Richtig populär wurde das Internet jedoch erst mit der Einführung von HTTP, wodurch jedermann leicht Zugang ins Netz der Netze findet. Das Hypertext Transfer Protocol (HTTP) 1989 entwickelte Tim Berners-Lee am CERN, dem europäischen Kernforschungslabor in Genf, ein Übertragungsprotokoll, das den dort arbeitenden Wissenschaftlern den Zugang zu Informationen erleichtern sollte. HTTP basierte auf Anwendungsebene, war in gewissem Maße objektorientiert und funktionierte nach einem simplen Frage/Antwort-Schema. Es definiert lediglich, wie Daten von einem Rechner (Server) auf einen anderen (Client) zu übertragen sind. Dazu werden diese Daten in einzelne, kleine Teilpakete gepackt, wie bei der Post mit einer Adresse versehen und auf die Reise geschickt. Der Empfänger (Client) muss die empfangenen Pakete dann nur noch in der richtigen Reihenfolge aneinander fügen und schon hat er die Antwort. Aufgrund diesen einfachen Prinzips erfreute sich HTTP schnell wachsender Beliebtheit, doch da wohl keiner der beteiligten Wissenschaftler etwas von dessen Einsatz für sekundengenaue Börsendaten, authentifiziertes Onlinebanking, Chatforen und unternehmensweite Intranet-Applikationen ahnte, müssen wir einige seiner Beschränkungen heute mit diversen Konventionen umgehen.

Was ist ein Protokoll? Nun stellen Sie sich einmal vor, Sie wären beim norwegischen Kronprinz Haakon Magnus und seiner Frau Mette-Marit zum Dinner eingeladen. Dann würde das Hofprotokoll vorschreiben, dass der Kronprinz Sie zuerst begrüßt, Sie dann zurückgrüßen, sich verneigen können usw. Ein Protokoll bestimmt also den Ablauf der Kommunikation und nicht ihren Inhalt.

Dabei ist HTTP bei weitem nicht das einzige Protokoll, über das Computer miteinander kommunizieren. Viele Kommunikationsprotokolle, wie beispielsweise das bekannte File Transfer Protocol (FTP), setzen dabei allerdings eine feste Verbindung zwischen den Kommunikationspartnern voraus. Dadurch kann der Server zu jedem Zeitpunkt feststellen, an wen er im Augenblick Daten übermittelt und ob der Aufbau einer weiteren Verbindung möglich ist. Diese Protokolle werden deshalb auch als Zustandsprotokolle oder Stateful Protocols bezeichnet. Im Gegensatz dazu verpflichtet HTTP als zustandsloses Protokoll den Server dazu, auf jede eingehende Anfrage (Request) mit einer Antwort (Response) zu reagieren, auch wenn die Antwort lediglich aus einem Abweisen des Clients besteht. Zustandlose Protokolle benötigen wesentlich weniger Ressourcen als Zustandsprotokolle. Dafür „vergisst“ der Server jede Übertragung und damit auch den beteiligten Rechner, sofort nachdem er sie abgeschlossen hat. Schauen wir uns nun eine solche Übertragung an. Der Request – Eine Seite anfordern Haben Sie heute schon die Nachrichten im Newsticker Ihrer Wahl gelesen oder sich die Java-Dokumentation auf der Webseite von Sun angeschaut? Die Informationsgesellschaft benötigt stets aktuelle Informationen und das rund um die Uhr, weltweit.

28


Doch was passiert eigentlich, wenn wir in unserem Browser eine URL wie z.B. http://www.dwd.de (Deutscher Wetterdienst) eingeben und so ein Dokument aus dem Internet anfordern? Nun, zunächst wird der Browser über das so genannte Domain Name System (DNS) die Nummer des Servers ermitteln, der sich hinter dem von uns angegebenen Namen (z.B. dwd.de) verbirgt. Wir können uns das DNS damit als so etwas wie das Telefonbuch des Internets vorstellen und brauchen uns darüber keine Gedanken mehr zu machen.

Das Domain Name System (DNS) ist der meistgenutzte Dienst des Internets überhaupt. Er dient dazu, symbolischen Servernamen wie www.dwd.de die tatsächlichen IP-Adressen (141.38.3.62) zuzuordnen.

Nachdem der Browser den Server auf diese Weise ermittelt hat, sendet er unseren Request an diesen, gepackt in kleine Pakete. Ein solcher Request könnte beispielsweise folgende Form haben: *(7 LQGH[KWPO +773 8VHU$JHQW 0R]LOOD $FFHSW LPDJHJLI LPDJH[[ELWPDS LPDJHMSHJ $FFHSW/DQJXDJH GH HQXV $FFHSW(QFRGLQJ J]LS GHIODWH

Listing 2.1 Ein HTTP-Request

Ein HTTP-Request beginnt stets mit einer Zeile, die drei Informationen enthält: 1. die Anfragemethode (*(7), 2. die angeforderte Ressource (LQGH[KWPO), 3. die vom Client verwendete Version des HTTP-Protokolls (+773). Damit teilen wir dem Server mit, welche Ressource wir benötigen und versetzen ihn in die Lage, uns zu antworten. Manchmal ist es jedoch ratsam, dem Server zunächst auch etwas von sich preiszugeben, damit dieser seine Antwort optimal auf uns zuschneiden kann. Informationen dieser Art könnten beispielsweise der von uns verwendete Browser (z.B. Mozilla), unsere bevorzugten Sprachen (z.B. Deutsch und Englisch) oder die von uns unterstützten Komprimierungsverfahren (z.B. ZIP) sein. Für solche Informationen sieht das HTTP-Protokoll Request-Header vor. Das sind vom Browser übermittelte Meta-Informationen der Form: +HDGHU1DPH :HUWB$ :HUWB%

Diese werden immer direkt im Anschluss an die initiale Zeile übermittelt. Nun haben wir dem Server alle Informationen gegeben, die er benötigt, um unserem Wunsch optimal nachkommen zu können. Unsere Request-Header sind übrigens nicht zu verwechseln mit den RequestParametern. Diese dienen dazu, den Wert bestimmter Variablen zu setzen und einen allgemeinen Request in einen mit eindeutigen Merkmalen zu versehen. Wenn wir beispielsweise die Suchmaschine Google aufrufen wollen, lautet die URL http://www.google.de/. Wollen wir unsere Suchmaschine nun dazu verwenden, nach bestimmten Begriffen zu suchen, und geben beispielsweise 0DVWHU FODVV in das Eingabefeld ein, so werden wir nach Betätigen des Such-Buttons an die Seite VHDUFK weitergeleitet, deren URL etwa folgende Form haben kann: KWWSZZZJRRJOHGHVHDUFK"T 0DVWHUFODVV

Als Ergebnis erhalten wir eine etwas abgewandelte Version der ersten Seite, die nun das Ergebnis unserer Suche enthält. Der Parameter q (wie Query) gibt der

29

2 Java Server Pages

Suchmaschine also an, nach welchem Begriff wir suchen. Fehlt dieser, so wird uns ein leeres Standardformular präsentiert, um die Eingabe der Request-Parameter zu erleichtern. Request-Parameter sind also dokumentspezifische Variablen, die vom Server gezielt ausgelesen werden können, während Request-Header Informationen über uns und unseren Browser enthalten. Der Response – Ein Server antwortet Jeden empfangenen Request quittiert der Server mit einem Response. Dieser beginnt ebenfalls mit einer Statuszeile, die uns (bzw. unserem Browser) die Informationen liefert: 1. die vom Server verwendete HTTP-Version, 2. einen numerischen Statuscode, der uns die Art der Antwort mitteilt, 3. eine kurze Statusbeschreibung in Textform. Die beiden bekanntesten Vertreter der Response-Statuszeilen sind wohl:

bzw.

Auf diese Statuszeile folgen wiederum beliebig viele Response-Header, die analog zu den Request-Headern den nachfolgenden Inhalt, wie beispielsweise den Dokumenttyp, und schließlich den gewünschten Inhalt (also das Dokument) selbst beschreiben. Listing 2.2 Ein HTTP-Response

!" # !"$ #%"$ "" & '"#%"$ #( $ "" & '"#( $ # !"$

Hypertext Markup Language (HTML) – die Darstellung Nachdem unser Browser alle Pakete empfangen und richtig aneinander gesetzt hat, muss er den übermittelten Inhalt nun auch noch korrekt darstellen. Zunächst überprüft er dazu den empfangenen Status des Dokumentes. Ist die von uns angeforderte Seite beispielsweise „umgezogen“ und nun unter einer neuen Adresse erreichbar, sendet der Server den Statuscode ) * + '!",, der den Browser, von uns unbemerkt, dazu veranlasst; einen neuen Request zu stellen. Moderne Browser wie der Internet Explorer interpretieren auch Fehlercodes wie * , und stellen eine eigene Seite mit Hinweisen zur Fehlerbehebung dar. In den allermeisten Fällen antwortet der Server jedoch mit dem Status * ,, der dem Browser mitteilt, dass das Dokument erfolgreich ausgeliefert werden konnte. Jetzt interpretiert der Browser die vom Server empfangenen MetaInformationen (Response-Header), um Hinweise über das Dokument, z.B. die Art, zu erhalten. Anschließend beginnt er mit der Darstellung der Seite.

30


Um die Seite korrekt darstellen zu können, muss sie vom Server in einer für den Browser verständlichen Sprache verfügbar gemacht werden. Eine von allen Browsern verstandene Sprache ist HTML, die Tim-Berners Lee bei seinen Arbeiten am CERN gleich mit erfand. Als Markup Language (Auszeichnungssprache) bezeichnet man eine Sprache, die neben der reinen Textinformation auch Informationen über die Darstellung des Inhaltes enthält. Diese Struktur-Informationen bestehen aus so genannten Tags (Marken, Kennzeichen) und bezeichnen bestimmte Elemente wie Überschriften, Tabellen, Absätze etc. unseres Dokuments. Ein Tag besteht dabei aus einem Paar spitzer Klammern !, die den Namen und Attribute des Tags umschließen. Aus dem Namen erschließt sich für den Browser die Funktion des Tags („Hier kommt eine Überschrift“), die durch Attribute des Tags noch konkretisiert werden kann („Die Überschrift ist grün“).

Der Name Hypertext (griech. „hyper“, „über“) leitet sich übrigens aus der Eigenschaft ab, dass der Text auf ein anderes Dokument verweisende Textpassagen enthalten kann. Diese „dahinter liegenden“ Seiten geben dem Text damit in gewisser Weise die Dimension der „Tiefe“.

IRQW FRORU JUHHQ IDFH DULDO! 'LHVHU 7H[W ZLUG JUQ XQG LQ GHU 6FKULIWDUW $ULDO GDUJHVWHOOW IRQW!

Der Markup definiert letztendlich die Anordnung des Textes und der Bilder und wird in der Regel nicht dargestellt. Über die Funktion SEITENQUELLTEXT ANZEIGEN können wir jedoch auch einen Blick auf das vollständige Dokument werfen. Das Ergebnis Das alles geschieht für uns meist völlig unbemerkt, wenn wir uns z.B. bei unserer morgendlichen Tasse Kaffee nebenbei über das Wetter informieren. Abbildung 2.1 Was für ein Wetter ...

31

2 Java Server Pages

2.2

Einrichten unserer Web-Applikation

Nachdem wir nun eine Vorstellung von den Dingen haben, die passieren, um ein Dokument im Browser darzustellen, werden wir nun unsere eigene WebApplikation entwickeln. Da wir dies in der Regel nur mit einem Rechner tun werden, muss dieser sowohl die Rolle des Clients als auch die des Servers übernehmen. Für den Computer ist dies kein Problem, aber unser Verständnis kann sich noch ein wenig dagegen sträuben, dass ein Computer quasi eine Anfrage an sich selbst stellt, darauf antwortet und den von sich selbst empfangenen Inhalt z.B. in einem Webbrowser darstellt. Um unsere grauen Zellen zu entlasten, können wir uns vorstellen, dass wir immer, wenn wir keinen Browser darstellen, unseren Rechner als Server betrachten, der Anfragen von beliebigen Clients beantworten kann. Das Browserfenster zeigt uns schließlich das Resultat unserer Arbeit beim Endnutzer. Zunächst jedoch müssen wir uns eine Arbeitsumgebung schaffen, in der wir unsere Web-Applikation erstellen wollen. Die Beschreibung unserer Applikation (web.xml) Damit unser Webserver (Tomcat) die von uns erzeugte Applikation im Netz verfügbar machen kann, muss er unter Umständen bestimmte Initialisierungen vornehmen. Als Ablageort für diese Setup-Informationen dient der so genannte Web Deployment Descriptor in der Datei web.xml. Typischerweise werden bei der Installation des Tomcat bereits eine oder mehrere solcher Dateien angelegt. Auch wenn wir zunächst noch keine Initialisierungen vornehmen, benötigt unser Server diese Datei, dennoch um sicherzustellen, dass er zunächst nichts zu konfigurieren braucht. Listing 2.3 zeigt einen Web Deployment Descriptor, den wir als Ausgangspunkt verwenden wollen. Listing 2.3 Web Deployment Descriptor

!"# $%&'' "()* ++, - . / 0 ++ 1% 2'' &/ 34++#5 6//'7++8&& , +/+$%&''9394/ $%&'' '&. &1 / :3##-& /& + '&. & '/ 1 / :3##-& /& + '/ +$%&''

Unser Deployment Descriptor enthält also im Moment nur den fiktiven Namen unserer Applikation ( '&. &) sowie eine kurze Beschreibung ( ' / ). In den Kapiteln 3 und 4 werden wir ihn jedoch Stück für Stück ausbauen.

32

Einrichten unserer Web-Applikation

Anlegen eines Arbeitsverzeichnisses In Kapitel 1 haben wir besprochen, wie wir unseren Apache Tomcat installieren. Als Nächstes benötigen wir ein Arbeitverzeichnis, das zum Beispiel so aussehen könnte: Abbildung 2.2 Unser Arbeitsverzeichnis

Diese Ordner enthalten folgende Dokumente: T css – In diesem Ordner können wir unsere Cascading Stylesheets (.css) ablegen. T html – Dieser Ordner nimmt unsere statischen HTML-Dokumente auf. T images – In diesem Ordner speichern wir unsere Bilder. T jsp – Dieser Ordner enthält schließlich unsere dynamischen Dokumente. T WEB-INF – Dieser Ordner enthält den Web Deployment Descriptor und wird von unserem Webserver an genau dieser Stelle erwartet. Einbinden der Applikation in den Apache Tomcat Nachdem wir unseren Tomcat installiert haben, müssen wir ihm natürlich noch mitteilen, dass eine neue Web-Applikation existiert, wo diese liegt und unter welcher URL sie erreichbar sein soll. Dazu editieren wir die Datei server.xml im conf-Verzeichnis unseres Tomcat und fügen folgenden Context ein. !" ! #

Damit ist unsere Applikation im Netz unter der URL http://localhost:8080/ JSPs_02/ verfügbar. Über das Attribut teilen wir Tomcat mit, mit welchem tatsächlichen Pfad im lokalen Dateisystem er diese URL verknüpfen soll.

Achtung Vergessen Sie das schließende # am Ende des Tags nicht. Der Tomcat wird uns sonst den Dienst verweigern.

Listing 2.4 Das Tomcat-Context-Element

Der Servername localhost steht stellvertretend für die IP-Adresse 127.0.0.1, die für unseren eigenen Rechner reserviert ist. Wenn wir also im Browser nach diesem Server suchen, rufen wir stets Dienste auf unserem eigenen Rechner auf, der in diesem Fall Server und Client ist.

Das war es! Nun müssen wir unseren Tomcat lediglich neu starten und schon steht uns unsere Applikation bereit.

33

2 Java Server Pages

2.3

Statisches HTML

Um die Funktionsweise unseres Webservers zu demonstrieren und um einer langen Tradition zahlreicher Computerbücher zu folgen, beginnen wir zunächst mit einer statischen Webseite, die als Ausgangspunkt für unsere JSPs dienen soll. Listing 2.5 Eine statische HTML-Seite

HTML unterscheidet im Gegensatz zu den später beschriebenen dynamischen Elementen nicht zwischen Groß- und Kleinschreibung.

! " #$!%&& '

'

"' "' " " ()*" " "' "' +!,' -! ! !.%"" -". ' ""'("

! /! ""' 0 '

'/

1! " " 23)" ' 0 ' -!' +!,' '

Diese Seite enthält nur statischen Markup, also Tags, die dem Browser Informationen über das gewünschte Aussehen des Inhalts geben. Sie wird von unserem Webbrowser interpretiert und führt zu dem in Abbildung 2.3 gezeigten Resultat. Abbildung 2.3 Eine statische HTML-Seite

Um den Unfang dieses Buches in einem den Leser motivierenden Rahmen zu halten, verzichten wir an dieser Stelle auf eine umfassende Einführung in HTML. Hierfür möchte ich Sie beispielsweise auf das SelfHtml-Projekt unter http://de.selfhtml.org/ verweisen oder Ihnen das Buch „HTML & CSS lernen“, erschienen im Addison-Wesley Verlag, nahe legen.

34

Achtung Die erste Zeile in Listing 2.5 ist kein Bestandteil von HTML, sondern gibt den Standort einer so genannten Document Type Definition (DTD) an. DTDs definieren eine Grammatik für die verwendete Sprache (hier HTML) und bestehen, analog zur deutschen Grammatik, aus einem Satz von Regeln über die Verwendung der Elemente. Unser Browser kann die in der DTD hinterlegten Informationen nutzen, um das Dokument zu überprüfen. Die Seite wird aber auch ohne DTD korrekt dargestellt. Daher kann man in der Praxis meist darauf verzichten.

Die erste dynamische HTML-Seite

2.4

Die erste dynamische HTML-Seite

Ohne die Möglichkeit, dynamischen Inhalt in den Markup einzufügen, wären wir gezwungen, für jede von uns gewünschte Seite ein solches HTML-Dokument zu erzeugen. Als Nächstes wollen wir unserer Seite noch ein „Quasi-Geburtsdatum“ mitgeben: Datum und Uhrzeit sollen den Zeitpunkt der Auslieferung unserer Seite festhalten – ohne dynamische Elemente unmöglich. Das Listing 2.6 liefert das gewünschte Resultat. ! " #$!%&& '

'

"' "' " ( " )**" " "' "' +!(' ,! ! !-%"" ,"- ' ""'."

! /! ""' 0 '

'/

1! " " )23" '

' 4"5 %"0 6- " 470 "896' ' 0 ' ,!' +!(' '

Listing 2.6 Unsere erste JSP

Abbildung 2.4 Unsere erste JSP

Das ist Ihre erste dynamische JSP! Schauen wir uns den Quellcode einmal genauer an. Zu unserem strukturierenden HTML-Markup ist ein neues Element hinzugekommen, das offensichtlich den dynamischen Inhalt (in unserem Fall das aktuelle Datum) in den HTML-Quelltext einfügt. Wenn wir dieses Element mit dem folgenden Java-Code-Fragment vergleichen, das das aktuelle Datum auf der Kommandozeile ausgibt, erkennen wir deutlich die Analogie. *(" !0# 8 4"5 %"0 : " 470 "899;

Listing 2.7 Ausgabe des aktuellen Datums auf der Kommandozeile

In beiden Listings wird zur Laufzeit ein neues "-Objekt erzeugt, mit der statischen Zeichenkette 4"5 %"0 verknüpft und anschließend ausgegeben.

35

2 Java Server Pages

Der Webserver führt über das JSP-Tag ! die von ihm umschlossene JavaAnweisung zum Zeitpunkt des Requests aus und fügt das zurückgegebene Objekt unter Verwendung der WR6WULQJ -Methode in die Ausgabe ein. Java nimmt uns damit also das explizite Schreiben der Anweisung ab, den immer wenn ein Objekt (MDYDODQJ2EMHFW einem MDYDLR2XWSXWVWUHDP oder MDYDLR:ULWHU übergeben wird, ruft Java automatisch die Methode WR6WULQJ auf, um dessen Ausgabe zu erzeugen. OL!(V LVW MHW]W JHQDX

2.5

QHZ MDYDXWLO'DWH WR6WULQJ !OL!

Die Bausteine einer JSP

Nach unserem jetzigen Wissenstand ist eine JSP also nichts anderes als eine um „besondere“ Tags erweiterte HTML-Seite, die die dynamischen Inhalte in unser Dokument einfügen. Diese Tags unterteilen sich in vier Klassen, deren Verwendungszweck Ihnen dieser Abschnitt näher bringen soll. T Ausdrücke der Form -DYD$XVGUXFN HLQH -DYD$QZHLVXQJ ! T Scriptlets der Form -DYD&RGH ! T Deklarationen der Form -DYD&RGH ! T Kommentare der Form -63.RPPHQWDU ! oder +70/.RPPHQWDU !

2.5.1 JSP-Ausdrücke Diese Art Markup haben Sie schon kennen gelernt. Er besteht aus einer einzigen, die Ausgabe produzierenden Java-Anweisung und wird zum Zeitpunkt eines Requests stets aufs Neue ausgeführt. JSP-Ausdrücke (Expressions) haben die Form -DYD$QZHLVXQJ ! und werden, wie es das Gleichheitszeichen ( ) bereits andeutet, durch die Ausgabe der Anweisung ersetzt. Sie dienen in erster Line dazu, Werte direkt in die Ausgabe einzufügen.

Achtung Die Java-Anweisungen in JSP-Ausdrücken werden nicht mit einem Semikolon abgeschlossen. Sie sind allein schon deswegen auf eine einzige Anweisung beschränkt. Als Gedächtnisstütze können wir uns merken, dass wir alle Anweisungen, die wir in das Java-Code-Fragment: 6\VWHPRXWSULQWOQ §+LHU VWHKW VSlWHU ,KUH $QZHLVXQJ¨

einfügen können, auch in einem JSP-Ausdruck verwenden können.

36


Vordefinierte Variablen in einer JSP Nun gibt es vergleichbar wenige Ausdrücke, die als einzelne Anweisung formuliert ein brauchbares Ergebnis liefern und damit wären JSP-Ausdrücke außer zur Darstellung von kontextunabhängigen Variablen wie Datum und Uhrzeit ziemlich unbrauchbar. Doch JSP-Ausdrücke haben unter anderem auch Zugriff auf folgende, vom Webserver bereitgestellte Variablen: T

: Hinter dieser Variable verbirgt sich die Anfrage (vom Typ ), die die Seite angefordert hat. Der Request liefert den Zugriff auf die in Abschnitt 2.1 beschriebenen RequestHeader (Accept-Language, User-Agent usw.).

T

(Typ ): Diese Variable ermöglicht es Ihnen, die Antwort des Servers an den Client zu modifizieren. Durch diese Variable können Sie beispielsweise Status-Codes setzen oder Response-Header modifizieren.

T : Diese Variable stellt nichts anderes als den zuvor beschriebenen Writer vom Typ dar, den der Server verwendet, um seine Ausgabe an den Client zu senden. Keine Angst, wenn Ihnen die Mächtigkeit dieser Variablen noch verborgen ist. Wir werden in Abschnitt 2.6 noch einmal näher auf diese und andere vordefinierte Variablen eingehen. Lassen Sie uns nun unsere erste JSP um die Ausgabe eines optionalen RequestParameters ergänzen, um die Verwendung der vordefinierten Variablen in JSPAusdrücken zu demonstrieren.

! "#$% &''()*''++ ! ,- ''& & .''(((() /'' ! ,-' *++&0

! 0 +0 0 +1!* ' 0 ' +0 2+10 3 * 4&/ & 3*4& &0 * 0 +'* 0 0 0 5!! + 6 7 ' 0 0 8 / 94 ( :; 90' 0 0 +. 94 / ! :&!&;90' 0 ' 0 '30 '2+10 ' ! 0

Listing 2.8 Verwendung von vordefinierten Variablen

37

2 Java Server Pages

Der Browser hat die Möglichkeit, an seine Anfrage bestimmte Daten, etwa die Werte aus HTML-Formularfeldern, anzuhängen. Diese Daten erscheinen je nach Anfragemethode (POST oder GET) entweder in der Adresszeile des Browsers oder werden in einem versteckten, dem Benutzer nicht sichtbaren Feld des Dokumentes abgelegt und können vom Server über das -Objekt ausgelesen werden, was zu der Ausgabe in Abbildung 2.5 führt: Abbildung 2.5 Ausgabe eines HTTP-Parameters

Listing 2.8 zeigt eine weitere Analogie zur Java-Welt. Wir können das Objekt offensichtlich so verwenden, als würde es sich hierbei um eine lokale Variable handeln, die wir zuvor erzeugt haben. Um einen Eindruck von den Möglichkeiten zu bekommen, die sich uns durch diese vordefinierte Variable erschließen, empfehle ich Ihnen an dieser Stelle, die JavaDocs der Klasse zu konsultieren.

Achtung Wenn nicht nur die resultierenden HTML-Seiten, sondern auch ihre JSPs (also ihre Ausgangsdokumente) XML-konform sein müssen, gibt es eine alternative Notation für JSP-Ausdrücke. Statt ! " können wir auch folgende Notation verwenden Listing 2.9 Alternative Syntax für JSP-Ausdrücke

# " !$# "

Dabei sind jedoch zwei Dinge zu beachten: Zum einen darf der verwendete Java-Ausdruck auch hier nur aus einer einzigen Java-Anweisung bestehen, die nicht mit einem Semikolon abgeschlossen wird, und zum anderen wird bei den Tags # " im Gegensatz zu den HTML-Tags zwischen Groß- und Kleinschreibung unterschieden. Im Folgenden werden wir bis auf weiteres jedoch die nach Meinung des Autors intuitivere Standard-Notation ! " verwenden. Zusammenfassend können wir uns also merken, dass JSP-Ausdrücke dazu dienen, dynamische Inhalte in unsere HTML-Seite einzufügen. JSP-Ausdrücke sind das Pendant zur -Anweisung in Java.

38


2.5.2 JSP-Scriptlets JSP-Ausdrücke werden durch die vordefinierten Variablen zwar aufgewertet und durch die mehrfache Verwendung von JSP-Ausdrücken können wir mehrzeilige Ausgaben erzeugen, doch um sinnvoll arbeiten zu können, benötigen wir in der Regel einiges mehr. Als da wären: T eigene lokale Variablen, um z.B. Zwischenergebnisse oder Parameterwerte zu speichern, T Entscheidungen ( ), um das Verhalten unserer JSP an äußere Bedingungen zu knüpfen, T Schleifen, um unsere Anweisungen für eine unbekannte Anzahl gleicher Elemente zu wiederholen. Hier kommen die JSP-Scriptlets ins Spiel. JSP-Scriptlets haben die Form und ermöglichen es uns, eine beliebige Folge von Java-Befehlen zu definieren. Sie können überall dort in die HTML-Seite eingefügt werden, an der auch ein JSP-Ausdruck stehen könnte, besitzen jedoch einen großen Unterschied: Während JSP-Ausdrücke ausschließlich Objekte erwarten, die implizit über die Ausgabe-Methode verfügen, müssen in JSP-Scriptlets Ausgaben explizit definiert werden. Da uns die oben beschriebenen vordefinierten und vom Server bereitgestellten Variablen auch in JSP-Scriptlets zur Verfügung stehen, bedienen wir uns dazu am einfachsten der Variable . Um den Request-Parameter aus Listing 2.8 über ein JSP-Scriptlet einzufügen, würden wir schreiben: ! "

Und es kommt noch besser: Alle in einer JSP verwendeten JSP-Scriplets und JSP-Ausdrücke werden wie zu einer einzigen zusammenhängenden JavaMethode verknüpft. Eine zuvor in Form eines Scriptlets definierte Variable können wir also problemlos in späteren Scriptlets oder Ausdrücken weiterverwenden. Diese Eigenschaft wollen wir uns zunutze machen, um unsere JSP weiter zu verbessern.

Die zuvor kennen gelernten JSP-Ausdrücke #$% & #

sind lediglich besser lesbare Abkürzungen für einzeilige JSP-Scriptlets der Form: ! #

$% & #

Wenn Sie ein wenig mit Listing 2.8 herumexperimentieren, werden Sie feststellen, dass bei fehlendem Request-Parameter eine eher unschöne Bemerkung auf dem Bildschirm erscheint. Dies wollen wir nun verbessern, indem wir den User bei fehlendem Parameter stattdessen lieber etwas charmanter als „unbekannten Benutzer“ begrüßen. '()*+, - ./01 2234$22 - 56 22 -!72233334 2*828,-562 $ - - , 9 $- 2 2-

Listing 2.10 Verwendung von JSP-Scriptlets und JSP-Ausdrücken

39

2 Java Server Pages

Listing 2.10 (Forts.) Verwendung von JSP-Scriptlets und JSP-Ausdrücken

ERG\! IRQW FRORU JUHHQ IDFH DULDO! FHQWHU!+HOOR :RUOGFHQWHU! XO! OL!:LOONRPPHQ LQ GHU -((0DVWHU&ODVVOL! OL!(V LVW MHW]W JHQDX QHZ MDYDXWLO'DWH !OL! LI XVHU1DPH QXOO ^ ! OL!6LH VLQG XVHU1DPH !OL! ` HOVH ^ ! OL!6LH VLQG (LQ XQEHNDQQWHU %HQXW]HUOL! ` ! XO! IRQW! ERG\! KWPO!

Zuerst lesen wir den Request-Parameter QDPH aus und speichern ihn zur späteren Verarbeitung in der lokalen Variablen XVHU1DPH: 6WULQJ XVHU1DPH

UHTXHVWJHW3DUDPHWHUQDPH !

Anschließend überprüfen wir an gegebener Stelle, ob die Variable eine gültige Zeichenkette enthält: LI XVHU1DPH QXOO ^ !

Ist diese Bedingung erfüllt, wird der entsprechende Zweig ausgeführt, sonst wird überprüft, ob ein alternativer HOVH-Zweig definiert wurde, der dann zur Anwendung kommt. Zur Ausgabe des Benutzernamens verwenden wir einen JSP-Ausdruck, der auf die zuvor in einem JSP-Scriptlet definierte Variable XVHU1DPH zugreift: OL!6LH VLQG XVHU1DPH !OL!

Wie wir bereits wissen, sind solche JSP-Ausdrücke auf die Ausgabe von Daten spezialisiert. Wir hätten an dieser Stelle aber auch das folgende JSP-Scriptlet verwenden können, das die gleiche Ausgabe produziert, jedoch unnötige Schreibarbeit bedeutet. OL!6LH VLQG RXWSULQW XVHU1DPH !OL! Abbildung 2.6 Reagieren auf einen fehlenden HTTP-Parameter

Als Nächstes wollen wir einige klassische Java-Konstrukte betrachten, um ein Gefühl für JSP-Scriptlets und ihre Verwendung zu entwickeln.

40


Die if-Abfrage Die Verwendung der -Abfrage in JSPs haben wir bereite in Listing 2.10 kennen gelernt. Durch einfache -Abfragen lassen sich HTML-Seiten, die sich nur durch wenige Code-Zeilen voneinander unterscheiden, mit einer einzigen JSP realisieren. Anstatt also eine Begrüßungsseite für angemeldete und eine für unbekannte Nutzer erstellen und pflegen zu müssen, ermöglicht es uns die -Abfrage in Listing 2.10, eine JSP für beide Benutzergruppen zu verwenden und das endgültige Aussehen der Seite erst zum Zeitpunkt des Requests, in Abhängigkeit vom HTTP-Parameter , zu bestimmen. Eine -Abfrage innerhalb einer JSP hat immer die folgende Form: ! "!# $ " %&! ! "!# $

Listing 2.11 Die if-Abfrage

Wenn sie bereits mit der Programmiersprache Java vertraut sind, sollte Ihnen die Syntax keinerlei Probleme bereiten. Innerhalb der !&- oder "-Zweiges können wiederum beliebige HTML- oder JSP-Fragmente stehen. Insbesondere können, sofern dies erforderlich sein sollte, mehrere -Anfragen ineinander verschachtelt werden. Die switch-Abfrage Eleganter als verschiedene -Abfragen ineinander zu verschachteln ist es jedoch, diese Entscheidungen durch eine " !%&-Abfrage zu realisieren. Listing 2.12 zeigt schematisch den hierfür notwendigen JSP-Markup: " !%& %" ' ( %" ) ( *+, %" - ( !( $

Listing 2.12 Die switch-Abfrage

Schleifen Eine weitere wichtige Ablaufstruktur, die häufig in JSPs zum Einsatz kommt, ist die Schleife. Unserer Vorstellung einer JSP als zusammenhängende Java-Methode folgend können wir bereits mit unserem jetzigen Wissen auch Schleifen leicht von der Java-Welt in die der JSPs übertragen. Listing 2.13 demonstriert den notwendigen Markup deshalb nur schematisch anhand einer -Schleife: ! .', $

)', //

Listing 2.13 Die for-Schleife

41

2 Java Server Pages

Der rote Faden Wie wir uns erinnern, dienen JSP-Ausdrücke dazu, Inhalte in unsere HTMLSeite einzufügen, und stehen an genau der Stelle, an der dieser Inhalt später erscheinen soll. JSP-Ausdrücke werden durch die von Ihnen erzeugte Zeichenkette ersetzt. Wenn wir uns Listing 2.10 noch einmal genauer anschauen, ziehen sich unsere einzelnen JSP-Scriptlets wie ein roter Faden durch das gesamte Dokument: KLHU EHJLQQW GHU )DGHQ 6WULQJ XVHU1DPH UHTXHVWJHW3DUDPHWHUQDPH ! KLHU ZLUG HU IRUWJHVHW]W LI XVHU1DPH QXOO ^ ! XVHU1DPH ! ` HOVH ^ ! XQG KLHU JHKW HV ZHLWHU ` !

Listing 2.14 Der rote Faden unserer JSP

Es hat zwei entscheidenden Vorteile, wenn wir das Lesen von Request-Parametern oder die Berechnung von wichtigen Ergebnissen in einem gemeinsamen JSP-Scriptlet zusammenfassen und später nur noch auf die oben definierten Variablen zugreifen: Die Lesbarkeit der JSP erhöht sich deutlich und wir sind bei Anpassungen nicht mehr gezwungen, uns die einzelnen Java-Anweisungen innerhalb des Dokumentes zusammenzusuchen. Listing 2.15 JSP-Scriptlets als Java-Methode

Es gibt auch eine alternative, XML-konforme Schreibweise für JSP-Scriptlets. Diese lautet:

MVSVFULSWOHW! +70/-63&RGH MVSVFULSWOHW!

42

Es scheint, als ob alle JSP-Scriptlets zusammenhängen und nur durch statischen HTML-Markup unterbrochen sind: An einer zentralen Stelle (meist unmittelbar nach dem schließenden HEAD-Tag) werden für das Verhalten wichtige Parameter gelesen oder Ergebnisse berechnet und in lokalen Variablen (hier XVHU1DPH) gespeichert. Dann folgt die eigentliche HTML-Seite und bei Verzweigungen oder Ausgaben greifen wir nur noch auf die oberhalb definierten Variablen zu. JSP-Scriptlets bilden eine zusammenhängende Java-Methode, die den Ablauf unserer JSP definiert. Die vordefinierten Variablen UHTXHVW, UHVSRQVH und RXW können wir dann wiederum als Argumente dieser Methode begreifen, die beim Aufruf des Servers an diesen übergeben werden. Für den Servlet-Container unseres Webservers ist unsere JSP also nichts anderes als ein Java-Programm folgender Signatur, das er zur Ausführung bringt: SXEOLF FODVV -63 ^ SXEOLF YRLG DQWZRUWH 5HTXHVW UHTXHVW 5HVSRQVH UHVSRQVH ^

`

`

KLHU VWHKHQ DQHLQDQGHU JHUHLKW XQVHUH -636FULSWOHWV ZLH 9DULDEOHQGHILQLWLRQHQ (QWVFKHLGXQJHQ 6FKOHLIHQ


2.5.3 JSP-Deklarationen Über JSP-Ausdrücke können wir beliebige Zeichenketten in unser Dokument integrieren und JSP-Scritplets ermöglichen es uns, den Ablauf unserer JSP abhängig vom Kontext, etwa gesetzten Request-Parametern, zu gestalten. Und doch sind wir noch arg in unseren Möglichkeiten beschränkt, denn die Gedankenstütze, unsere JSP als zusammenhängende Methode aufzufassen, macht uns schnell klar, dass wir hier nur lokale Variablen deklarieren können, die ihren Wert am Ende der Methode, also nach einem Request, wieder verlieren. Ein Beispiel: Nehmen wir einmal an, wir wollten mit unseren Scriptlets die Anzahl der Zugriffe auf unsere Seite zählen. Da unser JSP-Scriptlets und Ausdrücke einen festen Rahmen bilden, der bei jedem Aufruf neu initialisiert wird, würde unser Webserver bei jedem Zugriff auf unsere Seite die lokalen Variablen innerhalb des Rahmens zurücksetzen und unsinnigerweise wieder von vorn zu zählen beginnen. Jeder Benutzer wäre also der erste seiner Zählung. Was wir benötigen, sind Variablen außerhalb des Rahmens, die ihren Wert über verschiedene Zugriffe hinweg speichern können. Außerdem kennen wir bisher keine Möglichkeit, wiederkehrende Befehlsfolgen in zusätzliche Methoden auszulagern, um etwa das Vorhandensein eines RequestParameters zu überprüfen. Dazu würden wir Listing 2.15 wie folgt erweitern:

! "#

Listing 2.16 JSP als erweiterte Java-Methode

$% %& $ ''' ( )%& ** ++# , '''

,

- . .( $% ( ./ - ) $% %&

/ 0

,

( %'/ 0 !! (# , #

,

Diesen zwei Herausforderungen begegnen wir am besten mit JSP-Deklarationen. Dies haben die Form: 123 4 *$* 25'

43

2 Java Server Pages

Dabei werden JSP-Deklarationen nicht als Bestandteil der JSP-ScriptletMethode interpretiert. Das hat unter anderem die Konsequenz, dass wir Methoden innerhalb von JSP-Deklationen immer als Ganzes definieren müssen und nicht wie in JSP-Scriptlets in einzelne Blöcke aufteilen können. Listing 2.17 demonstriert die Verwendung von JSP-Deklarationen anhand eines zugegebenermaßen sehr einfachen Webcounters, der einen Request zunächst auf seinen Gültigkeit überprüft (im Augenblick akzeptieren wir noch jeden Request) und anschließend die Zahl der Requests seit dem letzten Start des Servers ausgibt. Listing 2.17 Ein einfacher Webcounter

! " #$!%&& '

'

"' "' " ( " )**" " "' "' + # ," !- . / +' + # ," 0!! " "1 23,1", "*", "&"4-" "4-"5 * % # 6 "7 8

: +'

" !0 "" "1 " 9 2"4-"%" ""2# 6 "7 .. -

7 8 "- 9 "/ : "- -"/

0!(' 9! ! !.%"" 9". ' ""';"

! L@OHQJWK M SULQW DUUD\>L@>M@ SULQWOQ ` !

Dieses JSP-Scriptlet schreibt die Werte einer Zeile (in DUUD\>L@) getrennt durch Kommata auf und beginnt anschließend eine neue. Excel erkennt dieses Dokument und startet einen Import-Assistenten, der die Datei in ein Excel-Dokument überführen wird. Aber es kommt noch besser: Im Zuge der zunehmenden Vernetzung hält das WWW Einzug in die klassischen Standard-Applikationen. So verstehen inzwischen auch die meisten Office-Programme rudimentäre HTML-Anweisungen und stellen sie entsprechend ihrer Möglichkeiten dar. Listing 2.23 demonstriert dies an einer einfachen HTML-Tabelle, die sich durch Manipulation des FRQWHQW7\SHs für den Browser als Excel-Tabelle „tarnt“. Listing 2.23 Manipulation des Content-Types

'2&7@ FRRNLHV

`

120

`

UHTXHVWJHW&RRNLHV

LI FRRNLHV QXOO ^ IRU LQW L LFRRNLHVOHQJWK L ^ LI FRRNLHV>L@JHW1DPH HTXDOV&22.,(B1$0( ^ UHWXUQ FRRNLHV>L@JHW9DOXH ` ` ` UHWXUQ QXOO

Ein einfacher Chatroom

3.6.6 Die Darstellung des Chats Jetzt benötigen wir lediglich noch die Chat.jsp, um unseren Chat darstellen zu können. Auch diese können wir mit unserem bisherigen Wissen problemlos umsetzen. ! " #$!%&& '

Listing 3.18 Der Chatroom

(#$)"" *!" !#"*"+)" * " (,""-" !" ' (#$)"" *"% . !#"*"+)" * " (,""-""&"% . '

'

"' "' &!! "' "' -!.' /! ! !*%"" /"* ' '0! %"" " ! "$ (#$%"!#". "*"% . #!#".*)" ' ' 1& ' (#$%"!#". "*!" #!#".*!" ' 1& ' /! !* " !*#! ' 2 .#"*"3 "*!" ' 2 .#"*)- 4 )"*5-"" ' /! ' /!' -!.' '

In diesem Listing verwenden wir die beiden JavaBeans !" und " &"% ., um eine Liste mit angemeldeten Benutzern ausgeben zu können und das bisherige Chatgespräch darstellen zu können. Im unteren Teil schließlich lassen wir den Nutzer zu Wort kommen, indem wir ihm ein Formularfeld für weitere Beiträge zur Verfügung stellen und diese senden wir wiederum, sie ahnen es schon, an das Chat-Servlet. Abbildung 3.7 Unser Chat in Aktion

121

3 Servlets

3.6.7 Fazit Bis hierher war es ein langer Weg und vielleicht sind Sie bei der Implementierung einzelner Komponenten abgeschweift und haben das große Ziel ein wenig aus den Augen verloren. Doch durch die klare Aufgabenverteilung am Anfang konnten wir uns dem Problem stückweise nähern und uns immer auf die jeweils nächste Aufgabe konzentrieren. Die interne Weiterleitung vom Servlet an die JSPs hat den weiteren Vorteil, dass der Benutzer unseres Chats immer nur die URLs des Servlets sehen. Die konkrete Implementierung bleibt ihm verborgen und kann auch nachträglich von uns angepasst werden. Was unserem Chat noch fehlt Unsere Chat-Applikation ist natürlich im Augenblick sehr rudimentär. Es fehlen ihr einige wichtige Details. So kann sich ein einmal registrierter Benutzer nicht mehr abmelden, sondern muss warten, bis das von ihm gesendete Cookie verfällt. Auch gibt es noch keine Methode, die abgelaufene Cookies wieder aus der Registry entfernt. Viele nützliche Funktionalitäten wie etwa private Gespräche oder automatische Aktualisierungen des Browserfensters fehlen noch. Lassen Sie Ihrer Phantasie also freien Lauf. Wissenswertes über Mücken und Elefanten Vielleicht ist Ihnen ja beim Lesen der letzten Seiten auch der Gedanke gekommen: Das hätten wir doch auch anders machen können, oder?! Richtig, für eine einfache Chat-Applikation ist die hier beschriebe Cookie-Technik eigentlich zu groß dimensioniert, denn das dauerhafte Speichern von nutzerbezogenen Daten wie einem Nickname für unsere Chat haben wir auch früher schon unter zu Hilfenahme des 6HVVLRQ-Objekts realisiert. Dieses ist eindeutig einem bestimmten Nutzer zugeordnet, hat bei längerer Nichtbenutzung eine begrenzte Lebensspanne (Session Timeout) und gestatten es uns obendrein, beliebige Werte zu speichern. Tatsächlich setzen viele Webserver sogar Cookies zur Verwaltung der verschiedenen Benutzer-Sessions ein. Dabei wird jeder neue Browser (ohne Cookie) mit einem solchen ausgestattet und intern ein neues Objekt zur Verwaltung des Benutzers angelegt. Unsere UserBean (&KDW8VHU) ist also nichts anderes als ein zusätzliches, sehr spezialisiertes 6HVVLRQ-Objekt. Und würde es beispielsweise über die Methoden JHW$WWULEXWH und VHW$WWULEXWH verfügen und die übergebenen Objekte intern beispielsweise in einer +DVK0DS speichern, könnten wir es sogar als Alternative zur „echten“ Session einsetzen.

122

Filtern von Formulardaten

Wann lohnt sich also der Einsatz eines Cookies gegenüber dem schon vorhandenen Session-Objekt? Nun, das Session-Objekt ist die Konvention eines Webservers, um verschiedene Benutzer unterscheiden zu können. Diese können damit aber nicht über verschiedene Server gemeinsam genutzt werden, genau wie das -Objekt nur den Anwendungen eines Webservers zugänglich ist. Besteht unsere Anwendung nun jedoch aus verschiedenen Teilen, die auf unterschiedliche Server unserer Domain verteilt sind, können wir die Session-Objekte nicht mehr verwenden. Hier kommen unsere Cookies ins Spiel und da einige „schlaue“ Marketingstrategen diesen serverübergreifenden Informationsaustausch zu weit getrieben haben, besitzen Cookies heute manchmal einen eher zweifelhaften Ruf, oder wollen Sie vielleicht, dass sich Ihre werbefinanzierte Suchmaschine noch genau daran erinnert, wonach sie vorgestern gesucht haben, um Ihnen auch ja ein personalisiertes Werbebanner einblenden zu können?!

3.7

Filtern von Formulardaten

In unserem Chatroom (siehe vorherigen Abschnitt) machen wir uns keine Gedanken darüber, welchen Text ein Benutzer eingibt. Möchte ein Benutzer etwas zum Gespräch beitragen, so fügen wir seinen Text einfach in die aktuellen Gesprächsspeicher an, ohne dessen Inhalt in irgendeiner Form zu überprüfen. Das brauchen wir auch nicht, da es sich hier um eine rein textbasierte Applikation handelt. Richtig? Dann fügen wir doch einmal folgenden Text in das Eingabeformular unseres Chats ein.

Listing 3.19 Ein manipulierender Chateintrag

Das Ergebnis dieser seltsam anmutenden Eingabe ist das folgende: Abbildung 3.8 Die manipulierte Chatseite

123

3 Servlets

Für unseren Browser sieht die empfangene Seite nämlich folgendermaßen aus: Listing 3.20 Manipulierter HTML-Code

! " #$!%&& '

'

"' "' &!! "' "' (!)' *! ! !+%"" *"+ ' ',! %"" " ! "$ - '

' ## .! " " //0 1$23 '

'

.! " " //0 1$23 '

' ! .! " " //0 1$23 ' - ' ' 4& ' ! $ 5! ! ('

$ 6- %"

*"7 (' ##$ *! ! !+"' 89 ,: 8, *!' (' 4& ' *! !+ " !+#! ' ; )#"+"< "+!" ' ; )#"+-( = -"+8>- "" ' *! ' *!' (!)' '

Wie wir sehen, empfängt der Browser eine ganz normale HTML-Seite, die er nach bestem Wissen und Gewissen zu interpretieren sucht. Er kann dabei nicht zwischen gewolltem und nachträglich eingefügtem Markup unterscheiden. Was in unserer Chat-Applikation wie eine gewitzte Spielerei aussieht, kann in Produktionssystemen ungeahnte Folgen haben (sog. Code-Intrusion). So kann ein Angreifer bei ungefiltertem Code das Verhalten unserer Applikation vollkommen verändern. Er könnte den Benutzer ohne dessen Wissen auf eine andere Webseite umlenken oder unschöne Banner einblenden und all das nur über Eingaben in unser Formular. Eine weitere unschöne Eigenschaft von ungefiltertem Code wird offenbart, wenn der Browser das Character Set UTF-8 respektive ISO-8859-1 nicht versteht und bei Eingabe „Sonderzeichen“ wie deutsche Umlaute, das KaufmannsUnd (&) etc. enthält. Der Browser erwartet diese Zeichen dann nämlich in der entsprechenden Sonderform. Deshalb bietet es sich an, dynamisch eingefügte Inhalte zu filtern und entsprechende Konvertierungen vorzunehmen. Glücklicherweise gibt uns Java mit den regulären Ausdrücken ein kraftvolles Werkzeug in die Hand, mit dem wir diese Art Ersetzungen vornehmen können. Listing 3.21 zeigt eine Methode, die die Sonderzeichen , ', und ? in ihr HTML-Pendant überführt.

124

Zusammenfassung

)LOWHU 0DUNXS SXEOLF VWDWLF 6WULQJ ILOWHU 6WULQJ LQSXW ^

`

UHWXUQ LQSXWUHSODFH$OO UHSODFH$OO UHSODFH$OO UHSODFH$OO

DPS ? TXRW OW ! JW

Listing 3.21 Eine Methode zum Filtern von reservierten Zeichen in HTML

Diese Methode eignet sich nicht nur, um Eingaben aus Formulardaten in die richtige Form zu überführen. Wann immer wir dynamischen Inhalt (keine Tags) in unser Dokument einfügen, sei es nun aus Datenbanken, Textdateien oder anderen Applikationen, sollten wir diesen mit der oben angegebenen Methode filtern.

3.8

Zusammenfassung

Wir haben gesehen, dass JSPs intern ebenfalls in Servlets umgewandelt werden und damit auf der gleichen Technologie wie Servlets aufbauen. Beide Klassen laufen in unserem Servlet-Container und haben Zugriff auf die gleichen Objekte. Doch während uns in JSPs bereits acht vordefinierte Variablen zur Verfügung standen, haben wir in Servlets zunächst nur Zugriff auf das 5HTXHVW- und das 5HVSRQVH-Objekt. Benötigen wir andere kontextspezifischen Variablen, so müssen wir diese über Methoden des +7736HUYOHW5HTXHVW, des +7736HUYOHW5HVSRQVH oder der Basisklasse (+7736HUYOHW) explizit an bestimmte Variablen unseres Servlets binden. Der Vorteil, Variablen wie RXW erst im Nachhinein zu binden, besteht darin, dass wir den Typ der Verbindung selbst festlegen können. So können wir bei Bedarf beispielsweise über die Methode JHW2XWSXW6WUHDP eine byteorientierte Verbindung etablieren und über diese binärcodierte Dokumente an den Client versenden. Dabei müssen wir den MIME-Type unserer Antwort korrekt setzen. Der Mehraufwand bei Servlets gegenüber JSPs lohnt sich immer dann, wenn wir T komplexen Java-Code zur Steuerung verwenden. Da die Java-Anweisungen in Servlets nicht durch HTML-Markup unterbrochen werden, sind diese deutlich leichter zu warten. Außerdem werden Programmfehler bereits beim Kompilieren des Servlets bemerkt. T zwischen einzelnen Request-Typen (PUT, GET, POST etc.) unterscheiden wollen. Die einzelnen Servicemethoden ermöglichen es uns, sehr differenziert zwischen den unterschiedlichen Anfragetypen zu unterscheiden. So können beispielsweise Upload-Servlets realisiert werden, die es dem Benutzer ermöglichen, Dokumente auf dem Server zu hinterlegen. In der Regel enthalten Servlets die gesamte Applikationslogik einer Webanwendung, innerhalb der sie dann JavaBeans verwenden, um Daten in den benötigten Kontexten (Applikation, Session, Request) abzulegen. Anschließend wird

125

3 Servlets

der Request innerhalb des Servers an eine JSP weitergeleitet, die die JavaBeans wieder extrahiert und die Darstellung übernimmt. Um JavaBeans innerhalb eines Kontexts abzulegen, verwenden wir innerhalb eines Servlets die standardisierten Methoden VHW$WWULEXWH und JHW$WWUL EXWH(). Der JSP-spezifische Kontext SDJH entfällt dabei. Durch dieses Wissen erweitern wir unsere Vorstellung über die Funktion von Kontexten. Statt Informationen „nur“ in Form von JavaBeans „nur“ über die Grenzen eines Requests hinweg zu speichern, dienen sie auch dazu, diese Informationen während der Weiterleitung eines Requests abzulegen. Auch unser Bild vom allgegenwärtigen Hypertext Transfer Protocol hat sich inzwischen gewandelt: Denn während wir am Anfang von Kapitel 2 von zustandslosen Urprotokollen ausgegangen sind, kennen wir heute mit den Session-Objekten und unseren Cookies gleich zwei Technologien, die uns trotzdem die Identifikation von bereits bekannten Benutzern und die Zuordnung von Daten über verschiedene Requests hinweg erlauben.

126

4 Tag-Bibliotheken In den Kapiteln 2 und 3 haben wir uns damit beschäftigt, wie wir unsere statischen HTML-Seiten um dynamische Elemente in Form von Java-Code erweitern. Wir haben mit JSPs, JavaBeans und Servlets drei wichtige Technologien des J2EE-Frameworks von Sun kennen gelernt. Dabei spielte Markup in Form von Tags eine große Rolle, doch wurden stets auch grundlegende Java-Kenntnisse benötigt, um die Magie unserer Dokumente verstehen zu können. In diesem Kapitel wollen wir uns nun mit unseren eigenen Tags befassen. Durch sie werden wir die Möglichkeit haben, immer wieder benötigte Funktionalität in einer eigenen Klasse zu kapseln und diese dann durch ein einfaches und verständliches Tag in unsere JSPs einzubinden. Hierdurch werden unsere JSPs nicht nur von lästigem Java-Code befreit, der sie häufig aufbläht und unübersichtlich macht. Wir können unseren Code darüber hinaus wieder verwenden und leicht selbst über Projektgrenzen hinweg portieren. Um all das zu erreichen, ist es lediglich notwendig, Tags mit der gewünschten Funktionalität zu erstellen und zu einer eigenen Tag-Bibliothek zusammenzufassen (denn was sollten wir mit einer losen Reihe von Tags). Anschließend können wir diese in unsere Web-Applikation einzubinden.

4.1

Ein eigenes Tag

In den Beispielen der beiden vorangegangenen Kapitel benötigten wir häufig die Ausgabe des aktuellen Datums. Dazu verwendeten wir häufig JSP-Ausdrücke oder JSP-Scriptlets, die jedoch ein gewisses Grundverständnis der Programmiersprache Java erforderten. In diesem Abschnitt wollen wir die Ausgabe des Datums nun durch ein eigenes Tag kapseln. Hierdurch wird das Datum später auch ohne Java-Kenntnisse verfügbar sein. Bei der Erstellung eigener Tag-Bibliotheken (Taglibs) sind, ähnlich wie bei Servlets, verschiedene Schritte notwendig, die uns beim ersten Mal vielleicht aufwändig und umständlich erscheinen, später jedoch schnell zur Routine werden.

127

4 Tag-Bibliotheken

4.1.1 Erstellen der Java-Klasse Als Erstes benötigen wir natürlich eine Java-Klasse, die unsere -Logik aufnimmt: den so genannten Tag-Handler. Java stellt uns im Package

verschiedene Interfaces bereit, die wir implementieren können, um unseren Tag-Handler mit bestimmten Fähigkeiten auszustatten. Da wir unsere Klassen aber von Grund auf neu entwickeln wollen, können wir darauf verzichten, alle von den verschiedenen, benötigten Interfaces deklarierten Methoden selbst zu implementieren, und uns das Leben deutlich einfacher machen. Denn die Klassen und (ebenfalls in diesem Package), auf die wir später noch zu sprechen kommen werden, implementieren bereits alle notwendigen Funktionen. Indem wir unsere Klassen also von einer dieser beiden Klassen ableiten, können wir unsere gewünschte Funktionalität durch einfaches Überschreiben der jeweiligen Methode realisieren. Der Lebenszyklus unseres Tags – die Methoden der Klasse TagSupport Während die JSP-Engine später unser Tag verarbeitet, ruft sie verschiedene Methoden auf, innerhalb derer wir unterschiedliche Möglichkeiten der Interaktion haben. Unser Tag durchläuft dabei, analog zu unseren Servlets, einen bestimmten vordefinierten Lebenslauf (Lifecycle). T

Wir können das Überspringen des Rumpfes dabei auch als Vorsichtsmaßnahme verstehen: Bei Tags, die keinen Rumpf besitzen sollen, wie z.B. unser Datumstag (siehe Listing 4.1), wollen wir verhindern, dass Code, den wir selbst oder Dritte später vielleicht versehentlich dort einfügen, mit in der Ausgabe erscheint. Als Rumpf eines Tags bezeichnen wir alle Zeichen (Markup und Text), die sich zwischen dem öffnenden Tag () und dem schließenden Tag () befinden. Tags der Art besitzen also keinen Rumpf. Bei ihnen wird die Methode nicht ausgeführt.

128

Diese Methode wird bei einem öffnenden Tag () gerufen. Hier haben wir die Möglichkeit, unser Tag zu initialisieren und festzustellen, ob das Tag an der richtigen Stelle innerhalb des Dokuments verwendet wurde. Am Ende dieser Methode können wir durch Rückgabe eines Parameters entscheiden, ob der Rumpf des Tags verarbeitet oder übersprungen werden soll. In letzterem Fall endet an dieser Stelle die Bearbeitung des Tags und der Rumpf einschließlich des schließenden Tags () wird schlicht ignoriert. T Diese Methode wird immer unmittelbar vor dem schließenden Tag () gerufen und gibt uns die Möglichkeit, den Rumpf des Tags zu modifizieren. An dieser Stelle können wir entscheiden, ob wir die Bearbeitung des Tags beenden wollen und zu weitergehen oder den (möglicherweise modifizierten) Inhalt des Tags noch einmal bearbeiten wollen. In diesem Fall beginnt die Bearbeitung des Tags und seines Inhalts wieder unmittelbar nach dem öffnenden Tag (dort wo wir standen, nachdem wir beendet hatten). Anschließend wird wird erneut gerufen. wird nur ausgeführt, wenn unser Tag tatsächlich einen Rumpf besitzt. Bei leeren Tags ( ) wird diese Methode übersprungen.

T Wenn wir die Bearbeitung eines Tags nicht am Ende von abgebrochen, sondern fortgesetzt haben, wird das Tag durch die Methode abgeschlossen. Hier haben wir die Möglichkeit, eventuell benötigte Ressourcen wieder freizugeben oder den Zustand unseres Tags in einer Datei zu speichern.

Ein eigenes Tag

Wo die Bearbeitung eines Tags fortgesetzt wird, teilen wir der JSP-Engine am Ende jeder Methode durch die Rückgabe einer Konstanten mit. Abbildung 4.1 veranschaulicht die Verarbeitung eines Tags und die möglichen Konstanten noch einmal. Abbildung 4.1 Der Lebenszyklus eines Tag-Handlers

Unser Tag-Handler Da unser Tag nur durch die Ausgabe des aktuellen Datums ersetzt werden soll, genügt es, die Methode zu implementieren. Danach wollen wir die Bearbeitung abbrechen und den möglicherweise vorhandenen Rumpf sowie das End-Tag aus dem Dokument entfernen.

Listing 4.1 Ein einfaches Date-Tag

!

"

!

"

# " $ % & ' ( " '

'

'

)*+,-

So schwer sieht das doch gar nicht aus. Indem wir unser Tag von der Superklasse

ableiten, verfügen wir automatisch über die vordefinierte Variable % , die es uns nicht nur ermöglicht, den aktuellen Request weiterzuleiten (Forward) oder andere Dokumente einzubinden (Include), sondern beispielsweise auch den Zugriff auf bekannte Variablen wie . / und . , die aktuelle Session oder ermöglicht. In unserem Fall erzeugen wir einfach ein neues Datumsobjekt, das wir über ausgeben. Um die JSP-Engine anzuweisen, die Bearbeitung des Tags an dieser Stelle zu beenden und den Rumpf zu überspringen (engl. to skip), verwenden wir die uns ebenfalls von

zur Verfügung gestellte Konstante )*+,-.

129

4 Tag-Bibliotheken

4.1.2 Der Tag Library Descriptor Nachdem wir unser Tag mit einem Ant-Script oder unserer IDE erfolgreich übersetzt haben, müssen wir unserem Webserver natürlich noch mitteilen, welches Tag unsere Klasse behandeln soll. Bei Servlets verwendeten wir dazu den Web Deployment Descriptor und analog existiert für Tag-Bibliotheken der so genannte Tag Library Descriptor (TLD). Ein TLD besteht aus einer meist auf dem Kürzel .tld endenden XML-Datei, die im Wesentlichen die Aufgabe hat, unsere Tags den von uns erstellten JavaKlassen Tag-Handler zuzuordnen (Mapping). Listing 4.2 Ein Tag Library Descriptor (TLD)

!"# $% & "'() **+ , - $ . ** /" % ) &%- 0**#1 2$$34**5%% + *$*6&5 3$% &%-770$ $% & $ & *$ & 5 3 0 *5 3 2$ %50 * 2$ % + 666% $% *50 *+ 3$ 3 /0## % & * 3$ $% %%$ * % $%% % $% 50$% 3%$ % *$%% 3$ 3%- + $ %$ * 3$ *$% *$% &

Einleitende Tags Zunächst müssen wir angeben, welchen Taglib- ( $ & ) und JSP-Version ( 5 3 ) unser TLD unterstützt, und anschließend können wir eine kurze Beschreibung ( 3$ ) unserer Tag-Bibliothek hinterlegen. Die unter dem Tag 2$ % abgelegte Zeichenkette gibt den Namensraum (Namespace) unserer Bibliothek an. Dieser ist notwendig, da innerhalb einer Web-Applikation verschiedene Tag-Bibliotheken parallel zum Einsatz kommen können. Dabei könnte beispielsweise das Tag %$ in zwei Bibliotheken mit jeweils unterschiedlichem Verhalten definiert sein. Damit die JSP-Engine dennoch sicher feststellen kann, welches der beiden Tags gemeint ist, werden diese zu so genannten Tag-Familien zusammengefasst. Jede Tag-Familie besitzt dadurch einen einheitlichen (Nach-)Namen, über den ein Tag sicher zugeordnet werden kann. Ein Beispiel für solche Namensräume haben wir bereits in Kapitel 2 verwendet: Erinnern Sie sich, dass wir statt 86% und + stets 5 34 + und 5 3486% schreiben mussten? Damit haben wir der JSP-Engine mit-

130

Ein eigenes Tag

geteilt, dass diese Tags in der Bibliothek jsp zu finden und nicht etwa Bestandteil von HTML sind.

Achtung Die Namensräume MDYD, MDYD[, MVS, MVS[, VHUYOHW, VXQ und VXQZ sind bereits reserviert und können nicht verwendet werden. Auch leere Präfixe sind wegen der Verwechslungsgefahr mit HTML-Tags nicht zulässig. Da sich auch Namensräume aufgrund der wenigen Zeichen überschneiden können, ist es sinnvoll, jeden Namensraum mit einer URL zu verbinden. Denn eine URL ist schon per se eineindeutig, so dass es zu keinen Überschneidungen kommen kann. Die unter XUL! angegebene Ressource kann frei gewählt sein und muss nicht wirklich existieren. Es ist jedoch sinnvoll, unter dieser Adresse eine kurze Beschreibung des Namensraumes, etwa die entsprechende DTD, zu hinterlegen, auf die wir in Kapitel 10 noch genauer eingehen. Das Mapping Auf diese stets gleich bleibende Einleitung folgt das eigentliche Mapping von Tags auf Java-Klassen. Wichtig dafür sind ein konkreter Name (QDPH!) für unser Tag sowie die Angabe unseres Tag-Handlers (WDJFODVV!). Außerdem können wir natürlich noch eine konkrete Beschreibung unseres Tags hinterlegen (GHVFULSWLRQ!). In unserem Fall definieren wir, dass unser Tag-Handler zunächst Tags der Form GDWH! behandeln soll.

Ein Namespace ist ein Kontext, in dem ein konkreter Name nur ein einziges Mal existiert. Durch die Aufteilung von Ressourcen in einzelne Namensräume brauchen wir uns keine Gedanken mehr darüber zu machen, ob der gewählte Name vielleicht mit der Bezeichnung in einem anderen Teil der Applikation kollidiert. Beispiele für Namensräume sind etwa die Packages in Java: Dort enthalten die Packages MDYDVTO und MDYDXWLO beide eine Klasse 'DWH, doch durch die Angabe des Namensraumes kann der Compiler beide voneinander unterscheiden. In Markup-Dokumenten wie HTML oder dem später besprochenen XML erfolgt die Angabe des Namensraums durch ein Präfix, das durch einen Doppelpunkt „“ vom Namen getrennt wird.

Einbinden des Tag Library Descriptors in unsere Webapplikation Um unseren TLD in unsere Web-Applikation einzubinden zu können, muss dieser unter einer URL verfügbar gemacht werden. Dazu können wir diesen beispielsweise in einem Ordner tlds ablegen und durch unseren Webbrowser selbst verfügbar machen, wie in Abbildung 4.2 gezeigt. Abbildung 4.2 Direktes Einbinden unserer TLDs

Damit ist unser TLD jedoch im gesamten Netz unter der URL http://UnserServer:8080/masterClass/tlds erreichbar. Besser ist es, unseren TLD in den Web Deployment Descriptor einzubinden und, wie unsere Servlets auch, unter einer virtuellen URL verfügbar zu machen. Da unsere Tags vor der Auslieferung an den Browser mit der Bearbeitung durch unsere Tag-Handler ersetzt werden, bleiben unsere Tag-Bibliotheken so dem Benutzer verborgen.

131

4 Tag-Bibliotheken

Um unseren TLD zu verbergen, verschieben wir unseren Ordner tlds zunächst in das für den Client unsichtbare Verzeichnis WEB-INF (siehe Abbildung 4.3): Abbildung 4.3 Indirektes Einbinden unserer TLDs

Anschließend binden wir unsere TLDs durch folgenden Eintrag in die Datei web.xml in unsere Applikation ein: Listing 4.3 Eintrag in unseren Web Deployment Descriptor

Jetzt können wir unsere Tag-Bibliothek innerhalb der Web-Applikation unter der URL /j2ee-tags erreichen und in unseren JSPs verwenden.

4.1.3 Verwendung in JSPs Erinnern Sie sich noch an unsere JSP-Direktiven? und haben wir ja bereits in Kapitel 2 kennen gelernt. Nun wollen wir die dritte Direktive verwenden, um der JSP unsere Tags bekannt zu machen: .

!"

Durch diese Zeile weisen wir die JSP-Engine an, für alle Tags mit dem Präfix

die entsprechende Klasse des TLD zu suchen und auszuführen. Genau genommen muss das Präfix nicht mit dem Namensraum dieser Bibliothek übereinstimmen, sondern kann frei gewählt werden, da es nur für diese Seite gültig ist. Zum besseren Verständnis empfehle ich Ihnen jedoch, den gleichen Namen zu wählen. Jetzt können wir unser Tag beliebig innerhalb der JSP verwenden. Fast so, als wäre es ein Bestandteil der HTML-Spezifikation. Listing 4.4 Verwendung unseres Tags

#$%&'() *+ ),-& ./ *+ 01 *2 ..../ '3 3& *+01

!"

*+ * ' *4 * 5 ! ! ' *4

132

Attribute verwenden

XO! OL!(V LVW MHW]W MHHGDWH !OL! XO! IRQW! ERG\! KWPO!

Listing 4.4 (Forts.) Verwendung unseres Tags

Lediglich ein Neustart unseres Webservers ist nötig, damit dieser die neu hinzugefügten Informationen der Datei web.xml auch registriert, und schon können wir loslegen: Abbildung 4.4 Das Resultat unseres Tags

4.2

Attribute verwenden

Jetzt stehen wir wieder vor dem Problem, dass unser Datum unformatiert ausgegeben eher unschön ist. Als Nächstes wollen wir unser Tag also um das Attribut IRUPDW erweitern, das die Form unseres Datums spezifizieren soll. Der erweiterte Tag-Handler Analog zu einer JavaBean müssen wir für jedes unserer Attribute eine Methode VHW$WWULEXWQDPH deklarieren, über die uns die JSP-Engine den Wert des jeweiligen Attributs mitteilt. Wir erweitern unseren Tag-Handler also folgendermaßen: SDFNDJH PDVWHUFODVVMHHWDJV LPSRUW LPSRUW LPSRUW LPSRUW LPSRUW

MDYDXWLO'DWH MDYDWH[W6LPSOH'DWH)RUPDW MDYDLR,2([FHSWLRQ MDYD[VHUYOHWMVS-VS:ULWHU MDYD[VHUYOHWMVSWDJH[W7DJ6XSSRUW

Listing 4.5 Ein erweitertes Date-Tag

SXEOLF FODVV ([WHQGHG'DWH7DJ H[WHQGV 7DJ6XSSRUW ^ )RUPDW3DWWHUQ SULYDWH 6WULQJ IRUPDW3DWWHUQ 0DS 7DJ$WWULEXWH IRUPDW WR -DYD$WWULEXWH IRUPDW3DWWHUQ SXEOLF YRLG VHW)RUPDW 6WULQJ YDOXH ^ IRUPDW3DWWHUQ YDOXH `

133

4 Tag-Bibliotheken

SXEOLF LQW GR6WDUW7DJ ^

Listing 4.5 (Forts.) Ein erweitertes Date-Tag

WU\ ^ -VS:ULWHU RXW

SDJH&RQWH[WJHW2XW

LI IRUPDW3DWWHUQ QXOO ^ RXWSULQW QHZ 'DWH ` HOVH ^ 6LPSOH'DWH)RUPDW GDWH)RUPDW QHZ 6LPSOH'DWH)RUPDW IRUPDW3DWWHUQ RXWSULQW GDWH)RUPDWIRUPDWQHZ 'DWH ` ` FDWFK ,2([FHSWLRQ LRH ^ LRHSULQW6WDFN7UDFH ` `

UHWXUQ 6.,3B%2'<

`

Registrieren im Tag Library Descriptor (TLD) Anschließend erweitern wir unseren Tag Library Descriptor (TLD) um den Eintrag: Listing 4.6 TLD-Eintrag für unser erweitertes Date-Tag

WDJ! QDPH!H[WGDWHQDPH! WDJFODVV!PDVWHUFODVVMHHWDJV([WHQGHG'DWH7DJWDJFODVV! GHVFULSWLRQ! 'LVSOD\ IRUPDWWHG GDWH GHVFULSWLRQ! DWWULEXWH! QDPH!IRUPDWQDPH! UHTXLUHG!IDOVHUHTXLUHG! DWWULEXWH! WDJ!

Für jedes unserer Tag-Attribute, die wir verwenden wollen, benötigen wir ein DWWULEXWH-Tag in unserem TLD, in dem wir zumindest den Namen (QDPH!) des Attributs angeben. Wenn wir dabei das optionale Flag UHTXLUHG (benötigt, erforderlich) auf WUXH setzen würden, würden wir die JSP-Engine dazu veranlassen, jedes unserer Tags auf das Vorhandensein dieses Attributes zu überprüfen, und die Bearbeitung des Requests bei fehlendem IRUPDW-Attribut mit einem Fehler abzubrechen. Dies ist sinnvoll, wenn unsere Tags für die korrekte Bearbeitung bestimmte Pflicht-Attribute benötigen. So benötigt beispielsweise das Tag MVSIRUZDUG! eine Seite (SDJH), an die der Request weitergeleitet werden soll.

134

Vordefinierte Variablen

Die Verwendung innerhalb unserer JSP Nun brauchen wir dem neuen Tag nur noch eine Format-Anweisung in Form einer Zeichenkette (siehe ) mitzugeben und schon wird unser Datum wie gewünscht ausgegeben. !!"#$!! %& '( ' !! ' )!!""""#*!+!+ %&!( $ , -. * / 0 1 !2

*(

3 1 2

Listing 4.7 Formatierte Datumsausgabe

-,

, , , * ' * / 4 '! ,! , /5, 3' $ 1 * ' 3$ 1 , $ ' , * ' * / 4 '!$ ' , 0 , ,( ( 6) 2 ) 31 775555 88) !,! , !0 , !3', !/5, ! , Abbildung 4.5 Unser erweitertes Tag in Aktion

4.3

Vordefinierte Variablen

Häufig benötigen wir in für unsere Tag-Handler die gleichen Informationen wie in unseren JSPs. Im Gegensatz zu diesen steht uns innerhalb der Tag-Handler-Klasse zunächst aber nur die vordefinierte Variable * ' zur Verfügung. Über diese Variable haben wir jedoch auch die Möglichkeit, auf viele andere Objekte wie die Session oder den Request zuzugreifen und können so zum Beispiel gesetzte Request-Parameter auslesen oder Attribute innerhalb der Session speichern. In diesem Abschnitt soll es um die Verwendung dieser Variablen gehen. Dazu wollen wir ein Tag entwickeln, das seinen Rumpf nur preisgibt, wenn der Request über eine sichere Verbindung, wie zum Beispiel über HTTPS, erfolgt. Anderenfalls wird der Inhalt nicht übertragen.

HTTPS steht für Hypertext Transfer Protocol Secure und ermöglicht eine auf Zertifikaten basierende gesicherte HTTPVerbindung zwischen zwei Rechnern. Die größte Schwachstelle dieses Protokolls liegt dabei in der Verwendung nicht signierter Zertifikate, die einen so genannten „man in the middle“-Angriff ermöglichen. Mehr zu HTTPS finden Sie im RFC 2818.

135

4 Tag-Bibliotheken

Listing 4.8 Ist der empfangene Request als sicher eingestuft?

!

"

#$%&'()*+',-!&.*# /

/

/

0,1'()*+

Der Unterschied zwischen ServletRequest und HTTPServletRequest Die Information, ob ein empfangener Request als sicher eingestuft wird, teilt uns der Webserver über die Methode des -Objekts mit. Und hier zeigt sich schon die nächste Herausforderung: JSP-Dokumente sind nicht zwingend auf die Übertragung per HTTP angewiesen. Deshalb gibt uns die Methode auch kein 21 -Objekt, sondern „nur“ ein Objekt der Basisklasse zurück. Da uns die Methode auch vom Basis-Objekt zur Verfügung gestellt wird, stört uns das nicht weiter. Um aber auf Cookies ( !) oder die Anfragemethode ( 3 4) zugreifen zu können, müssten wir unser Objekt zunächst casten. Unter einem Cast oder genauer einem Typecast (Typumwandlung) verstehen wir die Zuweisung eines Objekts zu einem bestimmten Typ. Wie wir wissen, können wir die Klasse 21 auch an eine Variable des Typs binden, denn jeder 21 ist auch ein (upcast). Dabei ändern wir nicht den Typ des Objekts selbst, sondern nur unsere Sichtweise darauf. Wenn wir sicher wissen, dass ein bestimmtes Objekt eine bestimmte Subklasse (downcast) oder ein spezifisches Interface (sidecast) implementiert, können wir es natürlich auch in diese Richtung casten.

136

21 21 !

Dabei müssen wir darauf achten, dass wir ein Objekt wirklich nur dann casten, wenn wir es tatsächlich mit einem 21 zu tun haben, das heißt, wenn wir uns sicher sind, dass das übergebene -Objekt tatsächlich vom Typ 21 ist. Anderenfalls quittiert uns 5 den verbotenen Cast mit einer !! # . Den Rumpf einbinden oder überspringen Je nachdem, ob die Verbindung zum Client sicher ( ) ist oder nicht, entscheiden wir durch Rückgabe der entsprechenden Konstante, ob der Rumpf unseres Tags eingefügt (#$%&'()*+',-!&.*#) oder übersprungen (0,1'()*+) werden soll.

Den Rumpf manipulieren

Nachdem wir folgende Mapping-Informationen in unseren TLD eingefügt haben:

Listing 4.9 Mapping-Informationen zu unserem Secure-Tag

können wir unser Tag schließlich verwenden: !"#$% &'()# *

+

,-

* *.

+ / /%#,- *

Listing 4.10 Unser Secure-Tag

01 2 3* * 43** 0 % '25 2 3* * 3* *

% '25 ! ) 62 7 2 2 . ! 7 2

.

2

Abbildung 4.6 Darstellung über eine sichere Verbindung

4.4


Bisher haben wir unsere Tag-Handler stets nur dazu verwendet, Zeichenketten in das Dokument einzufügen oder den Rumpf unseres Tags, und damit alle enthaltenen Tags, zu überspringen. In diesem Abschnitt werden wir lernen, wie wir den Rumpf unseres Tags auslesen und verändern können.

137

4 Tag-Bibliotheken

Die Klasse BodyTagSupport Um den Rumpf unseres Tags manipulieren zu können, lassen wir unseren TagHandler von der Klasse

erben. Diese stellt uns über die Methode ein -Objekt zur Verfügung, hinter dem sich nichts anderes als der Rumpf unseres Tags verbirgt. Über die Methoden des -Objekts können wir den Rumpf unseres Tags beispielsweise auslesen ( ), löschen ( ) oder ausgeben ( ). Das Iteration-Tag Um die Verwendung des -Objekts zu veranschaulichen, wollen wir ein Iteration-Tag entwickeln, das den enthaltenen Rumpf (ähnlich einer Schleife) für eine vorher festgelegte Anzahl wiederholt: Listing 4.11 Die Methode doAfterBody

! " #

$

%

&' () #) '&

* + &' ,( $ , - ,( $ ,

'&

$ % * - . /

$ (- % $ * " # * $ ! # % - *+ 0 11 %

$ / / ) ! % /

/

/

2 34 56

Die durch $ zurückgegebene Zeichenkette beinhaltet übrigens alle im Rumpf enthaltenen Zeichen, also Text und Markup, ganz so, wie sie der Browser später empfängt.

138


Eintrag im Tag Library Descriptor (TLD) Für unseren TLD ist es einerlei, ob unser Tag-Handler die Klasse oder erweitert oder alle Interfaces „zu Fuß“ implementiert. Und so lautet der erforderliche Eintrag:

Listing 4.12 Registrieren unseres IterationTags im TLD

Das Iteration-Tag in Aktion Nun wollen wir unser Iteration-Tag dazu verwenden, sowohl Markup als auch Text zu vervielfältigen, und da man manche Dinge gar nicht oft genug sagen kann ... ! "#$ % #& '! ()* % +, ( (%-))))* ..$!%+, (

Listing 4.13 Unser Iteration-Tag in Aktion

/0 1(( 231(( / % %

$ %4 %

2 1(( 21(( $ %4 - 1(*( # ! - 56 # - 2 % Abbildung 4.7 Das Resultat unseres IterationTags

139

4 Tag-Bibliotheken

4.5

Mit dem Kontext arbeiten

Bisher haben wir unsere Tag-Handler stets nur für sich betrachtet und ihren Kontext vollkommen außer Acht gelassen. Einige Tags ergeben jedoch nur in Kombination mit anderen eine sinnvolle Struktur. So beschreibt das -Tag in HTML beispielsweise die Zelle einer Tabelle (Table Data), was nun wirklich nur dann Sinn macht, wenn es sich tatsächlich in einer solchen ( ) befindet. In diesem Abschnitt soll es um diese geschachtelten Tags gehen. Eltern-Tags finden Tags, die das aktuelle Element umschließen, werden auch als Eltern-Tags (Parent-Tags) bezeichnet. Analog sind alle Elemente innerhalb eines Rumpfes Kind-Tags (Child-Tags). Aus dieser vermenschlichten Interpretation leitet sich auch die Methode ab, mit der wir die umschließenden Elemente (Vorfahren) unseres augenblicklichen Tags finden können:

(Ancestor, dt.: Vorfahre, Ahne). Diese sowohl von als auch von unterstützte Methode gibt uns stets die „jüngsten“ Vorfahren unseres Tags zurück. Dieses Tag muss dabei auch in einer Tag-Library definiert und an einen Tag-Handler gebunden sein. Auf unser Beispiel mit der HTML-Klasse gemünzt könnten wir also innerhalb der Methoden des TD-Handlers die Methode

Um einen weiter entfernten („älteren“) Vorfahren unseres Tags zu erhalten, können wir beispielsweise die Methode

auf unser Eltern-Objekt anwenden und so die Ahnenreihe rückwärts abarbeiten.

ausführen, um die umschließende Instanz ( ) dieser Klasse ( ) zu erhalten. Dabei bedienen wir uns ein weiteres Mal der Technik des Castens, da uns die Methode

zunächst nur ein allgemeines Objekt zurückgibt. Die Methode

erwartet folgende Parameter: T !"# "! # $% Diese Klasse gibt das Ausgangs-Tag für unsere Vorfahrensuche an. Dies kann das aktuelle Tag ( ) oder zum Beispiel ein bereits gefundener Vorfahr sein. T !"

Für Kind-Elemente stellt uns Java leider bisher keine entsprechende Methode bereit. Wir können diese jedoch beispielsweise durch das Parsen („den Inhalt grammatikalisch bestimmen“) des Objekts ermitteln (siehe auch Kapitel 10).

140

Dieser gibt die Klasse des zu suchenden Objekts bzw. Tag-Handlers an. Ein Cast des zurückgegebenen Tags auf diesen Typ ist in jedem Fall erfolgreich.

4.5.1 Entscheidungen (if-else) Um die Arbeit mit verschachtelten Tags zu demonstrieren, wollen wir eine Reihe von Tags entwickeln, mir denen wir Entscheidungen ( - ) analog zu Java definieren können. Listing 4.14 verdeutlicht die spätere Form in unseren JSPs:

Mit dem Kontext arbeiten

LI! FRQGLWLRQ! +LHU VWHKW VSlWHU WUXH RGHU IDOVH FRQGLWLRQ! WKHQ! 1RPHQ HVW RPHQ WKHQ! HOVH! 'HU RSWLRQDOH (OVH=ZHLJ HOVH! LI!

Listing 4.14 Entscheidungen (schematisch)

Dabei verteilen wir die Aufgaben folgendermaßen: T LI Das umschließende LI!-Tag hält den gesamten Verbund zusammen und hat die Aufgabe, den Zustand des &RQGLWLRQ!-Tags zu speichern, da WKHQ! und HOVH! dieses (als Geschwister-Tag) nicht referenzieren können. Des Weiteren zeigt das Vorhandensein eines LI!-Tags den anderen drei Tags an, dass sie im richtigen Kontext verwendet worden sind. T FRQGLWLRQ Dieses Tag enthält den Wahrheitswert unserer Entscheidung. Wir realisieren diesen durch ein extra Tag (und nicht etwa durch ein Attribut des LI!-Tags), damit wir den Wahrheitswert später auch zur Laufzeit ermitteln können. Etwa aus dem Attribut einer verwendeten JavaBean: FRQGLWLRQ! JHW3DUDPHWHU QDPH GHVFLVLRQ SURSHUW\ YDOXH ! FRQGLWLRQ!

T WKHQ In dieses Tag kommt der Markup, der ausgegeben werden soll, wenn der Wahrheitswert WUXH ist. Ist der Wert IDOVH, wird der Inhalt übersprungen. T HOVH Dieses Tag ist (wie das WKHQ!-Tag) optional. Es ermittelt zur Laufzeit den Zustand der Entscheidung und gibt seinen Inhalt aus, wenn der Zustand nicht wahr (IDOVH) ist. Überprüfung des Kontextes Die Tags FRQGLWLRQ!, WKHQ! und HOVH! ergeben nur dann einen Sinn, wenn sie innerhalb eines LI!-Tags verwendet werden. Daher überprüfen alle drei zu Beginn (GR6WDUW7DJ ), ob ein solches Eltern-Tag existiert, und speichern es gegebenenfalls zur späteren Verwendung in einer Instanz-Variablen. 3DUHQW LI7DJ SULYDWH ,I7DJ LI7DJ

Listing 4.15 Test, ob ein if-Tag vorhanden ist

SXEOLF LQW GR6WDUW7DJ WKURZV -VS7DJ([FHSWLRQ ^ LI7DJ ,I7DJ ILQG$QFHVWRU:LWK&ODVV WKLV ,I7DJFODVV LI LI7DJ QXOO ^ WKURZ QHZ -VS7DJ([FHSWLRQ &RXOG RQO\ EH XVHG LQVLGH LI ` `

UHWXUQ (9$/B%2'2= =34 ) > / * % 234 ? /2* * 30 * % > 234 ? / 2

* 3 0 % > 23 ?

193

6 Java Naming and Directory Interface

Auch wenn es die Schnittstelle nicht zwingend erfordert, empfehle ich Ihnen beim Casten vom Objekten, insbesondere beim Zugriff auf einen Verzeichnisdienst, eine abzufangen. Schließlich können Sie nicht mit Sicherheit sagen, ob an dieser Stelle im Directory tatsächlich ein Objekt vom Typ

liegt. So können Konfigurationsfehler unseres Verzeichnisdienstes ein seltsames Verhalten unserer Anwendung bewirken.

Auch hier sehen wir wieder, dass unsere Objekte beim Ablegen im Kontext wie bei der Ablage in der Session oder dem Request ihren Typ „verlieren“ und nach dem Herauslösen zunächst erst wieder zurückgecastet werden müssen.

Ansonsten ist die Bereitstellung einer Datenquelle über JNDI ein Kinderspiel, wenn wir wissen, in welchem Kontext sich unsere befinden. Erzeugt, Kontext initialisiert und abgelegt – das war's. Diese Technik ermöglicht es uns auch, auf einfache Art und Weise unterschiedliche Datenquelle zu verwalten und über ein einheitliches Interface zu bedienen.

6.3.3 Datenquellen im Apache Tomcat Auch wenn unser Apache Tomcat kein „vollwertiger“ Application Server im Sinne der J2EE-Spezifikation ist, stellt er uns dennoch eine Reihe von nützlichen Diensten zur Verfügung. Einer davon ist ein JNDI-Service, der allerdings nur seinen eigenen Web-Applikationen zur Verfügung steht. Dieser ermöglicht es uns, Datenquellen und andere Ressourcen vorzukonfigurieren und erleichtert uns so die tägliche Arbeit durch: T Integration des Services in den Apache Tomcat Da der vom Tomcat emulierte JNDI-Service bereits in den Webcontainer integriert ist, wird kein weiterer Dienst benötigt. T Pooling der Verbindungen Bei der Verwaltung von Datenquellen verwendet der Apache Tomcat automatisch einen Connection-Pool, indem vorhandene Datenbankverbindungen zur späteren Wiederverwendung zwischengespeichert werden können. Das spart Ressourcen für den Auf- und Abbau der Verbindung und bringt einen deutlichen Geschwindigkeitsgewinn. Doch wie immer bekommt man nichts geschenkt in dieser Welt und so erkaufen wir diese Vorteile durch Abhängigkeit von Apache Tomcat. So wird unsere WebApplikation nach der Verwendung dieser Services nicht mehr ohne Anpassungen auf einem einfachen Webserver wie Mort Bay's Jetty (http://jetty.mortbay.org) laufen. Solche Abhängigkeiten treten allerdings bei der Verwendung aller webserverspezifischen Dienste auf und wenn Sie sich einmal für einen solchen entschieden haben, steht einer Verwendung dieser Services nichts mehr im Wege. Konfiguration Zunächst müssen wir unseren Tomcat natürlich entsprechend anpassen und mit der Datenquelle bekannt machen. Dazu erweitern wir unsere Konfigurationsdatei conf/server.xml, auf die wir in Kapitel 1 schon einmal zu sprechen gekommen sind, folgendermaßen:

194

Arbeiten mit der JNDI

!""# $"" $ ""!"$#"$ %!"!& ' ( !

)

Listing 6.9 Konfiguration einer DataSource im Apache Tomcat

*++ %!"! ,-+& ++ %!"!"#& *++ .! '/ # "+0!1" ++ & "# 2 )#(3 " 4"

( 2""5$6!$""

#" !" #(3 &78 )

$$$ $$$ $$$

$$$

$$$

*++ ""1 & +9""# ++ & 9""# "# 2 )#(3 ""# "#4!""# )"# "! #$#(6!$2 $ )"! )""# ""# "#! )"# "!2 :#(6!:))! "!:;; ' "(9!" # " ?5 ++ 45 " )#"4!" 7" #" !"

!""! '"! 45 & 1 "# "! "7

!"! 2 )#(3

( 2""5$6!$"" )

)45 ) )= ) )

195

6 Java Naming and Directory Interface

Wir können im Top-Level-Element beliebig viele JNDI-Ressourcen und Datenquellen ablegen und mit einem symbolischen Namen (hier ) versehen. Diese werden dann über das Element in den Kontext der jeweiligen Web-Applikation eingebunden. Zugriff innerhalb der Applikation Da wir bereits gelernt haben, über einen JNDI-Service auf eine Datenquelle zuzugreifen, stellt Listing 6.10 für uns nun lediglich eine Wiederholung dar. Listing 6.10 Zugriff auf die Tomcat-DataSource

!"# $ ! " %&!'$(& $'"# ) !) " $%&!'&& )*'"# % !"#

Vielleicht sind Sie jetzt etwas verwundert darüber, dass wir den Standardservice ohne spezifische Parameter verwenden können. !"#

Unser Apache Tomcat richtet für jede seiner Web-Applikationen eine eigene JNDI-Umgebung ein, in der deren ResourceLinks (siehe Listing 6.9) gebunden sind. Diese wird dann für diese Java Virtual Machine als Standardumgebung gesetzt und kann ohne Parameter adressiert werden. Innerhalb eines solchen Kontextes sind die einzelnen Datenquellen innerhalb des Subkontextes $( $ abgelegt, den wir über die Methode $ ! " %&!'$(& $'"# Wenn Sie Ihre ) nicht im Kontext finden, lassen Sie sich zu Debug-Zwecken einmal alle Objekte im Subkontext $(& $ anzeigen. Häufig haben wir in diesem Fall einfach nur den symbolischen Namen des ResourceLinks ('&& )*') mit dem der Ressource ('') vertauscht. Denken Sie immer daran, dass der Anwendung die konkrete Datenbank verborgen bleiben soll, um diese später austauschen zu können. Deshalb ist hier der Name && )* o.ä. gerechtfertigt. Innerhalb der Konfigurationsdatei deklarieren wir jedoch unter Umständen verschiedene Datenquellen, weswegen wir hier einer bestimmten (eigenen) Namenskonvention folgen sollten.

196

finden. Nachdem wir nun den richtigen Kontext gefunden haben, ist das Extrahieren der Datenquelle ein Kinderspiel. Wir müssen einfach nur nach dem symbolischen Namen unseres (nicht den der Ressource!) suchen und das zurückgegebene Objekt zur ) casten – fertig. ) !) " $%&!'&& )*'"#

Verwendung unterschiedlicher Umgebungen Wenn wir unsere Datenbankumgebungen über den Webserver verwalten, haben wir einen weiteren Vorteil: Größere Applikationen durchlaufen vor dem Produktiv-Einsatz häufig zunächst eine Art Testsystem unter einem anderen Webserver und greifen dabei auf eine Test-Datenbank zu. Ist die jeweilige URL der Datenbank dabei fest in den Quelltext eincodiert oder beispielsweise im Web Deployment Descriptor hinterlegt, laufen wir immer Gefahr, versehentlich auf die falsche Datenbank zuzugreifen oder müssen unsere Anwendung zwischen Test und Produktion vielleicht sogar neu übersetzen. Hinterlegen wir unsere Datenbankverbindungen jedoch in den jeweiligen Webservern, minimieren wir diese Gefahr ganz beträchtlich, da diese nur sehr selten umkonfiguriert werden, und können außerdem auf ein erneutes Übersetzen bei der Produktivsetzung verzichten. Stattdessen müssen wir in diesem Fall nur das

Arbeiten mit der JNDI

Applikationsverzeichnis (oder die WAR-Datei, die es enthält) von einem Server auf den anderen übertragen und schon greift die Anwendung auf die Produktionsdatenbank zu. Dieser Abschnitt sollte uns an einem praxisnahen Beispiel verdeutlichen, wie wir das JNDI einsetzen können, um unsere Applikationen effizienter und weniger fehleranfällig zu machen. Natürlich bietet der Apache Tomcat, wie viele andere Webserver auch, ein weitaus größeres Spektrum zur Nutzung von JDNI an. Eine umfassende Dokumentation über die Möglichkeiten erhalten wir dazu unter http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jndi-resources-howto.html.

197

7 Enterprise JavaBeans „Beans!“, so lautet das Zauberwort der Firma Sun Microsystems, wenn es um wieder verwendbare Software-Komponenten geht. Die populärsten Vertreter dieser Spezies sind dabei wohl die JavaBeans. Diese (Daten-)Container haben uns seit dem Anfang dieses Buches begleitet und werden es wohl auch weiter tun. Bisher haben wir JavaBeans vor allem dann eingesetzt, wenn wir miteinander in Beziehung stehende Daten zu einem gemeinsamen Objekt zusammenfassen wollten. JavaBeans halfen uns dabei, unsere Geschäftslogik auf abstrakte, an die Wirklichkeit angelehnte Objekte wie beispielsweise Adressen zu operieren, statt etwa eine Menge von Straßennamen und Städten zu verwalten. Durch den restriktiven Aufbau, bei dem alle inneren Eigenschaften unserer JavaBean für den Benutzer verborgen bleiben und dieser lediglich über eine explizit definierte Schnittstelle (Setter- und Getter-Methoden) mit dem Objekt operiert, können wir unsere JavaBean und den umgebenden Code unabhängig voneinander weiterentwickeln, ohne Seiteneffekte befürchten zu müssen.

7.1

Vom Einschicht- zum Dreischichtsystem

Am Anfang dieses Buches haben wir gelernt, den Response für eine Client dynamisch zur Laufzeit zu erzeugen, indem wir an den entsprechenden Stellen JavaCode in unsere Dokumente integrierten. Dabei stand vor allem die Darstellung im Vordergrund, doch prinzipiell ist jede Art von Java-Code möglich und vielleicht haben Sie sich ja auch die Mühe gemacht und eine kleine Applikation inklusive Datenbankanbindung und Benutzerauthentifizierung realisiert. Wie wir bereits wissen, wird eine solche JSP-zentrierte Applikation auch als „Model 1“-Architektur bezeichnet. Später haben wir Servlets kennen gelernt und mit ihnen die Vorteile, unsere Anwendungslogik von der Darstellung zu trennen. In diesem Zusammenhang sprachen wir über das Model-View-Controller (MVC)-Paradigma, das im Struts-Kapitel schließlich zur Anwendung kam. Verallgemeinert spricht man dabei dann von mehrschichtigen Systemen (n-Tier-Systemen), bei denen wir uns vorstellen können, dass unsere Logik (die Anwendung) die Basis

199

7 Enterprise JavaBeans

für die Darstellungsschicht (JSPs) bildet, die darauf aufsetzt. Diese SoftwareArchitektur wird auch als zweischichtiges System (Two-Tier-System) bezeichnet. Diese Abstraktion lässt sich nun beliebig fortsetzen: So kann unsere Logik beispielsweise auf eine Datenhaltungsschicht aufsetzen oder eine Kommunikationsschicht verwenden, um mit anderen Systemen zu kommunizieren, wodurch ein Three-Tier-System entsteht und so fort. Abbildung 7.1 Aufbau eines Three-Tier-Systems

Durch die Aufteilung unserer Aufgaben in verschiedene Schichten, wie beispielsweise Darstellung, Applikationslogik (in diesem Zusammenhang oft auch als Business-Logik bezeichnet) und Datenhaltung, können diese auch auf mehrere Systeme verteilt und von verschiedenen Rechnern erbracht werden. Hierdurch wird das Gesamtsystem besser skalierbar, indem Lastspitzen etwa auf mehrere Rechner verteilt werden können, und durch den modularen Aufbau können neue Aufgaben leicht durch eine Kombination aus verschiedenen Teilsystemen gelöst werden. Da die hier besprochenen Enterprise JavaBeans (EJBs) die Anwendungslogik kapseln und über keine Darstellungskomponente verfügen, lassen sie sich auf allen zwei- und mehrschichtigen Systemen einsetzen. Typische Anwendungen gehen oftmals einen Schritt weiter und teilen die Aufgaben in die Bereiche Darstellung, Applikationslogik und Datenhaltung, die als Dienste miteinander kommunizieren.

7.2

Einsatz eines Application Servers

Um unsere Anwendung in verschiedene Dienste aufteilen zu können, benötigen wir natürlich Umgebungen, über die diese Dienste angeboten werden. So benötigten wir für unsere JSPs und Servlets beispielsweise einen Webserver (Apache Tomcat), der die Anfrage des Clients zunächst entgegennahm und anschließend an das dafür zuständig Objekt weiterleitete. Im Fall von Webanwendungen war der Client einfach der Webbrowser des Benutzers, mit dem wir über das textbasierte HTTP-Protokoll kommunizieren konnten. Da die Anfrage des Benutzers bereits durch das Domain Name System

200


an unseren Server weitergeleitet worden war, mussten wir uns auch keine Gedanken darüber machen, wie der Client unseren Dienst im Netz gefunden hat und wie unsere Antwort den Weg zurück fand. Wir mussten lediglich den (vom Server zur Verfügung gestellten) Ausgabekanal öffnen und konnten unsere Antwort einfach hineinschreiben. Der Webserver ist darauf getrimmt, uns bei dieser Arbeit bestmöglich zu unterstützen. Bei zwei- und mehrschichtigen Systemen werden jedoch mitunter Java-Objekte von einer Java Vitual Machine (JVM) auf eine andere übertragen. Diese sind zwar auch nicht mehr als eine Hand voll Bytes im jeweiligen Arbeitsspeicher, doch wir sollten jetzt verstehen, dass ein textbasiertes Protokoll zum Übertragen dieser nicht mehr ausreichen dürfte. Des Weiteren funktionieren diese Systeme nicht mehr nach einem simplen Frage-Antwort-Schema, Client und Server sind in dieser Welt nicht klar getrennt und können ihre Rollen mitunter auch tauschen. Und da in der Regel kein Namensdienst für diese Services existiert, müssen wir zusätzlich dafür Sorge tragen, dass sich unsere Dienste auf der Datenautobahn auch finden. Wie wir sehen, kommen bei verteilten Systemen einige zusätzliche Aufgaben auf uns zu, die deren Einsatz komplex erscheinen lassen. Und tatsächlich lohnt sich der Einsatz von Enterprise JavaBeans auch erst bei mittelgroßen bis großen Systemen, bei denen verschiedene Applikationen auf die gleiche Anwendungslogik zugreifen sollen. Dort allerdings spielen sie mit längerer Laufzeit meist den Mehraufwand durch eine Reihe von Vorteilen heraus: Sei es nun, dass nicht vorhergesehene Lastspitzen dynamisch durch Hinzuschalten weiterer Server abgefangen werden oder dass durch die lose Kopplung auch zentrale Module noch im Nachhinein ohne Seiteneffekte ausgetauscht werden können. Und keine Angst, auch bei der Bewältigung dieser Aufgaben steht uns ein starker Partner zu Seite: der Application Server JBoss!

7.2.1 Aufbau eines Application Servers Wenn wir bisher von einem Webserver sprachen, meinten wir in der Regel unseren Servlet-Container, also die Laufzeitumgebung unserer JSPs und Servlets. Genau wie diese benötigen auch unsere Enterprise JavaBeans einen Platz, an dem sie erzeugt, mit Aufgaben betreut und schließlich wieder entfernt werden. Diese Laufzeitumgebung ist der so genannte EJB-Container. Abbildung 7.2 Aufbau eines J2EE-Servers

201


CORBA steht für Common Object Request Broker Architecture und definiert plattformunabhängige Kommunikationsprotokolle, die nicht an eine bestimmte Programmiersprache gebunden sind. Über einen so genannten Interface Definition Language (IDL)Compiler werden dabei zunächst formale Objekte definiert und anschließend um die gewünschte Funktionalität erweitert; dazu wird diese dann in einer konkreten Programmiersprache implementiert. Der entfernte Client operiert auf einem leeren Stub-Interface, dessen Methodenaufrufe dann über einen Object Request Broker (ORB) an das eigentliche Business-Objekt weitergeleitet werden, das vom erzeugten Skeleton ableitet. In Abschnitt 7.3.2 werden wir uns genauer mit dieser Technik der Methoden-Fernaufrufe beschäftigen.

Nun gibt es kaum einen Hersteller, der einen reinen EJB-Server anbietet. Dies liegt daran, dass eine Enterprise JavaBean als Logik-Container ohne Darstellung- und Datenhaltungsschicht meist reichlich nutzlos wäre. So statten inzwischen auch viele Anbieter von Datenbanken, Transaktionsmonitoren oder CORBA-ORBs ihre Server mit einem EJB-Container aus. Suns J2EE-Spezifikation fordert sogar, dass ein J2EE-konformer Application Server sowohl einen Servlet-, als auch einen EJB-Container und außerdem eine Reihe von unterstützenden APIs enthält, auf die wir gleich noch zu sprechen kommen werden. Damit scheidet unser Apache Tomcat nun endgültig aus, da er zwar eine Reihe der Normen erfüllt und zahlreiche Dienste anbietet, aber eben keinen EJB-Container enthält.

7.2.2 Portabilität Java, das steht auch für „Write once, run anywhere!“ und natürlich sollte es laut Spezifikation möglich sein, EJB-Komponenten, die unter einem EJB-Container entwickelt wurden, problemlos auf einen anderen zu übertragen, so wie wir auch von JSPs erwarten, dass das resultierende HTML-Dokument des Jetty-Servers identisch mit dem des Apache Tomcat ist. Soweit die Theorie, doch in Wirklichkeit entwickelt jeder Anbieter seinen J2EEServer so, dass er möglichst harmonisch mit den anderen Komponenten zusammenarbeitet, und passt die Spezifikation entsprechend an. So können OracleBenutzer beispielsweise ihre EJBs wahlweise im Internet Application Server IAS (vormals OAS) oder direkt in der Datenbank zum Einsatz bringen, wodurch ein merklicher Performancegewinn erreicht wird und die aufwändige Administration des OAS entfällt. Man muss sich schon sehr zwingen, statt der vom Hersteller angeboten Abkürzung den EJB-konformen Weg zu gehen. Ob und inwieweit Sie Ihren EJB-Container austauschen können, hängt also stark davon ab, wie weit sich die Anbieter und Sie an die Spezifikation halten. Auf der jährlich in San Francisco stattfindenden JavaWorld werden von einer unabhängigen Jury die besten Produkte in zehn Kategorien gewählt. Die Finalisten der Kategorie „Best Java Application Server“ lauten dabei seit Jahren: T JBoss (http://www.jboss.org) T BEA WebLogic (http://www.bea.com) T IBM WebSpere (http://www.ibm.com)

Die Lesser General Public License (LGPL) ist eine Software-Lizenz der Free Software Foundation, unter der Open Source-Programme vertrieben werden. Ein wesentlicher Unterschied zur General Public License (GPL) besteht darin, dass auf LGPL basierende Applikationen auch proprietär vertrieben werden dürfen.

202

Diese drei Kandidaten liefern sich jedes Jahr ein knappes Kopf-an-Kopf-Rennen. Dies zeigt einmal deutlich, dass Open Source-Software durchaus mit kommerziell entwickelten Produkten mithalten kann, und nicht ohne Grund haben wir uns in diesem Buch für den unter LGPL-Lizenz verfügbaren JBoss entschieden. Dieser frei verfügbare Application Server beinhaltet gleich zwei Servlet-Container (Apache Tomcat und Mort Bay's Jetty) und den gleichnamigen EJB-Container. Eine kurze Installationsanleitung zu ihrem JBoss finden Sie in Kapitel 1.


7.2.3 Unterstützte APIs Natürlich bietet jeder Anbieter besondere APIs (Application Programming Interfaces) an, um die Entwicklung von wieder verwendbaren EJB-Komponenten auf seinem System zu vereinfachen. Ein vollwertiger EJB-Container muss dem Entwickler jedoch seit der Spezifikation 2.1 zumindest folgende Programmierschnittstellen (APIs) anbieten: T Java 2 Standard Edition (J2SE), Version 1.3 T Enterprise JavaBeans 2.1 T Java Message Service (JMS)-API, Version 1.0.2 T Java Naming and Directory Interface (JNDI)-API, Version 1.2 T die Erweiterungen der Java Database Connectivity (JDBC)-API, Version 2.0 T User Transaction API (JTA), Version 1.0.1 T JavaMail-API, ab Version 1.1 T Java API for XML Processing (JAXP), Version 1.0 Solange wir also lediglich die Services dieser APIs verwenden, besteht zumindest die Chance, unsere EJBs von einem Container auf einen anderen übertragen zu können. Natürlich können wir daneben noch weitere APIs, etwa für das Logging oder die Erzeugung von PDF-Dokumenten verwenden, nur müssen diese dann ebenfalls in die neue Umgebung übertragen werden.

7.2.4 Aufgaben eines EJB-Containers Ein EJB-Container dient als Laufzeitumgebung für unsere Enterprise JavaBeans (EJBs). Das verpflichtet ihn, neben der Bereitstellung der oben beschriebenen APIs, dazu, folgende Dienste anzubieten:, Überwachung des Lebenszyklus von EJBs Genau wie Servlets durchlaufen EJBs einen bestimmten Lebenszyklus, auf den wir später noch zu sprechen kommen werden. Der EJB-Container ist in diesem Fall für den Übergang von einem Zustand in einen anderen verantwortlich und steuert diesen. Instanzen-Pooling Im Gegensatz zu Servlets, von denen zur Laufzeit stets nur eine einzige Instanz existiert, kann ein EJB-Container mehrere Instanzen einer Enterprise JavaBean auf Vorrat erzeugen und über einen Pool verwalten. Namens- und Verzeichnisdienst Wie wir wissen, finden sich die einzelnen EJBs über einen gemeinsamen Namensdienst. Dieser wird ebenfalls vom Container verwaltet.

203


Transaktionsdienst Komplexe Aufgaben bestehen in der Regel aus einer Menge von Teilaufgaben, die entweder ganz oder gar nicht ausgeführt werden. So besteht eine Überweisung beispielsweise aus dem Abbuchen eines Betrages vom Belastungskonto und der anschließenden Gutschrift dieses auf dem Gutschriftkonto. Misslingt der zweite Schritt, etwa weil das Konto nicht existiert oder der verantwortliche Server nicht erreichbar ist, muss auch der erste Teil der Transaktion rückgängig gemacht werden. Wir können die Abarbeitung einzelner EJBs auch zu Transaktionen zusammenfassen, die entweder erfolgreich ablaufen (Commit) oder rückgängig gemacht werden (Rollback). Nachrichtendienst (Message Service) Mit der Spezifikation 2.0 führte Sun die Message Driven Beans ein. Diese kommunizieren nicht via Prozedur-Fernaufruf, sondern über den Java Message Service (JMS) miteinander und ermöglichen so erstmals einen asynchronen Objektaustausch. Persistenz Hin und wieder kommt es vor, dass ein EJB-Container neu gestartet wird oder selten genutzte Komponenten aus dem Arbeitsspeicher ausgelagert werden, um benötigte Ressourcen freizugeben. In diesem Fall kann es erforderlich sein, dass eine Enterprise JavaBean nach der Reinstanziierung den gleichen Zustand wie vorher wiedererlangt. Während einige Beans selbst dafür Sorge tragen können, dass ihr Zustand persistent gemacht wird (man spricht in diesem Fall von BMP – Bean Managed Persistence), beschreibt die EJB-Spezifikation einen Mechanismus, mit dem bestimmte Beans automatisch persisiert werden können (dies wird dann CMP – Container Managed Persistence – genannt). Die Art der Speicherung, ob nun in einer Datenbank, im Dateisystem oder in anderen EJB-Services bleibt dabei dem Container überlassen, wichtig ist nur, dass das Objekt vollständig im Speicher wiederhergestellt werden kann.

7.3

Kurzer Überblick über EJB-Technologien

In diesem Abschnitt wollen wir kurz die wichtigsten Konzepte hinter JavaBeans und Enterprise JavaBeans besprechen und den Unterschied zwischen beiden kennen lernen. Denn obwohl beide augenscheinlich starke Ähnlichkeit in der Namensgebung besitzen, verfolgen sie gänzlich andere Ziele und stehen für verschiedene Konzepte der Software-Entwicklung, die sich allerdings vortrefflich ergänzen.

204


7.3.1 Beans, Beans, Beans Beans, bei diesem Wort sollte inzwischen schon etwas in unserem Ohr klingeln, denn schließlich begegnen uns diese Software-Komponenten auf Schritt und Tritt. Doch Bean ist nicht gleich Bean und deshalb sollten wir die eine von der anderen unterscheiden können. Beans Unter einer Bean verstehen wir in Java nichts anderes als eine in sich geschlossene Software-Komponente, die einer Hand voll Bedingungen genügt, die wir seit Kapitel 2 zusammentragen. Dabei kann es sich prinzipiell um alles handeln, von einer Wrapper-Class, die nichts anderes tut, als ein Objekt zu kapseln und den Zugriff darauf zu steuern, bis hin zur vollständigen ERP-Lösung inklusive Buchhaltung und Lagerverwaltung.

ERP steht in der Informatik für Enterprise Resource Planning und bezeichnet alle Prozesse, die alle in einem Unternehmen verfügbaren Ressourcen (z.B. Betriebsmittel, Kapital) möglichst effizient koordinieren und einsetzen.

JavaBeans Der wohl meistzitierte Satz zum Thema JavaBeans ist: „Eine JavaBean ist eine wiederverwendbare Software-Komponenten, die mit einem Builder-Tool visuell manipuliert werden kann.“ Er stammt aus Suns JavaBean-Spezifikation 1.01 aus dem Jahre 1997. Doch was verbirgt sich dahinter und was versteht Sun unter einem Builder-Tool? Nun, wenn Sie je mit Visual Basic oder anderen Microsoft-verwandten Programmiersprachen und ihren meist grafischen IDEs zu tun hatten, dürfte der Begriff Property (Eigenschaft) keine Schwierigkeiten bereiten. Sie können sich eine JavaBean in diesem Fall als eine Sammlung von Eigenschaften einer (grafischen) Komponente vorstellen. Für alle anderen kommt hier ein kurzer (und sehr persönlich interpretierender) Erklärungsversuch. Ende der neunziger Jahre wurde eine neue Art der SoftwareEntwicklung populär. Grafische Benutzeroberflächen setzten sich mehr und mehr durch und hielten insbesondere Einzug in die Computer von Informatikstudenten. Es wuchs eine neue Generation von Informatikern heran, für die Lochkarten und Assembler-Programmierung Saurier einer längst vergangenen Computer-Steinzeit angehörten. Mit den weit verbreiteten Hochsprachen C/C++ und Borland Pascal ließen sich zwar alle möglichen und unmöglichen Algorithmen relativ komfortabel realisieren, doch die Programmierung dieser grafischen Benutzeroberflächen war weiterhin eine schwer zu meisternde Königsdisziplin. Diese Lücke zwischen Programmieranspruch und Realität erkannte Microsoft und setzte sich mit seinen grafischen IDEs schnell in bestimmten Märkten durch. Die vordefinierten Bibliotheken gestatteten es, relativ einfach zu erlernenden BasicCode mit anspruchsvollen grafischen Elementen zu verknüpfen und diesen per Mausklick bestimmte Eigenschaften zuzuweisen. Eine gewisse Zeit war man der Meinung, dies sei die Zukunft der Programmierung (und darüber kann wieder jeder eigener Meinung sein). Doch egal, ob es sich dabei nun um eine Antwort von Sun auf Microsofts Standard oder lediglich um eine Lösung für einen ähn-

205


lichen Problemkreis handelte: JavaBeans sind gewissermaßen das Java-Gegenstück zu diesen Properties. Durch die Namenskonventionen und war man in der Lage, per Reflection (Package ) auch zur Laufzeit auf die Properties zuzugreifen und sie über einen Dialog zu verändern. Unsere Vorstellung von einer JavaBean kann also im Wesentlichen unverändert bleiben. Eine JavaBean T ist ein Daten-Container, der bestimmte Eigenschaften eines Objekts repräsentiert, T erlaubt durch eine besondere Namenskonvention diese Eigenschaften auch dynamisch zu erkennen und per Reflection zu manipulieren, T konzentriert sich im Wesentlichen auf die Persistenz dieser Eigenschaften. Enterprise JavaBeans (EJBs) Als Mainframe (Großrechner) bezeichnet man komplexe Computersysteme, die sich vor allem durch Zuverlässigkeit und Datendurchsatz auszeichnen. Die Kapazitäten eines solchen Rechners liegen typischerweise weit über denen eines PCs oder Servers, wobei viele Komponenten redundant ausgelegt sind, um einen durchgängigen Betrieb zu gewährleisten. Im Gegensatz zu den so genannten Supercomputern, die sich vor allem durch eine hohe Rechenleistung auszeichnen, sollen Mainframes vor allem robust sein. Dazu statten Anbieter von Mainframes (z.B. IBM, Siemens und Sun) ihre Systeme meist mit selbst entwickelten und auf den Server zugeschnittenen Betriebssystemen aus. Typische Nutzer von Mainframes sind vor allem Banken, Versicherungen und öffentliche Verwaltungen.

EJBs entstanden wiederum aus einem ganz anderen Software-Blickwinkel. Ihre Heimstätte war nicht der heimische PC, auf dem der Anwender optisch ansprechende Dialoge realisieren wollte, sondern die Mainframe-Rechner großer Recheninstitute. Eines der großen Probleme serverseitiger Prozesse ist deren Skalierbarkeit. Darunter versteht man, wie gut ein System auf steigende Belastung reagiert bzw. wie viel mehr Ressourcen es benötigt. Ein gut skalierendes System benötigt, um die zehnfache Leistung zu erbringen, auch zehnmal mehr Ressourcen, während ein schlecht skalierendes System diese Ressourcen bereits bei doppelter Leistung beanspruchen würde und bei zehnfacher Last komplett versagt ([WIKI]). Die EJB-Spezifikation beschreibt nun ein Framework, das die verteilte Verarbeitung von transaktionsorientierter Geschäftslogik ermöglicht. Dabei bleiben die Enterprise JavaBeans im Gegensatz zu „reinen“ JavaBeans für den Benutzer stets verborgen. Statt Namenskonventionen und Eigenschaften werden EJBs also im Wesentlichen durch die Programmierschnittstellen (APIs) und angeboten Dienste (Services) realisiert. Dabei verwenden EJBs zur Transaktion von Daten JavaBeans als Daten-Container, wobei diese dann oftmals auch als Value-Beans oder Wert-Objekte bezeichnet werden.

7.3.2 Methodenfernaufrufe Kern der EJB-Technologie ist der Methodenfernaufruf (engl. Remote Methode Invocation, RMI). Darunter verstehen wir das Abarbeiten von Befehlen auf einem entfernten Rechner oder einer anderen Java Virtual Machine. Die entfernten Befehle liegen dabei in Form einer Methode vor, die von einem Objekt im Speicher des entfernten Rechners implementiert wird. Wir kommunizieren mit diesem Objekt über eine vom entfernten Server bereitgestellte Schnitt-

206


stelle (,QWHUIDFH). Diese deklariert dabei alle bereitgestellten Methodenrümpfe und leitet deren Aufruf über den Application Server an das reale Objekt weiter. Abbildung 7.3 Remote Method Invocation (RMI) schematisch

Der dem Client lokal verfügbare, abstrakte Rumpf der Klasse wird als Stub (Stumpf) bezeichnet; dieser entspricht in Java einem Interface. Zu diesem gehört ein Skeleton: eine abstrakte Klasse, die einerseits dem Interface des Clients genügt und andererseits als Basis für die „echte“ Klasse dient. Diese implementiert dann die gewünschte Funktionalität und liefert schließlich das „Fleisch“ um unser nacktes Skelett (Skeleton), das im Wesentlichen nur die Methoden-Signaturen enthält. Um die Funktionalität der entfernten Klasse bereitzustellen, bedarf es eines Maklers (Broker), der zwischen abstraktem Objekt und tatsächlicher Implementierung vermittelt. Bekannte Broker Architekturen sind dabei: T Common Object Request Broker Architecture (CORBA) Server, die CORBA-Dienste anbieten, werden hierbei als Object Request Broker (ORB) bezeichnet. T Remote Method Invocation (RMI) T Distributed Component Object Model (DCOM) Auch Microsofts Implementation ermöglicht die Kommunikation von Komponenten, die in verschiedenen Sprachen geschrieben wurden. Hierfür wird allerdings die nicht auf allen Plattformen verfügbare DCOM-Laufzeitbibliothek benötigt. Seitdem dem JDK 1.3 stellte Sun die Kommunikation seiner Architektur auf das CORBA zugrunde liegende Internet Inter-ORB Protocol (IIOP) um, wodurch es prinzipiell (wenn auch mit einigem Aufwand) möglich ist, über RMI auch Objekte anzusprechen, die nicht in Java implementiert sind (RMI-IIOP). Um entfernte Objekte anzusprechen, bedienen sich die meisten Broker-Architekturen eines Namens- oder Verzeichnisdienstes. Der bedeutendste Service ist dabei der COS Naming Service.

207


7.3.3 Objektserialisierung Wie wir wissen, werden durch RMI die über ein Interface bereitgestellten Methoden eines entfernten Objekts zur Ausführung gebracht. Solange alle Methoden keinen Rückgabewert YRLG haben, existiert bis dato auch noch kein Problem. Doch was passiert mit zurückgegebenen Objekten, seien es nun Strings oder eigene JavaBeans? Das Zauberwort heißt Serialisierung. Abbildung 7.4 Objektserialisierung

Dabei wird ein Objekt bzw. seine Repräsentation im Speicher des entfernten Rechners in einen Datenstrom (z.B. MDYDLR'DWD2XWSXW6WUHDP) umgewandelt und an den lokalen Rechner gesendet. Dieser deserialisiert das empfangene Objekt anschließend wieder und übergibt dem Benutzer des Interfaces eine Referenz auf dieses, ganz so, als sei der Aufruf der Methode lokal erfolgt. Mit der Serialisierung und Deserialisierung kommt der Benutzer in der Regel nicht in Berührung. Dies erledigen die Klassen des RMI-Packages für uns. Nun hat zwar jedes Objekt eine Repräsentation im Speicher, dennoch können nicht alle Objekte serialisiert werden. So stellt eine JDBC-Verbindung beispielsweise eine lokal gebundene Referenz auf einen Datenbankdienst dar und kann damit nicht übertragen oder gar auf einem persistenten Speichermedium festgehalten werden. Damit unsere eigenen Objekte übertragen werden können, müssen sie das Marker-Interface MDYDLR6HULDOL]DEOH implementieren. Versuche, ein nicht serialisierbares Objekt per RMI zu übertragen, quittiert Java wie immer mit einer entsprechenden Exception.

7.4

Die verschiedenen Bean-Typen

Fassen wir die RMI-Grundgedanken noch einmal zusammen: Ein EJB-Objekt besteht also aus einer Enterprise JavaBean, die unsere Funktionalität aufnimmt und im Speicher des entfernten Rechners läuft, sowie einem zugehörigen Interface (Stub), das sich in unserem Speicher befindet und über den Broker (EJBContainer) mit dem Originalobjekt kommuniziert. Unser Stub leitet die Metho-

208


denaufrufe an das entfernte Objekt weiter (wo sie abgearbeitet werden) und stellt uns die per Serialisierung übertragenen Ergebnisobjekte (z.B. JavaBeans als Daten-Container) zur Verfügung. In diesem Kapitel wollen wir uns nun mit den verschiedenen Implementierungen und ihren Funktionen beschäftigen.

7.4.1 Bestandteile einer Enterprise JavaBean Unsere Enterprise JavaBean kann aus unterschiedlichen Blickwinkeln betrachtet werden. Um dies zu ermöglichen, besteht sie aus folgenden Komponenten, die wir hier noch einmal aufzählen wollen, um die einzelnen Begriffe zu erklären: T Remote-Interface Über dieses Interface kommuniziert der entfernte Rechner mit dem BeanObjekt. Diese Schnittstelle stellt die nach außen sichtbare Funktionalität zur Verfügung. T Home-Interface Dieses Interface wird innerhalb des EJB-Containers verwendet, um mit der EJB lokal kommunizieren zu können. Eine Bean soll laut Suns Spezifikation immer einen leeren Konstruktor besitzen, über den sie vom Container erzeugt wird; dabei machen auch EJBs keine Ausnahmen. Manchmal benötigen wir allerdings dennoch parameterbehaftete Methoden, um unser Objekt zu initialisieren, denn bevor ein EJBKonto-Bean per Fernzugriff verwaltet werden kann, muss es erst einmal wissen, welches Konto es repräsentiert. Das Home-Interface ist der Ort, an dem wir diese Methoden deklarieren können. T Bean-Klasse Da unsere Funktionalität schließlich auch irgendwo stehen muss, benötigen wir ein Objekt, das die vom Home- und Remote-Interface deklarierten Methoden implementiert. Dies ist das Bean-Implementierung. T Bean-Kontext Der Bean-Kontext (Typ MDYD[HME(-%&RQWH[W) dient als Schnittstelle zwischen dem der Enterprise Bean und dem EJB-Container. Über ihn hat die EJB die Möglichkeit zu erfahren, welche Identität (Primary Key) sie gerade repräsentiert und mit welchem Client sie interagiert. T Deployment Descriptor Zu guter Letzt müssen wir (wie fast überall im J2EE-Umfeld) unseren Server konfigurieren und ihn über die neue EJB und ihre Funktionen in Kenntnis setzen. Genau wie den Servlet-Container (Web Deployment Descriptor) konfigurieren wir unseren EJB-Container über eine XML-Datei, die hier allerdings nur Deployment Descriptor genannt wird.

209


7.4.2 Entity-Beans Entity-Beans sind das Herzstück unserer EJB-Architektur. Sie werden verwendet, um Geschäftsmodelle abzubilden, und repräsentieren etwa das zu bearbeitende Konto, die Lagerverwaltung oder die Kundenbuchhaltung. Sie werden verwendet, um die in der Datenbank abgebildeten Objekte in Java verfügbar zu machen. In Kapitel 8 werden wir im Zusammenhang mit Java Data Objects (JDO) auf die Abbildung von relationalen Datenbankdaten auf Java-Objekte und umgekehrt noch einmal zurückkommen.

Entity-Beans enthalten also unsere fachliche Logik und können ihren Zustand festhalten (persistieren), indem sie ihre Änderungen an diesem in das zugrunde liegende Datenmodell übertragen. Wie wir sehen werden, existieren für diese Beans gleich zwei konkurrierende Persistenz-Mechanismen. Lebenszyklus einer Entity-Bean Beim Start des J2EE-Servers erzeugt der EJB-Container (je nach Konfiguration) eine Reihe von Entity-Beans und verwaltet diese in einem gemeinsamen Pool. Wird per JNDI ein bestimmtes Objekt dieses Typs angefordert, so weist der Container einer Instanz des Pools diese Identität zu und stellt sie anschließend dem Client zur Verfügung. In diesem Zustand pendelt die Bean (je nach Aktivität des Clients) zwischen einem aktiven und einem passiven Zustand hin und her. Fordern verschiedene Clients zur gleichen Zeit dieselben Objekte an, so übergibt ihnen der EJB-Container stets die Referenz auf dasselbe Objekt. Ganz so, als würden die Clients auf einem Datensatz des Datenbanksystems operieren. Nachdem die Bean nicht mehr benötigt wird, hält der Container ihren inneren Zustand auf dem persistenten Speichermedium (Datenbank) fest, anonymisiert diesen anschließend wieder und die Bean wandert zurück in den Pool.

7.4.3 Stateless Session-Beans Während Entity-Beans versuchen, das Datenmodell abzubilden, werden SessionBeans dazu verwendet, Geschäftsprozesse nachzuahmen. Um auf das eingangs erwähnte Beispiel der Überweisung zurückzukommen, gehören dazu immer zwei beteiligte Konten, also auch zwei Entity-Beans. Der Benutzer hingegen sieht nur den Vorgang des Geldtransfers von einem Konto auf ein anderes, der durch eine Session-Bean gehandhabt wird. Session-Beans werden also verwendet, um komplexe Operationen auf Entity-Beans zusammenzufassen und dem Benutzer als kompakte Methode zur Verfügung zu stellen. Die Methoden einer Stateless Session-Bean können wir uns als statische Objektmethoden vorstellen. Genau wie Servlets vergessen diese Beans nach einer Transaktion den Client sofort wieder und widmen sich dem nächsten. Wenn ein Client zwei aufeinander folgende Transaktionen durchführt, ist es gut möglich, dass er dabei mit unterschiedlichen Instanzen dieses Objekts zusammenarbeitet. Weder der Client noch die Stateless Session-Bean können ihren jeweiligen Partner von anderen unterscheiden oder gar wiedererkennen, genauso wenig, wie ein Servlet einen Request von einem anderen unterscheiden kann.

210


Da für den EJB-Container alle Instanzen dieses Objekts identisch sind, können sie von ihm sehr ressourcenschonend über einen gemeinsamen Pool verwaltet werden. Lebenszyklus einer Stateless Session-Bean Auch Stateless Session-Beans werden vom Container über einen Pool verwaltet. Da sie jedoch keinen inneren Zustand besitzen und dem Client damit nur das Pendant von statischen Methoden zur Verfügung stellen, können die von ihnen zur Verfügung gestellten Dienste von einer oder mehreren Instanzen parallel erbracht werden. Ob und wie viele Instanzen gleichzeitig existieren, hängt dabei von der konkreten Implementierung und Konfiguration des EJB-Containers ab.

7.4.4 Stateful Session-Beans Stateful Session Beans sind in der Lage, ihren Zustand in Instanz-Variablen zu speichern. Dieser Speicher wird auch als Konversationsgedächnis bezeichnet, da sich die Bean darüber den Zustand ihrer Interaktion mit dem Client „merkt“. Im Gegensatz zu Stateless Session-Beans, bei denen einem Client für jede Transaktion ein beliebiges Bean-Objekt zugewiesen wird, arbeitet dieser im Fall von Stateful Session-Beans stets mit der gleichen Instanz. Dies ist vergleichbar mit den 6HVVLRQ-Objekten unserer Servlets, die ebenfalls über verschiedene Requests des Clients hinweg eineindeutig waren. Ein typisches EJB-Szenario für den Einsatz von Stateful Session-Beans ist ein virtueller Warenkorb, der natürlich einem Benutzer zugeordnet sein muss. Die Produkte in diesem Warenkorb könnten dann entweder Entity-Beans oder (da sie alle gleichwertig sind) Stateless Session-Beans sein. Da sich der innere Zustand dieser Beans nun von Instanz zu Instanz unterscheidet und diese bei einer Transaktion nicht mehr beliebig gegeneinander ausgetauscht werden können, muss der EJB-Container wesentlich mehr Aufwand betreiben, um diese Beans zu verwalten. Mein Tipp an dieser Stelle ist: Wenn Sie bereits über ein Session-Objekt für Ihren Benutzer verfügen (etwa weil dieser über ein WebInterface mit Ihnen kommuniziert und somit bereits eine HttpSession vom Webserver verwaltet wird), ersparen Sie Ihrem EJB-Container diesen Zusatzaufwand. Er wird es Ihnen durch einen sparsameren Ressourcenverbrauch danken. Lebenszyklus einer Stateful Session-Bean Stateful Session-Beans besitzen wie Entity-Beans einen inneren Zustand, der jedoch nicht persistent festgeschrieben werden kann. Sie stellen vielmehr den Zustand und Fortschritt eines bestimmten Geschäftsprozesses dar. Stateful Session-Beans werden deshalb nach der Anforderung aus dem Pool jedem Client exklusiv zur Verfügung gestellt und wechseln dabei zwischen aktivem und passivem Zustand hin und her, bis sie nach Beendigung der Transaktionen wieder anonymisiert werden und zurück in den Pool wandern.

211


7.4.5 Message Driven Beans Diese Beans sind die jüngsten Ableger unserer Bohnenzucht. Seit der EJB-Spezifikation 2.0 (2001) beschreibt diese die asynchrone Kommunikation von Komponenten über den Java Message Service (JMS). Message Driven Beans (MDB) sind dabei im Grunde erweiterte Stateless Session-Beans, bei denen die beiden Partner nicht mehr aufeinander warten müssen und stattdessen parallel weiterarbeiten können. MDBs werden wie alle anderen Komponenten über das Java Naming and Directory Interface (JNDI) gefunden, benötigen aber im Gegensatz zu diesen kein Home-Interface, da die Inititalisierungsmethode HME&UHDWH in jedem Fall parameterlos sein muss. Da der Client im Fall einer JMS lediglich über eine MessageQueue mit der Bean kommuniziert, wird auch kein Remote-Interface benötigt. Wie wir sehen, ist die Verwendung einer MDB für den Client vollkommen transparent. Das Einzige, was er tun muss, ist eine Nachricht mit der gewünschten Operation an das gewünschte Objekt zu senden. Da auch der Java Message Service (JMS) eine zentrale Rolle im J2EE-Umfeld spielt und MDBs lediglich eine besondere Spielart dessen darstellt, wollen wir auf diesen Typ hier nicht weiter eingehen und JMS stattdessen lieber ein eigenes Kapitel widmen. Lebenslauf einer Message Driven Bean Message Driven Beans verhalten sich in fast jeder Hinsicht wie Stateless Session-Beans. Da auch sie keinen inneren Zustand besitzen, könnte theoretisch eine Instanz der Bean alle eingehenden Nachrichten bearbeiten. In der Regel tun dies jedoch einige vom EJB-Container parallel verwaltete Instanzen.

7.4.6 Remote-Client-View vs. Local-Client-View Wenn Session-Beans dazu dienen, Geschäftsprozesse abzubilden, agieren sie dabei üblicherweise mit Entity-Beans, die daran beteiligte Geschäftsobjekte repräsentieren, oder weiteren Session-Beans, die etwa bestimmte Subprozesse kapseln. Doch jetzt stehen wir vor einem kleinen Konflikt: Für den Endanwender sind die Session-Beans entfernte Objekte, die sich im Speicher eines anderen Computers befinden (Remote-Client-View). Die Session-Bean läuft aber typischerweise in derselben Java Virtual Machine wie die Entity-Beans. Sie tritt zwar gegenüber den Entity-Beans als Client auf und kann genauso wie ein „echter“ Client über den EJB-Container mit diesen kommunizieren, doch können wir uns die Ressourcen des Serialisierens und Deserialisierens sparen. In diesem Fall sprechen wir von einer Local-Client-View, bei der die erzeugten Objekte (wie überall sonst in Java) vom Container einfach per Referenz übergeben werden. Das schont Ressourcen und geht obendrein schneller.

212

Persistenz-Typen (BMP vs. CMP)

Prinzipiell kann jede EJB sowohl über die Remote-Client-View wie auch über die Local-Client-View angesprochen werden. In der Praxis ist es jedoch ratsam, sich pro Bean für eine der beiden Sichten auf die EJB zu entscheiden, da es das Verständnis für die Anwendung erleichtert und Missverständnissen vorbeugt. Ist es dennoch erforderlich, sowohl lokal wie auch entfernt auf ein Objekt zuzugreifen, so implementieren Sie die Local-Client-View und schalten für den entfernten Zugriff einfach eine Session-Bean mit Remote-Client-View dazwischen, die alle Aktionen des „echten“ Clients an das lokale Objekt weiterleitet.

Achtung Verwechseln sie die Remote-Client-View bzw. Local-Client-View nicht mit den Remote- bzw. Home-Interfaces. Das Remote-Interface deklariert alle Methoden, über die der Benutzer der Bean (Client) mit dieser interagieren kann, während das Home-Interface die Schnittstelle zwischen EJB und dem Container bildet. Die Home-Schnittstelle ist für jeden Client unsichtbar. Remote-Client-View und Local-Client-View geben lediglich an, in welchem Speicher sich der Client befindet und ob das Objekt zwischen zwei Rechnern (Remote-Client-View) übertragen werden muss.

7.5

Aktuelle Application Server wie der JBoss erkennen selbstständig, ob der Aufruf eines Interfaces von der eigenen oder einen anderen Java Virtual Machine stammt und optimieren den Zugriff daraufhin vollautomatisch, so dass wir (in naher Zukunft) auf die Local-ClientView verzichten können und uns ganz auf die Remote-ClientView konzentrieren können.

Persistenz-Typen (BMP vs. CMP)

Wie wir sehen, müssen wir schon bei der Auswahl der verwendeten Beans Entscheidungen treffen, die sich auf die Applikation als Ganzes auswirken: So ersparen wir uns durch die Verwendung von Message Driven Beans die Definition von Remote-Interfaces für unsere Stateless Session-Beans, können dafür aber nicht mehr direkt mit der Bean in Kontakt treten, sondern müssen alle Anfragen in entsprechende Nachrichten verpacken. Eine ähnlich schwere Entscheidung müssen wir bezüglich unserer Entity-Beans treffen. Denn der Zugriff dieser auf ein persistentes Speichermedium wie die Datenbank muss gesteuert werden. Hierbei hat der Entwickler der Bean die Wahl, alles selbst zu regeln und den dafür vorgesehenen Code in der Bean zu hinterlegen. In diesem Fall sprechen wir von der so genannten Bean Managed Persistence (BMP), da die EJB elbst dafür Sorge tragen muss, dass die von ihr repräsentierten Werte mit denen der Datenbank übereinstimmen. Der Vorteil dieser Lösung ist, dass wir selbst bestimmen können wie unser SQLCode aussehen soll. Dies ermöglicht es einem datenbankerfahrenen Entwickler auch komplexe Suchanfragen oder JOINs über mehrere Tabellen in unsere Entity-Bean aufzunehmen. Auf der anderen Seite steht die so genannte Container Managed Persistence (CMP), bei der uns der Container die Aufgabe des Füllens und Speicherns der Bean abnimmt. Der Entwickler kann sich bei diesem Modell ganz auf die Anwendungslogik konzentrieren und braucht sich über JDBC-Verbindungen und SQL-Befehle keine Gedanken mehr zu machen.

213


Beim Absenden einer SQLAnfrage werden zunächst keine Daten von der Datenbank in den Arbeitsspeicher des Rechners übertragen. Erst nach einem expliziten Fetch (Abruf) werden die Datensätze der Ergebnismenge seitenweise herüberkopiert. Normalerweise bemerkt der Endanwender nichts von dieser Operation, da die JDBCImplementierung uns das Fetching abnimmt.

Gerade SQL-unerfahrene Entwickler nutzen CMP häufig gern, da die Bean in diesem Fall sehr schlank bleibt. Und auch alte „SQL-Hasen“ sollten dieser Technik eine Chance geben: Mittlerweile sind gute EJB-Container in der Lage, die Performance ihrer Persistenz-Strategie auch zur Laufzeit zu optimieren, und spezielle JDBC-Treiber ermöglichen ihm die Verwendung von SQL-Cursoren und das Prefetching vom Datensätzen, wodurch der Container die Persistenz zur Laufzeit optimieren kann.

Unter dem Prefetching verstehen wir nun, dass die JDBC-Implementierung unter bestimmten Umständen bereits mehr Daten in den Arbeitsspeicher überträgt als eigentlich benötigt werden. Dies führt, insbesondere bei großen Datenmengen, zu einem Performanceanstieg.

7.6

Wir werden später im Zusammenhang mit Java Data Objects (JDO) noch einmal mit diesem Konzept in Berührung kommen.

Bean Managed Persistence (BMP) am Beispiel

Es ist an der Zeit, die viele Theorie durch ein Beispiel mit Leben zu füllen. Ein in vielen Tutorials und Büchern ([EJB 2002]) verwendetes Beispiel ist das eines Bankkontos und auch wir wollen es hier verwenden, da es sich um ein realitätsnahes Beispiel handelt und sich damit trotzdem alle wichtigen Techniken an ihm demonstrieren lassen. Ein Bankkonto wird durch eine Kontonummer und einen Betrag repräsentiert, der entweder erhöht oder reduziert werden kann. Da sich die Bean meist auf einem geschützten Rechner (Host) befindet, hat der Anwender keine Möglichkeit, direkt auf die Bean zuzugreifen, sondern muss mit dieser über ein von EJBContainer bereitgestelltes Interface kommunizieren. Entsprechend gehen wir in diesem Beispiel von einer Remote-Client-View auf die Konto-Bean aus.

7.6.1 Voraussetzungen Wir wollen in diesem und im nächsten Kapitel die Implementation einer EntityBean besprechen, die einen typischen Kontodatensatz, bestehend aus einer Kontonummer und einem Betrag, repräsentieren soll. Dabei gehen wir davon aus, dass bereits eine entsprechende Datenbank mit der abzubildenden Tabelle Accounts existiert und via JDBC erreichbar ist. Tabelle 7.1 Datenbankschema Accounts

214

Spaltenname

Beschreibung

Primary Key?

$&&2817B180%(5

Eineindeutiger, alphanumerischer Nummerncode

Yes

%$/$1&(

Saldo des Kontos

No


Eine JavaBean für unseren Primary Key Unser Primary Key besteht in unserem Fall zwar „nur“ aus einer Zahl oder einer Zeichenkette und ließe sich auch problemlos über einen String abbilden, um diesen jedoch auch im Nachhinein erweitern zu können und zu demonstrieren, wo wir unseren Primary Key überall einsetzen, wollen wir ihn in einer eigenen JavaBean kapseln: ! "

Listing 7.1 Unser Primary Key

! #

(

# $! # % " & # ' #

! # $% "

# (

(

(

) $* & % " $ & % " & ' $ % & $ # )$ & # $%%%"

( (

! ! $% "

++ , # (

Neben den üblichen Methoden zum Lesen und Schreiben der Properties ( # ) zeichnet sich diese JavaBean durch zwei Besonderheiten aus: T Zum einen implementiert sie das Interface ! um per Serialisierung übertragen werden zu können. T Zum anderen enthält sie die Methode )$%, in der wir zunächst überprüfen, ob es sich bei dem übergebenen Objekt um eine handelt und ob die Schlüsselattribute dieser gegebenen falls identisch mit den eigenen ist. Mit dieser Technik sind wir schließlich auch in der Lage, aus mehreren Attributen zusammengesetzte Schlüssel zu erzeugen und zu verwalten.

215


7.6.2 Das Remote-Interface Die Schnittstelle, über die der entfernte Benutzer mit dem System interagiert, wird als Remote-Interface bezeichnet. Dieses Interface stellt damit so etwas wie die öffentliche Schnittstelle unseres EJB dar und muss dabei alle vom Endbenutzer benötigte Funktionalität enthalten. Listing 7.2 zeigt das Remote-Interface für unser Konto. Listing 7.2 Das Remote-Interface unseres Bankkontos

! ! " # " $% & ' ( ) $% & ' " $" % & ' " " $" % & ' *

+ In diesem Beispiel gehen wir von einer Remote-Client-View auf die Bean aus. Für eine Local-Client-View würde unser Remote-Interface vom Typ

,

ableiten, das prinzipiell die gleichen Methoden deklariert, dem Container jedoch signalisiert, dass die zurückgegebenen Objekte direkt übergeben werden können und nicht serialisiert werden müssen.

Listing 7.3 Ausnahme bei Kontoüberziehung

Da alle Methoden dieses Interfaces ein entferntes Objekt aufrufen, muss jede eine deklarieren. Daneben können wir natürlich noch beliebige andere Ausnahmen ( ) benennen, doch die ist Pflicht. Damit der Client das Objekt nach Benutzung zur Wiederverwendung an den Container zurückgeben kann, muss die öffentliche Schnittstelle vom Interface ableiten.

7.6.3 Eine Ausnahme bei Kontoüberziehung Natürlich kann man in der Realität ein Konto nicht um mehr als einen gewissen Dispositionskredit überziehen. Versucht ein Kunde dies dennoch, soll eine entsprechende Fehlermeldung erzeugt werden. - . !/ " # $( % # $% + $( * 0& ' % # $* %

+

216

+


7.6.4 Das Home-Interface Das Home-Interface deklariert Methoden, die es dem Container ermöglichen, den Lebenszyklus unserer EJB zu steuern. Während JavaBeans per Definition über einen parameterlosen Konstruktor erzeugt werden, ermöglicht es uns das Home-Interface, unsere Bean über -Methoden mit Initialisierungsparametern zu versorgen. Des Weiteren können wir hier Methodenrümpfe deklarieren, die das Wiederauffinden von bereits erzeugten Beans bzw. Datensätzen ermöglichen.

"# $ % &

Listing 7.4 Home-Interface unseres Bank-Accounts

!

#" '

($ ) * + %, *

.

&!- ! ! ( ! !+ %, *

Wie beim Remote-Interface müssen auch alle Methoden des Home-Interfaces die

/0 deklarieren. Zusätzlich existieren spezielle Ausnahmen für das Erzeugen ( ) und Wiederauffinden ( ) eines Datensatzes. Zu beachten ist dabei, dass die Methode (+ in unserem Fall ein neues Konto mit der angegebenen Bezeichnung ( ) ) und einem definierten Startguthaben ( ) erzeugt. Im wirklichen Leben könnte natürlich beispielsweise auch der Server für die Vergabe neuer Kontonummern verantwortlich sein, in diesem Fall hätte die Methode (+ nur den Parameter . Bei der konkreten Suche nach einem Datensatz hingegen verwenden wir den zuvor definierten Primary Key ( !). Hinter dieser Bean verbirgt sich zwar nichts anderes als die Kontonummer, aber schließlich war es ja Sinn und Zweck, den Schlüssel auch nachträglich anpassen zu können.

7.6.5 Die Implementierung

Auch in der Definition des Home-Interfaces spiegelt sich die Remote-Client-View unserer Bean wieder. Für eine LocalClient-View würden wir statt vom Interface

1 ableiten.

Nach all den Deklarationen ist es nun endlich so weit – wir dürfen unsere Bean mit der gewünschten Funktionalität implementieren. Doch auch die Anzahl der zu erzeugenden Methoden ist inzwischen auf ein bedeutendes Maß angewachsen. Listing 7.5 zeigt uns zunächst den schematischen Aufbau der EJB.

217


Listing 7.5 Abstrakter Aufbau unserer Konto-Bean

! "

#$

#

%$

&

' " &

( )# ( *+ ( ,! +* ( $$- #$ . *+ ) / +*

/ %" !0 $0(12 3 4 5 ** *( $4 *+ +*

/ -(60 !' 3 7888 88 *+ $, $ +*

# *+ $ +*

*+ ) +*

" *+ ) +*

$ *+ - 9 ,! / :$ - 9; +* ( " :; .< $ :; .< $ : ; .< $ : ; 9 = ( .
'( %

0 =.>>" 5, ?.8>> ( 3 @>>.. >?

> > <+?+8. 9 7 <9 7

9 7

J2EE Master Class. Einstieg für Anspruchsvolle

Softwareentwicklung: Einstieg für Anspruchsvolle (Master Class)

Excel-VBA. Einstieg für Anspruchsvolle (Master Class)

Java EE 5.0 Master Class. Einstieg fur Anspruchsvolle

Visual C# 2010. Einstieg fur Anspruchsvolle

Excel VBA Master Class

Strasbourg Master Class on Geometry

J2EE

d'artiste Matte Painting: Digital Artists Master Class

dartiste Character Modeling - Digital Artists Master Class

FR-1 Firebal

J2EE Antipatterns

Der Einstieg

J2EE Unleashed

J2EE AntiPatterns

Eine Falle fr die Medon

J2EE and XML Development

The J2EE Tutorial

J2EE Professional Projects

Das J2EE Codebook GERMAN

Einstieg Japanisch - Für Kurzentschlossene

Einstieg in XML

Class

The J2EE Architect's Handbook

J2EE Developer's Handbook

The J2EE Architect's Handbook

J2EE and XML Development

J2EE Platform Web Services

J2EE Master Class. Einstieg für Anspruchsvolle

Softwareentwicklung: Einstieg für Anspruchsvolle (Master Class)

Excel-VBA. Einstieg für Anspruchsvolle (Master Class)

Java EE 5.0 Master Class. Einstieg fur Anspruchsvolle

Visual C# 2010. Einstieg fur Anspruchsvolle

Excel VBA Master Class

Strasbourg Master Class on Geometry

J2EE

d'artiste Matte Painting: Digital Artists Master Class

dartiste Character Modeling - Digital Artists Master Class

FR-1 Firebal

J2EE Antipatterns

Der Einstieg

J2EE Unleashed

J2EE AntiPatterns

Eine Falle fr die Medon

J2EE and XML Development

The J2EE Tutorial

J2EE Professional Projects

Das J2EE Codebook GERMAN

Einstieg Japanisch - Für Kurzentschlossene

Einstieg in XML

Class

The J2EE Architect's Handbook

J2EE Developer's Handbook

The J2EE Architect's Handbook

J2EE and XML Development

J2EE Platform Web Services

Recommend Documents