magazinJava • Architekturen • SOA • Agile

10 Regeln der Modernisierung »90

www.javamagazin.de

IntelliJ IDEA 9Neue Version und Open-Source-Strategie »17

Offshoring JavaWas bedeutet der Strukturwan-del im IT-Bereich » 80

InterviewMit Craig Russell hinter den Kulissen von JPA 2.0 » 14

CD-INHALT

Österreich € 9,80 Schweiz sFr 16,80Deutschland € 8,50 1.2010

EXKLUSIV

IBM WebSphere

Application Server

Community Edition DVD

Alle CD-Infos ab Seite 3

JSF 2.0 – A Complete Tour

Session von der JAX 2009

in voller Länge

CDinkl

.

Java Magazin 1.2010

Google W

eb Toolkit JSF-Tutorial

Ajax-Framew

orks BPEL

Interview m

it Craig Russell

JAVA

Mag

Ajax 360 GradFrameworks auf einen Blick »41

Open-Source-OrchesterModellierung von Geschäftsprozessen mit BPEL »62

Das Tutorial zu JSF 2.0Bean-Management, Navigation und mehr »30

Was sich dahinter verbirgt »50

Was bringt GWT 2.0 »54

GoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleWeb Toolkit

DIE HIGHLIGHTS Google Web Toolkit

Spring Batch

Klaros-Test-management

Wie man das Außergewöhnliche in alltägliche Dinge hineinbringt.

Intelligente Technologien für einen smarten Planeten

Schon in einem Jahr werden mehr als 100 Millionen Zeilen Software-Code die Elektronik eines ganz normalen Autos steuern – bei einem Passagierflugzeug über 1 Milliarde. Wir erreichen bald einen Punkt, an dem ein Auto, eine Bank oder ein Flugzeug mehr als nur die Summe ihrer Einzelteile sind. Was all diese Dinge tatsächlich auszeichnet, ist die zugrundeliegende Software – dieses unsichtbare Netz, das alles mit Intelligenz durchdringt. Kein Wunder, dass im letzten Jahr schon 66 % aller entwickelten Produkte mit eingebetteter Software liefen. Heute ist Software von zentraler Bedeutung, um Unternehmen strategisch auszurichten. Aber: 41% aller Software-Projekte scheitern immer noch daran, den Geschäftsnutzen und die Rentabilität zu steigern. IBM hat die einmalige Erfahrung, die Ressourcen und die Lösungen, damit international führende Unternehmen Software effizient entwickeln und bereitstellen können.

Smarte Unternehmen brauchen intelligente Software, Systeme und Services. Also: Machen wir den Planeten ein bisschen smarter. Wie, erfahren Sie unter ibm.com/delivery/de

IBM=IT 9/10/33, IBM “Delivery”, 210 x 297 mm, 4c, DTP: J:Böhme, Titel: Java30005964_210x297_IBM-IT 9 10 33_Delivery_Java_39l.indd 1 16.10.2009 15:32:46 Uhr

javamagazin 1|201050 www.JAXenter.de

er Browser hat sich zur belieb-testen Anwendungsplattform entwickelt. Allerdings müssen

Webanwendungen den hohen Anforde-rungen der Nutzer in Bezug auf Antwort-zeiten in der Nutzung und Bedienbarkeit gerecht werden. Webanwendungen ent-wickeln sich immer mehr zu „Anwen-dungen“ und verdrängen die native Kon-kurrenz. Google hat mit Google Maps, Google Docs, Google Wave & Co. längst bewiesen, dass Webanwendungen viel mehr können als ursprünglich vermutet.

Titelthema Webanwendungen mit GWT

GWT – Was ist das?Seitdem das Google Web Toolkit [1] auf der JavaOne 2006 vorgestellt wurde, erfreut sich das Projekt immer größerer Beliebtheit. Mit GWT kann ein Java-Entwickler schnell in die Lage versetzt werden, Ja-vaScript/Ajax-Anwendungen zu schreiben. Die Nachfrage nach der so genannten „Ajaxifi zierung“ ist groß und immer mehr Projekte sollen mit JavaScript im Browser dem Trend des Web 2.0 folgen: von intelligenter Validierung über Drag and Drop bis hin zu Mashups.

von Papick Taboada

Gerade Kalenderanwendungen galten sehr lange als nicht webanwendungsfä-hig. Mit den in HTML 5 vorgesehenen Erweiterungen werden zum Beispiel O� inefähigkeit, 2-D-Gra� ken als letz-tes Alleinstellungsmerkmal von Rich Clients endgültig fallen. Interessanter-weise haben inzwischen alle modernen Browser (außer dem Internet Explorer) die wichtigsten Neuerungen aus HTML 5 bereits implementiert.

Was aber ist das Google Web Tool-kit? Kurz: eine Technologie bzw. ein

Framework, mit dem JavaScript-Web-anwendungen erstellt werden können. Das Besondere am GWT-Entwick-lungsprozess ist nicht nur das Ergebnis, sondern auch die Vorgehensweise: Der Entwickler schreibt die gesamte Weban-wendung in Java. Der Trick besteht da-rin, den Java-Quelltext nach JavaScript zu übersetzen, sodass die Vorgehens-weise das Nutzen aller Fähigkeiten der IDE wie das Refactoring und Debuggen im clientseitigen Code ermöglicht. Das Google Web Toolkit bietet ein gra� sches

www.JAXenter.de 51javamagazin 1|2010

Webanwendungen mit GWT Titelthema

UI-Komponentenmodell, ein Modu-larisierungskonzept, eine fragmentari-sche Java-Runtime-Emulation, ein API zur Manipulation der Browser-History, eine eigene RPC-Implementierung, Internationalisierung und noch eini-ges mehr. Hier Googles Leitspruch für GWT: „GWT's mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser“ [2]. Frei übersetzt bedeutet das eine radikale Verbesserung

bei der Verwendung von Webanwen-dungen (für den Endanwender). Beste-hende Java-Werkzeuge sollen eingesetzt werden, um ohne Einschränkungen Ajax-Anwendungen auf beliebigen Browsern zu entwickeln. Und genau hier liegt die Stärke in dem Ansatz: Wir können unsere angesammelte Erfah-rung aus der So� wareentwicklung mit Java übernehmen. Schlagwörter wie Entwurfsmuster, Refactoring, Debug-ging, statische Codeanalyse, Unit Tes-ting und Wiederverwendbarkeit stehen

nicht mehr auf Kriegsfuß mit der Web-entwicklung. Nicht umsonst heißt es, dass GWT Software-Engeneering zur Webentwicklung bringt.

Es ist schon beeindruckend, was sich hinter dieser neuen Technologie ver-birgt. Allerdings wurde ich nicht selten mit der Aussage „Aber es ist von Goog-le!“ konfrontiert. Schon seit einiger Zeit hat Google das Image des sauberen klei-nen Start-ups verloren. Google ist groß, Ziele und Mittel teilweise umstritten. An dieser Stelle erst einmal eine Entwarnung

GoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleGoogleWeb Toolkit

Titelthema Webanwendungen mit GWT

javamagazin 1|201052 www.JAXenter.de

– auch wenn Google draufsteht, ist kein Google drin. Durch die Verwendung von GWT werden keinerlei Dienste von Google verwendet. Es ist, wie viele an-dere sehr interessante Projekte aus dem Hause Google, ein Nebenprodukt aus einer sehr großen Softwareschmiede. An dieser Stelle sei zum Beispiel Google Collections genannt, die eine Erweite-rung des Java Collection APIs darstellen. Google verfolgt mit GWT zwei einfache Ziele: Erstens wird GWT intern für die Entwicklung von Webanwendungen eingesetzt, zweitens macht GWT es sehr einfach, JavaScript-Anwendungen zu schreiben. Google hat natürlich nichts dagegen, wenn sich immer mehr Pro-dukte bei anderen Google-Technologien bedienen – zum Beispiel Google Search oder Google Maps. Wenn die Hemm-schwelle hier bislang bei den nötigen JavaScript-Kenntnissen lag, so ist diese mit GWT letztendlich behoben worden: „Naturally, GWT is also a great way to easi ly take advantage of the latest-and-greatest Google APIs and browser en-hancements, such as Google Gears“ [3].

GWT ist heute „production ready“: Es ist seit Version 1.3 unter der Apache License 2.0 veröffentlicht und seit Versi-on 1.4 trägt GWT nicht mehr den Zusatz „Beta“ im Namen. Die aktuelle Versions-nummer lautet 1.7.1 und kann von der GWT-Homepage in Google-Code her-untergeladen werden. Das GWT-Team arbeitet gerade an der neuen Version 2.0, mehr dazu in dem folgenden Artikel von Michael Seemann (S. 54).

Die Technologie

GWT kann einerseits als Technologie und andererseits als Framework betrachtet werden. In der technologischen Betrach-tung wird die Vorgehensweise erläutert, anhand derer mit GWT Webanwendun-gen entwickelt werden. Eine dynami-sche Java-Webanwendung – wie wir sie ohne Ajax kennen – ist prinzipiell eine Ansammlung von einzelnen Seiten, die miteinander verlinkt sind. Eine Anwen-dung entsteht letztendlich dadurch, dass diese Seiten auf gemeinsame Sitzungsda-ten zurückgreifen (Server Session State). Die einzelnen Seiten werden serverseitig erzeugt und per HTTP an den Browser geschickt. Was sich einfach anhört, wird

schnell zum Wartungsalptraum. Die bun-te Vielfalt an Frameworks aus dem Java-Umfeld versucht Ordnung in die eine oder andere Facette der Entwicklung von Web-anwendungen zu bringen, und zwar mit dem Ziel, eine höhere Wartbarkeit und Änderbarkeit zu erreichen. Von MVC über Templating, XSL-Transformationen und aufwändigen serverseitigen GUI-Komponentenmodellen werden dem gemeinen Java-Entwickler im Enterprise-Bereich viele Ansätze angeboten.

Seit eine Webanwendung mit Ajax asynchrone Aufrufe zum Server aus-führen kann, ist die Notwendigkeit des „Seitenhüpfens“ nicht mehr gegeben. Allerdings müssen die HTML-Seiten so gestaltet werden, dass Teile ohne ei-nen Seitenaufruf neu erstellt bzw. aus-getauscht werden können, damit die im Hintergrund geladenen Daten auch an-gezeigt werden können. Hier kommen schließlich CSS, JavaScript und HTML ins Spiel. Die bösen Drei, auch DHTML genannt, sind – wie schon Ajax – defi-nitiv nichts Neues. Allerdings sind die Unterschiede zwischen den modernen Browsern und sogar zwischen einzelnen Versionen eines Browsers so groß, dass es praktisch unmöglich ist, DHTML effi-zient in Projekten einzusetzen.

Dank Ajax und DHTML entfällt der Gedanke des Request-Response-Zyklus dynamischer Webanwendungen, wie wir es von JSP und JSF kennen. Die in JavaScript geschriebene Anwendung im Browser ist in der Lage, selbstständig nach Daten zu fragen und die Anzeige zu aktualisieren. Diese Technik wird schon oft in bestehenden Anwendungen ein-gesetzt, um beispielsweise Suchergeb-nisse einzublenden, ohne dass die Seite neu geladen werden muss. Eine GWT-Anwendung ist die Weiterführung die-ses Gedankens: Nicht nur Teile werden „ajaxifiziert“, sondern gleich die gesam-te Anwendung. In diesem Sinne ist eine GWT-Anwendung aus Serversicht eine statische Webanwendung, die ähnlich wie Flash-Anwendungen oder auch Applets lediglich einmal geladen wird. Ein Applet wird den Server nur aufru-fen, um neue Daten zu erfragen oder um eine Benutzereingabe an den Server zu schicken. Ein Applet, das keine Dienste des Servers benötigt, wird nur einmal

geladen und ist autonom (oder auch off-linefähig). Das gleiche Prinzip gilt auch für GWT-Anwendungen. Sie laufen autonom im Browser und werden nur dann einen Server benötigen, wenn des-sen Dienste gefragt sind. So hat der erste Aufruf der Anwendung prinzipbedingt eine größere Antwortzeit als die einer klassischen Webanwendung, da die ge-samte Webanwendung geladen wird.

Keine Lust auf Last?

Dank der Java Servlets und JSP-Spezi-fikation haben wir Technologien bzw. Laufzeitumgebungen bereitgestellt be-kommen, die sehr effizient mit den Ser-verressourcen umgehen. Neue Techno-logie-Stacks sollten dies nicht ändern. Während JSP und Servlets eine leicht-gewichtige Laufzeitumgebung mit spei-cherpersistenten Servlets zur Verfügung stellen, tauchen die Skalierungsprobleme schließlich mit weiteren einzusetzenden Technologien auf. Sobald es sich nicht um eine Prototyp- oder eine Intranetan-wendung für eine überschaubare Menge an Endanwendern handelt, sollte man sich kritisch mit dem Problem der Last und der Skalierbarkeit auseinanderset-zen. Dabei muss berücksichtigt werden, wie hoch der serverseitige Aufwand pro Sitzung ist. So können bereits die Daten-bankverbindungen zum Engpass wer-den oder grobe Programmierfehler (zu viele neue Objekte pro Request, zu viele Exceptions) den Server in die Knie zwin-gen. Aufwändige serverseitige Verarbei-tung ist in Bezug auf Performance und Skalierbarkeit kritisch zu betrachten, da der Ressourcenverbrauch entsprechend mit der Anzahl der Requests steigt.

Die meisten Java-Webframeworks haben eines gemeinsam: Sie sind in Ja-va geschrieben und werden serverseitig ausgeführt. Webseiten werden server-seitig erstellt und schließlich dem Brow-ser übertragen. Man spricht an dieser Stelle von dem „Rendern“ der Webseite, das dynamisch serverseitig stattfindet. GWT geht hier einen anderen Weg: Die Webanwendung wird einmalig übertragen. Die eigentliche JavaScript-Anwendung ist aus Serversicht eine Ansammlung statischer Ressourcen, die sogar von einem vorgelagertem Apache-Webserver ausgeliefert werden können.

TitelthemaWebanwendungen mit GWT

www.JAXenter.de 53javamagazin 1|2010

Hier besteht keine Notwendigkeit, die Servlet-Engine in Anspruch zu nehmen: Das „Rendern“ der Anwendung findet ausschließlich im Browser statt und spart Ressourcen auf dem Server. Die Kommunikation auf dem Server wird auf ein Minimum reduziert, es werden lediglich Daten hin und her geschickt.

Die Vorgehensweise

GWT liefert den GWT Compiler, der Java nach JavaScript übersetzt. Dieser führt nicht nur eine einfache lexikalische Übersetzung durch, sondern ist zudem in der Lage, Optimierungen vorzuneh-men. So wird zum Beispiel unbenutzter Code nicht übersetzt und das Ergebnis auf Wunsch komprimiert. Die Imple-mentierung von DHTML ist in mo-dernen Browsern leider alles andere als kompatibel. Aus diesem Grund erzeugt der GWT Compiler für jeden Browser und für jede Sprache die entsprechen-den JavaScript-Dateien. So wird in je-nem Browser nur das JavaScript ausge-führt, das auch wirklich vom Browser verstanden wird. Dadurch wird die tat-sächliche Menge an JavaScript- Quell-text, der zur Laufzeit im Browser be-nötigt wird, reduziert. Aus dem in Java vorhandenen Konzept des Java Native Interface (JNI) wurde JavaScript Native Interface (JSNI), ein einfacher Weg, na-tiven JavaScript direkt in der Java-Klasse einzubinden. So werden beispielsweise Aufrufe von Fremdbibliotheken ermög-licht. Prominentes Beispiel an dieser Stelle ist die Brücke von GWT zu Google Maps: Es werden Java-Klassen bereit-gestellt, die das Google Maps API kap-seln. Ein GWT-Projekt hat ein teilweise vorgeschriebenes Layout. Für die ersten Gehversuche mit GWT lautet die Emp-fehlung, sich auch tatsächlich an dieses zu halten. GWT liefert ein paar Skripte aus, mit denen Beispielprojekte angelegt werden können. In den Beispielen und Anleitungen, die mit GWT geliefert wer-den, wird die Eclipse IDE verwendet.

Google hat mit dem Dreifachrelease im April nicht nur GWT 1.6 (keine Über-raschung), ein Google-Plug-in (Überra-schung) und AppEngine für Java (sehr große Überraschung) herausgebracht. Seitdem ist es möglich, GWT-Anwen-dungen direkt aus der Entwicklungsum-

gebung in Googles Cloud zu installieren. Also findet die Entwicklung zum Beispiel in Eclipse mit dem Google-Eclipse-Plug-in statt. Eine GWT-Anwendung wird aus der Entwicklungsumgebung heraus im so genannten Hosted-Modus (ab 2.0 wird es dann Developer-Modus heißen) ausge-führt. Im Hosted-Modus wird ein Fenster (die Development Shell, mit einem Jetty als Webserver) und ein spezieller Browser gestartet. In diesem Modus wird der Java-Bytecode der Anwendung ausgeführt – es findet also noch keine Übersetzung in JavaScript statt: Änderungen im Quell-text (sofern diese dann automatisch von der IDE übersetzt werden) werden sofort in der laufenden Anwendung sichtbar. Über diesen Mechanismus wird auch das Debuggen der Webanwendung im Java-Code ermöglicht. Eine Übersetzung kann per Knopfdruck aus der Develop-ment Shell heraus ausgelöst werden. Erst dann kann man mit beliebigen Browsern die Anwendung testen. Diese Vorgehens-weise wurde technisch komplett neu ent-wickelt und wird im Folgeartikel zu den Neuerungen aus GWT 2.0 vorgestellt, Stichwort „OOPHM“.

Das Framework

Das mit GWT gelieferte Framework ist recht umfangreich, daher an dieser Stelle nur ein kurzer Überblick über das Kom-ponentenmodell. Neben Swing, SWT und JSF hat der Java-Entwickler jetzt ein neues Komponentenmodell erhalten, denn GWT führt ein eigenes UI-Kom-ponentenmodell ein:

Widgets sind grafische Komponenten, wie z. B. eine Textbox, ein Button oder eine Checkbox

Panels sind Widgets, die ganz nach dem Entwurfsmuster des Composite-Patterns wiederum Widgets aufneh-men können

Neben den Standardkomponenten, die wir von HTML kennen, finden sich hier auch komplexere UI-Elemente wie etwa Tree, TabBar, SplitPanel und Dialog-Box. GWT versucht dem Web bzw. den HTML-Komponenten treu zu bleiben. Hierzu ein Zitat aus einer GWT-Prä-sentation während der Google Devel-oper Days: „Wir wollen unseren Eltern das Web nicht neu beibringen müssen. Es soll nicht anders, sondern nur bes-ser werden“. Hier grenzt sich GWT von jenen Frameworks ab, die einen Rich Client nachahmen oder ganz neuartige Benutzerführungen anstreben, wie z. B. RAP oder OpenLaszlo. Das Kompo-nentenmodell von GWT ist erweiterbar. Dank Vererbung können sehr einfach neue eigene Komponenten aus den vorhandenen Komponenten gebildet werden. Es können auch neue Kompo-nenten gebildet werden, die von Grund auf neu sind oder sogar fremdes, natives JavaScript einsetzen.

Fazit

Unumstritten ist Googles Erfahrung mit Web-2.0-Anwendungen – sowohl Google Maps als auch Google Mail sind Anwendungen, die das Unmögliche möglich gemacht haben. Dank GWT können jetzt Java-Entwickler an den Browsereigenarten vorbei sauberen JavaScript-Code erzeugen. Die durch GWT eingeführte Vorgehensweise in der Entwicklung ist effizient und ähnelt der Vorgehensweise bei der Entwicklung von Rich Clients mit Java. Der Einstieg in die Technologie wird dadurch sehr erleichtert. Wenn Web 2.0 sich als Inte-grationsplattform durchsetzt und der Browser die am häufigsten verbreitete Anwendungsplattform bleibt, so wurde mit GWT sicherlich ein Meilenstein in der Geschichte moderner Webanwen-dungen geschaffen.

Papick Taboada ist Softwarearchitekt und Technology Scout. Schwer-punkte seiner Arbeit liegen in der Konzeption und Erstellung von Soft-warearchitekturen im Java-EE-Umfeld mit Open-Source-Technologien. Mit GWT setzt er sich bereits seit 2007 auseinander und hat praktische GWT-Erfahrung in Projekten gesammelt. Seine Erfahrungen gibt er auch als

Coach und Trainer weiter. In den vergangenen Jahren hielt er verschiedene Vorträge auf namhaften Konferenzen und veröffentlichte Artikel in anerkannten Fachzeitschrif-ten. Kontakt: pgt@pgt.de.