Java aktuell

Ungewisse Zukunft:

Die Gerüchteküche um Java

Java

aktu

ell

Mag

azin

der

Java

-Com

mun

ity

D: 4,90 EUR A: 5,60 EUR CH: 9,80 CHF Benelux: 5,80 EURwww.ijug.eu

Erfahrungen, Ideen und Lösungen für Java-Entwickleriiiiii iii

iiiiJUGVerbund

Rapid Java Development

Tipps zur Java- Zertifizierung

AJAX vs. Java & Co.Außerdem: Interview mit Ed Burns

Das iJUG Magaziniiiiii iii

iiiJavaaktuellFRÜH

JAHR

2011NEU

02/2011 Copyright © 2009, Oracle. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates.

Other names may be trademarks of their respective owners.

Telefon: 0800 – 18 10 111www.oracle.com/de/middleware

#1# 1 in Application Servers

# 1 in Application Infrastructure Suites

# 1 in Enterprise Performance Management

Middleware

RZ Anzeige Middleware DIN A4 20090722.indd 1 22.07.2009 15:58:34 Uhr

4191978

304903

02

ISSN 2191-6977

Java aktuell Q1-2011 | 3

iiiiii iii

iii

Ein Java für alle

Die Sache bleibt spannend. Die Zukunft von Java ist ungewiss, die Gerüchteküche bro-delt. Seit der Übernahme von Sun durch Oracle sind viele Java-Anwender verunsichert, Oracle hält sich mit klaren Aussage weitgehend zurück. Die ersten Java-Entwickler sehen sich bereits nach Alternativen um. Auch die Community ist aktiv, auf Blogs werden Mög-lichkeiten diskutiert, wie Harmony und einen Fork vom OpenJDK zu einer eigenständige Sprache zusammenzulegen – unabhängig von Oracle. Die Vision klingt verlockend, denn damit könnte man gleich etliche Altlasten entsorgen und hätte Apache, Google etc. wie-der mit im Boot.

Viele Entwickler würden sich sicher für dieses offenere „Java reloaded“ entscheiden, die anderen blieben wahrscheinlich eher beim kommerziell ausgerichteten Original. Beiden Welten wären jedoch nicht vollständig kompatibel zueinander. Letztlich fahren dann zwei Communities mit halber Kraft, und am Ende verlieren vielleicht alle. Zudem würde Oracle den Bestrebungen zu einem neuen offenen Java sicher nicht tatenlos zuschauen. Massive Behinderungen und Patentklagen könnten die Bestrebungen über Jahre blockieren.

So gesehen kann eine Spaltung nicht im Sinne der Community sein – höchstens dann, wenn Java unter Oracle wirklich einen völlig falschen Weg einschlägt. Momentan kann das Ziel jedoch nur lauten: „Ein Java für alle“.

Ein anderes Thema: Ende letzten Jahres hat der Interessenverbund der Java User Groups e.V. (iJUG), Herausgeber der Java aktuell, Zuwachs bekommen: Zu den neun Gründungs-mitgliedern hat sich die Swiss Oracle User Group (SOUG) gesellt (siehe Seite 37). Zumin-dest hier stehen die Zeichen eindeutig auf „Eine Community für alle“.

Ich wünsche Ihnen viel Spaß beim Lesen dieser Zeitschrift und freue mich auf Ihr Feed-back an [email protected].

Ihr

Wolfgang TaschnerChefredakteur Java aktuell

Editorial

Capta

inCasa

Ente

rpri

se C

lient

CaptainCasa

Wow!...mit Sinn und

Verstand!

Die Entwicklungseffizienz

in vielen Rich Client Projekten

ist dramatisch schlecht.

CaptainCasa Enterprise Client

gibt Ihnen die Effizienz

wieder, die Sie benötigen,

um anspruchsvolle, operativ

genutzte, langlebige

Anwendungen erfolgreich

zu erstellen.

CaptainCasa basiert auf

Java Standards und bietet:● exzellente Interaktivität● hochwertige Controls● klare Architektur● einfache, Server-basierte

Entwicklung

CaptainCasa Enterprise Client

ist Community-basiert und

frei nutzbar.

http://www.CaptainCasa.com

Java Frontend

JSF Backend

http(s)

4 |

iiiiii iii

iii3 Editorial

Wolfgang Taschner

5 Interview mit Ed Burns: „Für mich ist der Übergang von Sun zu Oracle ein guter Wechsel …“

7 Das Java-TagebuchAndreas Badelt

12 JavaFX UpdateOliver Szymanski

13 Die Java-Zertifizierung „Sun Certified Java Programmer“ – ein ErfahrungsberichtKai Wähner

16 Single Sourcing mit JVxRené Jahn

19 Direct-Call-PatternOliver Szymanski, David Tanzer

20 Rapid Java mit XDEV 3Gerald Kammerer

25 Fragile Agilegelesen von Andreas Badelt

26 Code-GenerierungDavid Tanzer

28 BPM-Lösungen mit Java EE selbst gebautRalph Soika

32 Cloud in a BoxJens Dollenbacher

34 AJAX-Entwicklung wie SwingGerald Kammerer

38 JSXP-TemplatesDavid Tanzer

39 Java-Entwicklung wie Oracle Forms geplant Markus Stiegler

40 Integration mit Launch4j – der letzte SchliffDr. Stefan Koch

42 Java-Coherence-Cache-Architektur Wolfgang Weigend

45 OSGi-Scripting mit GroovyDirk Mahler

48 Von Oracle Forms auf JavaHans Niedermeier

51 AJAX vs. Java & Co.Markus Stiegler

56 Intelligente Migration?Matthias Pfau und Berthold Maier

Inhalt

58 GlassFish Open Source Server 3.0 – ein Vorgeschmack auf die Application-Server der nächsten GenerationPeter Doschkinow

61 Testen mit JUnit für FortgeschritteneJens Schauder

66 Eclipse Rich Client PlatformJürgen Thierack

47 Impressum

65 Unsere Inserenten

„Das Java-Tagebuch“, Seite 7

Interview mit Ed Burns, Spec lead für JSF, Seite 5

Ein Erfahrungsbericht zur Java-Zertifizierung „Sun Certified Java Programmer“, Seite 13

Ungewisse Zukunft: Die Gerüchteküche um Java


iiiiii iii

iii

„Für mich ist der Übergang von Sun zu Oracle ein guter Wechsel …“Oliver Szymanski (auf den Fotos rechts), Vorstand des iJUG, traf sich am Rande der DOAG 2010 Konferenz + Ausstellung mit Ed Burns, Spec Lead für JSF bei Oracle.

Wie hat sich das Leben durch den neuen „Be-sitzer“ von Java verändert?

Ed Burns: Es gibt zwei Antworten. Zu-nächst hat sich nur der Name auf der Ge-haltsabrechnung geändert. Es ist sehr gut, dass es noch Gehalt gibt. Auch die Konti-nuität hält an. Auf der anderen Seite hat sich die gesamte Philosophie verändert. Sun war ein von Technikern getriebenes Unternehmen. Wir erfanden die Technolo-gie, hatten sie und suchten Märkte. Oracle ist anders, mehr produktbezogen und auf die Werte der Anteilseigner fokussiert. Das ist ein guter Weg, um sich auf etwas zu konzentrieren und die Software mehr in den Mittelpunkt zu stellen. Für mich ist es ein guter Wechsel.

Was ist der größte Unterschied zwischen Oracle und Sun?

Ed Burns: Oracle ist viel größer und bietet mehr Tools. Es ist einfach schön, in einem größeren Team zu arbeiten und mehr Res-sourcen zur Verfügung zu haben.

Kommen wir zu der Technologie, die du re-präsentierst. Wie ist die Zukunftsvision von JSF?

Ed Burns: Wir haben im Juli 2009 die Ver-sion 2.0 herausgebracht. Für Ende 2010 ist ein größeres Maintenance-Release 2.1 geplant. Darin sind einige Fehlerbehe-bungen enthalten, die Konvertierung von JSP nach Facelets wird einfacher und es gibt neue Möglichkeiten, um Zustände zu speichern, zum Beispiel Zustände in Komponenten, die nur im Request Scope gültig sind. So lässt sich in einer Tabelle eine einzige Zeile oder Zelle gezielt ren-dern. Anfang 2011 kommt dann ein neuer JCP für JSF, es wird JSF 2.2 für Java EE 7 sein.

Wird es darin viele neue Features für Entwick-ler geben?

Ed Burns: JSF 2.2 wird einige neue Fea-tures haben wie HTML5-Unterstützung oder die Datei-Upload-Komponente. JSF 2.0 benötigte AJAX, das war Pflicht, sonst

DOAG @talk: Interviews und Gespräche

Das Interview mit Ed Burns ist in englischer Sprache auf Youtube unter http://www.youtube.com/watch?v=SdNMRkR_vM8 zu sehen.

wäre es mit JSF aus gewesen. Ich denke, der nächste JSR für JSF braucht HTML5. Wir sind in einer guten Position dafür. Für HTML5 haben wir bereits die Separierung von Komponenten-Semantik vom Ren-derer. Es gab immer die XML-Puristen, die Presentation von Rendering trennen wollten – SGML hatte das bereits zum Ziel. Dann kam HTML und packte alles wieder zusammen. Jetzt wird endlich eini-ges an Semantik wieder ausgelagert, bei-spielsweise kann der Browser die neuen HTML5-Range-Tags als Slider oder etwas anderes rendern. Somit bietet HTML5 et-was, das wir in JSF schon lange unterstüt-zen.

6 |

iiiiii iii

iii

Zur Person: Ed Burns

Ed Burns ist derzeit Berater in der Tech-nical Group von Oracle America, Inc. Er leitet die Spezifizierung von JavaServer Faces, dem Standard Web-Applications-Framework fur Java EE. Ed Burns führt in dieser Position seine Arbeit von Sun fort. Er leitet ein Team von Web-Experten aus verschiedenen Industriebereichen, um die JavaServer-Faces-Technologie innerhalb des Java Community Process als Open Source weiterzuentwickeln. Sein Interesse gilt Web-Applications-Frameworks, AJAX, der Reduzierung von Komplexität, Test-driven Development, dem Sammeln von Anforderungen und der computerunterstützten Zusammen-arbeit. Bevor er sich mit JavaServer Faces beschäftigte, arbeitete Ed Burns seit 1994 an verschiedenen Client-/Server-Web-Technologien wie NCSA Mosaic, Mozilla, das Sun Java Plugin, Jakarta Tomcat, das Cosmo Create HTML Authoring-Tool, und dem Web-Transport-Layer im Irix Betriebs-system von Silicon Graphics.Ed Burns besitzt den Bachelor of Compu-ter Science von der Universität Illinois in Urbana-Champaign. Während des Stu-diums belegte er Deutsch als Nebenfach und arbeitet für IBM, wo er seine Vorliebe für Computer-Geschichte entdeckte, als er mit der Office-Software des Systems /370 arbeitete. Ed Burns hält häufig Vorträge auf inter-nationalen Konferenzen, darunter etliche Male auf der JavaOneSM Konferenz.

Wenn du selbst frei entscheiden könntest, was würdest du in JSF ändern?

Ed Burns: JSF ist ein sehr stabiler Standard. Ich denke, es ist an der Zeit, etwas auf der Basis von JSF zu machen, möglicherwei-se einen neuen JSR zur Standardisierung der nützlichen Komponenten. Es gibt eine breite Palette an reichhaltigen Komponen-ten wie RichFaces, ICEFaces, PrimeFaces oder ADF. Ich würde gerne die wichtigsten identifizieren und in den Standard auf-nehmen. Die Herausforderung ist, dabei den Markt für Komponenten nicht zu ent-täuschen, denn dieser ist der Schlüssel für den Erfolg von JSF. Der ideale Weg wäre, wenn sich Komponenten-Bibliotheken un-terscheiden, aber dennoch die Messlatte für Standard-Komponenten höher gelegt werden kann.

Wie arbeitet ein so großes Team zusammen, das in JSF involviert ist?

Ed Burns: Das Team ist weit verteilt. Es ist aber nicht so groß, wenn man es mit den Oracle-Development-Teams vergleicht. Wir bekommen Unterstützung von vie-len, die Code einreichen. In meinen Prä-sentationen zeige ich immer ein Slide mit allen Gesichtern. JSF ist ein typisches Open-Source-Projekt – es gibt Personen mit unterschiedlich verfügbarer Zeit und verschiedenen Arbeitsplänen. Wir haben einen IRC-Channel (Internet Relay Chat) und benutzen IM (Instant Messaging). Ich bevorzuge IRC, damit andere sehen, was gerade vor sich geht. Das ist gut für das Teamgefühl. Und wir haben eine offene Mailingliste.

Bei Java gibt es den Java Community Process (JCP). Wie lebt ihr den Community-Gedanken in einem realen Projekt wie JSF?

Ed Burns: Wir nutzen viel von dem Spiel-raum, den uns der JCP für den Spec Lead gibt, und versuchen, so offen wie möglich zu sein. Wir sind die erste EE Spec, die eine öffentliche Open-Source-Referenz-Implementierung hatte, sowie bereits seit 2004 eine transparente Entwicklung. Wir machen unseren JCP-Prozess sehr durch-sichtig und haben eine Mailingliste, die lesbar allen zur Verfügung steht. Jeder kann sich anmelden. Die JSF-Experten, die im JSPA eingetragen sind, sind Teil der JSP-Expertengruppe. Darüber hinaus gibt es die erweiterte Expertengruppe für Personen, die wir kennen und die lei-tend in der Community sind. Diese haben Schreibrechte.

Du hast ein Buch über JSF2 geschrieben. Deckt es alle Inhalte ab, die Entwickler benö-tigen?

Ed Burns: Ich habe das Buch und die JSF-Spec im selben Zeitraum geschrieben und denke, es deckt die wichtigsten und meis-ten Dinge ab. Es gibt einige Themen, die ich gerne detaillierter beschrieben hätte, aber leider fehlte mir dazu die Zeit. Viel-leicht hole ich das in der Neuauflage von „Java Server Faces 2.0, The Complete Refe-rence“ nach, das ich mit Chris Schalk und Neil Griffin im McGraw-Hill-Verlag veröf-fentlicht habe.

Vielen Dank für das Gespräch!


iiiiii iii

iii

Das Java-TagebuchAndreas Badelt, Leiter SIG Java, DOAG Deutsche ORACLE-Anwendergruppe e.V.

Seit Oracle Sun und damit Java übernommen hatte, gab es viele Fragen und noch mehr Gerüchte, welche Strategie der neue Eigentümer mit Java verfolgen wird. Die Gerüchteküche brodelte, und Oracle selbst hielt sich ziemlich bedeckt.

Es gab eine Reihe von Erklärungen, die auch in der letzten Ausgabe der Java ak-tuell standen, aber viel Substanzielles war in den offiziellen Statements nicht enthal-ten – letztlich wurde immer wieder darauf verwiesen, dass Oracle erst einmal Zeit be-nötigt, um eine publizierbare Strategie zu entwickeln. Dies sollte, so hieß es immer wieder aus dem Hause Oracle, Ende Sep-tember 2010 geschehen, auf den nun ge-meinsam in San Francisco stattfindenden Konferenzen OpenWorld und JavaOne.

Tatsächlich wurde dort auch einiges an Neuigkeiten verkündet. Mindestens eben-so spannend waren aber die Geschehnisse in den Tagen vor und den Wochen nach diesen Konferenzen. Mit dem „Java-Tage-buch“ möchte ich in komprimierter Form einen Blick auf die Ereignisse rund um das Thema „Java“ werfen: auf Ankündigungen von Oracle und anderen wichtigen Java-Kontributoren ebenso wie auf Kommenta-re aus der „Community“, auf die entschei-denden Presse-Erklärungen ebenso wie auf die kleineren Themen am Rande. Alles aus meiner subjektiven Sicht, aber den-noch mit dem Ziel, einen guten Überblick über die Entwicklungen zu geben. Begin-nen möchte ich mit dem Tag vor dem of-fiziellen Start der „Open World“ – an dem erstmals seit längerer Zeit wieder Konkre-tes zu Java verkündet wurde.

20. September 2010

„It’s time for … Plan B“... so steht es im Blog von Mark Reinhold, dem „Chef-Architekten“ der Java-Plattform (http://blogs.sun.com/mr/entry/plan_b). Anfang September hat er in seinem Blog zwei alternative Pläne für das lang ersehn-te JDK 7 beziehungsweise eine Aufteilung der Features in ein JDK 7 und ein JDK 8 vor-

gestellt und um Feedback gebeten – ein Schritt, die Java-Community wieder ein-zubinden. Jetzt wird die (intern getroffene, aber auch in den Blog-Kommentaren favo-risierte) Entscheidung verkündet. Plan B verspricht ein JDK 7 immerhin noch Mitte 2011, aber um wichtige Features reduziert, gefolgt von einem JDK 8 Ende 2012 mit eben diesen wichtigen Features wie Mo-dularisierung („Jigsaw“) und Lambda-Aus-drücken. Die Alternative wäre gewesen, bis Mitte 2012 auf das JDK 7 zu warten. In den Kommentaren ist vielfach vom „kleineren zweier Übel“ die Rede, die etwas wüten-deren Kommentatoren („Wake up Oracle!“) haben aber wohl vergessen, dass das Pro-jekt bereits vor der Übernahme von Sun durch Oracle deutlich im Verzug war.

21. September 2010

Offizieller Start der JavaOne – Thomas Kurian stellt Java-Pläne vorAuf seiner Präsentation zu Beginn der Ja-vaOne bestätigt Thomas Kurian, Chef der Software-Entwicklung bei Oracle, den Plan für das JDK. Darüber hinaus stellt er vor, wie Oracle sich die Zukunft von Java im Desktop- und Mobile-Bereich vorstellt (In-teroperabilität von Java und JavaScript, Ja-vaFX, Java Mobile.Next). Die Pläne klingen gut, sind aber in vielen Fällen noch zu un-konkret und insbesondere noch kein Be-weis dafür, dass Oracle „ernst macht“. Zwei konkrete Informationen gibt es aber doch. Erstens: Netbeans bleibt für Oracle als IDE gesetzt. Damit tritt Kurian den Spekulatio-nen entgegen, dass es als strategisch un-wichtigste der drei IDEs neben JDeveloper und Eclipse bald verschwinden wird. Zwei-tens: Die GlassFish-Version 3.1 mit High-Availability-Features soll wie versprochen bis Ende 2010 fertig werden – ein über-

schaubarer Zeitraum, an dem Oracle direkt gemessen werden kann.

JavaFX und SwingEbenfalls um die Desktop-Entwicklung geht es in einem Blog-Eintrag von Amy Fowler aus dem Java-Entwicklungsteam (http://amyfowlersblog.wordpress.com/ 2010/09/21/a-heartfelt-ramble-on-swing-javafx/). Interessanter als der reine Inhalt – es geht um die Sorgen von Swing-Entwick-lern und was JavaFX für diese Entwickler bedeuten könnte – ist, dass hier mit relativ offenen Worten die „Community“ ange-sprochen wird. Es entwickelt sich auch eine lebhafte Diskussion in den Kommentaren, in der der oberste Produktmanager für die Entwicklungsplattformen (Duncan Mills) sich genötigt fühlt, die IDE-Strategie noch einmal zu präzisieren: Das Ja zu NetBeans heißt nicht, dass jetzt JDeveloper oder das OEPE (für Eclipse) geopfert werden. Es mag ein subjektiver Eindruck sein, aber Oracle scheint langsam seine Kommunikations-strategie besser an die Java-Community anzupassen.

22. September 2010

„General Technical Session“ auf der JavaOneAuftritt der „Chief Architects“: Mark Rein-hold (Java Platform Group), Roberto Chin-nici (Java EE) und Greg Bollellaa (Embedded Java). Mark Reinhold detailliert im Wesent-lichen die Pläne für JDK 7 und 8 und redet über eine Zusammenführung der HotSpot und JRockit JVMs. Roberto Chinnici spricht über die – schon nicht mehr taufrische – Java Enterprise Edition 6 und wirft dann einen Blick auf kommende Releases: Un-terstützung für Cloud Computing – etwas, das für die meisten Entwickler, die froh

8 |

iiiiii iii

iiisind, wenn sie schon Java EE 5 einsetzen können, aber wohl noch weit weg ist. Greg Bollellaa geht ausführlicher auf die Em-bedded- und Mobile-Pläne aus Thomas Kurians Keynote ein (verbesserte Kompa-tibilität zwischen CLDC, CDC und SE für Entwicklung und Betrieb für Java ME.next) sowie auf die Integration von Java ME und Web-Technologien (HTML, JavaScript). Klingt gut, aber angesichts des iPhones und der Diskussion um Android bleibt die Zukunft für Java im Mobile-Bereich span-nend. Vielleicht gibt die vielzitierte „ability to execute“ nach Gartner ja den Ausschlag zugunsten von Oracles Plänen.

27. September 2010

Die Zukunft von JavaFX Script: Project VisageFür alle Freunde von JavaFX Script gibt es Hoffnung: JavaFX-„Guru“ Stephen Chin hat ein Projekt ins Leben gerufen, das Ja-vaFX Script erhalten und weiterentwickeln will (http://steveonjava.com/accouncing- visage/).

30. September 2010

The Register meldet „JCP-Aufstand“Die Internetseite „The Register“ berichtet über eine nicht-öffentliche Abstimmung im Executive Committee (EC) des Java-Com-munity-Process kurz vor der OpenWorld (http://www.theregister.co.uk/2010/09/30/oracle_alone_on_java/). Dessen Mitglie-der (unter anderem IBM, Google, VMware und Vodafone) hätten gegen Oracle eine Resolution verabschiedet, dass der JCP in eine unabhängige und neutrale Organisa-tion ausgelagert werden soll. Oracle selbst hat diese Forderung noch 2007 gegenüber Sun vertreten, aber nach der Übernahme von Sun – wenig überraschend – das In-teresse daran verloren. Die Resolution an sich dürfte ohne Folgen bleiben, aber die Auswirkungen des Kräftemessens im JCP sind noch nicht abzusehen. Wenn man den Rechtsstreit mit Google sowie den seit Sun-Zeiten andauernden Konflikt mit der Apa-che Software Foundations hinzunimmt, ist für weiteres politisches Spektakel gesorgt – sicher nicht zum Besten von Java.

10. Oktober 2010

Java SE: Weitere Details zu „Plan B“Wie Mark Reinhold in seinem Blog be-richtet, wurde Oracles „Plan B“ auf einem Meeting des JCP Executive Committee in Bonn von den anderen Mitgliedern abge-segnet (http://blogs.sun.com/mr/entry/plan_b_details). Er kann nun in Form von JSRs in den JCP einfließen. Befürchtungen, dass der JCP aufgrund der politischen und juristischen Auseinandersetzungen zwi-schen einzelnen Parteien in seiner Arbeit behindert wird, haben sich damit erst mal nicht bestätigt.

11. Oktober 2010

IBM und Oracle wollen zusammen am OpenJDK arbeitenIBM und Oracle verkünden in Presseerklä-rungen, dass sie in Zukunft gemeinsam am OpenJDK arbeiten wollen (http://emea-pressoffice.oracle.com/Press-Releases/Oracle-and-IBM-Collaborate-to-Accele-rate-Java-Innovation-Through-OpenJDK-173d.aspx). Ein gelungener Schachzug von Oracle. Was immer hinter den Kulissen aus-gehandelt wurde, es dürfte für Oracle nicht einfach gewesen sein, IBM mit ins Boot zu holen. Gleichzeitig ist dies ein herber Ver-lust für die Apache Software Foundation beziehungsweise ihr Open-Source-JDK „Project Harmony“ (das auch als Grundla-ge für Android gedient hat), da IBM sich hier sehr stark engagiert hat und dies nun einstellen wird. Letztlich dürfte die Zusam-menarbeit am OpenJDK aber der Java-Community zugute kommen.

20. Oktober 2010

Apple will Java für OS X nicht weiter pflegenGanz unscheinbar in den Release Notes für „Java for Mac OS X 10.6 Update 3 and 10.5 Update 8“ steht ein Satz, der für Aufruhr in der Java-Community sorgt: „... the Java run-time ported by Apple and that ships with Mac OS X is deprecated“ – die von Apple ge-pflegte Runtime könnte in zukünftigen OS X Releases gar nicht mehr vorhanden sein.

Das wäre ein schwerer Rückschlag für „write once, run anywhere“. Wer übernimmt?

08. November 2010

Eine kostenpflichtige Virtual Machine?Verschiedene Online-Magazine und Blogs berichten, dass Oracle in Zukunft auch eine kostenpflichtige Version der JVM auf Grundlage der zusammengeführten Hot-spot und JRockit VMs anbieten will – dies habe Vice President Adam Messinger auf einer Konferenz gesagt (http://www.heise.de/open/meldung/Oracle-will-auch-kos-tenpflichtige-Java-Virtual-Machine-anbie-ten-1131860.html). Die Nachricht sorgt natürlich auf der Stelle für Unruhe in der „Blogosphäre“ – die Verfechter freier Soft-ware (wie in „freies Bier“) sehen ihre Alb-träume nach der Sun-Übernahme bestätigt. Die Nachricht ist aber viel zu unkonkret, um daraus wirkliche Schlüsse zu ziehen. Letzt-lich war auch JRockit (ursprünglich von BEA entwickelt) immer eine kostenpflichtige JVM, wenn auch nicht einzeln lizensierbar, sondern nur mit dem Weblogic Server.

09. November 2010

Die Apache Software Foundation droht aus dem JCP auszusteigenDie ASF wurde gerade für weitere drei Jahre in das Executive Committee des JCP gewählt. In einer Erklärung nach der Wahl droht sie aber gleich, die Zusammenarbeit im JCP zu beenden, wenn der langwähren-de Streit um das TCK nicht endlich zu ihren Gunsten beendet wird. Oracle sei ebenso wie Sun durch das Java Specification Par-ticipation Agreement (JSPA) vertraglich verpflichtet und solle endlich das tun, was Sun jahrelang verweigert hat: Der ASF ein Test Compatibility Kit (TCK) ohne weitere Li-zenzeinschränkungen zu gewähren, damit die Open Source JVM „Harmony“ als Spezifi-kations-konform unter einer Apache-Lizenz veröffentlicht werden kann. Auch ohne Rechtsexperte für Lizenzen zu sein, denke ich, dass dies so ziemlich das Letzte ist, was Oracle während eines laufenden Rechts-streits um Android tun wird, das auf einem Teil von „Harmony“ basiert. Wir dürfen auf weitere Schritte gespannt sein.


iiiiii iii

iii(https://blogs.apache.org/foundation/ entry/statement_by_the_asf_board1)

10. November 2010

Oracle präzisiert Aussagen zur kostenpflichtigen JVMIn seinem Blog stellt Henrik Ståhl, bei Oracle verantwortlich für die Java-Produktstrategie, weitere Details zu den JVM-Plänen vor. Da-bei geht er insbesondere auf die kommer-ziellen Versionen ein. Oracle wird weiterhin die kostenlose Implementierung unterstüt-zen beziehungsweise selber herausbringen (OpenJDK beziehungsweise die konvergie-renden VMs JRockit und Hotspot). Nur eini-ge „value-adds“ sollen proprietär bleiben, sie sollen im Rahmen kostenpflichtiger Ver-sionen erhalten sein (namentlich erwähnt werden „Java for Business“ und „JRockit Mission Control“, „JRockit Real Time“ und „JRockit Virtual Edition“). Diese „value-adds“ sollen Verbesserungen in Management und Deployment für Enterprise-Umgebungen bringen. Andere wichtige Features („all JRockit performance features“) sollen dage-gen ins OpenJDK einfließen. Nicht explizit erwähnt wird die Implementierung neuer „value-adds“ – ansonsten würden die kos-tenpflichtigen Versionen irgendwann obso-let. Aber das ist vermutlich nur eine sprach-liche Ungenauigkeit (http://blogs.oracle.com/henrik/2010/11/oracles_jvm_strategy.html).

12. November 2010

Java für Mac OS – die WiederauferstehungOracle und Apple verkünden, dass nun auch Apple im OpenJDK-Projekt mitarbei-ten wird. Nur wenige Tage nach Apples An-kündigung, dass Java für OS X nicht mehr weiter gepflegt werde, kehrt auf dieser Seite wieder Ruhe ein, und das OpenJDK-Projekt wird weiter aufgewertet. Natürlich werden sofort Hoffnungen in der Java-Community geweckt, dass demnächst Ja-va-Applikationen über den AppStore ver-trieben werden können. Aber bis dahin ist es sicher noch ein weiter Weg. Aktuell wird Java namentlich als eine für den AppStore nicht zulässige Technologie erwähnt.

16. November 2010

Oracle und die Apache Software Foundation, reloadedDas Spiel geht weiter. Oracle hat auf die Drohung der ASF geantwortet, die Zu-sammenarbeit mit dem JCP einzustellen: Oracle stelle das TCK unter fairen Bedin-gungen bereit und es sei Zeit, gemeinsam an der Zukunft von Java zu arbeiten, statt die Stagnation der vergangenen Jahre fortzusetzen (http://blogs.oracle.com/hen-rik/2010/11/moving_java_forward_open_response_from_oracle_to_apache.html). Die ASF antwortet prompt: „Oracle, the ball is in your court. Honor the agreement“ (https://blogs.apache.org/foundation/ entry/statement_by_the_asf_board2).

Die JSRs für Java SE 7 und 8 sind daAn anderer Stelle gibt es positive Nachrich-ten: Die JSRs für Java SE 7 und 8 sind beim Java-Community-Process eingereicht wor-den. Insgesamt sind es vier: jeweils einer für den „Release Content“, einer für „Pro-ject Coin“, das viele kleinere Sprachver-besserungen zusammenfasst, und einer für die „Lambda Expressions“. Bis zum 6. Dezember 2010 können nun Kommenta-re abgegeben werden beziehungsweise Bewerbungen zur Teilnahme an der Expert Group für die Spezifikationen. Dann wird abgestimmt, ob die JSRs akzeptiert wer-den und damit der eigentliche Spezifika-tionsprozess starten kann. Ob die Apache Software Foundation sich vom Nikolaus milde stimmen lässt?

18. November 2010

Java auf der DOAG-KonferenzIm Rahmen der DOAG 2010 Konferenz hat das Thema „Java“ dieses Jahr logi-scherweise einen höheren Stellenwert als zuvor. Trotz der zeitlichen Kollision mit der Devoxx sind auch viele prominente Oracle-Vertreter aus Entwicklung und Pro-duktmanagement vor Ort. Eines der Top-Themen ist natürlich immer noch Java EE 6 mit den Einzelspezifikationen wie JSF 2.0, das tatsächlich die Augen vieler Ent-wickler wieder zum Leuchten bringt, die ja in der Vergangenheit mit der sperrigen

Java-EE-Spezifikation nicht verwöhnt wa-ren. Noch ist nicht alles perfekt, aber Java EE ist wieder eine echte Alternative zu den Frameworks (wie Spring) geworden, die ja überhaupt erst durch die – drastisch aus-gedrückt – Unbenutzbarkeit vergangener Spezifikationen entstanden sind.

Weitere wichtige Themen sind auch hier die Zukunft von JavaFX sowie von Java für Embedded und Mobile. Eine Reihe von Fragen bleiben offen, etwa wie Oracle sich die Zukunft von Java für Mobile jenseits von Projekten wie Java ME.next und LWUIT vorstellt: Wie sieht die Strategie für Android aus; wäre eine Zusammenarbeit mit Apple irgendwann auch für das iPhone denkbar? Aber es ist wohl utopisch, darüber jetzt et-was zu erfahren. Generell ist das Feedback aus der Community: Es passiert in den letz-ten Monaten mehr als in den Jahren zuvor; die Leute warten jetzt einfach ab, ob Orac-le seine Versprechen einlöst – bis Mitte 2011 wissen wir mehr. Diese – verglichen mit den teilweise hitzigen Diskussionen in der Blogosphäre – doch recht entspannte Haltung mag teilweise dadurch begründet sein, dass die klare Mehrheit der Java-Fans hier deutlich näher an Oracle „dran“ ist und die Übernahme nicht ganz so argwöhnisch beäugt wie der Rest der Community. Viel-leicht ist es auch ein Zeichen dafür, dass diese Diskussionen – so sehr sie natürlich sinnvoll sind, um die Entwicklung von Java voranzutreiben – auch nicht den Quer-schnitt der Community widerspiegeln.

Devoxx 2010Die Devoxx ist als etablierte Java-Konfe-renz natürlich ein Anziehungspunkt für alle Java-Fans, von denen die meisten bis-lang wohl weniger mit Oracle zu tun hat-ten. Aber auch hier ist die Stimmung schon entspannter, als manche Blog-Einträge im Vorfeld vermuten lassen. Einem Kommen-tar zufolge ist „der erste Schock verdaut“. Eine nette Idee des Veranstalters ist es, Whiteboards mit bestimmten Fragen auf-zustellen, auf denen die Teilnehmer dann per Strichliste abstimmen oder Kommen-tare hinterlassen können. Auf die Weise wird einiges an Feedback aus der Commu-nity gesammelt, auch wenn es nicht un-bedingt repräsentativ ist. So ist beispiels-weise eine deutliche Mehrheit überzeugt, dass die Klage gegen Google eine schlech-

10 |

iiiiii iii

iiite Idee war. Bei der Frage, ob Oracle an die Java-Community glaubt, entscheidet sich die Mehrheit für „Vielleicht, sie sehen es nur etwas anders als Sun.“ Eine weniger politisch aufgeladene, aber mindestens ebenso spannende Abstimmung: Bei der Frage, ob Java 8 oder 9 mit vorhergehen-den Versionen inkompatibel sein soll, setzt die überwältigende Mehrheit ihren Strich unter „Ja, es wird Zeit, altes Zeug zu entfer-nen, um Platz für Neues zu schaffen“. Die Fotos davon sind unter (http://picasaweb.google.com/JavaPolis.com/Devoxx2010) zu sehen, und im Weblog von Stephen Colebourne findet sich auch eine Abschrift (http://www.jroller.com/scolebourne/ent-ry/devoxx_whiteboard_votes_2010).

26. November 2010

Kairos und ChronosEine sehr interessante Interpretation von Geschwindigkeit und Zeit in Bezug auf Java findet sich in Markus Eiseles Blog. Er bezieht sich auf eine Umfrage auf java.net, ob die aktuelle Geschwindigkeit für Java SE 7 und 8 angemessen sei. Dies setzt er in Zusammenhang mit den altgriechi-schen Zeit-Begriffen Kairos (qualitativ, der rechte Zeitpunkt) und Chronos (quantita-tiv, die messbare Zeit). Eine Analyse ver-gangener Release-Zyklen zeigt beide am Werk: Releases etwa alle zwei Jahre, aber die „geraden“ Releases beinhalten große, revolutionäre, die „ungeraden“ weniger tiefgreifende Veränderungen. Dies hat sich seit Release 1.5 verändert. Jetzt warten wir seit vier Jahren auf Release 7. Aber die Zeit muss nicht verloren sein, sie hat vielleicht einfach Gelegenheit gegeben, „Luft zu ho-len“. Den alten Zweijahres-Turnus mit der Unterscheidung zwischen revolutionären und evolutionären Releases sieht er den-noch für die Zukunft als sinnvoll an (http://blog.eisele.net/2010/11/thoughts-on-ja-vas-pace-will-kairons.html).

06. Dezember 2010

Die Wahlbüros haben soeben geschlossenDie „Review Ballots“ für die vier JSRs zu Java SE 7 und 8 sind abgeschlossen. Die Apache Software Foundation ist bei ihrer

Linie geblieben und hat alle vier JSRs ab-gelehnt – mit der Begründung, dass sie zwar inhaltlich zustimmen, aber nicht mit „ja“ stimmen könnten, solange der Speci-fication Lead „die vertraglichen Pflichten aus dem JSPA verletze“. Auch andere Mit-glieder des Exceutive Committees unter-stützen diese Position: Google, Tim Pei-erls, RedHat, die Eclipse Foundation und sogar IBM gehen in ihren Kommentaren zur Abstimmung darauf ein. Die meisten stimmen aber trotzdem mit „ja“ – um die dringend nötige Weiterentwicklung von Java nicht aufzuhalten. So werden zumin-dest die beiden ersten JSRs „Small Enhan-cements to the Java Programming Langua-ge“ und „Lambda Expressions for the Java Programming Language“ mit nur einer Ge-genstimme und einer Enthaltung (Tim Pei-erls) akzeptiert. Weniger einheitlich sieht das Bild bei den wichtigen „Umbrella JSRs“ für SE 7 und 8 aus, die den Gesamtumfang der Releases definieren. Neben der ASF votieren auch Google und Tim Peierls mit „nein“. Aber auch diese werden mit immer noch großer Mehrheit (12 ja-Stimmen) ak-zeptiert. Sorge und Erleichterung halten sich also weiter die Waage: Der Streit um Lizenzen und die Zusammenarbeit im JCP wird weitergehen, aber es geht trotzdem inhaltlich voran – zügiger als in den ver-gangenen Jahren.

07. Dezember 2010

Der nächste Akt im JCP-Streit: Tim Peierls steigt ausEs hat nur einen Tag gedauert: Nach dem Ende der Review Ballots für Java SE 7 und 8 verlässt Tim Peierls, unabhängiges Mitglied im Executive Committee für Java SE, das Gremium. In seinem Blog (http://tembrel.blogspot.com/2010/12/resigned-from-ec.html) berichtet er, dass er nicht mehr daran glaubt, mit seiner Stimme in diesem Gremi-um etwas auszurichten. Ausschlaggebend sei insbesondere die Tatsache gewesen, dass Oracle zu Fragen um die hier bereits mehrfach erwähnten Lizenzbedingungen für das TCK geschwiegen habe; außerdem habe Oracle in einer Telefonkonferenz des Executive Committee verkündet, sie wol-len mit den JSRs weitermachen, egal wie das Votum ausfalle.

Inhaltlich unterstützt er die Arbeit an den JSRs weiterhin, fügt aber hinzu, dass das Java-Ökosystem seiner Meinung nach so groß und reich sei, dass es auch ohne die Weiterentwicklung in den JSRs eine vielversprechende Zukunft haben könne. Im Prinzip hat er damit wohl Recht. Schwä-chen in den Spezifikationen – oder „stecken-gebliebene“ Specification Requests wurden immer durch Weiterentwicklungen durch Dritte kompensiert (beispielsweise das alte J2EE durch Spring). Aber hier geht es um die gemeinsame Basis für den Sprachstandard, von der nicht nur Java selbst, sondern sogar andere Sprachen wie Scala und Clojure be-troffen sind, die auf der JVM laufen. Da wäre es ein schlechtes Zeichen, wenn jetzt, wo die Weiterentwicklung endlich wieder Fahrt aufnehmen soll, stattdessen eine weitere Zersplitterung eintritt.

09. Dezember 2010

Und noch ein Paukenschlag: Die ASF steigt ebenfalls ausMan hätte es nach dem Ausstieg von Tim Peierls erwarten können. Auch die Apache Software Foundation steigt aus dem JCP aus und legt ihren gerade erst wiederer-langten Sitz im Executive Committee für Java SE/EE nieder. Die Gründe sind letztlich dieselben (größtenteils altbekannten) wie bei Tim Peierls. Während man den Austritt von Tim Peierls vielleicht hätte ignorieren können, ist dies hier ein wirklich ernstes Sig- nal. Die ASF hat viel Gewicht in der Java-Welt und es wäre schlecht für die Zukunft des Ökosystems, wenn sie und Oracle ge-geneinander arbeiten würden.

Oracles Antwort auf den AusstiegOracle antwortet postwendend: Java-„Produktstratege“ Henrik Ståhl veröffent-licht in seinem Blog ein Statement von Adam Messinger (Vice President of Deve-lopment bei Oracle). Darin steht aber auch nur, dass Oracle die Verantwortung dafür trägt, dass Java weiterentwickelt wird, und zwar unter Einhaltung von Standards. Die ASF möge daher bitte ihre Position noch einmal überdenken, da sie einen wichti-gen Beitrag zum Java-Ökosystem leiste.

Die Fronten bleiben also weiterhin ver-härtet. Aus der Community gibt es (bis-


iiiiii iii

iiilang einzelne) Stimmen, unabhängig vom Java-Standard, aber aufbauend etwa auf Harmony / dem OpenJDK, eine eigenstän-dige Sprache mit eigener VM zu etablieren. Bei allen Schwierigkeiten, die ein solches Projekt vermutlich hätte (siehe „Android“, Oracle würde auch hier sicher nicht ta-tenlos zusehen), wird es so weit hoffent-lich nicht kommen. Was kostet es Orac-le, das TCK für Java SE uneingeschränkt freizugeben? Es geht um den Markt für Mobilfunkgeräte und entsprechende, nicht unbeträchtliche Lizenzeinnahmen (für Java ME). Schon Sun hat jahrelang verweigert, Apache Harmony eine TCK-Lizenz zu erteilen, die die volle Nutzung für mobile Geräte erlaubt (inklusive der Patentrechte) – um eben diese Lizenzein-nahmen vollständig für sich zu haben. Nun bedroht Android die Lizenzeinnahmen, und Oracle sieht in der TCK-Lizenzfrage wohl einen wichtigen Baustein seiner Argumentation im Rechtsstreit: Google hat Android auf einem Apache Harmony aufgebaut, das eben keine vollen Lizenz-rechte (einschließlich der Patente) für den Mobilfunkbereich hat. Und solange dieser Rechtsstreit nicht beigelegt ist, besteht wenig Hoffnung auf eine Einigung mit der ASF (http://blogs.oracle.com/henrik/2010/ 12/oracle_response_to_apache_depar-ture_from_jcp.html).

14. Dezember 2010

Myriad verklagt Oracle wegen LizenzgebührenDas muntere Klagen geht in die nächs-te Runde. Myriad, ein schweizerischer Hersteller von Software für den Mobil-funkmarkt (unter anderem für Java ME und Android), hat Klage gegen Oracle wegen „unfairer Lizenzbedingungen“ eingereicht. Sie werden dabei, wie im „fosspatents“-Blog nachzulesen ist, von der gleichen Firma vertreten wie Google im Android-Rechtsstreit (http://fosspa-tents.blogspot.com/2010/12/google-ally-myriad-group-sues-oracle.html). Ein Schelm, wer Böses dabei denkt. Na, so ein Zufall ... Oracle hat noch am selben Tag mit einer Gegenklage geantwortet. Wir werden wohl noch mehr Kapitel die-ser Geschichte erleben. Wann kommt die nächste positive Nachricht? Müssen wir bis Mitte 2011 warten?

28. Dezember 2010

JBoss 6 freigegeben – mit Java EE 6 „Web Profile“-Unterstützung Wir wollen das Jahr nicht mit Negativ-Schlagzeilen enden lassen. Heute hat

Andreas Badelt ist Berater und Soft-wareentwickler / -Architekt bei der CGI Information Systems and Ma-nagement Consultants (Deutsch-land) GmbH. Sein Schwerpunkt ist die Realisierung von großen eCom-merce-Systemen, insbesondere für die Telekommunikationsbranche. Daneben organisiert er seit 2001 die Special Interest Group (SIG) De-velopment bzw. SIG Java der DOAG.

JBoss das Release 6.0.0 des gleichnamigen Application Servers als „final“ freigegeben. Es unterstützt im Gegensatz zu GlassFish und JEUS noch nicht die komplette Java EE 6-Spezifikation – aber mit dem „Web Profile“ immerhin eine in der Spezifikation definierte Teilmenge, die für viele oder die meisten Projekte ausreichen dürfte. Ein wichtiger Meilenstein für die Verbreitung der „Enterprise Edition“ (http://communi-ty.jboss.org/wiki/AS600FinalReleaseNo-tes).

Stuttgarter Test-Tage

Nach den erfolgreichen Stuttgarter Test-Tagen im Jahr 2009 veranstaltet die Java User Group Stuttgart am 4. und 5. Mai 2011 den Workshop erneut. Sie laden dazu noch Referenten ein. Gesucht sind Erfahrungen im Softwaretest sowie Methoden und Werkzeu-ge für den effizienten Test.Der Hintergrund: Softwaretest spielt in der täglichen Projektpraxis eine große Rolle. Ein erheblicher Teil des Gesamtaufwands wird für das Testen verwendet. Dennoch ist der Test oft lückenhaft und unvollständig, und bekannte Methoden und verfügbare Test-werkzeuge werden unzureichend eingesetzt. Zum Schluss stellt man immer wieder fest, dass nicht alle Fehler gefunden wurden.

Für die Stuttgarter Test-Tage 2011 plant die Java User Group Stuttgart die Umsetzung eines neuen Konzepts. Morgens tragen die Referenten vor, Nachmittags werden die Themen unter Anleitung in Arbeitsgruppen in der Praxis vertieft. Die Vorträge dauern jeweils dreißig Minuten mit anschließender Diskussion. Für die Arbeitsgruppen stehen vier Stunden am Nachmittag zur Verfü-gung. Der Vorteil: Jeder Teilnehmer vertieft das Thema, das ihn am meisten interessiert.

Referenten können sich mit einem Vortrag und einer Übung beteiliegen. Dazu schicken sie bis zum 11. Februar 2011 einen Abstract des geplanten Vortrags und der geplanten Übung (jeweils maximal eine halbe DIN-A4-Seite) per E-Mail an [email protected]. Für den Vortrag sind dreißig Minuten einzuplanen, für die Übungsaufgabe sollte ein Teilnehmer nicht länger als eine Stunde benö-tigen, da die Teilnehmer die Arbeitsgruppen wechseln können, um sich verschiedene Methoden und Werkzeuge anzuschauen.Weitere Informationen unter http://jugs.org

12 |

iiiiii iii

iii

JavaFX UpdateOliver Szymanski, Freiberufler, Source-Knights.com

JavaFX begann als GUI-Lösung für unterschiedliche Client-Arten als Kombination aus neuer Skriptsprache, Programmier-Schnittstelle und einem zugrunde liegenden Framework. Dabei wurde besonders auf die allgemeine Java-Devise „Write once – run everywhere“ Wert gelegt und daher Zielgeräte wie Browser mit Java-1.5-Unterstützung, Mobile Client und TV-Geräte zusätzlich zu Rich-Client-Anwendungen unterstützt.

Ob ein neues GUI-Framework nötig ist oder war, liegt sicherlich in der Sichtweise des Betrachters. Fakt ist aber, dass Swing immer wieder dazu führt, dass sich einige Entwick-ler über alternative Frameworks Gedan-ken machen. Und wenn man Alternativen braucht, scheint etwas in bestehenden Lö-sungen zu fehlen oder falsch zu sein.

JavaFXJavaFX ist eine GUI-Technologie. Darin ent-halten sind bisher die JavaFX-Skriptsprache, die JavaFX-APIs (etwa für Transformationen auf Elementen der Oberfläche) und die Laufzeit-Umgebung. Diese liegt für die ver-schiedenen Client-Arten vor und ist auch für die Ereignisbehandlung und den Lebenszy-klus der Applikation verantwortlich.

Das für die Entwicklung benötigte Ja-vaFX-SDK hat Compiler für die Skriptspra-che, die Laufzeitumgebung und einige Tools (wie den JavaFX Mobile Emulator) im Lieferumfang. Kompilieren und Aus-führen kann man in JavaFX geschriebene Anwendungen dann zum Beispiel über die Kommandozeile mit den Tools „javafxc“ und „javafx“. Die Integration in die Entwick-lungsumgebung ist in NetBeans gegeben oder in Eclipse mit dem JavaFX-Plugin. Die erforderlichen Tools kann man über die of-fiziellen Webseiten (http://javafx.com) von JavaFX finden.

Meine größte Kritik an JavaFX war seit Beginn dieser Technologie der Faktor, dass hier eine neue Skriptsprache künstlich ge-schaffen wurde. Ohne expliziten Grund ist keine neue Sprache erforderlich, und Java-Entwickler sollten nicht gezwungen wer-den, für Aufgaben, die sie ohne Schwierig-keiten in Java selbst entwickeln können, eine neue Sprache zu lernen. Die Begrün-dung war, dass Designer die Skriptsprache leichter lernen und damit GUIs erstellen können. Gut, das lassen wir mal kurz wir-

ken, und dann kann sich jeder selbst Ge-danken darüber machen, ob er glaubt, jemals einen reinen Designer zu sehen, der JavaFX lernt und darin GUIs definiert. Designer haben ihre eigenen Werkzeuge und teils eigene Sprachen. Wir sollten uns nicht damit beschäftigen, wie wir die Arbeit der Designer ändern, sondern wie wir unse-re darauf abstimmen. Realistisch betrachtet hätte diese Skriptsprache doch, wie auch in anderen Technologien, dazu geführt, dass Java-Entwickler sie zusätzlich lernen und damit Design (re-) implementieren. Das kennen wir bereits von JSPs, JSF und mehr. Doch zum Glück hat Oracle gelernt. Vielleicht wurden sie von Technologien wie dem Webframework JSXP (http://jsxp.org) inspiriert. Denn die neue Skriptsprache hat ihre aktive Phase bald abgeschlossen, die Zukunft von JavaFX beinhaltet die Skript-sprache nicht mehr. Oracle wird die Weiter-entwicklung der Skriptsprache einstellen, diese wird dann wahrscheinlich der Open-Source-Community zur Verfügung gestellt.

Die Zukunft?Doch ohne die Skriptsprache wird JavaFX als Technology keineswegs sterben. Im Gegenteil, ich denke der Wegfall der Skript-sprache wird JavaFX stärken. Da die Skript-sprache bereits vorher zur Definition von Klassen und zur Laufzeit zu Objektinstan-zen führte und in Java ByteCode kompiliert wurde, war das Ergebnis kompatibel zu Java. Wir konnten innerhalb der Skriptspra-che auf die gesamte Java-Welt zugreifen. Dies ermöglicht die kommende komplette Integration der JavaFX-Technologie in Java, sodass GUIs nicht mehr in einer Skriptspra-che, sondern in Java-Code definiert werden. JavaFX wird stärker mit Swing verbunden und somit ist der Weg frei in Richtung einer einheitlichen und starken GUI-Technologie in Java. Wer gern sehen möchte, wie so et-

was aussehen kann, sollte sich Amino von Josh Marinacci ansehen. Der Entwickler, der aus dem JavaFX-Team stammte, hat mit Amino (http://leonardosketch.org/amino) ein ähnlich geartetes, reines Java-GUI-Framework geschaffen.

Nach meiner Meinung zur Abstimmung von Entwicklung und Design, scheint Oracle diese bei JavaFX nicht nur beim Wegfall der Skriptsprache zu teilen. Mit der kommen-den Version von JavaFX wird es auch Mög-lichkeiten geben, JavaFX GUIs mit Adobe Photoshop CS4 and Adobe Illustrator CS4 zu definieren. Das wird die Designer sicher mehr freuen als eine neue Sprache. Ob sich in der OpenSource-Community genügend Unterstützung findet, die JavaFX Skript-sprache weiterzupflegen, wird sich zeigen.

Auf der DOAG 2010 Konferenz gab es von Dr. Stefan Schneider (Oracle Deutsch-land) auch die Aussage, die JavaFX-Tech-nologie werde jetzt wieder stärker auf Desktop-Anwendungen fokussiert. Was dies konkret für die anderen Client-Typen bedeuten wird, muss abgewartet werden. Ich hoffe nicht, dass der „Write once – run everywhere“-Gedanke bei JavaFX verloren geht. Es ist (war?) eine der Stärken dieser Technologie. Auf eine andere können wir uns jetzt im reinen Java freuen: die Bin-ding-API, um auf Wertänderungen von Variablen automatisch zu reagieren und abhängige Werte direkt neu zu ermitteln.

Kontakt:Oliver Szymanski

[email protected]

Oliver Szymanski (Dipl. Inform., Univ.) ist als Software-Architekt / Entwickler, Bera-ter und Trainer in den Bereichen Java, .NET und Mobile-Development tätig. Parallel dazu arbeitet er als Schriftsteller (siehe auch Seite 53)


iiiiii iii

iii

Die Java-Zertifizierung „Sun Certified Java Programmer“ – ein ErfahrungsberichtKai Wähner, MaibornWolff et al GmbH

Der Sun Certified Java Programmer (SCJP) – zukünftig auch Oracle Certified Professional Java Programmer genannt – ist ein weltweit anerkanntes Zertifikat, das dem Besitzer die Kenntnis der wichtigsten Konzepte und Application Programming Interfaces (API) der Programmiersprache Java in der Standard Edition (Java SE) bescheinigt. Allerdings existieren auch Meinungen: „Zertifizierungen bringen eh nichts, und die gestellten, unlesbaren Code-Schnipsel sind fern von jeder Realität“. Dieser Artikel ist ein Erfahrungsbericht über die Durchführung der SCJP-Zertifizierung − Java SE 6 und zeigt dabei einige Tipps und Fallstricke auf.

Viele Entwickler stehen vor der Frage, ob sie an der Prüfung zur SCJP-Zertifizierung teilnehmen oder darauf verzichten sollen. Oftmals schreckt auch das fehlende Wissen über den damit verbundenen Aufwand so-wie die eigentlichen Prüfungsmodalitäten ab. Der Autor beschreibt daher kurz den fachlichen Inhalt der SCJP-Zertifizierung und diskutiert das „Für“ und „Wider“ einer Teilnahme sowie den Prüfungsablauf. Da-nach wird erläutert, warum die Durchfüh-rung überhaupt sinnvoll erscheint, und detailliert auf den Prüfungsablauf einge-gangen. Es werden wichtige Hilfsmittel zur Unterstützung genannt und Tipps zur Vorbereitung auf die Zertifizierung gege-ben. Darüber hinaus skizziert der Autor seine Verbesserungsvorschläge, zieht ein

persönliches Fazit und geht auf weitere Zertifizierungen ein.

Warum ist diese Zertifizierung überhaupt sinnvoll?Die SCJP-Zertifizierung ist den meisten Java-Entwicklern bekannt. Dennoch sind viele nicht bereit, den Aufwand für die Prü-fung in Kauf zu nehmen. Es stellt sich die berechtigte Frage, warum diese Zertifizie-rung überhaupt gemacht werden sollte. Die naheliegendste Antwort ist natürlich die Zertifizierung an sich, die dem Java-Entwickler nach erfolgreichem Abschluss der Prüfung die grundlegenden Kennt-nisse dieser Technologie bescheinigt und sowohl den Kunden als auch potenziellen Arbeitgebern vorgelegt werden kann.

Durch die Teilnahme an diesem Zertifi-zierungsprogramm werden die technischen Grundkenntnisse von Java erworben und die wichtigsten Konzepte hierzu verinner-licht. Dies resultiert in der Regel in besserem und sichererem Quellcode, der einfacher zu warten ist, sowie in einer Reduzierung der Duplikate. Beispiele dafür sind:

Verwendung von StringBuilder statt •StringBuffer oder gar statt der „+“-Kon-katenation zur Performance-Verbesse-rungEinsatz von „static initializer“ für die Er-•stellung einer Thread-sicheren Single-ton-KlasseAnonyme innere Klassen nicht nur ein-•setzen (beispielsweise in der Swing-

Foto

s: D

OAG

14 |

iiiiii iii

iiiAPI), sondern auch verstehen und in ei-genen Klassen sinnvoll nutzen

Die Zertifizierung beinhaltet die wichtigs-ten Designkonzepte von Java sowie wich-tiger APIs, die jedem Entwickler bekannt sein sollten. Dies betrifft beispielsweise die gängigsten Konzepte der Objektori-entierung wie Vererbung, Polymorphie und innere Klassen. Aber auch die Themen Sprachsyntax, API, Generics, Multithrea-ding und die Anwendungserstellung wer-den behandelt.

Der PrüfungsablaufDie Prüfung wird in einem von vielen „Pro-metric Test Centern“ [1] durchgeführt, die weltweit und auch in Deutschland in jeder größeren Stadt zur Verfügung stehen. Die Prüfung kostet 235 Euro und dauert 180 Mi-nuten. Dabei müssen 58,33 Prozent (35 von 60) der „Multiple-Choice“- und „Drag-and-Drop“-Fragen richtig beantwortet sein, auf dem Zertifikat ist diese Zahl allerdings nicht sichtbar. Das Prüfungsergebnis wird unmit-telbar im Anschluss an die Prüfung mitge-teilt. Auch Upgrades sind möglich, diese fra-gen nur die Änderungen beziehungsweise Neuigkeiten zur letzten durchgeführten Zertifizierung ab, beispielsweise bei einem Upgrade von SCJP5 auf SCJP6.

Vorsicht ist bei der Auswahl des Test-Centers geboten, da seitens des Anbie-ters Prometric keine Qualitätssicherung durchgeführt wird. Aus eigener Erfahrung ist zu berichten, dass Monitore mit guter Bildqualität, akzeptable Licht- und Tempe-raturverhältnisse sowie geringe Lautstärke nicht immer selbstverständlich sind.

Außerdem ist zu beachten, dass die Firma Prometric, die in Deutschland nicht

ansässig ist, keine Rechnung auf den Fir-mennamen ausstellt, sondern nur auf den Test-Kandidaten – eine nicht akzeptable Situation für die Buchführung der eigenen Firma. Als Begründung gibt Prometric an, dass das Zertifikat für eine konkrete Person gilt und daher die Rechnung auch immer nur auf diese Person ausgestellt werden kann. Als Lösung bleibt nur die Möglich-keit, dass die Firma den Test-Voucher direkt bestellt oder aber die Anmeldung direkt beim ausgewählten Test-Center durchge-führt wird anstatt auf der Prometric-Web-seite.

Hilfsmittel zur VorbereitungAls Hilfsmittel sollten Bücher, Foren so-wie Prüfungssimulationen (sogenannte „Mock-Examen“) verwendet werden. Zu empfehlen ist das Buch „SCJP Sun Certified Programmer for Java 6 Study Guide“ von Katherine Sierra und Bert Bates (ISBN 978-0071591065). Die Autoren sind auch an der Erstellung der SCJP-Prüfungsfragen betei-ligt. Neben ausführlichen Erläuterungen des Prüfungsinhalts sind viele „Question & Answer“-Blöcke inklusive Erläuterungen nach jedem Kapitel sowie zwei vollständi-ge Mock-Examen enthalten.

Das „JavaRanch“-Forum bietet zudem einen eigenen, sehr gut besuchten Bereich, der ausschließlich die SCJP-Zertifizierung thematisiert [2]. Fragen werden in der Re-gel innerhalb weniger Stunden beantwor-tet, auch die Autoren des obigen Buches sind dort tätig.

Mock-Examen ermöglichen eine rea-listische Prüfungsvorbereitung zu Fragen, die alle Themen der Zertifizierung enthal-ten. Die oben erwähnten zwei Examen als Beilage des Buches sind jedoch nicht ausreichend, da nicht alle in der Prüfung vorkommenden Fallstricke behandelt werden. Zahlreiche weitere Mock-Examen sind allerdings im Internet verfügbar. Der Kauf von kostenpflichtigen Examen ist nicht notwendig, da genug kostenloses Material kursiert. Für den Einstieg ist die Webseite „Java Black Belt“ [3] gut geeig-net, die unabhängig vom SCJP-Inhalt grundlegende Java-Kenntnisse kostenlos abfragt. „Exam Labs“ [4] bietet danach ausreichend zusätzliche Fragen zur Vorbe-reitung auf die SCJP-Prüfung an. Die gra-fische Oberfläche ist dabei nahezu iden-

tisch zur wirklichen Prüfung. Zu beachten ist, dass diese Fragen sehr schwierig sind. Wer hierbei etwa 50 Prozent der Fragen korrekt beantworten kann, sollte keine Probleme beim Bestehen der eigentlichen Prüfung haben.

Tipps zur VorbereitungIm Folgenden werden einige Tipps gege-ben, welche bei der Vorbereitung auf die Prüfung beachtet werden sollten. Der ge-samte Inhalt − wirklich jeder Absatz des oben genannten Buches − ist prüfungs-relevant, sofern dies nicht ausdrücklich anders erwähnt wird. Wirklich jede Zeile kann geprüft werden und ist insofern re-levant zur Vorbereitung. Die Konzepte und APIs sollten dabei nicht nur auswendig gelernt, sondern wirklich praktisch durch Programmierung nachvollzogen werden, und zwar ohne Entwicklungsumgebung, da diese schließlich auch während der Prüfung nicht verfügbar sein wird. Dies gilt insbesondere für Konstrukte, die zwar oft verwendet werden, die jedoch nicht jeder Entwickler in voller Tiefe versteht. Zudem dürfen Mock-Examen nicht einfach nur durchgeführt werden. Einen großen Teil der Zeit sollte man für die Analyse falsch beantworteter Fragen aufwenden, um sich Konzepte einzuprägen und diese zu ver-stehen. Auch das Prinzip der „Test-taking Methodology“ sollte zum Einsatz kom-men. Konkret bedeutet das, Schlüsselwör-ter wie beispielsweise „may“ oder „must“ zu beachten, das Schema der Fragestel-lungen zu verstehen (etwa alle korrekten oder alle falschen Antworten auswählen) und immer erst die Syntax zu prüfen, dann die Logik (außer es gibt gar keine „does not compile“-Antwort).


iiiiii iii

iiiFür den Teilnehmer bietet es sich zudem

an, sich erst dann zur Prüfung anzumel-den, wenn die Vorbereitung nahezu abge-schlossen ist. Anderenfalls wird nur unnöti-ger Druck aufgebaut. Prüfungstermin und Uhrzeit sind frei wählbar und auch wenige Tage vor der Prüfung kurzfristig möglich. Die Prüfungsdauer ist bei guter Vorberei-tung völlig ausreichend. Es bietet sich an, zuerst alle einfachen beziehungsweise schnell lösbaren Aufgaben abzuschließen und erst am Ende die komplizierten zu beantworten. Obwohl die Prüfung auch auf Deutsch durchführbar ist, empfiehlt es sich, die englische Variante auszuwäh-len. Dies liegt darin begründet, dass die deutsche Übersetzung von eher schlechter Güte ist. Außerdem sind sowohl in Qualität als auch in Quantität keine gleichwertigen deutschen Hilfsmittel zur Prüfungsvorbe-reitung verfügbar.

VerbesserungsvorschlägeGenerell ist anzumerken, dass hinsichtlich der SCJP-Prüfung einige Verbesserungen angemessen erscheinen. Sicherlich soll-te ein zertifizierter Java-Entwickler die wichtigsten APIs kennen – das Auswen-diglernen vieler Methoden, wie etwa der Collection-Klassen, ist allerdings nur wenig hilfreich. Aus diesem Grund gibt es APIs, um die Funktionalität nachzuschauen. Stattdessen sollten lieber wichtige und es-senzielle Bereiche zur Zertifizierung hinzu-gefügt werden, die bisher fehlen. Beispiele sind hier Annotations, Reflection und das Classloader-Konzept.

Des Weiteren erscheinen manche Fra-gen zweideutig, weshalb eine konkrete Antwort oft nicht möglich ist. Dies gilt insbesondere für das Thema „Coupling, Cohesion and Encapsulation“. Verbesse-rungswürdig ist auch die Situation der

schlechten Prüfungsbedingungen in man-chen Test-Centern. Eine Rechnung auf Fir-menadresse sollte, wie bereits erwähnt, ebenfalls ermöglicht sein.

FazitDie Vorbereitung auf die SCJP-Zertifi-zierung ist sehr aufwändig. Sofern diese hauptsächlich nach Feierabend oder am Wochenende durchgeführt werden soll, sind auch für Java-erfahrene Entwickler mindestens zwei Monate Vorbereitungs-zeit einzuplanen. Dennoch lohnt sich die Zertifizierung für jeden Java-Entwickler, da nicht nur die Zertifizierung, sondern auch ein verbessertes Java-Wissen als Er-gebnis herauskommen. Auch wenn noch Zertifizierungen für ältere Java-Versionen möglich sind, sollte man unbedingt den SCJP für die aktuelle Version Java SE 6 ma-chen.

Ausblick auf weitere Java-ZertifizierungenIm Java-Umfeld sind noch zahlreiche weite-re Zertifizierungen verfügbar. Der Sun Cer-tified Java Associate (SCJA) prüft lediglich die grundlegenden Konzepte und richtet sich daher eher an Einsteiger. Für profes-sionelle Entwickler ist diese Zertifizierung nur wenig hilfreich. Auf dem SCJP aufbau-end sind einige weitere Zertifizierungen verfügbar, welche insbesondere einzelne Bereiche der Java Enterprise Edition (JEE) prüfen, wie beispielsweise Web-Entwick-lung (Sun Certified Web Component De-veloper), Komponentenentwicklung (Sun Certified Business Component Developer) oder Web Services (Sun Certified Developer for Java Web Services). Praxiserfahrung im jeweiligen Gebiet sollte vorhanden sein, ansonsten ist die Zertifizierung nur schwer zu schaffen – auch deshalb, weil die Hilfs-

mittel bei weitem nicht die Anzahl, Aktuali-tät und Qualität des SCJP erreichen.

Des Weiteren sind im Java-Umfeld auch Zertifizierungen für konkrete Produkte, wie beispielsweise der IBM Certified Solution Developer − Web Services Development for WAS 7.0, verfügbar. Hierbei ist allerdings oftmals ein anderes Vorgehen zu empfeh-len: Diese Zertifizierungen sind insbeson-dere dann sinnvoll, wenn das konkrete Produkt in einem Projekt eingesetzt wird. Für die meisten Produkte werden mehrtä-gige Vorbereitungskurse angeboten, wo-durch die Zertifizierung oft innerhalb einer Woche erledigt werden kann.

Kontakt: Kai Wähner

[email protected]

Kai Wähner ist als IT-Consultant bei „MaibornWolff et al“ tätig. Seine Schwerpunkte liegen in den Berei-chen JEE, EAI und SOA. Außerdem berichtet er auf „www.kai-waehner.de/blog“ über seine Erfahrungen mit neuen Technologien, IT-Konferenzen und Zertifizierungen.

Quellen:http://www.prometric.com1. http://www.coderanch.com/2. forums/f-24/java-programmer-SCJPhttp://www.blackbeltfactory.com 3. http://examlab.tk/4.

16 |

iiiiii iii

iii

Single Sourcing mit JVxRené Jahn, SIB Visions GmbH

Hinter dem Begriff „Single Sourcing“ versteckt sich die Möglichkeit, eine Anwendung einmalig zu codieren und mit unterschiedlichsten Technologien – ohne Source-Code-Änderung – zu verwenden. Dieser Artikel zeigt, wie man Single Sourcing in JVx umsetzt, und eine Beispiel-Anwendung demonstriert, wie eine Anwendung als Desktop- sowie als Web-Anwendung läuft.

Abhängig von den Projekt- oder Kunden-anforderungen stehen bereits frühzeitig geeignete Technologien und Frameworks für die Umsetzung fest. Um Desktop-An-wendungen zu entwickeln, sind hingegen andere Frameworks und Mechanismen erforderlich. Im Bereich der RIAs sieht es nicht anders aus.

Ein häufiges Problem bei der Entwick-lung ist die Komplexität und die Menge eingesetzter Frameworks, denn nicht im-mer harmonieren diese problemlos mit-einander. Außerdem sind nicht in jedem Unternehmen ausreichend Spezialisten dafür vorhanden. Wenn die Unterstützung von mobilen Geräten, die Nutzung mit ei-nem Browser, der Komfort einer Desktop-Anwendung, kurze Antwortzeiten und die Bewältigung von Millionen Datensätzen gefordert werden, dann verursachen die Komplexität und der zu erwartende Auf-wand erhebliches Kopfzerbrechen. Spä-testens dann wird nach neuen Lösungen

gesucht, um die Entwicklung vielleicht doch etwas einfacher und auch effizienter durchführen zu können. Das Enterprise Application Framework JVx ist in diesem Zusammenhang mehr als eine Alternative. Durch den Single-Sourcing-Mechanismus benötigt man nur ein einzelnes Framework für die Entwicklung von RIAs, Web- oder Desktop-Anwendungen.

Die ArchitekturDas Framework ist ein sogenanntes „Full-Stack Application -Framework“ für die Ent-

wicklung von Multi-Tier-Anwendungen und beinhaltet Lösungen für alle Tiers (sie-he Abbildung 1). Wir beschränken uns hier jedoch auf die Client-Tier, da nur diese für Single Sourcing relevant ist.

Die Basis bildet das Interface-basierte User Interface (Generic UI). Mit simplen Java In-terfaces wird ein User Interface abstrahiert und es ist lediglich zu definieren, welche Eigenschaften die einzelnen GUI-Kompo-nenten unbedingt benötigen. Die Label-Definition „ILabel“ demonstriert das:

Das Interface legt fest, dass ein Label ausschließlich einen Text darstellt – auch wenn in manchen Technologien ein Label zusätzlich mit einem Icon ausgestattet sein kann. Das wirkt zwar auf den ersten Blick sehr eingeschränkt, ist aber mit den flexi-blen Layout-Managern in der Verwendung kein Nachteil. Für die üblichen GUI-Kom-ponenten wie Button, Checkbox, Menü, Tabelle und Tree existieren ebenfalls pas-sende Interfaces. Das Generic UI ist durch

public interface ILabel extends IComponent, IAlignmentConstants{ public String getText(); public void setText(String pText);}

Abbildung 1: JVx-Architektur Abbildung 2: WebUI


iiiiii iii

iii

die reine UI-Definition vollkommen unab-hängig von jeglichen UI-Technologien.

Eine Technologie-abhängige Imple-mentierung muss in weiterer Folge die In-terfaces einbauen, um mit JVx kompatibel zu sein – denkbar wären eine SWT- oder JavaFX-Implementierung. Für Swing und Qt Jambi sind die Interfaces bereits einge-setzt. Die Swing-Implementierung für ein Label sieht wie folgt aus:

Die Implementierung greift auf Stan-dard-Swing-Komponenten zurück und stellt diese als Ressource zur Verfügung (siehe Konstruktor). Eine weitere Imple-mentierung existiert für Web-Anwendun-gen. Diese unterscheidet sich allerdings von den anderen Umsetzungen, da die An-wendung am Server ausgeführt wird. Da-für wurde eine Interface-Implementierung auf Property-Basis durchgeführt. Der Client ist in diesem Fall eine separate Applikation, die mit dem Server bei speziellen Events, wie Button-Klick, kommuniziert. Bei jeder Kommunikation werden die aktuellen Properties zum Client übermittelt und dieser aktualisiert zur Laufzeit die geän-derten Komponenten. Die Client-Applika-tion selbst basiert auf GWT und wurde mit extGWT umgesetzt (siehe Abbildung 2). Die Server-Implementierung ist vollkom-men unabhängig von der Client-Technolo-gie und könnte auch mit Javascript-Clients zum Einsatz kommen.

Bisher wurde sehr viel über Interfaces gesprochen, jedoch sind diese ohne Hilfs-mechanismen wie das Factory-Pattern

nicht initialisierbar und würden die GUI-Entwicklung nicht sehr intuitiv gestalten:

ILabel label = getFactory().createLabel();label.setText(„Vorname“);

Um die gewohnte Arbeitsweise beibehal-ten zu können, wurde eine Technologie-unabhängige Standard-Implementierung durchgeführt, um Klassen-orientiert zu entwickeln:

UILabel label = new UILabel();label.setText(„Vorname“);

Der Anwendungs-Entwickler verwendet ausschließlich das Generic UI und entschei-det sich erst später für eine bestimmte Technologie. Für den Start der Anwendung in einer bestimmten Technologie sind soge-nannte „Launcher“ notwendig. Diese sind immer abhängig von der eingesetzten Tech-nologie und initialisieren lediglich die pas-sende UI-Factory für die Anwendung (siehe vorletztes Listing). Für Swing existieren die Launcher „SwingApplet“ und „SwingAppli-cation“. Beide Implementierungen greifen auf die „SwingFactory“ zurück. Abbildung 3 zeigt die Abhängigkeiten zwischen Anwen-dung, Launcher, Factory und Generic UI.

Eine Beispiel-AnwendungDas Beispiel ist eine Datenbank-Anwen-dung mit den Features „Anmeldung mit Benutzername und Passwort“, „Menü und Toolbar“ sowie einer Bearbeitungsmaske

(CRUD) für eine Tabelle aus der Datenbank. Wir verwenden hierfür die bereits lauffä-hige Anwendung (die erste Applikation) des Frameworks. Das Archiv kann von [1] geladen werden. Es enthält ein vorkonfi-guriertes Eclipse-Projekt, alle notwendigen Bibliotheken, den Source Code und die zugrundeliegende HSQL-Datenbank. Das Archiv wird einfach an beliebiger Stelle ent-packt und das Projekt in Eclipse importiert:

Menü: File/Import…1. Auswahl: General, Existing Projects into 2. Workspace<Projektverzeichnis>/rad/apps/firstapp 3. wählenProjekt JVxFirstApp importieren4.

Das Projekt wird problemlos kompiliert und sollte sich dann, wie in Abbildung 4 gezeigt, in Eclipse darstellen.

public class SwingLabel extends SwingComponent<JLabel> implements ILabel{ public SwingLabel() { super(new JLabel()); } public String getText() { return resource.getText(); }

public void setText(String pText) { resource.setText(pText); }}

Abbildung 3: Anwendung, Launcher und Factory

Abbildung 4: Eclipse-Projekt

18 |

iiiiii iii

iiiNun wird die Anwendung zum ersten

Mal als Swing Application gestartet. Dafür öffnen wir die Run Configurations (Menü: Run) und verwenden entweder die vor-handene Konfiguration JVxFirstApp oder erstellen eine neue mit folgenden Einstel-lungen (siehe Abbildung 5):

Als Main Class verwenden wir die Klasse „com.sibvisions.rad.ui.swing.impl.Swin-gApplication“ als Launcher. Nun fehlt nur noch die Anwendung selbst. Diese wird als Argument „apps.firstapp.FirstApplication“ an den Launcher übergeben (siehe Abbil-dung 6).

Bevor wir die Anwendung ausführen, ist noch unsere Datenbank zu starten. Dazu reicht es aus, die Datei „<Projektverzeich-nis>/rad/apps/firstapp/db/startHSqlDB.bat“ auszuführen. Nach dem Start der Anwendung können wir uns mit dem Be-nutzernamen „admin“ und dem Passwort „admin“ an der Anwendung anmelden. In der Toolbar befindet sich ein Icon zum Öffnen unserer Bearbeitungsmaske (siehe Abbildung 7).

Nun wird die gleiche Anwendung als Web-Anwendung gestartet. Dazu be-nötigen wir die Web-Implementierung des Generic UI, die wir von [2] laden. Das Archiv enthält die Client- und Ser-ver-Komponenten für die Installation in einem Applikationsserver. Wir verwen-den hierfür einen Apache Tomcat 6. Der Server muss bereits installiert und lauf-fähig sein. Nun richten wir unsere Web-Anwendung ein:

1. Die Verzeichnisse <Tomcat>/webapps/firstapp und <Tomcat>/webapps/firstapp/WEB-INF erstellen

2. Den Inhalt des client-Verzeichnisses aus dem Archiv in den firstapp-Ordner ko-pieren

3. Den Inhalt des server-Verzeichnisses aus dem Archiv in den firstapp/WEB-INF-Ordner kopieren

4. Die Datei firstapp/WEB-INF/web.xml öffnen, den Parameter „main“ auf apps.firstapp.FirstApplication und den Para-meter „config“ auf einen Leerstring set-zen

5. In der Datei firstapp/webui.html die kompletten META-Tags mit den Namen gwt:property löschen

Abbildung 5: Run Configuration Main

Abbildung 6: Run Configuration Arguments

Abbildung 7: Applikation, Swing


iiiiii iii

iiiZum Abschluss benötigen wir noch die kompilierte Anwendung. Dazu müssen wir folgende Schritte durchführen:

1. Den Inhalt des Verzeichnisses <Projekt-verzeichnis>/rad/apps/firstapp/clas-ses in ein zip-Archiv mit dem Namen „firstapp.jar“ packen

2. Die Datei in das Verzeichnis <Tomcat>/webapps/firstapp/WEB-INF/lib kopieren

3. Die Datei <Projektverzeichnis>/rad/apps/firstapp/libs/server/hsqldb.jar in das Verzeichnis <Tomcat>/webapps/firstapp/WEB-INF/lib kopieren

4. Die Verzeichnisstruktur für <Tomcat>/webapps/firstapp/WEB-INF/rad/apps/firstapp und <Tomcat>/webapps/firstapp/WEB-INF/rad/server erstellen

5. Die Dateien <Projektverzeichnis>/rad/apps/firstapp/config.xml und users.xml anschließend nach <Tomcat>/webapps/firstapp/WEB-INF/rad/apps/firstapp kopieren

6. Die Datei <Projektverzeichnis>/rad/ser-ver/config.xml nach <Tomcat>/webapps/firstapp/WEB-INF/rad/server kopieren

Nun starten wir unseren Tomcat, und nach der Eingabe von „http://localhost/firstapp/webui.html“ erhalten wir unsere Applika- tion als Web-Anwendung mit den gleichen Funktionen wie in der Swing-Anwendung.

FazitDie Beispielanwendung könnte man auch als Applet im Browser oder mit Webstart anbieten. Die Anwendung selbst muss in keinem Fall geändert werden. Es reicht aus zu konfigurieren, mit welcher Technologie die Anwendung zu starten ist. Der Auf-wand für die Erstellung der Konfiguration hält sich auch in Grenzen, da die Konfigu-ration für weitere Anwendungen wieder-verwendet werden kann. Üblicherweise würde das Build-System diese Aufgaben übernehmen.

Direct-Call-PatternOliver Szymanski, Freiberufler, Source-Knights.com, David Tanzer, Freiberufler

Wie jeder weiß, schließt die beste Art und Weise, Objekte miteinander kollaborieren zu lassen, Annotationen (siehe Spring und EJB für Beispiele), einiges an XML (wieder mit einem Blick auf Spring und EJB), noch mehr XML (siehe Oracle ADF) und dazu Drag & Drop in einem obskuren visuellen Editor (etwa wieder ADF) ein. Das ist Indus-trie-Standard und es ist wunderbar, denn Consultants können so viel Geld machen und Consulting-Unternehmen können noch mehr Consultants in Projekte brin-gen. Wie auch immer, es mag Situationen geben, in denen wir etwas anderes benö-tigen. Daher haben wir das Direct-Call-Pat-tern entwickelt (in einer Cocktailbar).

Direct-Call-Pattern [1](auch bekannt als Collaborateur-With-No-Intermediator Entwurfsmuster)

EinführungZwei Objekte wollen miteinander kommu-nizieren. Einer ist der Aufrufer (Caller), der andere der Aufgerufene (Callee). Für den

Aufgerufenen ist das völlig in Ordnung und der Aufrufer macht alles Erforderliche vor und nach dem Aufruf gerne selbst.Anforderungen: Zwei Objekte, manchmal ein Objekt in zwei Rollen (Aufrufer, Aufge-rufener), sonst nichts.Lösung: Der Aufrufer ruft den Aufgerufe-nen direkt auf. Kein Proxy, Interceptor oder sonst ein Vermittlerobjekt sind im Aufruf involviert. Wirklich, bloß ein Aufruf von einem vertrauenswürdigen Freund zum anderen. Vielleicht loggt eine dritte Partei den Aufruf, aber das lässt sich heutzutage schwer vermeiden.

ProsSchneller Aufruf•Saubere und kurze Stack-Traces•Weniger Verwirrung•WYSIWYG•

ContrasViele „WTF ist hier die Dependen-•cy Injection“- und „Wie finde ich den Interceptor“-Kommentare

Verärgert das nicht benötigte Annotati-•onen- und Aspektorientierungs-ZeugAndere können den Code verstehen, •den man geschrieben hatWeniger Geld mit Software-Support•

Nutzen, wennKein Geld für Application Server vor-•handen istKeine Zeit ist, um Frameworks zu de-•buggenMan sich nicht nach langen Zeiten voll •exklusivem Consulting sehntProjekt-Laufzeit länger als einige Wo-•chen/Monate beträgt (und man sich selbst ohne Aufpreis um den Support kümmern soll)

[1] http://source-knights.com/2010/11/direct-call-pattern.html

Kontakt:Oliver Szymanski

[email protected] Tanzer

[email protected]

Links[1] http://www.sibvisions.com/files/down-

load/releases/jvxfirstapp-1.1.zip[2] http://sourceforge.net/projects/

jvx/files/WebUI/0.7%20beta/jvxwe-bui-0.7%20beta.zip/download

Weitere InformationenDetails zu JVx und die Dokumentation: http://www.sibvisions.com/jvx

Kontakt:René Jahn

[email protected]

René Jahn ist Mitbegründer der SIB Visions GmbH und Head of Research & Development. Er verfügt über langjährige Erfahrung im Bereich der Framework-Entwicklung und der Qualitätssicherung von Software-Projekten.

20 |

iiiiii iii

iii

Rapid Java mit XDEV 3Gerald Kammerer, freier Redakteur

4GL-Tools wie Access, FoxPro, Oracle Forms, PowerBuilder, Filemaker oder Visual Basic haben die Anwendungsentwicklung so einfach und komfortabel gemacht, dass heutzutage nahezu jedes Unternehmen Geschäftsanwendungen mit einer 4GL-Lösung erstellt. Die Ziele von Rapid Application Deve-lopment sind dieselben wie bei 4GL (4th-Generation-Language), unter anderem die Verringerung des Codieraufwands durch eine visuelle Entwicklungsumgebung und automatisches Generieren von Code, kürzere und dadurch besser lesbare und leichter wartbare Programme sowie die Reduzierung der Entwicklungskosten. Die meisten 4GL-Lösungen wie beispielswei-se Oracle Forms sind mittlerweile in die Jahre gekommen und gelten bei vielen Anwendern als nicht mehr zeitgemäß. Verstaubte Oberflächen mit starrem Bild-schirm-Layout, begrenzte Erweiterbarkeit,

mangelhafte Interoperabilität, oft fehlende Web-Fähigkeit, Runtime-Lizenzgebühren, sinkende Akzeptanz bei Endanwendern und nicht zuletzt Unsicherheit in Bezug auf Support-Garantien durch den Hersteller zwingen Lösungsanbieter zur Suche nach zukunfts- und investitionssicheren Alter-nativen wie Java oder .NET.

Kritiker bemängeln ohnehin, dass mit „Drag&Drop“-Tools prototypisch, über-stürzt und unstrukturiert vorgegangen und zudem überwiegend prozedural pro-grammiert wird, was zu unsauberem Code und dadurch schwer wartbaren Anwen-dungen führt. Hinzu kommt, dass die Mög-

lichkeiten entsprechender Tools meist sehr begrenzt sind. Notwendige Erweiterun-gen sind wegen der proprietären, in sich geschlossenen Systeme dagegen kaum möglich, sodass erfahrene Entwickler oft prophezeien, langjährig gewachsene An-wendungen müssten früher oder später mit großem Aufwand letztendlich doch auf eine „vernünftige“ Technologie portiert werden, und daher raten, von Anfang an auf Java oder .NET zu setzen.

Java-Programmierung ist jedoch auch nach zwanzig Jahren immer noch genau-so kompliziert, und der Einstieg vor allem für Anwender mit 4GL-Erfahrung oft ein

Abbildung 1: XDEV 3 bietet den einfachsten GUI-Builder im gesamten Java Umfeld. Jede denkbare Oberfläche sowie aufwändige Formulare lassen sich schnell und einfach wie mit einem Grafikprogramm umsetzen. Mit Hilfe von GUI-Beans lässt sich der Standardumfang von XDEV 3 erstaunlich leicht mit eigener Funktionalität erweitern.


iiiiii iii

iiiqualvolles Erlebnis. Schon die Syntax von Java mit seinen zahlreichen Klammern und unbekannten Kontroll- und Datenstruktu-ren wie Try-Catch, Hashtables etc. ist für viele Umsteiger ungewohnt. Richtig zu schaffen macht auch das zeitaufwändige Suchen nach benötigten Methoden in der riesigen Java-API, die zudem nur in engli-scher Sprache dokumentiert ist. Die wohl größte Problematik besteht jedoch bei der Umstellung von prozeduraler auf objekt-orientierte Programmierung (OOP). Dies verlangt vom Entwickler ein vollständiges Umdenken und Umstellen der oft langjäh-rig gewohnten und aus Entwicklersicht be-währten Programmierweise.

Nach mehreren Monaten Kampf mit Java müssen viele Umsteiger feststellen, dass sie gerade einmal die Grundlagen erlernt haben und dies noch lange nicht ausreicht, um Anwendungen für den Un-ternehmenseinsatz entwickeln zu können, die man mit der alten Lösung noch aus dem Ärmel geschüttelt hätte. Denn für die Entwicklung unternehmenskritischer Ge-schäftsanwendungen sollte man nicht nur objektorientierte Programmierung, GUI-, Datenbank- und Input/Output-Program-mierung beherrschen, sondern möglichst auch eine Java-Enterprise-Technologie wie Servlets, Spring oder Hibernate. Vorausset-zung dafür ist wiederum, dass der Entwick-ler alle wichtigen Java-Konzepte wie Inter-faces, Reflections, Generics, Annotations, sämtliche Patterns etc. beherrscht und an-wenden kann. Falls die benötigte Lösung zudem als Web-Anwendung umgesetzt werden soll, ist auch noch umfassendes Wissen über Web-Technologien wie JSP, JSF oder andere Java-Frameworks notwen-dig, wobei HTML-, CSS- und JavaScript-Know-how stets vorausgesetzt wird. Kein Wunder, dass manche Java-Einsteiger sich schon nach kurzer Zeit ihre alte Lösung zu-rückwünschen und aufgeben.

Für alle, die einen Ausweg aus diesem Dilemma suchen, gibt es mit XDEV 3 eine professionelle Entwicklungsumgebung, welche die Vorteile von Rapid Application Development und konventioneller Java-Programmierung vereint und auch wäh-rend der Entwicklung einen fließenden Übergang ermöglicht, sodass zum einen Java-Einsteiger auf Anhieb zurechtkom-men und zum anderen auch erfahrene Ja-

va-Entwickler eine gewohnte Umgebung vorfinden und sich damit wohl fühlen.

Dafür bietet die IDE ein umfassendes RAD-Konzept mit allen wichtigen Kompo-nenten, die man sich für die Entwicklung von Datenbank-Anwendungen wünscht, darunter einen GUI-Builder auf Basis von Java Swing, ER-Diagramm-Tool, Data Bin-dings, einen komfortablen Query-Assis-tenten, ein Application-Framework mit Konzepten für Datenbank-Zugriffe und Datenverarbeitung inklusive einer für Datenbank-Programmierung optimierten Funktionsbibliothek, eine vorinstallierte Testumgebung sowie ein vollautomati-siertes Deployment für die Erstellung von Builds. Damit entlastet die Entwicklungs-umgebung den Entwickler von aufwän-diger Infrastruktur-, GUI-, Input/Output-,

Datenbank- und Web-Programmierung, bei Lokalisierungen, bei Anwendungstests sowie beim Deployment und reduziert den Entwicklungsaufwand insgesamt - um bis zu 90 Prozent - enorm. Zudem ist für die aufgeführten Arbeiten kein Java-Know-how mehr nötig, was die Einstiegs-hürde deutlich senkt. Erfreulich ist, dass XDEV 3 den Entwickler nicht mehr zum Einsatz seiner RAD-Features zwingt. Denn unter der RAD-Haube steckt ein konventi-oneller Java-Code-Editor, der nicht nur von der Funktionalität her, sondern auch durch sein Aussehen etwas an Eclipse erinnert. Das Austauschen von Code, APIs und Be-ans mit anderen Java-IDEs wie Eclipse geht damit reibungslos von der Hand. Nicht nur Projekte, sondern auch die Entwicklungs-umgebung selbst lässt sich dadurch bei

Abbildung 2: Mehrsprachige Oberflächen lassen sich mit Hilfe von Text-Variablen umsetzen, die sich an allen Stellen der GUI verwenden lassen, auch für Spaltennamen von Tabellen sowie für Hinweistexte und andere Strings. Die Variablenwerte werden automatisch aus einer Sprachda-tei ausgelesen. Dabei handelt es sich um eine ganz normale Textdatei, die als Ressource an die Anwendung angebunden wird. Über die Systemeinstellungen wird immer die richtige Sprache ermittelt. Manuelles Umschalten ist ebenfalls problemlos möglich.

22 |

iiiiii iii

iiiBedarf flexibel erweitern, sodass sich hier grundsätzlich alles umsetzen lässt, was Java kann.

Aus Sicht des Herstellers stellt die Ent-wicklungsumgebung das längst überfällige Zwischenstück zwischen 4GL-Tools, wie Ac-cess und Oracle Forms, und Profiwerkzeu-gen wie Eclipse dar. Die XDEV-3-IDE ist völ-lig lizenzkostenfrei und für Windows, Linux und Mac zum freien Download unter www.xdev-software.de verfügbar. Das XDEV-Ap-plication-Framework ist Open Source.

GUI-BuilderDas auffälligste Feature der Entwicklungs-umgebung ist der WYSIWYG- GUI-Builder zur Erstellung grafischer Oberflächen. Die Basis ist Java Swing, die neben AWT, SWT und JavaFX am häufigsten verwendete Grafikbibliothek in Java. Damit stehen dem Designer alle wichtigen Controls zur Verfü-gung, die man für den Entwurf moderner Oberflächen braucht, wie Buttons, Formu-lar-Eingabe- und Auswahlfelder, Register-

reiter, Tabellen, Trees sowie Drag&Drop, Fenstertechnik, Menüs und Kontextme-nüs. XDEV 3 verwendet allerdings nicht die Standardkomponenten von Java Swing (wie JButton), sondern davon abgeleite-te GUI-Beans (wie XdevButton), die mit zusätzlichen Eigenschaften angereichert wurden, etwa für die einfache Umsetzung mehrsprachiger Oberflächen. Die Vorge-hensweise beim GUI-Design ist fast genau-so wie bei Visual Basic. Alle Controls lassen sich mit Drag&Drop in die Arbeitsfläche einfügen, dort frei skalieren und pixelge-nau positionieren. Ein Raster sowie Hilfsli-nien ermöglichen ein schnelles und exak-tes Ausrichten. Auch ein Verschachteln der Elemente ist möglich. Auf diese Weise lässt sich jede erdenkliche Oberfläche oder Ein-gabemaske verblüffend schnell und kom-promisslos umsetzen. Aufzeichnen auf Pa-pier geht kaum schneller.

Damit sind auch Software-Architekten, Designer, Projektleiter oder Mitarbeiter von Fachabteilungen in der Lage, die Um-

setzung der kompletten Oberfläche zu übernehmen.

Bereits während der Arbeit am GUI-Buil-der entsteht der entsprechende Java-Code in Echtzeit im Code-Editor. Auch Event-Handler, die für die Verarbeitung von Ereig-nissen notwendig sind, werden automatisch erzeugt. Der generierte Code ist sauber und strukturiert und lässt sich vom von Hand geschriebenen GUI-Code praktisch nicht unterscheiden. Sehr positiv fällt auf, dass nachträgliche Änderungen am generierten Code vom GUI-Builder automatisch geparst und entsprechend umgesetzt werden, sodass die GUI-Entwicklung bidirektional möglich ist. Sogar mit Eclipse geschriebe-ner GUI-Code lässt sich übernehmen und kann vom Parser verarbeitet werden.

Anders als mit älteren 4GL-Tools ist mit XDEV 3 auch die Erstellung skalierfähiger Fenster und Dialoge möglich. Dafür setzt die Entwicklungsumgebung auf die von Swing zur Verfügung gestellten Layout-Manager. Mithilfe eines Grid-Layout-Assistenten las-

Abbildung 3: XDEV 3 bietet jetzt einen konventionellen Java Code-Editor, der den Vergleich mit Eclipse nicht scheuen muss. Autovervollständigung, Method-Finder, Drag&Drop Funktionalität und Partial-View machen das Codieren für Java Einsteiger viel einfacher als andere Java Editoren. Erfreuli-cherweise lässt sich generierter Code händisch ändern und erweitern. Der Austausch von Code von und nach Eclipse oder Netbeans klappt reibungs-los, sodass praktisch keine Abhängigkeit von XDEV 3 mehr besteht.


iiiiii iii

iiisen sich selbst aufwändigste Formulare ein-fach und schnell layouten, ohne dass man sich mit der komplizierten und vor allem für Einsteiger komplizierten Gridbag-Layout-Programmierung herumplagen muss.

Mit der Verwendung von Textvariablen bei der Beschriftung der Oberfläche lassen sich auch mehrsprachige Oberflächen sehr leicht umsetzen. Die Texte selbst werden in externe Sprachressourcen-Dateien ausge-lagert. Selbst wer kein Anhänger von ge-neriertem Code ist, sollte - angesichts der enormen Zeitersparnis und der möglichen Arbeitsteilung - die Entwicklungsumge-bung zumindest als GUI-Builder für Swing in seine Überlegungen mit einbeziehen. Denn ein damit generiertes Swing-User-Interface kann problemlos mit jeder be-liebigen Zwischenschicht zu einer n-Tier-Architektur verbunden werden, etwa mit Hibernate, EJB, Spring oder mit Businesslo-gik direkt in einer Datenbank.

Mehr Unabhängigkeit von der DatenbankTrotz vorhandener JDBC-Treiber stellt XDEV 3 eigene Datenbank-Schnittstellen

für alle wichtigen Datenbanken zur Verfü-gung, die auf JDBC aufsetzen. Damit wer-den zum Teil erhebliche Unterschiede bei der SQL-Syntax zwischen den unterstütz-ten Datenbanken über den JDBC-Standard hinaus ausgeglichen, sodass man von ei-ner JDBC-Erweiterung sprechen kann. Mit dem Einsatz der mitgelieferten Schnitt-stellen lässt sich demnach eine gewisse Datenbank-Unabhängigkeit erreichen. Im Falle eines Datenbank-Wechsels müssen lediglich die Schnittstelle ausgewechselt und das Programm neu kompiliert werden, während der Code für sämtliche Abfragen unangetastet bleibt. Das ist nicht nur sehr praktisch, sondern schließt gleichzeitig eine erhebliche Fehlerquelle aus.

Zur Entwicklung und Verwaltung von Datenmodellen steht ein ER-Diagramm-Editor zur Verfügung. Auch der Import und Export von Relationen ist damit möglich. Aufgrund der hinterlegten Relationen las-sen sich sogar komplexe Datenbankabfra-gen auf einfache Weise generieren.

Eines der Highlights ist der Query-Assis-tent. Selbst aufwändigste Datenbank-Ab-

fragen über mehrere Tabellen sowie Filter-bedingungen lassen sich damit bequem mit der Maus zusammenklicken, ohne dass man dafür eine Zeile SQL-Code schreiben muss. Die Vorgehensweise ist simpel. Die im ER-Diagramm verknüpften Tabellen werden mithilfe einer TreeTable wie eine Checkliste abgebildet, sodass man nur noch systematisch alle Datenfelder ankli-cken muss, die man selektieren möchte. Notwendige Join-Bedingungen werden automatisch erzeugt. Auch Filter-Bedin-gungen (Where-Conditions) lassen sich in Sekundenschnelle zusammenklicken. Damit auch bei verknüpften Filter-Bedin-gungen die Übersicht erhalten bleibt, wird jede Bedingung in einer eigenen Zeile an-gegeben. An Stelle von Klammern werden die entsprechenden Bedingungen ein-gerückt. Eine innovative Lösung, mit der selbst komplexeste Abfrage-Bedingungen übersichtlich bleiben. Auch das Suchen nach einem Datum oder in Zeiträumen sowie die Angabe von Limits zur Begren-zung der Ergebnismenge sind sehr einfach umsetzbar.

Abbildung 4: Mit Hilfe des Query-Assistenten lassen sich selbst aufwändigste Abfragen zusammen klicken. Dabei werden Joins und Filterbedingun-gen werden automatisch generiert. SQL-Kenntnisse braucht man dazu nicht. Der generierte Abfragecode lässt sich auch im Code-Editor ändern und erweitern.

24 |

iiiiii iii

iiiMit dem Schließen des Query-Assisten-

ten generiert die Entwicklungsumgebung zuerst einmal Datenbank-unabhängigen Java-Code. Erst zur Laufzeit erzeugt eine spezielle SQL-Engine daraus den SQL-Co-de für die jeweils angeschlossene Daten-bank. Änderungen und Erweiterungen, die am generierten Abfrage-Code vorge-nommen werden, sind automatisch ge-parst vom Query-Assistenten umgesetzt, sodass die Erstellung und Bearbeitung von Queries grundsätzlich bidirektional möglich ist. Wer seine Abfragen lieber selber formulieren möchte, kann mithilfe einer Methode natürlich auch „plain“ SQL-Strings absetzen oder dynamisch erzeu-gen lassen.

Bei XDEV 3 setzt sich das RAD-Konzept auch beim Code-Editor fort. So lassen sich sämtliche Anweisungen nicht nur über die Tastatur eingeben, sondern auch über eine Command-Toolbar bequem per Drag&Drop einfügen. Beim Einfügen einer Anweisung wird automatisch die komplet-te Kontrollstruktur inklusive Klammern und Semikolon erzeugt, sodass man kaum mehr Syntaxfehler machen kann. Markie-rungen zeigen zudem an, wo Parameter anzugeben sind. Alle Kontrollstrukturen sind als Code-Template hinterlegt, das sich zudem individuell anpassen lässt. Vor al-lem für Einsteiger, die mit der Java-Syntax noch nicht so vertraut sind, ist das eine wertvolle Hilfe. Auch das Anlegen eigener Code-Templates wird unterstützt.

Weniger Code für bessere ÜbersichtDer Code-Editor befindet sich standard-mäßig in einem sogenannten „Partial-Code-View-Modus“. Damit sieht der Ent-wickler nur den Aktionscode, den er für ein bestimmtes Ereignis selber schreibt, etwa den Code für ein Mausklick-Ereignis eines Formular-Buttons. 95 Prozent des restli-chen, automatisch generierten Codes, für den sich RAD-Entwickler ohnehin kaum interessieren werden, insbesondere Im-ports, Konstruktoren etc., bleibt unsicht-bar. Der Programmcode wird dadurch sehr viel leichter lesbar, was vor allem für Java-Einsteiger eine erhebliche Erleichterung darstellt. Erfahrene Entwickler können den Partial-Code-View über eine Einstel-lung abschalten, wodurch der generierte Source-Code vollständig sichtbar wird.

Um die Suche nach Methoden mög-lichst kurz zu gestalten, bietet der Code-Editor eine spezielle Split-View. Ein kurzer Klick auf eine GUI-Komponente genügt und die Bibliothek zeigt alle Methoden zum angewählten Objekt inklusive Doku-mentation dazu an. Die benötigte Metho-de lässt sich anschließend per Drag&Drop in den Code-Editor einfügen. Ein Assistent hilft dabei sogar bei der Übergabe der rich-tigen Parameter.

Test-Umgebung und DeploymentBereits bei der Installation richtet XDEV 3 automatisch eine Testumgebung ein, wel-che auch das Testen von Java-Applets er-möglicht. Für das Erstellen von Builds gibt es ein vollautomatisiertes Deployment auf Basis von Apache Ant. Damit lassen sich Projekte wahlweise als Java-Applikation, Java-Applet oder als Webstart-Applikation deployen. Die so installierten Applikati-onen sind lauffähig unter Windows und Linux sowie auf dem Mac und lassen sich wahlweise als Fat-Client- (Applikation mit Embedded-Datenbank wie HSQLDB) oder auch als Client-Server-Applikation betrei-ben. Auch die Java-Runtime lässt sich beim Deployen gleich mit anbinden. Für Win-dows wird zudem eine EXE-Datei erzeugt, welche jedoch lediglich die ausführbare JAR-Datei anstößt. Wer seine Anwendung mit einem Installations-Setup ausliefern möchte, benötigt eine spezielle Java-Ins-tallations-Software. Um die Kosten zu spa-ren, kann man seine Applikation mithilfe von Java-Webstart verfügbar machen, wo-mit gleichzeitig interessante Features wie automatische Updates und User-Autorisie-rung möglich sind.

Entgegen aller Vorurteile, die Java-Applets zu Unrecht anhaften, sind die von XDEV 3 deployten Applets weder langsam noch unsicher, denn sie sind in viele Einzel-dateien aufgesplittet, sodass beim Aufruf der Anwendung immer nur das Startfen-ster geladen wird. Alle weiteren Fenster und Dialoge werden „on Demand“ nach-geladen, sodass das Java-Applet wie eine Flash-Animation funktioniert. Dadurch bleibt das Applet, unabhängig von seiner Gesamtgröße, stets performant. Da Java-Applets immer in einer Sandbox laufen, ist Sicherheit ohnehin stets gewährleistet. Für das Betreiben von Java-Applets wird

ein Application-Server wie Jetty oder Tom-cat benötigt, während auf dem Client in jedem Fall eine Java-Runtime vorhanden sein muss. Der Hersteller möchte das De-ployment in Zukunft sogar noch einfacher machen und das Deployen fertiger Anwen-dungen direkt in eine Cloud-Infrastruktur ermöglichen, sodass sich Entwickler nicht mehr mit der Einrichtung der Zielumge-bung auseinandersetzen müssen. Konkre-te Infos sollen in Kürze auf der Webseite bekannt gegeben werden.

FazitWer möglichst schnell, einfach und kos-tengünstig auf Java umsteigen und da-bei schnell produktiv in Java entwickeln möchte, erhält mit XDEV 3 das perfekte Tool. Es ist die erste Entwicklungsumge-bung überhaupt, die den Spagat zwischen Rapid Application Development und kon-ventioneller Java-Programmierung schafft und somit sowohl RAD- als auch erfahrene Java-Entwickler zufriedenstellt. Durch die Ähnlichkeit mit Access, Oracle Forms und Visual Basic gelingt der Einstieg auf An-hieb. Die schnellen Ergebnisse motivieren jeden Einsteiger und das Arbeiten macht richtig Spaß. Für den Einsatz in Teams muss der Hersteller mit einer Versionsver-waltung noch nachbessern. Eine Integra-tion für Apache Subversion wurde jedoch bereits angekündigt. Unter der Haube sitzt ein konventioneller Java-Editor, der das Editieren des generierten Codes und somit bidirektionales Arbeiten ermöglicht. Wer an die Grenzen des RAD-Konzepts stößt oder entsprechende Features bewusst um-gehen möchte, kann seine Arbeit nahtlos in Java fortsetzen und somit alle Freihei-ten und Möglichkeiten genießen, die Java grundsätzlich bietet. XDEV 3 ist für jeden Einsatzzweck völlig lizenzkostenfrei.

Kontakt:Gerald Kammerer

[email protected]

Gerald Kammerer ist als freier Redakteur seit 2006 für verschie-dene Computerfachzeitschriften mit Schwerpunkt Java- und AJAX-Entwicklung tätig (siehe auch Seite 34).


iiiiii iii

iii

Fragile Agilegelesen von Andreas Badelt

Im September 2010 erschien im Carl Hanser Verlag das Buch „Fragile Agile“ von Pavlo Baron und Michael Hüttermann. Die beiden Autoren sind bereits durch diverse Bücher und Zeitschriftenartikel insbesondere zu Java, IT-Architektur und (agilen) Entwicklungsmethoden einschlägig bekannt. In diesem Werk widmen sie sich den Wurzeln der agilen Software-Entwicklung, wie sie im „Agilen Manifest“ (http://agilemanifesto.org) definiert wurden.

Dieses „Agile Manifesto“, wie es im Original heisst, wurde 2001 von 17 renommierten Verfechtern agiler Software-Entwicklung gemeinsam verfasst, und hat großen Ein-fluss auf die Entwicklung und Verbreitung entsprechender Methoden und Vorgehens-modelle genommen. Wie üblich hat aber auch dieses Manifest viel Spielraum für Interpretationen gelassen, und selbst wo keiner mehr war, wurde der Begriff „agil“ im-mer noch benutzt, wissentlich oder unwis-sentlich - wie sehr, zeigt eindrucksvoll das „Half-Arsed Agile Manifesto“ eines frustrier-ten Entwicklers (http://www.halfarsedagile-manifesto.org). Diesen falschen Interpreta-tionen entgegen zu treten, haben sich die beiden Autoren auf die Fahne geschrieben.

Das Buch ist konsequenterweise an-hand der vier Wertepaare des Agilen Mani-fests gegliedert, darunter „Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“, beziehungsweise anhand der daran ausgerichteten zwölf Prinzipien (zum Beispiel „Die besten Architekturen, Anforderungen und Designs ergeben sich aus selbst-organisierenden Teams“). Jedem dieser Prinzipien ist ein eigenes Kapitel gewidmet. Darin wird zunächst das Prinzip und seine Bedeutung erklärt. Daran schließt sich eine Beschreibung von Vorgehensweisen oder Situationen an, in denen dieses Prinzip verletzt wird. Diese „Fehlinterpretationen“ werden dabei von den Autoren anhand des aristotelischen Gedankens vom „rechten Maß“ aufgebaut: Eine „Fehlinterpretation“ ist immer dieje-nige, in der das Prinzip gar nicht befolgt wird, in der anderen Interpretation wird es so überzogen angewendet, dass es ad absurdum geführt wird. Dabei wird immer wieder mit kleinen Beispielen ein Bezug zu

realen oder gut ausgedachten Projekten hergestellt und es wird aufgezeigt, welche teilweise skurrilen Fehler in sogenannten „agilen“ Projekten gemacht werden.

Neben den Projekt-Beispielen arbeiten Pavlo Baron und Michael Hüttermann auch viel mit kleinen Anekdoten und Bildanalo-gien, sowohl um ihre Beschreibungen zu unterstützen, als auch um den Text ein we-nig aufzulockern. Hinzu kommt, dass sie eine eher lockere und lebendige „Schrei-be“ haben und viele flapsige Formulierun-gen verwenden. Das Buch ist dadurch sehr gut zu lesen.

Einige Kritikpunkte sind: Die gerade erwähnten Stilmittel werden vielleicht et-was übertrieben genutzt (nicht im „rech-ten Maß“, um im oben bemühten Bild zu bleiben). Insgesamt hätte das Buch sicher um einige Seiten kürzer ausfallen können, ohne an Informationsgehalt zu verlieren. Konkret auf die Beispiele „aus dem wahren Leben“ bezogen: Diese sind manchmal zu schwarz-weiss, auch wenn den Autoren in ihrer langjährigen Berufserfahrung si-cher schon einiges widerfahren ist. Und gerade für „Agile-Anfänger“ wären ein paar Analogien sinnvoll, die weniger die Wertepaare und Prinzipien des „Agile Ma-nifesto“ erklären, sondern den Wert agi-ler Projekte an sich: Warum kann es Sinn machen, mich jetzt noch nicht damit zu beschäftigen, was in drei Monaten imple-mentiert werden muss? Aus dem gleichen Grund, und weil das Buch sich mit den Grundwerten agiler Softwareentwicklung beschäftigt, wäre auch eine gründlichere Einbettung in den Kontext sicher sinnvoll gewesen: Wo kommt „Agile“ eigentlich her, in welchem historischen Kontext ist es entstanden?

FazitDas Buch richtet sich grundsätzlich an alle Menschen, die sich für agile Software-Ent-wicklung interessieren, egal ob technisch oder fachlich orientiert, oder aus dem (Pro-jekt-) Management. Das können „Agile-An-fänger“ oder schon Fortgeschrittene sein, die mehr über die grundlegenden Prinzipi-en ihrer täglichen Arbeit erfahren wollen. Diese Gruppe ist sicher größer als man auf den ersten Blick vermuten würde. Auch ein erfahrener Scrum-Master, um ein Beispiel zu nennen, ist nicht unbedingt mit allen Aspekten von „agile“ vertraut – aber es wird ihm sicherlich in seinen Projekten hel-fen. Aber auch für „Agile-Kenner“, die sich ein paar neue Denkanstöße holen wollen, kann das Buch interessant sein.

Das Konzept ist gut und einfach: Die Autoren wollen den Leser zum Nachden-ken über den Kern agiler Software-Rnt-wicklung anregen und mit vielen Miss-verständnissen rund um das Wort „Agile“ aufräumen – dabei arbeiten sie entlang der erwähnten Prinzipien. Und das machen sie auf jeden Fall auf sehr unterhaltsame und anregende Weise.

Kontakt:Andreas Badelt

[email protected]

Andreas Badelt ist Berater und Softwareentwick-ler / -Architekt bei der CGI Information Systems and Management Consultants (Deutschland) GmbH. Sein Schwerpunkt ist die Realisierung von großen eCommerce-Systemen, insbesonde-re für die Telekommunikationsbranche. Daneben organisiert er seit 2001 die Special Interest Group (SIG) Development bzw. SIG Java der DOAG.

26 |

iiiiii iii

iii

Code-GenerierungDavid Tanzer, Freiberufler

Code-Generierung, ob aus Domain Specific Languages (DSLs) oder grafischen Modellen (UML, BPMN), ist vor allem im Enterprise-Bereich seit Jahren ein Thema. Begriffe wie „Model Driven Software Development“ (MDSD) oder „Model Driven Architecture“ (MDA) sind bei Beratern und großen Unternehmen sehr beliebt. Dieses Essay stellt einen kritischen Standpunkt zu diesen Themen dar.

Ich werde manchmal gefragt, ob ich nun für oder gegen Code-Generierung bin. Manche denken, ich sei uneingeschränkt dafür, da wir in dem Web-Framework „JSXP“ (http://jsxp.org) Code-Generie-rung einsetzen. Andere schätzen mich als totalen Gegner ein, da ich oft gegen Code-Generatoren argumentiere. Was ist also wirklich meine Meinung zu diesem Thema? Dazu muss ich leider vorerst die Standardantwort eines Beraters geben: „Es kommt darauf an.“

Code-Generierung in JSXPDas Web-Framework JSXP setzt sehr stark auf Code-Generierung. Jedes Mal, wenn eine View (typischerweise eine XHTML-Datei) verändert wird, ist eine Basisklasse für den Controller neu zu generieren. Man kann moderne IDEs so konfigurieren, dass beim Speichern eines X(HT)ML-Dokuments in einem bestimmten Ordner automatisch der Generator aufgerufen wird. Der Auf-ruf des Generators stört also den Arbeits-ablauf nicht allzu sehr. Trotzdem besteht immer noch das Risiko, dass die XML-Datei und der generierte Code nicht zusammen-passen. Aus unterschiedlichen Gründen – beispielsweise eine falsche Konfiguration bei einem Mitarbeiter – ist es möglich, dass der Generator nach einer Änderung nicht ausgeführt wird.

Warum verwenden wir bei JSXP also einen Code-Generator? Einerseits wird dadurch ein technisches Problem gelöst, das anders äußerst schwer zu lösen wäre. Die Schwierigkeit, die viele Web-Frame-works haben, besteht darin, dass man über String-Konstanten Elemente des Designs mit dem Code verbindet. Bei Wicket muss man zum Beispiel die IDs (wicket:id) aus dem Design im Code referenzieren, bei JSF schreibt man Expression Language (EL). Manche Frameworks zwingen einen sogar

dazu, Code und Design zu mischen (EL ist Code und hat eigentlich im Design nichts zu suchen). JSXP löst das Problem, Design mit Code zu verbinden, durch einen Ge-nerator. Für jedes benannte Element aus dem Design wird ein typsicherer Getter erzeugt, für jede Variable ein typsicherer Setter (siehe dazu http://jsxp.org/Element-Template.xhtml und http://jsxp.org/Hello-World_1_2.xhtml).

Andererseits werden durch den Gene-rator zwei völlig unterschiedliche Aspek-te einer Web-Anwendung miteinander verbunden: das User-Interface-Design in Form von XHTML und der Programmcode der Anwendung in Java. Dadurch kann man getrennt voneinander entweder am Design oder am Code arbeiten, und der Generator bildet eine Brücke. Der gene-rierte Code hilft auch dabei, inkompatible Änderungen an einem der beiden Teile im anderen zu entdecken: Es ist sichergestellt, dass jedes im Code referenzierte Element im Design auch existiert. Bei Wicket oder JSF müsste man dafür Unit-Tests schrei-ben, da solche Fehler erst zur Laufzeit er-kannt werden.

Dadurch war für uns der Einsatz eines Generators gerechtfertigt: Wir lösen ein technisches Problem und der erzeugte Code bildet eine Brücke zwischen zwei un-terschiedlichen Aspekten der Anwendung.

Code-Generierung in MDSDIn MDSD verfolgt das Generieren von Code einen anderen Zweck: Hier wird aus einem Modell – typischerweise ein grafisches (UML) oder textuelles (DSL) – der Pro-grammcode generiert. Da dieser auch ein abstraktes Modell der Realität ist, handelt es sich hierbei in Wirklichkeit um eine „Mo-del-to-Model“-Transformation. Das heißt, eine Repräsentation eines Aspekts des Sys-tems wird in eine andere Repräsentation

desselben Aspekts überführt. Damit lösen wir kein technisches Problem, sondern ein organisatorisches: Es wird sichergestellt, dass die unterschiedlichen Darstellungen eines Aspekts konsistent zueinander sind. Das ist so ähnlich wie das, was der Compi-ler macht: Dieser übersetzt Code aus einer höheren Programmiersprache in Maschi-nencode. Daran ist doch nichts verkehrt, oder? Also, warum bin ich für Compiler, aber gegen MDSD?

Der Grund, aus dem wir Compiler ver-wenden, ist, dass niemand ein Projekt in Maschinencode entwickeln würde. Das wäre äußerst schwierig, fast schon un-möglich, und deshalb wird es nicht einmal versucht. Wenn wir also „Blub“-Programm-code (die hypothetische Programmierspra-che aus „Beating the averages“ von Paul Graham, siehe http://www.paulgraham.com/avg.html) generieren wollen, würde das doch bedeuten, dass wir nicht direkt Blub-Code entwickeln wollen. Vielleicht, weil Blub nicht mächtig genug ist (siehe http://paulgraham.com/power.html). Wa-rum sollten wir dann aber Blub-Code ge-nerieren, anstatt gleich eine mächtigere Programmiersprache zu verwenden, deren Compiler direkt Maschinencode erzeugt?

Ich denke jedoch, dass Java (und andere „Mainstream“-Programmiersprachen) sehr gut für viele Projekte geeignet sind. Selbst bei MDSD oder MDA will man ja den Pro-grammcode, der die Geschäftslogik abbil-det, in Java oder C# schreiben. Deswegen muss der Grund für Code-Generatoren ein anderer sein als der, warum wir Compiler verwenden.

Die Begründung, die oft angegeben wird – ich habe das bereits erwähnt – ist, dass man das Modell und den Code kon-sistent halten will. Aber – auch das habe ich bereits bemerkt – der Code ist ein Mo-dell. Und ich bin überzeugt davon, dass


iiiiii iii

iiider Code „das Modell“ sein sollte, also dass nicht mehrere Modelle existieren. Die Frage ist also: Warum brauchen wir unter-schiedliche Modelle derselben Realität?

Ein Grund, der manchmal genannt wird: Grafische Darstellungen sind einfacher zu verstehen. Aber: Das stimmt nur für sehr kleine Systeme oder Subsysteme, da grafi-sche Darstellungen sehr schlecht skalieren. Deswegen ist es nicht sinnvoll, ein großes System grafisch zu entwerfen und dann den Code zu generieren. Andererseits eignen sich grafische Darstellungen sehr gut, um kleine Teilbereiche des Systems zu doku-mentieren. Dafür gibt es aber eine bessere Lösung, als den Programmcode aus der gra-fischen Darstellung zu generieren: Die grafi-sche Darstellung wird aus dem Programm-code generiert! Doxygen (http://doxygen.org) funktioniert hier sehr gut, und es gibt auch Systeme, mit denen man solche Dia-gramme in Javadoc einbinden kann.

Eine andere, oft genannte Begründung lautet, dass man das System in der Sprache des Fachbereichs entwickeln will. Da grafi-sche Darstellungen so schlecht skalieren, entwickelt man „Domain Specific Langu-ages“, also eine textuelle Darstellung in Form einer formalen Sprache. Wäre das nicht schön, wenn man direkt in der Spra-che der Domäne entwickeln könnte? Nein, wäre es nicht. Erstens ist die DSL noch immer eine formale Sprache, es wird also nicht möglich sein, dass die Endanwender das System direkt in der DSL beschreiben. Man braucht also weiterhin Programmie-rer, um das System zu entwickeln. Es wer-den sogar noch mehr Software-Entwickler benötigt, da man die DSL ja entwickeln und warten muss. DSLs sind auch per Definition Domänen-spezifisch, können also nicht so einfach für mehrere Projekte verwendet werden. Man wird auch weiter-hin Code in Blub entwickeln müssen, also muss man auch die Anbindung an das in Blub entwickelte System berücksichtigen.

Aber es kommt noch schlimmer: Man kann DSLs oder grafische Darstellungen weder Unit-testen noch debuggen! Wenn also ein Problem auftaucht, muss man ge-nerierten Code debuggen. Wenn man das Problem dann endlich gefunden hat, kann man es nicht einfach beheben. Man muss zuerst überprüfen, ob das Problem im Mo-dell oder im Generator begründet ist. Falls

es im Modell begründet ist, ändert man dieses, generiert neuen Code, ändert ge-gebenenfalls die Unit-Tests, falls sie nicht mehr zum generierten Code passen, und kann dann endlich den Fehler neu testen. Falls das Problem im Generator begründet ist, wird es erst richtig kompliziert.

FazitCode-Generierung in MDSD ist Zeit- und Ressourcen-Verschwendung. Es bremst die Entwicklung, ohne dass es irgendjeman-dem einen wirklichen Vorteil bringen wür-de. MDSD ist zwar Management-tauglich, da es den falschen Eindruck von Kontrol-le erweckt („bei uns ist alles genauestens durch Modelle dokumentiert“), aber davon sollte man sich nicht täuschen lassen. Auch DSLs lösen die Probleme von MDSD nicht zufriedenstellend. In gewissen Fällen halte ich Code-Generierung für das geringere Übel, aber auch in JSXP bin ich nicht zu 100 Prozent zufrieden damit. Es wäre viel schöner, wenn wir eine noch engere Ver-bindung zwischen Design und Code hät-ten, zum Beispiel: public class IndexXhtml-Controller extends „index.xhtml“.

Der Java-Compiler selbst (oder ein Plug-in) müsste die Verbindung zwischen „index.xhtml“ und der Java-Klasse herstel-len. Das haben wir, als wir das Framework konzipierten, gar nicht in Betracht gezo-gen, da es technisch viel zu aufwändig (falls überhaupt möglich) wäre.

Um den Programm-Code mit den An-forderungen und der Sprache der Domäne synchron zu halten, ist „Domain Driven De-sign“ sehr gut geeignet. Hier ist das Buch von Eric Evans sehr empfehlenswert. UML-Diagramme halte ich durchaus für sinnvoll: Man sollte sie auf ein Whiteboard zeichnen und wieder löschen, sobald der Code das erfüllt, was das Diagramm aussagt.

Kontakt:David Tanzer

[email protected]

David Tanzer ist seit 2006 als selbststän-diger Software-Entwickler und Berater tätig. Im Rahmen dieser Tätigkeit be-schäftigt er sich mit Java-Enterprise-Anwendungen, Web-Anwendungen, mobilen Anwendungen und agiler Soft-ware-Entwicklung. Er ist Mit-Initiator des Java-Web-Frameworks JSXP.

aformatik Training & Consulting GmbH & Co. KG

Tilsiter Str. 6 | 71065 Sindelfingen | 07031 238070

www.aformatik.de

wissen wie´s geht

Training & Consulting

• Java Grundlagen- und Expertenkurse

• Java EE: Web-Entwicklung & EJB

• JSF, JPA, Spring, Struts

• Eclipse, Open Source

• IBM WebSphere, Portal und RAD

• Host-Grundlagen für Java Entwickler Unsere Schulungen können gerne auf Ihre individuellen Anforderungen angepasst und erweitert werden. Weitere Themen und Informationen zu unserem Schulungs- und Beratungsangebot finden Sie im Internet unter www.aformatik.de

1/3 Seite hoch im Anschnitt 77 x 303 Farbe

28 |

iiiiii iii

iii

BPM-Lösungen mit Java EE selbst gebautRalph Soika, Imixs

Das Imixs-Workflow-Projekt ist Open Source und erleichtert den Bau von Workflow-Management- (WfMS) sowie Business-Process-Management-Systemen (BPM). Wesentlicher Bestandteil sind die Imixs-JEE-Workflow-Komponenten, um BPM-Lösungen auf Basis der Java-EE-Plattform zu bauen.

Das folgende Tutorial zeigt, wie mithilfe von Eclipse, GlassFish und Maven eine Imixs-BPM-Lösung in wenigen Minuten erstellt werden kann. Für die Ausführung sind ein Applikationsserver, eine Daten-bank und die Eclipse IDE notwendig. Als Applikationsserver kommt der GlassFish Server V3 zu Einsatz, auf dem die ferti-ge Anwendung verteilt und ausgeführt werden kann. Die Daten sind in einer Da-tenbank gespeichert. Java EE stellt keine besonderen Anforderungen an eine Da-tenbank; im Open-Source-Umfeld fällt die Wahl meist auf MySQL.

Für die Ausführung der BPM-Lösung stellt der Applikationsserver zwei wesent-liche Funktionen bereit. Zum einen spei-chert er die Prozessdaten in der Datenbank über einen sogenannten „Database-Pool“, zum anderen stellt er einen Security-Realm bereit. Dieser sorgt dafür, dass User sich gegenüber der Anwendung authentifizie-

<?xml version=“1.0“ encoding=“UTF-8“?> <settings xmlns=“http://maven.apache.org/POM/4.0.0“ xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance“ xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd“> <profiles> <profile> <id>default</id> <repositories>  <repository> <id>repository.jboss.com</id> <name>Jboss Repository for Maven</name> <url>http://repository.jboss.com/maven2/</url> </repository> </repositories> </profile> </profiles> <activeProfiles> <activeProfile>default</activeProfile> </activeProfiles> </settings>

Listing 1

Abbildung 1: Ein neues Maven-Projekt erzeugen

ren können und unberechtigte Zugriffe unterbunden werden.

Die Imixs-Workflow-Lösung stellt um-fangreiche Funktionen bereit, um einzelne Datensätze in Abhängigkeit des Prozess-modells vor unerlaubtem Zugriff zu schüt-zen. Für den späteren Zugriff auf das Sys-tem wird mindestens ein User als Mitglied der Gruppe „IMIXS-WORKFLOW-Manager“ benötigt. Mitglieder dieser Gruppe sind auch berechtigt, Workflow-Modelle zu synchronisieren. Die Konfiguration des Database-Pools sowie des Security-Realms ist schnell erledigt. Eine vollständige Ins-tallationsanleitung für GlassFish und JBoss steht unter http://doc.imixs.org/jee/ins-tall_glassfish.html.


iiiiii iii

iii

Abbildung 2: Auswahl eines Maven-Archetypes

Abbildung 3: Einen Maven-Archetype hinzufügen

Eclipse und Maven konfigurierenFür die Arbeit mit Eclipse werden das Modeler-Plugin zur Modellierung des Pro-zessmodells sowie das Maven-Plugin von Sonatype für den Bau des JEE-Projekts benötigt (http://www.sonatype.com/pro-ducts/m2eclipse). Beide lassen sich inner-halb von Eclipse bequem über den Men-übefehl „Help −> install new Software“ aus folgenden URLs installieren:

http://www.imixs.org/org.imixs.eclipse.•updatesitehttp://m2eclipse.sonatype.org/sites/m2e•

Die Web-Oberfläche der BPM-Lösung wird mithilfe von RichFaces realisiert. Dies ist eine Komponenten-Bibliothek für JavaSer-ver Faces (JSF), mit der Ajax-basierte Web-Anwendungen erstellt werden können. Für die Verwendung von RichFaces in Ma-ven ist das Jboss-Repository in die eigene Maven-Konfiguration aufzunehmen. Die einfachste Art, das RichFaces-Repository für Maven sichtbar zu machen, besteht darin, in der Datei „%USERPROFILE%\.m2\settings.xml“ ein entsprechendes Profil einzurichten. Die settings.xml-Datei findet sich in Windows-Systemen unter c:\Benut-zer\USERNAME\.m2\. Existiert noch keine settings.xml-Datei, kann man diese einfach erstellen (siehe Listing 1).

Nachdem die Entwicklungsumgebung Eclipse und die Server-Infrastruktur ste-hen, kann der Bau der BPM-Lösung begin-nen. Da das Workflow-Projekt vollständig auf Maven basiert, ist das Erstellen einer neuen Anwendung sehr einfach. Über die Auswahl eines sogenannten „Maven Archetypes“ kann ein Template verwen-det werden, das bereits alle notwendigen Komponenten einer BPM-Lösung enthält. Das neue Maven-Projekt lässt sich in Eclip-se über „File −> new Project....“ erzeugen (siehe Abbildung 1).

Über den Projekt-Typ „Maven −> Maven Project“ gelangt man in den Maven-Projekt-Wizard (siehe Abbildung 2). Dieser Wizard erlaubt die Erstellung eines neuen Projekts auf Basis eines Maven-Templates. Auf der zweiten Wizard-Seite „Select an Archetype“ sind alle bekannten Templates angezeigt.

Da das Imixs-JEE-Template bisher noch nicht verwendet wurde, muss es einmalig über den Button „Add Archetype“ hinzuge-

fügt werden (siehe Abbildung 3). Für den Dialog „Add Archetype“ sind folgende An-gaben notwendig:

Archetype Group Id: org.imixs.application•Archetype Artivact Id: imixs-workflow-•jee-archetypeArchetype Version: 0.0.4•

Maven führt daraufhin den Download des Templates durch, das anschließend ausgewählt werden kann. Auf der letzten Wizard-Seite gibt man nun noch verschie-dene Parameter für das neue Projekt an (siehe Abbildung 4). Group Id und Artifact Id sind beliebig wählbar. Über die Arche-type-Eigenschaften können die zuvor am

30 |

iiiiii iii

iii...... [INFO] Unnamed - com.foo:my-bpm-app-ejb:ejb:0.0.1-SNAPSHOT SUCCESS [2.756s] [INFO] Unnamed - com.foo:my-bpm-app-web:war:0.0.1-SNAPSHOT SUCCESS [3.899s] [INFO] Unnamed - com.foo:my-bpm-app-ear:ear:0.0.1-SNAPSHOT SUCCESS [3.658s] [INFO] --------------------------------------------------------------------- [INFO] BUILD SUCCESS [INFO] --------------------------------------------------------------------- [INFO] Total time: 11.135s [INFO] Finished at: Sat Jul 17 17:00:55 CEST 2010 [INFO] Final Memory: 3M/15M [INFO] ---------------------------------------------------------------------

Listing 2

Abbildung 4: Maven-Archetype konfigurieren

Abbildung 5: Die Projektstruktur

Server eingestellten Informationen über den Database-Pool und den Security-Realm vorgenommen werden. Insgesamt lassen sich für das BPM-Projekt drei Para-meter einstellen:

jta-data-source: Dieser Wert bestimmt •den vom Server zu verwendenden Da-tabase Pool, in dem später die Prozess-daten gespeichert werden sollenrealm: Der Realm ist der Server Securi-•ty Realm, der zur Authentifizierung ver-wendet werden soll context-root: Der Context-Root be-•stimmt die Webadresse, unter der die Anwendung aufgerufen werden kann (etwa http://localhost:8080/workflow)

Die Schaltfläche „Finish“ erzeugt nun das Projekt. Maven beginnt automatisch da-mit, sämtliche benötigten Bibliotheken aus dem Internet zu laden und prüft da-bei auch alle notwendigen Abhängigkei-ten der einzelnen Bibliotheken. Dies er-leichtert die Arbeit sehr, da man keinerlei Java-Bibliotheken manuell herunterladen und installieren muss. So werden auch die RichFaces-Komponenten automatisch in das Projekt mit aufgenommen.

Anschließend erscheinen im Package Explorer insgesamt vier Projekte. Das erste (hier my-bpm-app) kann für den vollstän-digen Build und die Installation verwendet werden. Die Unterprojekte -ear, -ejb und -web enthalten jeweils das entsprechende Java-EE-Modul.

Die Anwendung builden, deployen und testenUm nun die fertige Anwendung zu bauen, genügt es, im Hauptprojekt (my-bpm-app) über das Kontext-Menü den Befehl „Run as −> Maven Install“ aufzurufen (siehe Abbil-dung 5). Daraufhin startet Maven automa-tisch den kompletten Build-Prozess und erstellt eine ausführbare EAR-Anwendung, die im GlassFish-Server installiert werden kann. Die Eclipse-Ansicht „Console“ zeigt den Build-Status an. Der Build ist erfolg-reich, sobald die Ausgabe „BUILD SUC-CESS“ erscheint (siehe Listing 2). Nun kann die Anwendung bereits auf dem Applika-tionsserver installiert werden. Das fertige EAR-Modul steht im Maven-Verzeichnis unter %USERPROFILE%\.m2\com\foo\my-


iiiiii iii

iii

Abbildung 6: Imixs-Modeller

bp-app-ear\0.0.1-SNAPSHOT. Um es unter GlassFish zu deployen, wählt man über die GlassFish-Web-Konsole den Menüpunkt „Applications −> Deploy“ aus (siehe Abbil-dung 6). Danach wird das EAR-File aus dem .m2-Verzeichnis ausgewählt. Während des Deployments legt das Java-EE-Framework automatisch die notwendigen Tabellen-Strukturen in der angegebenen Datenbank an. Die manuelle Erzeugung eines speziel-len Schemas ist hier also nicht notwendig.

Ein Modell erstellenBevor die Anwendung über den Web-Brow-ser geöffnet wird, ist noch ein Workflow-Mo-dell bereitzustellen. Die BPM-Anwendung in Eclipse besitzt bereits im Hauptprojekt unter /src/workflow/ticket.ixm ein Beispiel-Workflow-Modell. Die Datei ticket.ixm lässt sich mit dem Imixs-Modeler öffnen und bearbeiten. Über den Tab „Synchronize“ gelangt man zu den Web-Service-Settings, über die die Modelldaten per REST-Service mit der Workflow-Anwendung synchroni-siert werden. Die URL für den Web-Service lautet http://localhost:8080/workflow-rest/model. Wurde der Context-Root angepasst, ändert sich diese Adresse entsprechend in /[ROOT_CONTEXT]-rest/model. Über den Link „synchronize model“ wird das Modell in die Workflow-Anwendung übertragen (sie-he Abbildung 7). Hierzu ist eine Anmeldung mit dem zuvor eingerichteten User-Account aus der Zugriffsgruppe „IMIXS-WORKFLOW-Manager“ erforderlich. Anschließend kann man die Workflow-Anwendung auf http://localhost:8080/workflow über den Web-Browser starten. Über den Menübefehl „Meine Aufgaben −> neue Aufgabe −> Ticket“ wird dann ein erster Ticket-Prozess gestartet. Natürlich lässt sich anschließend das Modell über den Imixs-Modeler belie-big ändern beziehungsweise erweitern. Die laufende Anwendung muss dazu nicht mehr neu gestartet oder deployed werden.

Die Web-Anwendung weiterentwickeln Natürlich lässt sich die erstellte Workflow-Anwendung an die eigenen Anforderun-gen anpassen. Wer sich das in Eclipse er-zeugte JEE-Projekt genauer ansieht, wird feststellen, dass es aus nur wenigen Java-Klassen besteht. Die meiste Funktionalität kommt direkt aus den Imixs-JEE-Kompo-nenten. Um die Anwendung anzupassen,

genügt es meist, schon die im Web-Modul hinterlegten JSF-Seiten (.xhtml) zu än-dern und die Java-Klasse „WorkflowMB“ zu erweitern. Wer mehr über die hier ver-wendeten JSF-Klassen erfahren möchte, kann unter http://doc.imixs.org/jsf/ bezie-hungsweise http://doc.imixs.org/modeler/ Beispiele über die Imixs-JSF-Tools-Projekt-Homepage aufrufen oder den Source Code einsehen.

Kontakt:Ralph Soika

[email protected]

Ralph Soika begann mit 16 Jahren Homecomputer in Basic, Assembler und Turbo Pascal zu program-mieren. Danach hat er sich mit Windows-Program-mierung in Delphi beschäftigt. Seit 1998 konzent-riert er sich auf die Entwicklung von Software mit Java. Seine Schwerpunkte liegen im Bereich JEE. Er betreibt seit 2005 das Open-Source-Projekt Imixs.

Abbildung 7: Die fertige Workflow-Anwendung

32 |

iiiiii iii

iii

Cloud in a BoxJens Dollenbacher, Oracle Software (Schweiz) AG

Cloud Computing ist zu Zeit der beherrschende IT-Trend als Werkzeug der Konsolidierung, optimaler Ausnutzung bestehender Ressourcen und flexibler Lastverteilung in Rechenzentren.

Technologien wie Virtualisierung und schnelle Netzwerke ermöglichen eine neue Dynamik im unternehmensweiten Computing. Sie bieten neue Möglichkeiten zur Kosteneinsparung und schnellem De-ployment – der Sprung von „Software as a Service“ zu „Platform as a Service“. Längst sind große Anbieter wie Amazon auf die-sen Zug aufgesprungen und haben auf dieser Basis erfolgreich Geschäftsmodelle etabliert: die „Public Cloud“, die es jeder-mann ermöglicht, Computer-Ressourcen kurzfristig zu mieten, zu nutzen und da-nach wieder in der Wolke verschwinden zu lassen. Für Unternehmen außerhalb dieses Dienstleitungsbereichs bietet sich die „Pri-vate Cloud“ an, die dynamische Nutzung dieser Ressourcen innerhalb einer Unter-nehmens-IT.

Viele Jäger sind des Hasen TodDie Einführung einer solchen „Private Cloud“ stellt allerdings Herausforderun-

gen unterschiedlicher Art. Zum einen ent-stehen organisatorische Konsequenzen, denn auch eine virtualisierte Umgebung will verwaltet werden, zum anderen stellt sich auch die Frage, auf welcher Hard- und Software-Basis eine solche Umgebung entstehen soll. In klassischen Umgebun-gen treffen wir in den Rechenzentren eher kleinere Maschinen im Bereich von vier bis sechzehn Cores an, auf denen zumeist nur eine Applikation dediziert betrieben wird, mit allen daraus resultierenden Kon-sequenzen, wie mangelhafte Auslastung der Maschine, vermehrter Standplatz und großer Administrationsaufwand. Ein im-mer größer werdender Maschinenpark, teils mit unterschiedlicher Hardware, teils mit unterschiedlichen Betriebssystemen, jagen den Administrator vor sich her wie die Jäger den Hasen, und viele Jäger sind bekanntlich des Hasen Tod; der Aufwand im Operations wird durch Provisioning, Deployment, Patch Management und

Monitoring immer größer. Dieses Problem wird auch durch die klassische Virtualisie-rung nicht kleiner. Wir brauchen also neue Konzepte und Technologien, um die Her-ausforderungen einer Cloud zu meistern.

Die „Cloud in a Box“Mit der Exalogic-Maschine hat Oracle nun eine Lösung präsentiert, die genau diese Punkte adressiert. Statt mit vielen, rela-tiv kleinen Maschinen unterschiedlicher Bauart und mit unterschiedlichen Be-triebssystemen geht Oracle nun den Weg, seinen Kunden eine Komplettlösung für Private Clouds anzubieten, eine „Cloud in a Box“. Die Exalogic-Maschine ist modernes Computing vom Feinsten, von Hardware-Experten von Sun und Software-Experten von Oracle gemeinsam entwickelt und für die Aufgabenstellung optimal auf maxi-male Performance und Hochverfügbarkeit getunt. Dieses Expertenwissen und über hundert Personenjahre an Arbeit stecken in dieser Lösung, die es ermöglicht, Ap-plikationen in perfekt virtualisierbarer Umgebung hochperformant zu betreiben, Ressourcen on Demand zuzuordnen, und dies auf einer absolut standardisierten Plattform, die nicht beim Kunden, sondern beim Hersteller gereift ist. Das bedeutet, dass nicht nur Tuning und Engineering dieser Maschine nicht mehr vom Kunden zu leisten sind, sondern bereits im Auslie-ferungszustand ein perfekter Setup steht. Und hier ist erst der Anfang.

Patch-Management in IT-Operations stellt immer eine große Aufgabe dar. Wel-cher Patch kann in welcher HW/SW-Kom-bination eingespielt werden? Dies erfor-dert nicht unbeträchtlichen Aufwand an Testing und kann damit auch zum wahren Showstopper im Upgrade-Prozess wer-den. Dies alles entfällt in einer durch den Hersteller komplett standardisierten Um-

Allgemeine Geschäftsbedingungen:Die Abonnementsgebühr wird jeweils im Januar für ein Jahr fällig. Abonnementverträge, die während eines Jahres beginnen, werden für das DOAG News Plus Abonnement mit 20 Euro(*) und für das Java aktuell – das Magazin Abonnement mit 4,90 Euro (*) je volles Quartal berechnet. Das Abonnement verlängert sich automatisch um ein weiteres Jahr, wenn es nicht bis 31. Oktober eines Jahres schriftlich gekündigt wird. Es gilt ein zweiwöchiges Widerrufrecht bei Bestellung. DOAG News Plus Abonnement: Zum Preis von 75 Euro(*) pro Kalenderjahr erhalten Sie sechs Ausgaben der DOAG News, 4 Ausgaben der Java aktuell – das Maga-zin sowie zwei Ausgaben DOAG Business News jeweils direkt nach Erscheinen per Post zugeschickt. Java aktuell – das iJUG Magazin Abonnement: Zum Preis von 18 Euro (*) pro Kalenderjahr erhalten Sie vier Ausgaben der Zeitschrift „Java aktuell – das iJUG-Magazin“ direkt nach Erscheinen per Post zugeschickt. (*) inkl. USt. und Versandkosten für Deutschland, Österreich und die Schweiz.

Name, Vorname

Firma

Anschrift

E-Mail

Bitte senden Sie Ihre Bestellung per E-Mail an [email protected] per Fax an 0700-11362439

Jetzt Abonnement sichern:

DOAG News Plus Abo: alle Ausgaben DOAG News, οDOAG Business News und Java aktuell zu 75 Euro im Jahr

Abonnement Newsletter: οJava aktuell – der iJUG-Newsletter, kostenfrei

Java aktuell – das iJUG-Magazin Abo: οvier Ausgaben zu 18 Euro im Jahr

Ich habe die AGBs zur Kenntnis genommen.Datum/Unterschrift:


iiiiii iii

iii

gebung. Patches aller Art, ob Treiber, Be-triebssystem oder Applikationsserver, sind bei Oracle/Sun bereits auf absolut iden-tischer Hardware und Software getestet und freigegeben; der Aufwand verschiebt sich vom Kunden zum Hersteller. Erfahre-ne und talentierte Mitarbeiter können sich auf wichtigere Aufgaben konzentrieren.

Ein SystemüberblickDie Exalogic-Maschine (siehe Abbildung 1) ist die erste Maschine, die komplett dafür designed worden ist, Unternehmen eine sichere und hochverfügbare Private Cloud zu ermöglichen, mit einer unerreichten Per-formance, extrem einfachem Management und fast unbeschränkter Skalierbarkeit. Sie ist eine ideale Plattform für Applikationen aller Art. Obwohl die Exalogic-Maschine für Enterprise Java, Fusion Middleware und Fusion Applications optimiert ist, stellt sie dennoch eine optimale Umgebung für tausende Applikationen aller Art für Linux und Solaris. Sie ist die Maschine des Data-centers des 21. Jahrhunderts. Durch den optimalen und ausbalancierten Einsatz standardisierter Hardware-Technologien wie Infiniband, Flash Disks und Intel-Xeon-Prozessoren, optimiert durch Oracle Elas-tic Cloud Software und maximal getunte Oracle-Java-Technologie, entsteht ein völ-lig neuer Typ von Maschine, die in Bezug auf Leistung und Managebarkeit die erste ihrer Art ist.

Die Exalogic-Maschine wird in drei Ba-siskonfigurationen angeboten: Das Quar-ter-, das Half- und das Full-Rack, drei ver-schiedene Ausbaustufen, welche komplett Upgrade-fähig sind, das heißt, ein Quarter-Rack lässt sich z.B. problemlos nachträg-lich zu Half- oder Full-Rack ausbauen. Und auch ein Full-Rack lässt sich noch bis zu acht Maschinen skalieren. Tabelle 1 zeigt die verschieden Typen.

Extreme Java PerformanceDie Kombination aus Oracle Exalogic Soft-ware und Hardware führt zu signifikanten Performancezugewinnen bei Java-Ap-plikationen, die auf Weblogic Server und anderen Fusion-Middleware-Technologien laufen. Benchmark-Tests auf vergleichba-rer Hardware (gleicher Prozessor, gleiches RAM) lassen hier einen Vergleich zu und zeigen in verschiedenen Szenarien deutli-che Verbesserungen:

Zwei- bis dreifache Verbesserung bei •OLTP-Applikationen gegenüber den DBBis zu 60 Prozent mehr Java-Operatio-•nen pro SekundeBis zu zehnfach schnellere Antwortzei-•ten

Diese Ergebnisse zeigen die deutliche Überlegenheit der Exalogic-Maschine ge-genüber üblicher Standardhardware. Was macht den Unterschied? Die Optimierung für genau diesen Zweck. So wie ein Fahr-zeug für einen bestimmten Zweck entwor-fen wird – ein Sportwagen für schnelles Fahren, ein Lastwagen für große Lasten – ist die Exalogic-Maschine designt, um Java-Applikationen mit optimaler Perfor-mance auszuführen. Oder würde man ein Auto kaufen, das „für alles“ gut sein soll?

FazitDie Herausforderungen an eine moderne IT sind zweifelsohne immer mehr Perfor-mance, dynamisches Ressourcen-Manage-ment, Verfügbarkeit und Skalierbarkeit, dies bei anhaltendem Kostendruck, der es erfordert, immer effizienter zu arbeiten. Um dies zu meistern, sind neue Wege und Lösungen notwendig. Systeme selbst zu bauen, die solchen Ansprüchen genügen, ist teuer, langwierig und mit Risiko behaf-tet. Die Exalogic-Maschine bietet hier eine

Quarter-Rack Half-Rack Full-Rack 2-8 Racks

2.93 GHz Xeon Cores 96 192 360 720-2880

1333 MHz RAM 768 GB 1.5 TB 2.8 TB 5.6-22.4 TB

FlashFire SSD 256 GB 512 GB 960 GB 1.9-7.7 TB

SAS Disk Storage 40 TB 40 TB 40 TB 80-320 TB

Tabelle 1Abbildung 1: Das System im Überblick

Jens Dollenbacher ist Principal Sales Consultant bei Oracle Schweiz und berät Kunden und Partner zu IT Architekturen. Seine Schwerpunkte sind Middleware, Java EE und IT Modernisierung.

Alternative, die es Unternehmen ermög-licht, von Beginn an ohne zusätzliches ei-genes Engineering genau diese Punkte zu erreichen:

Bessere Java-Performance•Bessere Skalierbarkeit und Verfügbar-•keitBessere Managebarkeit•

Weitere Informationen http://www.oracle.com/us/products/middleware/exalogic/index.html

Kontakt:Jens Dollenbacher

[email protected]

Java aktuell – Der iJUG-Newsletter

Interessanten Nachrichten und Informationen aus der Java-Com-munity erhalten Sie einmal im Monat mit dem iJUG-Newsletter. Weitere Informationen unter www.ijug.eu

34 |

iiiiii iii

iii

AJAX-Entwicklung wie SwingGerald Kammerer, freier Redakteur

Vaadin ist eine Java-Grafikbibliothek, welche die Entwicklung und Pflege hochwertiger Web-Anwendungen auf Basis von AJAX (Asynchronous JavaScript and XML) erheblich vereinfacht.

Die Idee von Vaadin ist ein servergetriebe-nes Programmiermodell, mit dem Entwick-ler Web-Anwendungen vollständig in Java schreiben können – und zwar genauso wie mit Swing. Mit den Browser-Skriptsprachen HTML und JavaScript kommt der Vaadin-

Entwickler nicht mehr in Kontakt, denn das Browser-Frontend wird komplett von Vaa-din erzeugt. Beispielsweise wird ein Button mithilfe der Vaadin-Button-Klasse imple-mentiert, während im Browser ein entspre-chender JavaScript-Button angezeigt wird.

Anders als andere AJAX-Frameworks über-nimmt Vaadin nicht nur das Rendern der Oberfläche, sondern auch die komplette Kommunikation zwischen Browser-Fron-tend und Server - und somit den kompli-ziertesten Teil der AJAX-Programmierung.

Abbildung 1: Mit Vaadin lassen sich Ajax-Anwendungen entwickeln, deren Aussehen und Verhalten sich kaum mehr von klassischen Desktop-Anwen-dungen unterscheidet. Was die Performance betrifft, sind echte Desktop-Programme jedoch immer noch klar schneller.


iiiiii iii

iiiAJAX-Anwendungen vollständig in Java schreibenVaadin besteht aus einem serverseitigen Framework und einer clientseitigen Ja-vaScript-Engine, die für das Rendern des Frontends im Browser sowie für Interakti-onen mit dem Server zuständig ist. Beim Aufruf der Anwendung wird zunächst eine JavaScript-Engine geladen, welche mithil-fe von AJAX die Oberfläche aufbaut. Die Businesslogik einer Vaadin-Applikation läuft dagegen als Servlet in der Umge-bung eines Application-Servers auf dem Server. Da die Geschäftslogik auf dem Ser-ver getrennt und völlig unabhängig vom Frontend im Client läuft, kann man sich das User-Frontend wie einen Thin-Client vorstellen, der lediglich die Oberfläche anzeigt, Anwender-Aktionen entgegen-nimmt und an die eigentliche Applikation auf dem Server weiterleitet.

Da das komplette GUI dynamisch von einem JavaScript-Programm erzeugt wird, das jeder Web-Browser interpretieren kann, ist für die Ausführung einer Vaadin-Applika-tion - anders als bei Flash, Silverlight oder Java-Applets - kein proprietäres Browser-Plug-in erforderlich. Da die Oberfläche vom Framework selbstständig erzeugt wird, sind zudem keine eigenhändigen Browser-Anpassungen seitens des Entwicklers mehr notwendig. Aufwändiges und zeitrauben-des Testen und Anpassen des Frontends an die verschiedenen Browser ist somit nicht mehr notwendig. Um das Frontend genauso reaktionsschnell und interaktiv zu machen wie konventionelle Desktop-Appli-kationen, setzt Vaadin auf AJAX (Asynchro-nous JavaScript and XML).

Frontend mit Google Web ToolkitWas Vaadin aber so richtig spannend macht, ist die Tatsache, dass das Framework unter der Haube das Google Web Toolkit (GWT) für das Rendern der Oberfläche nutzt. GWT gilt als ausgereift, performant und ist für sehr große Nutzerzahlen ausgelegt, was die von Google selbst mit GWT entwickel-ten Applikationen wie Google Maps ein-drucksvoll unter Beweis stellen. Auch GWT-Programme werden in Java geschrieben, sodass sich der Entwickler nicht mit HTML und JavaScript auseinandersetzen muss. Mithilfe des GWT-Compilers werden diese jedoch vollständig in JavaScript übersetzt.

package com.vaadin.demo;

import com.vaadin.ui.Label;import com.vaadin.ui.Window;

@SuppressWarnings(„serial“)public class HelloWorld extends com.vaadin.Application {

/** * Init is invoked on application load (when a user accesses the appli cation * for the first time). */ @Override public void init() {

// Main window is the primary browser window final Window main = new Window(„Hello window“); setMainWindow(main);

// „Hello world“ text is added to window as a Label component main.addComponent(new Label(„Hello World!“)); }}

Abbildung 2: Die komplette Business-Logik einer Vaadin-Applikation läuft als Servlet auf dem Server. Das HTML/JavaScript Framework wird mit Hilfe von Google Web-Toolkit gerendert. Eigene Widgets und Themes lassen sich in Vaadin recht leicht einbinden. Die Datenübertragung managed das Framework, sodass sich der Entwickler darum nicht kümmern muss.

Abbildung 3: Das Ergebnis nach dem Aufruf (siehe Listing darüber)

36 |

iiiiii iii

iiiGWT eignet sich somit sehr gut für die Im-plementierung von UI-Controls und Inter-aktionslogik auf dem Client. Um die Kom-munikation zwischen Client und Server müssen sich GWT-Entwickler jedoch selber kümmern. GWT setzt dabei auf Remote Procedure Calls (RPC). Dabei versendet der Client eine Anfrage an eine Prozedur auf dem Server und wartet auf Antwort. Nach dem Empfang der Nachricht kann der Cli-ent mit anderen Prozessen fortfahren. Vaa-din dagegen nimmt dem Entwickler die Client-Server-Kommunikation komplett ab, was die Architektur einer AJAX-basie-renden Web-Anwendung und deren Pro-grammierung erheblich einfacher macht. Vaadin komplettiert den Ansatz von GWT sozusagen. Für die Übertragung der Da-ten verwendet Vaadin HTTP(S), das JSON-Format sowie die User Interface Definition Language (UIDL), womit der Entwickler je-doch nicht konfrontiert wird.

Vaadin selbst stellt bereits alle wichtigen UI-Controls wie Fenster, Tabellen, Register-reiter sowie Formular-Controls zur Verfü-gung. Die Qualität der Controls ist dabei so gut, dass sich eine Vaadin-Oberfläche nicht von einer Desktop-Anwendung un-terscheiden lässt. Ähnlich wie Swing bie-tet auch Vaadin verschiedene Look&Feels (Themes). Mithilfe von CSS lassen sich bei Bedarf auch individuelle Themes umset-zen. Zudem sind erstaunlich viele Extensi-ons verfügbar. Da Vaadin-Oberflächen mit GWT erzeugt werden, lassen sich grund-sätzlich alle GWT-Komponenten recht einfach einbinden. Wie Swing bietet auch Vaadin verschiedene Layout-Manager für die Realisierung skalierfähiger Oberflä-chen und Dialoge. Im Vergleich zu Swing erscheinen die Möglichkeiten zwar noch etwas rudimentär, die meisten Anwen-dungsfälle lassen sich damit jedoch sehr gut abdecken.

Geschäftslogik vollständig in Java schreibenDer Einsatz von GWT bedeutet zudem, dass auch die Geschäftslogik einer Vaadin-Applikation in Java geschrieben wird. Für den Server-Teil setzt Vaadin auf die Java-Servlet-API auf. Aber auch mit dieser muss sich der Vaadin-Entwickler nicht direkt aus-einandersetzen. Beim Aufruf einer Vaadin-Anwendung wird jeweils eine Instanz des Servlets mit Session erzeugt. Solange eine Session existiert, ordnet das Framework alle Client-Aktionen automatisch der rich-tigen Instanz zu.

Die Vaadin-Programmierbibliothek un-terscheidet klar zwischen User-Interface und Programmlogik und erlaubt, diese auch unabhängig voneinander zu ent-wickeln. Vaadin wurde ganz klar für die Entwicklung von webfähigen Geschäfts-anwendungen entwickelt, weniger für die Programmierung von herkömmlichen

Abbildung 4: Auf der Vaadin Webseite findet man für alle verfügbaren UI-Controls entsprechende Demos.


iiiiii iii

iiiWebseiten oder Portalen. Für Eclipse bietet Vaadin ein Plug-in, mit dem sich neue Vaa-din-Projekte anlegen, Themes individuell anpassen und eigene UI-Controls entwi-ckeln lassen.

Die XDEV Software Corp. hat für 2011 eine RAD-Entwicklungsumgebung für Vaa-din angekündigt, mit der AJAX-Entwick-lung sehr einfach und die AJAX-Techno-logie auch für 4GL-Entwickler zugänglich gemacht werden soll. Die IDE soll einen intuitiven Vaadin-GUI-Builder enthalten, der nicht nur den Vaadin-GUI-Code inklusi-ve Event-Handler generiert, sondern auch Änderungen des generierten Codes und somit bidirektionale GUI-Entwicklung er-laubt. Damit sollen Software-Architekten

und -Designer in der Lage sein, die kom-plette Oberfläche einer AJAX-Anwendung zu entwickeln, ohne dafür eine Zeile Code schreiben zu müssen. Datenbankzugriffe und Visualisierung sollen ähnlich einfach wie in Access und Oracle Forms funktio-nieren. Dazu kommen eine für Datenbank-Anwendungen optimierte Funktionsbib-liothek und ein Java-Code-Editor für die Entwicklung der Anwendungslogik. Damit entwickelte Anwendungen sollen sich an-schließend problemlos auf Eclipse portie-ren lassen. Informationen zu diesem Pro-jekt finden Sie unter www.xdev-software.de. Vaadin ist als Open Source unter Apa-che-License verfügbar unter www.vaadin.com.

Gerald Kammerer ist als freier Redakteur seit 2006 für verschiedene Computerfachzeitschrif-ten mit Schwerpunkt Java- und AJAX-Entwick-lung tätig. Seit über zehn Jahren programmiert er nun schon intensiv mit Java und kennt die Sprache seit ihren Anfängen. Seit einigen Jah-ren beschäftigt er sich nun auch intensiv mit der Entwicklung von Rich Internet Applications mit Java, JavaFX und verschiedenen AJAX-Frameworks wie jQuery, Wicket, Google Web-Toolkit und Vaadin (siehe auch Seite 20).

Kontakt:Gerald Kammerer

[email protected]

Neu im iJUG: Swiss Oracle User Group (SOUG)Vor dem Hintergrund der Sun-Übernahme durch Oracle haben sieben Java-Usergroups aus Deutsch-land zusammen mit der DOAG Deutsche ORACLE-Anwendergruppe e. V. sowie der Sun User Group (SUG) Deutschland e.V. den Interessenverbund der Java User Groups e.V. (iJUG) gegründet. Ziel des iJUG ist die umfassende Vertretung der gemeinsamen Interessen der Java Anwendergruppen sowie der Java-Anwender im deutschsprachigen Raum, insbesondere gegenüber Entwicklern, Herstellern, Ver-triebsunternehmen sowie der Öffentlichkeit. Eine weitere Aktivität ist die Herausgabe dieser Zeitschrift. In der letzten Ausgabe wurden die Gründungsmitglieder ausführlich vorgestellt. Neu hinzugekommen ist die Swiss Oracle User Group (SOUG).

Die SOUG wurde 1987 als unabhängiger Verein gegründet und umfasst heute rund 600 Mitglieder. Als Community der Oracle-Spezialisten fördern sie den Informations- und Erfahrungsaustausch, vertriit die Interessen der Mitglieder auf nationaler sowie internationaler Ebene und bietet verschiedene Mög-lichkeiten zur Vernetzung mit anderen Personen. Die SOUG-R (SOUG Romandie) ist in der Westschweiz für die französisch sprechenden Mitglieder aktiv.

Das Angebot für die Mitglieder umfasst Veranstaltungen (Special Interest Group Meetings, Konfe-renzen), den vierteljährlich erscheinenden Newsletter (Print-Maganzin), Downloads (Newsletter-Arti-kel, Präsentationen etc.) und verschiedene Vergünstigungen wie Rabatt bei Schulungsanbietern und reduzierte Teilnahmegebühren an User Group Konferenzen.

Traditionell war die SOUG eher Datenbank- und Oracle-Tool-orientiert. Mit dem Aufkommen von Java gewann dieses Thema natürlich auch für Oracle-Spezialisten an Bedeutung. Heute hat Java einen festen Stammplatz an den Veranstaltungen und im Newsletter der SOUG.

Mit dem Beitritt zum iJUG bietet die SOUG ihren Mitgliedern ein erweitertes Angebot. Die Java aktu-ell ist wie der SOUG Newsletter im Mitgliederbeitrag enthalten und die Vernetzung mit Java-Spezialis-ten wird einfacher. Auf der anderen Seite möchte man auch den Mitgliedern des iJUG einen Mehrwert bieten. Als Oracle User Group kann die SOUG den Java-Spezialisten die „Oracle-Welt“ unabhängig vom Hersteller etwas näher bringen. Die in diesem Bereich gemachten Erfahrungen dürften auch für die Java-Communities von Interesse sein. Weitere Informationen: www.soug.ch

Mitglieder stellen sich vor

38 |

iiiiii iii

iii

JSXP-TemplatesDavid Tanzer, Freiberufler

Just Simple eXtensible Pages (JSXP) ist ein Open-Source-Web-Anwendungs-Framework, das in der ersten Ausgabe von „Java aktuell“ bereits kurz vorgestellt wurde. Eines der Hauptziele des Frameworks ist, eine enge Zusammenarbeit zwischen Designern und Entwicklern zu ermöglichen. Dafür muss man für bestimmte Bereiche einer Webseite einheitliche Designs definieren können – das macht man in JSXP mittels View Templates.

Ein View Template bestimmt eine Grund-struktur für beliebige andere Views. Solche Templates werden, wie jede andere View auch, als XML-Datei (etwa XHTML) definiert und mittels Java Code mit Funktionalität angereichert. Diese View (XHTML) und de-ren View Controller (Java) kann man nicht nur als Template, sondern auch als eigene Seite verwenden.

Das TemplateAls Beispiel erstellen wir eine Seite „index.xhtml“, die sowohl als Einstieg für die An-wendung dient, als auch die Grundstruktur für alle weiteren Seiten vorgibt. Auf dieser Seite kann man z.B. das Hauptmenü für die gesamte Anwendung definieren (siehe Lis-ting 1).

Nach dem Speichern dieser Datei wird automatisch eine Basisklasse für den View Controller generiert. Von dieser generier-ten Klasse muss man ableiten und in der abgeleiteten Klasse bekanntgeben, dass diese View als Template verwendet wer-den kann. Dazu geben wir an, welche Teile des Templates durch andere Seiten ausge-tauscht werden können (siehe Listing 2).

In der Anwendungsklasse muss das Template noch registriert werden. Das bewirkt, dass das Template auf alle Seiten der Web-Anwendung benutzt wird (siehe Listing 3).

Anwenden auf eine andere SeiteDas oben definierte Template wird ab jetzt auf alle Seiten angewendet. Jede Seite kann den Bereich mit der jsxp:id „content“ austauschen, indem die Seite selbst einen Bereich mit dieser id definiert (siehe Lis-ting 4).

Alle anderen Bereiche dieser Seite wer-den ignoriert. Diese Tatsache kann vom Designer genutzt werden, um in alle De-

index.xhtml:<html> <body> <ul class=“menu“ jsxp:id=“main_menu“> <li jsxp:id=“menu_item“>$(MenuItemText)</li> </ul> <div jsxp:id=“content“> Willkommen in unserer Webanwendung </div> </body></html>

Listing 1

IndexXhtmlController.java:public class IndexXhtmlController extends IndexXhtmlControllerGenerated<Object> { @Override public Element[] getTemplateElements() { return new Element[] { getElementContent() }; }}

Listing 2

Application.java:public class Application extends WebApplication { private ViewController<?> template; public Application () { template = new IndexXhtmlController(); } @Override protected ViewController<?> getTemplate() { return template; }}

Listing 3

page2.xhtml:<html> <body> <div jsxp:id=“content“> Das ist Seite 2 der Anwendung </div> </body></html>

Listing 4


iiiiii iii

iiisigns Mockups der gesamten Seite einzu-fügen. Unsere „page2.xhtml“ könnte also ein Beispiel des Menüs enthalten, wie es sich der Designer für genau diese Seite vorstellt.

Funktionalität im TemplateUm in Seiten Funktionalität zu implemen-tieren, wird normalerweise die Methode „execute“ überschrieben. Diese wird aber nur aufgerufen, wenn die Seite selbst ge-rendert wird, nicht wenn sie ein Template für eine andere Seite ist. Deshalb muss man Funktionalität, die auf allen Seiten be-nötigt wird, in der Methode „init“ definie-ren. Funktionalität, die nur auf der Index-Seite benötigt wird, kommt weiterhin in „execute“(siehe Listing 5).

FazitWir haben gezeigt, dass View Templates in JSXP verwendet werden können, um eine einheitliche Struktur für alle Seiten einer Webanwendung zu definieren. Es ist au-ßerdem möglich, Templates nur für Teilbe-

IndexXhtmlController.java:public class IndexXhtmlController extends IndexXhtmlControllerGenerated<Object> { @Override protected void init(Importer importer) { menu = getElementMenu(); //Menü dynamisch erzeugen... } @Override public void execute() { }

}

Listing 5

reiche der Seite zu definieren, und sogar, Templates zu schachteln. So kann man ein globales Template für einen Teilbereich der Seite weiter verfeinern. Einzelne View Controller können auch angeben, dass sie nicht am globalen Templating teilnehmen möchten, indem sie die Methode „isGlo-balTemplateEnabled“ überschreiben. Ins-gesamt steht so ein mächtiges Werkzeug zum Design von Webanwendungen zur Verfügung.

Die XDEV Software Corp. plant, die freie Rapid Java Entwicklungsumgebung XDEV 3 so eng wie möglich an 4GL-Tools wie Oracle Forms und Microsoft Access anzu-lehnen. Dadurch sollen 4GL-Entwickler endlich schnell und einfach auf Java um-steigen können, eine vertraute Umgebung vorfinden und wie gewohnt entwickeln können. Dazu möchte XDEV Software die Anwender mit ins Boot holen und lädt alle Oracle Forms, Access und andere 4GL Entwickler am 23. März 2011 zu einem Brainstorming-Workshop in Nürnberg ein, bei dem zuerst die bereits vorhande-nen RAD-Features von XDEV 3 vorgestellt werden und anschließend jeder Teilneh-mer Feature benennen und vorführen kann, die XDEV 3 haben sollte. Ziel des

Java-Entwicklung wie Oracle Forms geplantMarkus Stiegler, XDEV Software GmbH

Anwender die sich schon lange eine richtig einfache Entwicklungsumgebung für Java wünschen, können jetzt die Entwicklung von XDEV 3 aktiv mitgestalten und maßgeblich beeinflussen.

Workshops ist die gemeinsame Erarbei-tung einer Feature-Liste und Roadmap für die Umsetzung. Thomas Schmetzer, Ge-schäftsführer von XDEV Software Deutsch-land GmbH: „Wir wollen möglichst alle Featuers in XDEV 3 abbilden, die für 4GL-, allen voran für Forms-Entwickler wichtig sind, um den Umstieg und Softwaremig-rationen auf Java so einfach wie möglich zu machen. Unsere Anwender können mit diesem Workshop die Weiterentwicklung von XDEV 3 entscheidend mitbestimmen“. Interessierte Anwender können sich unter www.xdev-software.de anmelden.

Kontakt:Markus Stiegler

[email protected]

David Tanzer ist seit 2006 als selbstständiger Software-Entwickler und Berater tätig. Im Rahmen dieser Tätigkeit beschäftigt er sich mit Java-Enter-prise-Anwendungen, Web-Anwendungen, mobilen Anwendungen und agiler Software-Entwicklung. Er ist Mit-Initiator des Java-Web-Frameworks JSXP (siehe auch Seite 27).

Kontakt:David Tanzer

[email protected]

Markus Stiegler ist Technologie-Evangelist und Product Manager für die Entwickler-Toolsparte der XDEV Software Corp. in Deutschland. In dieser Funktion ist er verantwortlich für die Entwicklung von Produkt-, Marketing- und PR-Strategien und deren Umsetzung, für die Verbreitung von XDEV-Lösungen im deutschsprachigem Raum sowie für Kooperationen mit Technologie-Partner. Derzeit ist Markus Stiegler mit dem Aufbau eines Experten-Teams für Migrationsprojekte beschäf-tigt, das ab Anfang 2011 in der Lage sein soll, besonders zeitkritische Migrationen auf Java und AJAX sicher und kostengünstig durchzuführen. Von 2007 bis 2008 war Markus Stiegler für die Produktion der Fernsehsendung XDEV TV zu-ständig, die XDEV Software Corp. zusammen mit dem Gaming-Sender GIGA Digital bis zu dessen Auflösung produzierte. Neben der Co-Moderation leitete er das Redaktionsteam.

40 |

iiiiii iii

iii

Integration mit Launch4j – der letzte SchliffDr. Stefan Koch, ORDIX AG

Anwender lieben das, was sie kennen. Also müssen sich Java-Programme nahtlos in die MS-Windows-Welt einfügen. Das Open-Source-Werkzeug Launch4j hilft dabei und lässt Java-Anwendungen genauso starten wie native Programme oder wandelt sie in ausführbare Windows-Dateien um. Obwohl Java mit Java Web Start selbst ein mächtiges Konzept zum Starten und Verteilen von Java-Software zur Verfügung stellt, wird dabei die Plattformunabhängigkeit angestrebt. Launch4j dagegen ist der Spezialist in Sachen „Integration“.

Unter Windows-Systemen kommt es oft zu Schwierigkeiten, wenn Anwender ver-suchen, Java-Anwendungen auszuführen. Abhilfe schafft hier das Open-Source-Werkzeug Launch4j. Nach der Installation erstellt es ein Startprogramm für Java-Anwendungen. Dieses hat die typischen Eigen schaften einer nativen Anwendung. Es lässt sich als exe-Datei mit Doppelklick starten und wird im Explorer mit eigenem Icon dargestellt. Die Versionseigenschaf-ten eines nativen Programms wie Datei-version, Firma, Produktname und -version werden im Windows-Explorer angezeigt.

Die durch Launch4j erzeugte exe-Datei zeigt bei der Ausführung einen Startbild-schirm; die installierte Java-Version wird überprüft. Alternativ ist eine spezielle Java-Installation für den Start möglich. Das Startprogramm kann die jar-Datei beinhal-ten. Der Nutzer sieht nur das ausführbare Programm. Launch4j ist über die Komman-dozeilen-Schnittstelle oder über ant-Tasks in den automatischen Build-Prozess integ-rierbar. Für die Entwicklung der Konfigura-tion steht eine grafische Benutzeroberflä-che zur Verfügung.

Los geht‘s: Download und InstallationLaunch4j ist über die Launch4j-Webseite [1] kostenlos verfügbar. Nach dem Down-load wird launch4j.exe gestartet (siehe Abbildung 1). Zunächst ist der Name des Programms im Reiter „Basic“ als Output-File einzutragen. Anschließend wird die jar-Datei angegeben, die gestartet werden soll. Standardmäßig wird sie in das Start-programm eingebettet.

Als letzte erforderliche Information wird im Reiter „JRE“ die Java-Version defi-niert, die für das Programm benötigt wird. Unter „Min JRE version“ ist die Java-Versi-on einzutragen, die durch „java –version“ ausgegeben wird. Danach wird die Kon-figuration abgespeichert. Anschließend muss der Anwender nur noch auf das Zahnrad klicken, um den Build-Prozess zu starten. Schon ist das Startprogramm fertig.

Neue Icons – darf es etwas bunter sein?Das so erstellte Startprogramm wird im Windows-Explorer mit dem Standard-Icon für ausführbare Programme dargestellt (siehe Abbildung 2). Im Reiter „Basic“ ist das Feld „Icon“ für die Angabe eines Icons vorgesehen. Es ist sinnvoll, das Startpro-gramm mit einem Icon zu dekorieren – so kann der Benutzer das Programm leichter identifizieren. In der Regel wird das Icon des Anwendungsfensters verwendet.

Abbildung 1: Benutzeroberfläche von Launch4


iiiiii iii

iii

Bei Java-Programmen kann je nach Hardware einige Zeit vergehen, bis sich die Anwendung bemerkbar macht. Um dem Anwender unmittelbar zu zeigen, dass das Programm geladen wird, ist ein Bild für den Startbildschirm − auch „Splash“ genannt − zu definieren. Das Start programm zeigt den Startbildschirm, noch bevor das Java-Programm gestartet wird. Dazu bietet Launch4j die Checkbox „Enable splash screen“ im Reiter „Splash“. Dort gibt der Entwickler eine Bitmap-Gra-fik als Splash-File an. Nach dem Erstellen des Startprogramms wird das definierte Icon im Windows-Explorer angezeigt (sie-he Abbildung 3).

Java macht abhängigMöglicherweise hat der Anwender nicht die richtige Java-Version installiert. In diesem Fall zeigt das Startprogramm die Nachricht, die im Reiter „Messages“ im Feld „JRE“ als „version error“ angegeben ist. Da-

rüber hinaus öffnet sich der HTML-Browser mit der Seite, die im Feld „Java download URL“ des Reiters „Basic“ eingegeben ist.

Gerade bei Java-Programmen mit Be-nutzeroberflächen liegt die Überlegung nahe, die Java Virtual Machine mit der Software auszuliefern, um Inkompatibili-täten zu neueren Java-Versionen auszu-schließen. Damit diese Java-Version ver-wendet wird, muss im Reiter „JRE“ das Feld „Bundled JRE path“ mit dem Java-Installa-tionspfad angegeben werden.

Weitere StartparameterTypischerweise wird die Anwendung Abhängigkeiten zu weiteren Bibliothe-ken haben. Bei einer überschaubaren Anzahl können die Biblio theken zusam-men mit dem Programm in eine jar-Datei gepackt werden. Damit lassen sich ex-terne Abhängigkeiten vermeiden. Al-ternativ werden die Abhängigkeiten zu externen Bibliotheken im Classpath ange-

geben. Launch4j spendiert dieser Einstel-lung eigens einen Reiter namens „Class-path“.

Konfigurationsparameter für die virtu-elle Maschine von Java, wie beispielsweise die Größe des Speicherraums, werden im Reiter „JRE“ eingetragen. Bemerkenswert ist, dass der Speicherbedarf auch prozentu-al zum freien Speicherbereich angegeben werden kann. Weitere Startparameter für das Programm werden im Feld „Command line args“ des Reiters „Basic“ definiert. Um-gebungsvariablen werden im Reiter „Set env. Variables“ festgelegt.

ProgrammeigenschaftenIm Windows-Explorer lassen sich Informa-tionen zu Programmen unter „Eigenschaf-ten“, Reiter „Version“ anzeigen. Die we-sentlichen Attribute sind „Beschreibung“, „Copyright“ und „Dateiversion“. Darüber hinaus können auch Angaben zu Firma, Produktname, Produktversion und Spra-che angezeigt werden. In Launch4j lassen sich diese Eigenschaften im Reiter „Ver- sion Info“ definieren. Launch4j kann auch verhindern, dass eine zweite Instanz des Programms gestartet wird. Im Reiter „Single Instance“ muss dazu ein sogenann-ter „Mutex name“ angegeben sein.

FazitLaunch4j ist bestens geeignet, damit der Anwender ein Java-Programm genauso wie eine native Anwendung nutzen kann. Der Umfang ist gut durchdacht, die Be-nutzerschnittstelle ist intuitiv bedienbar, ein automatischer Build-Prozess wird un-terstützt. Sind Aspekte der Verteilung der Software und die Ver sions-Pflege zu be-rücksichtigen, ist der Einsatz von Java Web Start in Erwägung zu ziehen.

Kontakt:Dr. Stefan Koch

[email protected]

Der Autor Dr. Stefan Koch, Java-Spezialist der ORDIX AG, schreibt seit Jahren Artikel über Neuigkei-ten und Best-Practice-Möglich-keiten in der Java-Entwicklung in dem firmeneigenen IT-Magazin „ORDIX News“.

Abbildung 2: Explorer-Darstellung einer Anwendung ohne Icon

Abbildung 3: Darstellung des gewählten Icons im Explorer

42 |

iiiiii iii

iiiJava-Coherence-Cache-Architektur Wolfgang Weigend, ORACLE Deutschland B.V. & Co. KG

Steigende Transaktionsvolumen in der Verarbeitungslogik und zunehmende Anforderungen für Software-Echtzeitdaten bei der Prozessauswertung und bei SOA/ereignisgetriebenen Architekturen verursachen eine höhere Last auf den Backend-Systemen. Dabei soll die Infrastruktur die Anforderungen der Systeme und Anwender erfüllen und die geforderte Leistung liefern. Dies macht jedoch den Einsatz von neuen Architekturen notwendig.

Die Architektur-Lösung muss die Daten für eine höhere Leistung bereithalten, verteil-te Datenmengen oftmals in Echtzeit verar-beiten und im Arbeitsspeicher befindliche Datenströme analysieren. Gleichermaßen soll sie sich in bestehende Hardware- und Software-Landschaften einfügen und Datenbanken, Anwendungsserver sowie Messaging-Systeme einbeziehen.

Mit einer Ressourcen-Bündelung durch die Anwendungsplattform werden die Skalierbarkeitsanforderungen optimal be-dient, da sie die vorhandenen Ressourcen effizient koordiniert. Die Anforderungen an die Anwendungsplattform nach hohem Durchsatz, niedrigen Antwortzeiten und massiver Skalierbarkeit erfordern den Ein-satz einer Middleware-Caching-Architektur und deren Implementierung. In einer ge-meinsamen Speicherstruktur mit separaten Cache-Memory-Bereichen können die Spei-cher-Inhalte auf andere Software-Knoten beliebig verteilt werden; damit befinden sich ein Datum im Hauptspeicher und wei-tere Kopien im jeweiligen Cache-Memory. Cache-Coherence ist der Mechanismus, der dafür sorgt und sicherstellt, dass die Verän-derungen der Daten sehr schnell innerhalb des Caching-Systems verteilt werden. Die daran teilnehmenden Anwendungen nut-zen diese Daten und deren Änderungen direkt aus einer verteilten, linear skalierba-ren und konzentrierten Caching-Struktur. Einfache und komplexe Abfragen können parallel innerhalb der Caching-Struktur verteilt „In-Memory“ ausgeführt werden. Damit wird auch die Anzahl der Zugriffe auf Backend-Systeme verringert oder stark eingeschränkt, um Datenbanken und Main-frame-Systeme zu entlasten.

Die Anforderungen an die IT-Infrastruk-tur steigen stetig und erfordern eine Op-timierung in der Anwendungsplattform.

Dabei sollen dynamische Änderungen und vorhersagbare Anwendungsskalierbarkeit die geschäftlichen Anforderungen unter-stützen. Durch eine verbesserte Anwen-dungsleistung wird ein schnellerer Daten-zugriff ermöglicht und die Antwortzeiten werden verkürzt. Durch die kontinuierliche Datenverfügbarkeit und Zuverlässigkeit mit definierten Service Level Agreements und deren Einhaltung werden die ge-schäftliche Kontinuität sichergestellt und die Kosten für Infrastruktur- und Entwick-lungskosten gesenkt.

Neue Services und Events stellen auch neue Anforderungen an die Transaktions-verarbeitung. Mit zunehmender geschäft-licher Geschwindigkeit und Innovation nimmt auch die Komplexität von Services und damit auch deren Zustandsverwal-tung zu. Dies erfordert die Bereitstellung von skalierbarer Leistung mit der Zielset-zung, dass ein Service innerhalb der erfor-derlichen, definierten Antwortzeit auch in extremen Situationen reagiert und bei Be-darf adhoc nahtlos skalierbar ist. Die dafür notwendige Transaktionsplattform verfügt über Merkmale einer verteilten Transakti-onsverarbeitung (Distributed Transaction Processing for Open Systems) und extrem leistungsfähiger Transaktionsverarbeitung (XTP).

Die IT bestimmt den Datenbedarf und macht eine bessere Auslastung der Infra-struktur erforderlich, da die Verbreitung von Daten oftmals alle Systeme betrifft. Durch Virtualisierung wird die verbesserte Ausnutzung der Ressourcen erreicht, und eine Neuverteilung von Anwendungen erfolgt transparent und ohne Unterbrech-nung des Datenzugriffs. Bei gleichzeitiger Datenversorgung und mehrfach erhöhter Last wird die Service-Infrastruktur einem starken Zugriff auf gemeinsame Ressour-

cen ausgesetzt und muss kontinuierliche Verfügbarkeit und absolute Zuverlässig-keit sicherstellen.

Geeignete Maßnahmen liefert Cohe-rence in der aktuellen Version 3.6 über eine zuverlässige Datenschicht mit einer konsistenten Sichtweise auf die Daten und mit transaktionaler Integrität. Es wird die dynamische Erhöhung der Datenkapazität mit Lastverteilung, kontinuierlicher Ver-fügbarkeit und Fehlertoleranz ermöglicht. Auch die erforderliche Verarbeitung und Skalierbarkeit der benötigten Datenkapa-zität mit extrem niedrigen Antwortzeiten wird damit sichergestellt. Bei diesem Lö-sungsansatz wird ein Anwendungsserver mit Coherence als Datenvermittler einge-setzt, der die Datenversorgung mit dem Datenbedarf vermittelt und in der Lage ist, die Middleware-Schicht mit Standard-Hardware zu skalieren.

Die dabei auftretenden Herausforde-rungen betreffen mehrere Architektur-Schichten, von der Anwendung über Last-verteilung, Web-Server, Applikationsserver und Persistenzschicht bis zur Datenbank. Dabei wird die Transaktionsverarbeitung der Java-Anwendung besonders gefor-dert; Objekt-relationale Werkzeuge verzö-gern oft die Durchlaufzeiten und machen eine In-Memory-Speicherverarbeitung notwendig, um die gewünschten Ant-wortzeiten zu erzielen. Gleichermaßen darf der Transaktionsstatus nicht verloren gehen, und die Verwaltung von Session-Zuständen gebietet besondere Aufmerk-samkeit in heterogenen Umgebungen. Den beschriebenen Herausforderungen begegnet Oracle Coherence durch Daten-Virtualisierung mit dem Caching von se-rialisierbaren Objekten. Die gemeinsame Nutzung von Daten wird organisiert und mit Read-Through und Read-Ahead Pat-


iiiiii iii

iiiterns umgesetzt. Parallele Abfragen, Indi-zes und Transaktionen im Cluster werden abgefedert, und Coherence entlastet die unterliegende Persistenzschicht mit den Write-Through- und Write-Behind-Pat-terns. Dabei integriert sich Coherence mit Applikationsservern, Objekt-relationalen Werkzeugen und Datenbanken.

Coherence verteilt die Daten gleich-mäßig auf alle Clusterknoten und sorgt dafür, dass auch ein Backup der Daten auf die entsprechenden Knoten verteilt wird. Dabei werden die Daten automatisch und synchron auf mindestens einen weiteren Server repliziert. Die logisch konsistente Sicht auf die Daten wird von allen Knoten

hergestellt sowie mit einem Health-Check ständig gegenseitig überprüft. Der Status bei auftretenden Fehlern wird über alle Knoten Cluster-weit diagnostiziert. Wird ein Knoten aus dem Cluster entfernt, so wer-den die Daten wieder gleichmäßig verteilt. Durch die automatische und dynamische Partitionierung der Speicherdaten über mehrere Server gewährleistet Oracle Co-herence die kontinuierliche Verfügbarkeit der Daten und Transaktionsintegrität auch beim Serverausfall. Neu hinzugefügte oder nach einem Ausfall erneut gestartete Ser-ver werden automatisch in das Cluster ein-gebunden und über Oracle Coherence mit Service-Anfragen versorgt, sodass die Clus-

ter-Last transparent umverteilt wird. Orac-le Coherence umfasst Funktionen zur Feh-lertoleranz auf Netzwerkebene und zum transparenten Warmstart im Rahmen der Server-Selbstheilung. Coherence-Caching ermöglicht den Anwendungen, Daten di-rekt aus verteilten und linear skalierbaren, gebündelten Datenquellen zu nutzen. Die Anzahl der Zugriffe auf Backend-Systeme wird reduziert bzw. gezielt vermieden (Datenbanken, Mainframe). Das Write-Queue-Pattern reduziert dabei die Last auf Backend-Systeme. Die Analyse-Funktiona-lität von Coherence bietet Aggregationen, und einfache sowie komplexe Abfragen können parallel im Daten-Pool clusterweit verteilt im Speicher „In-Memory“ ausge-führt werden. Als gemeinsam genutzte Infrastruktur kombiniert Coherence die lokale Datenverfügbarkeit mit lokaler Ver-arbeitungskapazität und ermöglicht damit Datenanalysen in Echtzeit, speicherbehaf-tetes Grid Computing sowie die parallele Verarbeitung von Transaktionen und Ereig-nissen mit automatischem Event-Handling und Änderungsbenachrichtigungen (siehe Abbildung 1).

Das Betriebsmodell von Coherence sieht sowohl die Integration mit einzelnen Applikationsservern vor, als auch den hy-briden Einsatz mit dem Applikationsserver als Transaktions-Manager und dem Zusam-menspiel mit mehreren Coherence-Knoten in einem Coherence Grid. Die Kombination von Coherence mit Applikationsservern bietet clusterweites Caching und Zu-standsverteilung. Dabei werden verteilte Daten im Cache gehalten und eine unab-hängige Zustandsverwaltung in hetero-genen Java-Umgebungen sichergestellt. Der Coherence-Client kann sich dabei in einem Applikationsserver oder in einem Cluster von Applikationsservern befinden. Der zugeordnete Coherence-Cache-Server ist clusterweit organisiert und entlastet die Datenbank mittels Pufferfunktion, bei-spielsweise über „Read-Through Pattern“ (siehe Abbildung 2) und „asychrone Write-Through Pattern“ zur Datenbank. Mit dem Coherence-Datenmanagement wird eine Verbesserung der Applikationsleistung und deren Zuverlässigkeit erreicht.

Die Eigenschaften von Coherence um-fassen die parallele Verarbeitung mit Daten und deren Verarbeitungsaffinität, parallele

Abbildung 1: Verteilte In-Memory Caching-Struktur

Abbildung 2: Coherence Read-Through Caching Pattern

44 |

iiiiii iii

iiiAbfragen und Aggregation für Objekt-basierte Abfragen. Coherence unterstützt Replikation, Partitionierung, Read-through, Write-through, Write-behind und Refresh-ahead Caching-Mechanismen. Bei der Ver-waltung von Daten über einen Cluster mit Coherence-Datenstrukturen wird ein sehr schnelles Objekt-Clustering-Verfahren verwendet. Die Kommunikation geschieht über das spezielle Tangosol Cluster Ma-nagement Protocol (TCMP), welches über einen eigenen Serialisierungs-Mechanis-mus für den Netzwerk-Transport verfügt und UDP verwendet. Weiterhin benutzt Coherence das Portable Object Format (POF) für optimierte Objekt-Serialisierung in Java und kein generisches „Java Seria-lizable Object Format”. Die Coherence Da-ten- und Verarbeitungsdienste stehen vom lokalen Netzwerk bis zum Wide-Area-Netz-werk (WAN) zur Verfügung und beinhalten ein Failover- und Recovery-Management sowie das Transaktions-Management. Die Echtzeit-Ereignisüberwachung wird mit dem Listener Pattern (Cache-Event-Be-nachrichtigung) bereitgestellt. Coherence benutzt JAAS-basierte Authentifikation, Netzwerkdurchsatz-Encryption (NTE) so-wie auf Java Management Extensions (JMX) basierendes Monitoring und Ma-nagement über clustered JMX. Die Per-sistenzschicht von Coherence stellt über JPA die Integration mit Oracle TopLink und anderen Objekt-relationalen Mapping-Technologien her. Oracle Coherence ist mit Oracle WebLogic Server und anderen Java-EE-Applikationsservern kombinierbar. Wei-terhin gibt es ein Coherence-API zur Unter-stützung für C++ und .NET.

Zusammenfassend bestehen die Vortei-le von Oracle Coherence aus der extremen und vorhersehbaren Reaktionsleistung und einer nahezu unbegrenzten Anwen-dungsskalierbarkeit. Zudem erlaubt das Ressourcen-Management den Einsatz von Standard-Hardware zur Leistungssteige-rung der Anwendungsplattform und maxi-miert die Ausnutzung von Ressourcen im Rechenzentrum mit dynamischen Service Level Agreements zur Gewährleistung ei-ner besseren Service-Qualität innerhalb ei-ner flexiblen Anwendungsplattform.

In der Java-Entwicklungsumgebung wird mit dem Code-Beispiel (siehe Listing 1) der NamedCache erzeugt, ein Wert mit

„put“ eingefügt und anschließend über-prüft, welche Werte im NamedCache vor-handen sind.

Fügt man eine weitere Java-Klasse „My-FirstSampleReader“ hinzu und verwendet „get“ anstelle von „put“, so kann man die eingefügten Werte vom Cache auslesen (Listing 2).

Kontakt:Wolfgang Weigend

[email protected]

Wolfgang Weigend ist als Systembe-rater für die Oracle Fusion Middlewa-re bei der Oracle Deutschland B.V. & Co. KG zuständig für Architektur und strategischen Produkteinsatz bei Großkunden. Er verfügt über langjäh-rige Erfahrung in der Systemberatung und im Bereich objektorientierter Softwareentwicklung mit Java. Davor war er als Principal Systems Engineer 9 Jahre bei der BEA Systems GmbH.

package com.oracle.coherence.handson;

import com.tangosol.net.CacheFactory;import com.tangosol.net.NamedCache;

public class MyFirstSample {public MyFirstSample() {}

public static void main(String[] args) {

// create or get a named cache called mycacheNamedCache myCache = CacheFactory.getCache(„mycache“);

// put key, value pair into the cache.myCache.put(„Name“,“Claudia Meier“);

System.out.println(„Value in cache is „ + myCache.get(„Name“));}}

Listing 1: NamedCache erzeugen; Werte einfügen und überprüfen

package com.oracle.coherence.handson;

import com.tangosol.net.CacheFactory;import com.tangosol.net.NamedCache;

public class MyFirstSampleReader {

public MyFirstSampleReader() {}

public static void main(String[] args) {// ensure we are in a cluser

CacheFactory.ensureCluster();// create or get a named cache called mycache

NamedCache myCache = CacheFactory.getCache(„mycache“);

System.out.println(„Value in cache is „ + myCache.get(„Name“));}}

Listing 2: Werte aus dem Cache auslesen


iiiiii iii

iii

OSGi-Scripting mit GroovyDirk Mahler, buschmais GbR

Laufzeit-Management besitzt für JEE-Anwendungen eine hohe Bedeutung. Klassische Application-Server bieten dafür neben grafischen Oberflächen mächtige Scripting-Schnittstellen an. Für OSGi als modulare JEE-Plattform ist es in diesem Punkt jedoch schlecht bestellt. Es existieren zwar neben Web- auch Telnet-basierte Konsolen, allerdings ist eine Automatisierung von Installationen und Konfigurationen so nur schwer zu erreichen. Der Artikel zeigt, wie MAEXO [1] und Groovy Abhilfe schaffen.

Folgendes Szenario soll verwirklicht wer-den: In einem leeren OSGi-Container ist eine neue Webanwendung zu installieren. Neben der eigentlichen Anwendung muss dafür ein Http-Service zur Verfügung ge-stellt werden. Dafür fallen folgende Ma-nagement-Aktivitäten an:

Abfrage des Container-Zustands•Installation der notwendigen Bundles •(Apache Felix HTTP Service [4], basie-rend auf Jetty)Konfiguration des zu verwendenden •Ports (8085)Start des Bundles, welches den HttpSer-•vice publiziertÜberprüfung der Verfügbarkeit des Http- •Service

Die Anwendung wird in einem Rechen-zentrum gehostet, sodass kein direkter Zugang möglich ist und das Management per JMX abgewickelt werden muss. Glück-licherweise sind im OSGi-Container die entsprechenden MAEXO-Bundles bereits installiert und aktiviert.

Applikation und WerkzeugkastenZur Nachvollziehbarkeit des geschilder-ten Szenarios kann das mit MAEXO aus-gelieferte Beispiel im Ordner „samples/basic” verwendet werden. Es stellt einen vorkonfigurierten Equinox- beziehungs-weise Felix-Container zur Verfügung, der alle benötigten MBeans beinhaltet. Nach dem Start über das Shell-Skript kann man mittels JConsole eine Verbindung zum MBean-Server des Containers herstellen. Da die Anwendung im beschriebenen Szenario nicht lokal verfügbar ist, muss die Verbindung über eine JMX-Connec-tion-URL erfolgen. Für das vorliegende

Beispiel sieht diese URL folgendermaßen aus:

service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi.

Nach erfolgreichem Verbindungsaufbau erscheint im Reiter MBeans eine Domain „com.buschmais.maexo”, unter der MAEXO verschiedene MBeans zur Verfügung stellt (siehe Abbildung 1).

Für das Erstellen und Ausführen der Admin-Skripte ist weiterhin eine Groovy-Installation notwendig. Das entsprechen-

de ZIP-Archiv beziehungsweise ein Win-dows-Installer stehen auf der Homepage des Projekts [3]. Die ersten Management-Aktionen können direkt in der GroovyCon-sole ausgeführt werden. Diese Konsole ist in der Installation enthalten und wird über ein Shell-Skript im $GROOVY_HOME/bin-Verzeichnis gestartet.

Der erste KontaktZunächst muss eine Verbindung zum ent-fernten MBean-Server aufgebaut werden. Dazu wird die zuvor genannte JMX-Con-nection-URL benötigt (siehe Listing 1).

url = new javax.management.remote.JMXServiceURL( ‚service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi‘);

con = javax.management.remote.JMXConnectorFactory .connect(url).MBeanServerConnection;

con.getAttribute(new javax.management.ObjectName( ‘com.buschmais.maexo:type=Framework’),’vendor’);

Listing 1

Abbildung 1: JConsole mit MAEXO-MBeans

46 |

iiiiii iii

iiiNach dem Ausführen dieser Anweisun-

gen in der GroovyConsole ([Strg+R]) zeigt Groovy den letzten Rückgabewert an, in diesem Fall den Namen des Herstellers des OSGi-Containers. Dieser steht durch ein Attribut einer MBean zur Verfügung, welche das OSGi-Framework repräsen-tiert und über den Namen „buschmais.maexo:type=Framework” erreichbar ist.

Es besteht die Möglichkeit, eine Groo-vyConsole direkt innerhalb der JConsole auszuführen. Unter [5] ist eine entspre-chende Anleitung zu finden. Daraus er-geben sich zwei Vorteile: Zum einen kann im Skript die bereits existierende Verbin-dung zum entfernten MBean-Server ge-nutzt werden:

con = plugin.context.MBeanSer-verConnection;

Andererseits kann man innerhalb der JConsole je nach Anwendungsfall bezie-hungsweise Nutzer-Präferenz durch einfa-ches Wechseln des Reiters mit der GUI oder mit der Script Shell arbeiten. Ein wichtiger Unterschied zur Groovy-eigenen Konsole besteht darin, dass die Eingaben unmittel-bar nach jeder Zeile interpretiert werden – das kann situationsabhängig von Vor- oder Nachteil sein.

Kleines Werkzeug, große WirkungAls Nächstes soll die Menge installierter Bundles abgefragt werden. Unter Nutzung der verfügbaren Java-APIs und der durch MAEXO bereitgestellten Framework-MBe-an sieht dies wie folgt aus:

con.getAttribute( new javax.management.Object-Name( ‚com.buschmais.maexo:type=Framework‘), ‚bundles‘);

Leider liefert diese umständliche Anwei-sung einen für den Nutzer unbrauchbaren Rückgabewert: Es wird ein ObjectName[]-Array anderer MBeans zurückgeliefert, das die Menge installierter Bundles repräsen-tiert. Zur Vereinfachung ist daher eine Hilfs-methode erforderlich, welche aus einem übergebenen ObjectName einen Proxy erzeugt, der die entsprechende MBean im OSGi-Container repräsentiert:

def asMBean(objectName) { return new groovy.util.GroovyMBean(con, objectName);

}

Damit können Attribute und Methoden in objektorientierter Art verwendet werden. Die Abfrage des Framework-Herstellers beziehungsweise der installierten Bundles gestaltet sich folgendermaßen:

framework = asMBean(‚com.buschmais.maexo:type=Framework‘);println framework.vendor;framework.bundles.each { bundle = asMBean(it); println it.getKeyProperty(‚name‘) + ‚ ‚ + bundle.stateAsName;}

Die letzte Anweisung ermittelt das Object-Name-[]Array der MBeans, das die installier-ten Bundles repräsentiert. Mittels „each{…}” wird darüber iteriert und für jedes Element der Symbolic-Name und der jeweilige Zu-stand des Bundles ausgegeben.

Vier Bündel und ein ServiceAls nächste Aufgabe steht die Installation und Konfiguration der Bundles des Apa-che Felix HttpService auf der Agenda. Dies ist mithilfe des erzeugten MBean-Proxys „framework” und der von ihm bereitge-stellten Methode jetzt einfach zu reali-sieren. Es werden der Einfachheit halber Artefakte aus einem öffentlichen Maven2-Repository verwendet (siehe Listing 1). Die

letzte Anweisung ermittelt den Zustand des Bundles, das den HttpService bereit-stellt. Unmittelbar nach der Installation ist dies „INSTALLED” (siehe Listing 2).

Für die gewünschte Konfiguration des Http-Service ist eine Instanz des Configura-tionAdmin-Services erforderlich; entspre-chende MBeans werden von MAEXO zur Verfügung gestellt. Um diese zu erhalten, muss man die MBeanServer-Verbindung abfragen:

con.queryNames(new javax.ma-nagement.ObjectName( ‚com.buschmais.maexo:type=ConfigurationAdmin,id=*‘),null);

Ergebnis ist ein ObjectName-Set, zum Beispiel [com.buschmais.maexo:type=ConfigurationAdmin,id=78]. Der erhaltene ObjectName – genaugenommen seine String-Repräsentation – wird verwendet, um einen MBean-Proxy für diesen Service („cfgAdmin”) zu erzeugen. Mithilfe des ConfigurationAdmin-MBeans kann man nun auf die Konfiguration des Jetty-Bund-les (”cfg”) zugreifen.

cfgAdmin=asMBean( ‚com.buschmais.maexo:type=ConfigurationAdmin,id=78‘);

cfg=asMBean( cfgAdmin.getConfiguration(‚org.apache.felix.http‘, jettyBundle.location));

framework.installBundle(„http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.log/1.0.0/“ + „org.apache.felix.log-1.0.0.jar“);

framework.installBundle(„http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.http.api/2.0.4/“ + „org.apache.felix.http.api-2.0.4.jar“);

framework.installBundle(„http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.http.base/2.0.4/“ + „org.apache.felix.http.base-2.0.4.jar“);

jettyObjectName = framework.installBundle( „http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.http.jetty/2.0.4/“ + „org.apache.felix.http.jetty-2.0.4.jar“);

jettyBundle = asMBean(jettyObjectName);jettyBundle.stateAsName;

Listing 2


iiiiii iii

iii

framework.installBundle(„http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.log/1.0.0/“ + „org.apache.felix.log-1.0.0.jar“);

framework.installBundle(„http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.http.api/2.0.4/“ + „org.apache.felix.http.api-2.0.4.jar“);

framework.installBundle(„http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.http.base/2.0.4/“ + „org.apache.felix.http.base-2.0.4.jar“);

jettyObjectName = framework.installBundle( „http://repo2.maven.org/maven2/“ + „org/apache/felix/org.apache.felix.http.jetty/2.0.4/“ + „org.apache.felix.http.jetty-2.0.4.jar“);

jettyBundle = asMBean(jettyObjectName);jettyBundle.stateAsName;

Listing 2

Das Setzen der Konfigurationsparame-ter erfolgt daraufhin am MBean-Proxy der Konfiguration; der Aufruf der Methode „update” publiziert diese Konfiguration:

cfg.setString(‚org.osgi.ser-vice.http.port‘, ‚8085‘);cfg.update();

Als letzte Schritte stehen lediglich das Star-ten des Jetty-Bundles sowie die Überprü-fung des Vorhandenseins des HttpService aus:

jettyBundle.start();jettyBundle.registeredServices.each { println it.getKeyProperty(‚name‘);

}

FazitDer skizzierte Anwendungsfall hätte pro-blemlos über eine grafische Oberfläche – wie sie JConsole & Co. anbieten – abge-arbeitet werden können. Die Korrektheit und Nachvollziehbarkeit der solcherart vorgenommenen Management-Aktivitä-ten hängt dabei stark vom Konzentrati-onsvermögen des Anwenders ab: Es kann nur bedingt garantiert werden, dass auf verschiedenen Instanzen in unterschied-lichen Umgebungen wirklich die gleichen Aktionen ausgeführt werden. Abhilfe ist durch die Verwendung vordefinierter

Skripte und den damit verbundenen Au-tomatisierungsgrad zu erreichen. Begriffe wie „Reproduzierbarkeit“ und „Testbarkeit“, die in anderen Bereichen der Softwareent-wicklung zum Standardvokabular zählen, halten damit Einzug im Bereich des OSGi-Laufzeitmanagements. Für komplexere als das geschilderte Szenario ist dies eine unverzichtbare Voraussetzung. Die Basis dafür stellt das Vorhandensein entspre-chender Werkzeuge dar. Im vorliegenden Beispiel sind dies Groovy und die durch MAEXO bereitgestellten MBeans.

Quellen[1] MAEXO, http://maexo.googlecode.com[2] VisualVM, https://visualvm.dev.java.net/[3] Groovy, http://groovy.codehaus.org/[4] Apache Felix HTTP Service, http://felix.apache.

org/site/apache-felix-http-service.html[5] Groovier jconsole!, http://blogs.sun.com/

sundararajan/entry/groovier_jconsole

Kontakt:Dirk Mahler

[email protected]

Kurzportrait MAEXO

MAEXO (Management Extensions for OSGi) ist ein Open-Source-Framework, welches das Laufzeit-management von OSGi-basierten Anwendungen ermöglicht. Es stellt sowohl die Infrastruktur zur Integra- tion der Java Management Exten-sions (JMX) in den OSGi-Container als auch entsprechende Managed Beans (MBeans) zur Verwaltung häufig genutzter OSGi-Ressourcen zur Verfügung. Dazu zählen bei-spielsweise installierte Bundles und laufende Services. Diese können so unter Zuhilfenahme beliebiger JMX-Management-Konsolen von entfernten Rechnern überwacht bzw. gesteuert werden.

Darüber hinaus stellt MAEXO ein Programmiermodell zur Verfü-gung, das die Implementierung eigener MBeans samt Verwaltung ihres Lebenszyklus unterstützt. Der grundlegende Ansatz besteht in der Nutzung der Service-Infrastruktur des OSGi-Containers und der trans-parenten Registrierung aller MBeans und MBean-Server als OSGi- Services.

Dirk Mahler ist als Senior Consultant auf dem Gebiet der Java-Enterprise-Technologien tätig. In seiner täglichen Arbeit setzt er sich mit Themen rund um Softwarearchitektur auseinander, kann dabei eine Vorliebe für den Aspekt der Persis-tenz nicht verleugnen. Er ist Gesellschafter der buschmais GbR, einem Beratungshaus mit Sitz in Dresden.

Impressum

Herausgeber:Interessenverbund der Java User Groups e.V. (iJUG)Tempelhofer Weg 64, 12347 BerlinTel.: 0700 11 36 24 38www.ijug.eu

Verlag: DOAG Dienstleistungen GmbHFried Saacke, Geschäftsfü[email protected]

Chefredakteur (VisdP):Wolfgang Taschner, [email protected]

Chefin von Dienst (CvD):Carmen Al-Youssef, [email protected]

Titel, Gestaltung und Satz:Claudia Wagner, DOAG Dienstleistungen GmbH

Anzeigen:CrossMarkeTeam, Ralf Rutkat, Doris Budwill [email protected]

Mediadaten und Preise finden Sie unter:www.ijug.eu/images/vorlagen/ 2011-Publ-DOAG_Mediadaten_2011.pdf

Druck:adame Advertising and Media GmbH Berlinwww.adame.de

48 |

iiiiii iii

iii

Von Oracle Forms auf JavaHans Niedermeier, Pro-Software GmbH

Nach über zwanzig Jahren Oracle Forms (und Designer-)Praxis war für den Autor eine Neuorientierung innerhalb der Anwendungsentwicklung notwendig. Der Weg führte über die visuelle Entwicklungsum-gebung XDEV 3 zu Java.

Seit Anfang der 1990er Jahre bietet Oracle mit der Designer- und Developer-Schiene eine starke Plattform für 4GL-Entwicklung. Diese Kombination war deshalb bei An-wendern so beliebt, weil mit Designer generierte Forms wegen des einheitli-chen Code-Aufbaus auch nach Jahren gut pflegbar sind. Die Nutzbarkeit von einmal erzeugten Forms-Anwendungen auf vielen gängigen Plattformen ist garan-tiert. Das Konzept, jeder Base-Table einen Forms-Block zuzuordnen und mehrere Blöcke über Foreign-Keys der Base-Tables sauber synchronisieren zu können, zieht sich durch alle Forms-Programme. Ist eine Base-Table einem Block zugeordnet, sorgt Forms auf generische Art selbst für die Defi-nition und Ausführung von Select-, Insert-, Update- und Delete-Operationen. Die in

allen Formularen und Table-Objekten ein-heitlich zur Verfügung stehenden Short-cut-Tasten (Query, Insert, Update Commit etc.) machen das Arbeiten für intensive Forms-Anwender sehr effektiv. Transakti-onssicherheit, Daten-Locking und Multi-Row-Operationen gehören ebenso zu den Key-Features von Forms, auf die Entwickler setzen können ohne dafür Code schrei-ben zu müssen. Über Menü-Steuerung und Nutzung globaler Variablen ist eine Integration vieler Forms-Masken mit au-tomatischer Datengewinnung beim Auf-ruf innerhalb einer Anwendung möglich. Eine sehr umfangreiche Property-Palette macht es möglich, alles Erdenkliche für das Look&Feel von GUI-Objekten definieren zu können. Das zentrale Sprachmittel für das Lösen betriebswirtschaftlicher Aufgaben

ist PL/SQL, das direkt in Forms formuliert werden kann. Besser ist es jedoch, diese Schicht in Form von Packages direkt in die Datenbank zu verlagern.

Die Schwäche von FormsAlles in allem bietet Forms eine sehr per-formante Plattform, speziell für Multi-Row-Bearbeitungen. Mit den neueren Versio-nen ist auch der Betrieb unter Webservern Standard. Zu den Schwächen von Forms aus Sicht des Autors zählt vor allem das GUI. Die in modernen grafischen Oberflächen geforderten Tree-Controls (Baumstruktur) sind mit Forms kaum oder nur mit erheb-lichem Aufwand und gleichzeitig geringer Leistungsfähigkeit erstellbar. Tree-Controls in Forms kommen daher praktisch nicht vor. Somit entfällt in Forms-Anwendungen

Abbildung 1: XDEV-Treecontrol und ein XDEV-Tab25 mit Pivot-Darstellung jener Daten, die mit den Anweisungen aus Anlage-1 zur Runtime gewonnenund dargestellt werden.


iiiiii iii

iiidie Möglichkeit, sich mithilfe gut struktu-rierter Bäume die Daten einer Anwendung zu erschließen. Stattdessen muss man massiv mit Suchmasken und Suchvorgän-gen operieren.

Werden in größeren Projekten mit meh-reren Entwicklern Anwendungen ohne Designer erstellt (leider ist die Anwen-dungs-Generierung mit Designer praktisch gestorben), kann man nur mit strengen Pro-grammierregeln erreichen, dass der Forms-Code nicht zu sehr mit individuellen Stilen befrachtet wird. Es erfordert erheblichen Aufwand, über Templates und Libraries eine gewollte einheitliche Standardfunktiona-lität und Codebasis bereitzustellen. Forms kann seine Stärken jedoch nur in Verbin-dung mit Oracle-Datenbanken ausspielen.

Rapid Application Development ist mit Forms grundsätzlich möglich, jedoch auf die Gefahr hin, dass schwer wartbarer Code entsteht.

Für den Autor war der Umstieg in die Java-Welt bereits mit XDEV 2 sehr einfach zu schaffen. Die Umstellung der Version 3 auf pures Java macht die Java-Migration für Forms-Entwickler nochmals leichter. Die im GUI-Builder zur Verfügung stehen-den Werkzeuge sind dem Forms-Designer in vielem verblüffend ähnlich. Analog zu

den umfangreichen Property-Paletten in Forms stehen zu allen Objekten vielfältige Methoden innerhalb des XDEV Applica-tion Frameworks (XAPI) bereit, um alle ge-wünschten Features einer Datenbank-An-wendung erstellen zu können. Anders als in Forms müssen sich Java-Entwickler jedoch auch hier selbst um Transaktionssicherheit kümmern und Datensatzkonsistenz per Change-Numbers (SCN in Oracle-Tables oder ähnliches) selber implementieren. In Kürze soll jedoch eine spezielle Transak-tions-Klasse eingeführt werden, die auch Fehlerbehandlungen innerhalb einer Transaktion ermöglichen soll.

Objektorientierung nicht zwingend notwendigWie mit jeder Java-IDE kann man natürlich auch in XDEV 3 objektorientiert entwickeln und eigene Klassen schreiben. Dies ist je-doch nicht zwingend notwendig. Auch rein prozedurale Programmierung ist mög-lich, was vor allem Forms-Entwickler, die in der Regel kaum über Erfahrung mit objek-torientierter Programmierung verfügen, sehr entgegen kommt. Businesslogik lässt sich auch überwiegend in die Datenbank verlagern. Mit den auf JDBC aufsetzenden Datenbank-Schnittstellen (Nutzung von

ODBC-Quellen möglich) kann man nahe-zu grenzenlos Daten aus verschiedenen Datenbanksystemen miteinander in Bezug setzen, innerhalb einer GUI repräsentieren und auch verarbeiten.

Unter Nutzung der Assistenten kann eine Anwendung mit überraschend we-nigen Anweisungen erstellt werden. Für anspruchsvollere Applikationen und spe-zielle Features sollte man sich eine ein-heitliche Code- und Methodenbasis sowie eine eigene GUI-Bean-Palette schaffen. An-ders als bei Forms generiert XDEV 3 keine fertigen Masken, sondern überlässt dem GUI-Designer die individuelle Gestaltung. Die Persistierung der Daten ist jedoch mit nur einem einzigen Methodenaufruf mög-lich. Für das Data Binding sind sogenannte „virtuelle Tabellen“ vorgesehen. Sie sind Resultset-Objekt und gemäß Model-View-Control (MVC) -Pattern eine Art Universal-Model für sämtliche GUI-Komponenten zugleich. Damit ermöglichen diese virtuel-len Tabellen eine effektive und einfache Art der Datenverarbeitung und Visualisierung, ohne dass der Entwickler dafür viel Code schreiben und sich mit MVC-Programmie-rung auseinandersetzen muss. Virtuelle Tabellen sind zudem auch als Steuerungs-element möglich.

Abbildung 2: XDEV-Treecontrol und eine XDEV-Tab mit klassicher Master-Detail-Detail Ansicht, die mit dem Forms-Assistenten aufgrund von Foreign-Key-Constraints mit wenigen Eingriffen generierbar wäre.

50 |

iiiiii iii

iii

Vorschau

Sehr angetan war der Autor von dem leistungsfähigen Tree-Control, das Java Swing standardmäßig zur Verfügung stellt, in Verbindung mit den angebotenen Füll-methoden dafür. Anstatt, wie in Swing üb-lich, komplizierte Tree-Models aufbauen zu müssen, ist es hier mithilfe virtueller Ta-bellen und etwas eigener Logik sehr leicht möglich, ein Tree-Control zur Laufzeit zu erzeugen und dabei statische Menüeinträ-ge und variable Daten in Form dynamisch generierter Tree Nodes in beliebiger Tiefe und Variabilität zu mischen. Auf diese Wei-se lassen sich allein mit SQL-Mitteln Tree-Navigationen mit Daten aus beliebigen Tabellen und Views losgelöst von starren Bindungen in einem ER-Modell generie-ren, die sich während des Navigierens dy-namisch erweitern. Alle Benutzeraktionen, die über die jeweiligen Tree Nodes aufge-rufen werden, können ausgelagerten Code ausführen, wobei es sich um SQL, PL/SQL, Stored Procedures, System-Aufrufe sowie um beliebige Java-Klassen handeln kann.

Wiederverwendbare KomponentenFür Forms-Entwickler erfreulich ist, dass sich entsprechende GUI-Objekte mit inter-ner Funktionalität wie Synchronisierung, Refreshing und mehrsprachiger Beschrif-tung auch ohne Objektorientierung als GUI-Bean erstellen lassen. Diese lassen sich anschließend nicht nur global im ge-samten Projekt, sondern auch in anderen Anwendungen mehrfach einsetzen.

Die Architektur von Swing und die ge-lungene GUI-Bean-Integration machen entsprechende Ableitungen und Abstrak-tionen auf frappierend einfache Weise

Hans Niedermeier arbeitet seit Ende der 1980-er Jahre mit Oracle-Datenbanken (beginnend mit Version 4.1.4) sowie von Anfang an mit der Oracle Designer-Schiene und war einer der ersten Mitglie-der der DOAG Deutsche ORACLE-Anwendergruppe e.V.Seit zwei Jahren beschäftigt sich Hans Niedermeier intensiv mit der Rapid Java Entwicklungsumgebung XDEV 2, mit der er den Umstieg von Oracle Forms auf Java erfolgreich vollziehen und seinen eigenen RAD-Konzepte umsetzen konnte. Schwerpunkt ist dabei die Leistungsmerkmale von Anwendungen in der Da-tenbank zu definieren, um möglichst kompakten Code erstellen zu können. Java und nun XDEV 3 mit dem XDEV Application Framework sorgen für die nötige Infrastruktur für diese Art der Anwendungsentwicklung.

möglich. So muss beispielsweise eine klas-sische Master-Detail-Darstellung zweier Tabellen, wie sie in Forms häufig verwen-det wird, nur einmal als GUI-Bean realisiert werden und kann anschließend vielfach mit unterschiedlichen Daten (Views) ein-gesetzt werden.

Schon in XDEV 2 war es möglich, exter-ne Java-APIs einzubinden. Mit der XDEV-3-Plattform werden diese Möglichkeiten noch wesentlich erweitert, sodass grund-sätzlich alles möglich ist, was Java kann.

FazitJava mit XDEV 3 bietet deutlich mehr Möglichkeiten als Forms, moderne GUIs agil und schnell zu designen. Auch bei der Integration unterschiedlicher Daten-quellen innerhalb einer Applikation ist die Entwicklungsumgebung Oracle Forms weit überlegen. Geht es um Transaktions-verhalten und -steuerung oder um Multi-Row-Verarbeitung, dann bietet Forms wesentlich mehr. In XDEV 3 muss man sich um diese Themen derzeit noch selber kümmern. Dass vieles in XDEV 3 nicht ganz so komfortabel ist wie in Forms, liegt zum einen an Java selbst und zum anderen dar-an, dass XDEV 3 nicht ausschließlich für die Oracle-Datenbank konzipiert, sondern als Java-IDE Datenbank-unabhängig ausge-richtet ist.

Alle Forms-Anwendungen, bei denen die Business-Logik konsequent als Stored Objects in die Datenbank verlagert wurde, können mit vertretbarem Aufwand im GUI-Builder von XDEV 3 überraschend schnell nachgebildet und verbessert werden. Da-tenbank und Geschäftslogik kann man 1:1

weiterverwenden. Mit der neuen Version 3 ist aus Forms-Anwender-Sicht der ideale Zeitpunkt gekommen, um den Umstieg auf Java anzugehen. Java-Migrationen erst dann anzugehen, wenn Oracle den Sup-port für Forms eines Tages doch einstellt, ist fahrlässig und nicht zu empfehlen. Der von XDEV Software angekündigte AJAX-GUI-Builder auf Basis von Google Web Toolkit wird auch im Forms-Lager für noch mehr Interesse sorgen.

Kontakt:Hans Niedermeier

[email protected]

Java aktuell – Sommer 2011Die nächste Ausgabe der Java aktuell erscheint am 4. Mai 2011. Bitte schreiben Sie uns an [email protected], was Ihnen an dieser Zeitschrift gefallen hat und welche Inhalte Sie sich für kommende Ausgaben wünschen. Falls Sie selbst einen Artikel in der nächsten Java aktuell veröffentlichen möchten, schicken Sie bitte vorab Ihren Themenvorschlag ebenfalls an [email protected], Redaktionsschluss für den fertigen Text ist am 4. März 2011.


iiiiii iii

iii

AJAX vs. Java & Co.Markus Stiegler, XDEV Software GmbH

Der Markt für Rich Internet Applications (RIA) gilt längst als Softwaremarkt der Zukunft. RIAs sind Software-Anwendungen, die sich über das Internet aufrufen und in einem Web-Browser ausführen lassen. Dabei handelt es sich nicht um gewöhnliche Webseiten oder Portale, sondern um echte Anwendungs-programme wie eine Kunden- oder Lagerverwaltung. Obwohl RIAs im Browser laufen, sehen sie aus und fühlen sich an wie konventionelle Desktop-Programme.

Mit RIAs ergeben sich vor allem für Unter-nehmenslösungen und Behörden-Soft-ware völlig neue Anwendungsmöglichkei-ten, aber auch Einsparungspotenzial bei den Kosten. Bislang mussten Computer-programme fest auf einem Rechner instal-liert sein. Das erfordert vom Hersteller die Produktion und Auslieferung eines Daten-trägers, der normalerweise in einer Verpa-

ckung zusammen mit gedrucktem Hand-buch ausgeliefert wird und hohe Kosten verursacht. Aber auch auf Anwendersei-te ist der Aufwand für den Umgang mit konventioneller Anwendersoftware groß, denn die Software muss auf zahlreichen Unternehmensrechnern installiert, konfi-guriert und manuell aktualisiert werden. Release-Wechsel verursachen erfahrungs-

gemäß großen Aufwand und Kosten; zu-dem stellen sie immer ein gewisses Risiko dar. Der Zugriff von außen ist mithilfe ei-ner Terminal-Server-Lösung oder via VPN zwar grundsätzlich möglich, verursacht jedoch zusätzliche Kosten für Lizenzen oder für eine deutlich leistungsfähigere Infrastruktur. Die Anbindung mobiler Ge-räte ist praktisch nur mit einer zusätzlichen

Abbildung 1: Excel als klassisches Desktop-Programm wie man es seit vielen Jahren kennt.

52 |

iiiiii iii

iiiMobile-Version möglich, die im Normalfall jedoch nur auf bestimmten Devices lauffä-hig ist, für den Hersteller jedoch doppelten Entwicklungs- und Wartungsaufwand be-deutet, sodass viele Lösungsanbieter bis heute auf eine mobile Variante verzichten.

Revolutionäre Möglichkeiten mit RIAsRIAs lasen sich dagegen über das Internet oder Firmennetz aufrufen und auf jedem beliebigen PC ausführen, auf dem ein Web-Browser installiert ist. Vorteile wie weltweite Verfügbarkeit, simple Vertei-lung, kein Installationsaufwand, ständige Aktualität, herkömmliche Internet-Band-breiten sowie minimaler Administrations-aufwand – und somit deutlich niedrigere Administrationskosten – sind vor allem aus Unternehmenssicht geradezu revolutio-när. Experten propagieren schon seit Jah-ren, dass Anwender in Zukunft nur noch einen Browser brauchen, um damit jede benötigte Anwendung über das Internet aufrufen und nutzen zu können. Lösungs-anbieter würden die Software-Nutzung

dann ähnlich wie Strom aus der Steckdose abrechnen. Mit RIAs, Software as a Service (SaaS) und Cloud Computing ist all das heute schon möglich und die Märkte dafür wachsen rasant.

Vor allem für Lösungsanbieter muss diese Entwicklung Signalwirkung ha-ben. Denn durch RIAs steht der gesamte Software-Markt derzeit vor einem ähnlich dramatischen Umbruch wie einst nach der Ablösung von MS-DOS durch Windows. So gut wie jeder Software-Hersteller war durch Windows gegen Ende der 1980er Jahre ge-zwungen, seine praktisch über Nacht ver-alteten DOS-Lösungen mit Hochdruck auf moderne Windows-Anwendungen umzu-stellen. Entweder um dadurch schneller in den Markt zu kommen als die Konkurrenz, oder um mit Wettbewerbern Schritt halten zu können und ein massenhaftes Abwan-dern von Kunden zu verhindern. Doch selbst bis dahin marktbeherrschende Un-ternehmen haben die dringende Notwen-digkeit einer Umstellung zu spät erkannt und sahen sich urplötzlich mit rasant ein-

brechenden Nutzerzahlen konfrontiert, verloren daraufhin schlagartig ihre Markt-stellung, überlebenswichtigen Umsatz und Unternehmenswert und haben sich davon nie wieder erholt. Prominenteste Beispiele dafür sind die bis dahin populärste Daten-bank dBASE von Ashton-Tate, die damals führende Textverarbeitung WordPerfect oder die Tabellenkalkulation Quattro Pro von Borland.

Wer clever ist, stellt jetzt umNachdem die Windows-Desktop-Anwen-dungen über zwanzig Jahre lang Status quo waren, beginnen Unternehmen jetzt damit, ihre Applikationen durch RIAs ab-zulösen oder setzen zumindest auf eine Doppel-Strategie. Vor allem die großen Anbieter wie SAP, Oracle und sogar der Desktop-Primus Microsoft arbeiten mit Hochdruck an RIA-Lösungen für ihr Busi-ness. Vorreiter Google bietet mit Google Docs sogar schon Office-Komponenten als RIA an, was OpenOffice und selbst Mi-crosoft zu einer Web-Strategie zwingt, um

Abbildung 2: Google hat eine Tabellenkalkulation entwickelt, die nicht nur im Web-Browser läuft, sondern fast genauso aussieht und funktioniert wie Excel. Damit kann man mit jedem PC mit Internetzugang auf seine Dateien zugreifen und diese bearbeiten.


iiiiii iii

iiinicht die eigenen Anwender an Google zu verlieren. Das zeigt, wie wichtig es ist, den RIA-Trend nicht zu verpassen. Aber auch kleinere Anbieter sollten sich schnellst-möglich umstellen und können sich ge-rade jetzt einen wertvollen Vorsprung vor der noch schlafenden Konkurrenz verschaffen. Denn RIAs sind bereits so po-pulär, dass mittlerweile so gut wie an jede neue Unternehmens- oder Behörden-Software der Anspruch gestellt wird, dass diese webfähig sein soll. Begünstigt wird dieser Trend durch immer leistungsfähi-gere mobile Geräte, mit denen das Betrei-ben anspruchsvoller Business-Applikatio-nen längst möglich ist.

Die Entscheidung, ob man auf eine altbe-währte Desktop-Lösung oder auf eine RIA-Strategie setzen soll, fällt vielen Herstellern schon nicht leicht. Wer sich dann für eine RIA entschieden hat, steht vor der schwie-rigen und strategisch entscheidenden Fra-ge, auf welche RIA-Technologie man am besten setzen soll.

Im Markt für RIAs stehen sich grund-sätzlich zwei völlig verschiedene Philoso-phien gegenüber, die miteinander kon-kurrieren. Auf der einen Seite steht AJAX (Asynchronous JavaScript and XML). Der Begriff umschreibt eigentlich nur die asyn-chrone Übertragung von Daten und Code zwischen Server und Browser mithilfe des

XMLHttpRequests. Durch die revolutionä-ren Möglichkeiten, die sich damit für das gesamte Internet und vor allem für die Anwendungsentwicklung ergeben, wurde der Begriff schnell zum Hype; er wird seit-her umgangssprachlich für alle Web-An-wendungen verwendet, welche AJAX als Übertragungstechnik benutzen. Die Basis von AJAX-Anwendungen ist jedoch ein Mix aus verschiedensten Web-Technologien.

Auf der anderen Seite stehen proprietä-re, also herstellerspezifische und somit - an-ders als HTML - nicht offene RIA-Technolo-gien. Dazu zählen Microsoft Silverlight, Java Applets und Java FX sowie Flash, das den meisten Anwendern als Animations-Tool

Abbildung 3: Unternehmen fordern immer stärker, dass ihre Mitarbeiter möglichst überall Zugriff auf wichtige Geschäftsanwendungen und Daten haben müssen. Dies gilt sowohl nur für Standardlösungen als auch für speziell entwickelte Individualsoftware. Lösungsanbieter sind dadurch gezwun-gen ihre Produkte möglichst schnell als webfähige RIA anzubieten. Auch immer mehr Inhouse-Software muss webfähig gemacht werden.

54 |

iiiiii iii

iiibekannt ist, zusammen mit Flex und Ado-bes neuer RIA-Plattform Air, die auch für die RIA-Entwicklung eingesetzt werden kann.

RIAs mit AJAX Mit AJAX lassen sich Daten und Code nachladen, ohne dass der Browser die komplette Webseite neu aufbauen muss. Das führte schnell zu der Idee, dass man im Browser nicht nur gewöhnliche Webseiten anzeigen, sondern auch echte Software-Anwendungen ausführen könnte. Das gro-ße Problem dabei ist jedoch, dass ein Brow-ser im Gegensatz zu Programmiersprachen wie Java in Sachen „grafische Oberfläche“ außer Buttons, den wichtigsten Formular-Komponenten und Scroller rein gar nichts zu bieten hat. Tabellen lassen sich mithilfe von HTML-Tables gerade noch umsetzen, aber ein Tree-Control, Registerreiter und Menüs gibt es in HTML nicht, geschwei-ge denn Drag&Drop, Kontextmenüs und Fenster-Technik. Das bedeutet, dass alles, was für eine moderne Benutzeroberfläche gebraucht wird und in jeder vernünftigen Programmiersprache zum Standardum-fang zählt, im Sprachumfang von HTML nicht vorhanden ist und somit vom Brow-ser auch nicht umgesetzt werden kann. Dies ist kein Wunder, da HTML ursprüng-lich für die Darstellung von formatiertem Text konzipiert wurde, niemals für die pro-fessionelle Anwendungsentwicklung.

Um dieses Defizit auszugleichen, müs-sen alle benötigten User Interface (UI) Controls in JavaScript nachprogrammiert werden. Diese können dann mithilfe der JavaScript-Engine des Browsers ausgeführt werden. Während sich Entwickler anfangs entsprechende Controls mit gigantischem Aufwand noch selber schreiben mussten, stehen mittlerweile zahlreiche JavaScript-UI-Libraries für die Oberflächen-Entwick-lung wie jQuery, Rico, Dojo, qooxdoo oder die Yahoo!-UI-Library zur Verfügung. Bei allen handelt es sich um Open-Source-Bibliotheken, sodass auch der Einsatz in kommerziellen Anwendungen möglich ist. Die Qualität der Controls ist inzwischen so gut, dass man eine JavaScript-Oberfläche praktisch nicht mehr von einer Desktop-Applikation unterscheiden kann. Der Code einer kompletten JavaScript-Oberfläche ist jedoch sehr umfangreich und aus Optimie-rungsgründen oft kaum mehr lesbar. Für

den Aufbau der Oberfläche wird norma-lerweise eine spezielle JavaScript-Engine beim Starten der Anwendung geladen, die unter anderem den Aufbau und Umbau der Oberfläche sowie das Nachladen von Daten und Code managt.

AJAX-Entwicklung ist aufwändig und teuerEines der größten Probleme bei HTML-/JavaScript-Frontends sind seit eh und je die nervtötenden Browser-Inkompatibilitäten, mit denen Entwickler trotz W3C-Standards wohl auch in Zukunft leben müssen, da sich die Browser-Hersteller nicht konsequent an die Standards halten und selbst die verschie-denen Versionen eines Browsers häufig nicht vollständig zueinander kompatibel sind. Dieser Umstand macht Web-Entwicklung unnötig aufwändig und teuer; er führt zu vergleichsweise kurzen Lebenszyklen einer Anwendung, wenn diese nicht permanent und zeitnah an aktuelle Browser-Updates angepasst wird. Mit dem Einsatz einer UI-Library wird die Wartung einer Anwen-dung deutlich leichter, da entsprechende Anpassungen nach Browser-Updates vom Framework-Hersteller erledigt werden müs-sen. Was dennoch bleibt, sind der Aufwand, das Library-Update einzubinden, manuelle Anpassungen bei erheblichen Änderungen und das erneute Deployen der Anwendung. Problematisch wird es jedoch, wenn das verwendete Framework nicht mehr zeitnah supportet oder schlimmstenfalls nicht mehr weiterentwickelt wird. Dies erlebt man bei Open-Source-Projekten leider häufig, insbe-sondere wenn führende Entwickler abge-worben werden, die Sponsoren des Projekts die finanzielle Unterstützung einstellen oder ihre Entwickler abziehen, wenn sich Interes-sengruppen vom Projekt abspalten oder zu einem anderen Projekt wechseln. Man sollte sich deshalb genau informieren, wer die trei-benden Kräfte hinter dem Framework sind, wie groß die Community ist und wie die ver-gangenen Release-Zyklen aussehen.

Um Java-Entwickler vollständig vom Um-gang mit HTML und JavaScript zu befreien, kommen immer mehr Frameworks auf den Markt, die das Schreiben der Oberfläche di-rekt in Java ermöglichen und sich anders als Java Server Pages (JSP) am Programmiermo-dell von Java Swing orientieren, während das Framework letztendlich HTML / JavaScript

generiert, etwa Apache Wicket, GWT (Goog-le Web-Toolkit), Vaadin oder wingS.

Während die Oberfläche einer AJAX-An-wendung im Browser dargestellt wird, läuft die komplette Programmlogik auf dem Ser-ver. Anders als das Frontend kann das Server-Programm mit jeder beliebigen Script- oder Programmiersprache wie PHP, Java oder mit einer .NET-Sprache geschrieben werden. Da die meisten Internet-Service-Provider LAMP-Systeme (Linux-Betriebssystem, Apa-che-Webserver, MySQL-Datenbank, PHP-Interpreter) zur Verfügung stellen und die Installation anderer Laufzeitumgebungen wie .NET oder Java nur auf dedizierten Ser-vern erlauben, trifft man in der Praxis meist PHP-Anwendungen an.

Durch die Trennung von Client- und Serverteil handelt es sich bei einer AJAX-Anwendung faktisch um zwei autark von-einander laufende Programme, was erheb-liche Probleme aufwirft. Unter anderem müssen Client und Server bei jedem Er-eignis synchronisiert sein. Dies geschieht mithilfe des „Document Object Model“ (DOM), das in beiden Anwendungsteilen alle Objekte auf einer Seite in Form einer Baumstruktur verwaltet. Das für die Regi-strierung von Events notwendige Polling darf nicht zur Überlastung des Servers füh-ren, und die bei Anfrage und Antwort ent-stehenden Latenzzeiten müssen möglichst gering ausfallen. Darüber hinaus muss ge-löst werden, wie die Anwendung mit Klicks auf die „Browser zurück“-Schaltfläche um-gehen soll. Weitere Problematiken stellen Deep Links sowie Barrierefreiheit dar. In-zwischen gibt es Frameworks, die sich auch der Kommunikation zwischen Client und Server angenommen haben, sämtliche Probleme für den Entwickler lösen und die AJAX-Entwicklung damit nochmals erheb-lich vereinfachen, wie wingS und Vaadin.

AJAX-Kritiker führen an, dass Anwen-dungsentwicklung ohnehin schon kom-pliziert genug ist und große Business-Applikationen nur mithilfe durchgängiger Objektmodelle und vernünftiger Archi-tekturen beherrschbar und wartbar blei-ben. Aus Sicht erfahrener Entwickler ist es daher äußerst bedenklich, dass für die AJAX-Entwicklung nur Technologien zum Einsatz kommen, die wie HTML niemals für die Anwendungsentwicklung konzipiert wurden, während Java seit über zwanzig


iiiiii iii

iiiJahren genau dafür optimiert wird. Ebenso fatal sind die Browser-Inkompatibilitäten. Jeder Auftraggeber erwartet, dass eine Software über Jahre hinaus fehlerfrei und stabil läuft. Bei einer AJAX-Anwendung lässt sich dies jedoch nur bis zum nächs-ten Browser-Update garantieren. Wie viele Anpassungen man in Zukunft vornehmen muss, kann nicht vorhergesagt werden; die Kosten sind somit nur schwer kalku-lierbar. Erschreckend ist, dass dies jedoch vielen Auftraggebern gar nicht bewusst ist. Für Software-Dienstleister ist das ein gutes Geschäft, für Auftraggeber eher ein Fass ohne Boden.

Sind Flash, Silverlight und Java die besseren RIA-Technologien?Die Alternative zu AJAX sind Flash-, Silver-light- und Java-Frontends. Damit lässt sich die komplette Anwendung einschließlich des Browser-Frontends mit ein- und der-selben Technologie entwickeln. Daraus ergeben sich jede Menge Vorteile. Dem Java-Entwickler beispielsweise stehen für die RIA-Entwicklung der komplette Sprachumfang von Java und somit alle Möglichkeiten einer ausgereiften Pro-grammiersprache zur Verfügung. Für die Frontend-Entwicklung stehen leistungsfä-hige APIs wie Swing, SWT oder Java FX zur Verfügung, während HTML und JavaScript nicht mehr benötigt werden, sodass geüb-te Java Entwickler in der Lage sind, alle Vor-gaben kompromisslos umsetzen. Darüber hinaus können die gewohnte Entwick-lungs- und Testumgebung eingesetzt und Anwendungen vernünftig debugged wer-den. Ausgeführt werden Flash-, Silverlight- und Java-RIAs nicht vom Web-Browser, sondern von der jeweiligen Laufzeitum-gebung, die als schlanke Browser-Plug-ins frei verfügbar sind. Flash-, Silverlight- und Java-RIAs laufen somit völlig Browser-un-abhängig. Browser-Updates wirken sich damit anders als bei AJAX-Anwendungen nicht im Geringsten auf die Lauffähigkeit der Anwendung aus.

Mit dem Einsatz von Flash, Silverlight oder Java für die RIA-Entwicklung sind die Möglichkeiten zumindest derzeit noch grö-ßer als mit AJAX-Frameworks. Die Entwick-lung ähnelt stark der Desktop-Entwicklung und ist im Vergleich zur AJAX-Entwicklung homogener und erheblich einfacher. Auch

der Testaufwand ist deutlich geringer. Ins-gesamt wird man bei der RIA-Entwicklung mit Flash, Silverlight und Java kürzere Ent-wicklungszeiten erreichen und mit nied-rigeren Entwicklungskosten kalkulieren können. Der durch Browser-Updates ver-ursachte Wartungsaufwand ist gleich Null, sodass auch die Wartungskosten minimal sein werden. Durch die Browser-Unabhän-gigkeit ist eine lange Lebenszeit der An-wendung und somit Investitionssicherheit garantiert.

Aufgrund der zahlreichen Vorteile wür-den sich die meisten IT-Leiter wahrschein-lich schnell für eine RIA auf Basis von Flash, Silverlight oder Java entscheiden. Gegenüber AJAX haben alle proprietären Lösungen jedoch einen schwerwiegen-den Nachteil: Auf dem Anwenderrechner muss die jeweilige Laufzeitumgebung in-stalliert sein, oder der Anwender muss das entsprechende Plug-in downloaden. Dies ist jedoch nicht immer möglich. In vielen Firmen und Behörden ist Download und Installation von Anwendungen nicht mög-lich, etwa aus Sicherheitsgründen. Ebenso in Internet-Cafés, öffentlich zugänglichen Internet-Terminals, Hotels etc. Darüber hinaus sind die Laufzeitumgebungen für Flash, Silverlight und Java noch nicht für alle mobilen Geräte verfügbar oder wer-den von Geräteherstellern wie Apple nicht toleriert. Ohne Plug-in können Silverlight-, Java- und Flash-Anwendung jedoch nicht ausgeführt werden, sodass mit dem Einsatz einer proprietären RIA-Technologie immer bestimmte Benutzergruppen ausgeschlos-sen werden. Darüber muss sich der Betrei-ber der Anwendungen bewusst sein. Vor allem bei firmeninternen Anwendungen kann das kein Problem sein. Für B2C-Lö-sungsanbieter, die ihr Angebot auch oder sogar überwiegend an Konsumer richten, ist diese Einschränkung jedoch nicht ak-zeptabel, sodass dann nur AJAX als Basis-Technologie in Frage kommt.

FazitWenn die benötigte Web-Anwendung nur von einem geschlossenen Anwenderkreis genutzt werden soll, wie z.B. ein Firmen-Intranet, die Anwendung nicht oder nur auf bestimmten mobilen Geräten lauffähig sein muss, die Anwender bereit sind, für die Nutzung ggf. auch ein Plug-in zu instal-

lieren und auf Entwicklerseite ausreichend Erfahrung mit Flash-, einer .NET-Sprache oder Java vorhanden ist, dann ist der Ein-satz einer proprietären RIA-Technologie möglich und empfehlenswert. Der Ent-wicklungs- und Wartungsaufwand sowie die Entwicklungszeit sind damit leichter kalkulierbar, die Kosten und das Projekt-risiko in den meisten Fällen geringer. Die Browser-Unabhängigkeit garantiert zu-dem minimalen Wartungsaufwand, einen langen Lebenszyklus der Anwendung und langfristige Investitionssicherheit.

Soll die Anwendung dagegen für möglichst viele, teilweise oder gänzlich unbekannte Nutzer verfügbar sein, wie beispielsweise ein Shop-System oder ein offenes Social Network, und muss man da-von ausgehen, dass nicht alle Anwender in der Lage oder bereit sein werden, für die Nutzung extra ein Plug-in herunterzuladen, und die Anwendung zudem auf möglichst vielen Mobilgeräten lauffähig sein soll, dann führt kein Weg an AJAX vorbei. Die Entwickler sollten dann möglichst genau prüfen, auf welche AJAX-Frameworks man setzt. Die Projektverantwortlichen sollten dagegen neben dem größeren Entwick-lungsaufwand auch den vielfach größeren Wartungs- und Änderungsaufwand auf-grund zukünftiger Browser-Updates ermit-teln und unbedingt einkalkulieren.

Kontakt:Markus Stiegler

[email protected]

Markus Stiegler ist Technologie-Evangelist und Product Manager für die Entwickler-Toolsparte der XDEV Software Corp. in Deutschland. In dieser Funktion ist er verantwortlich für die Entwicklung von Produkt-, Marketing- und PR-Strategien und deren Umsetzung, für die Verbreitung von XDEV-Lösungen im deutsch-sprachigem Raum sowie für Kooperationen mit Technologie-Partner. Derzeit ist Markus Stieg-ler mit dem Aufbau eines Experten-Teams für Migrationsprojekte beschäftigt, das ab Anfang 2011 in der Lage sein soll, besonders zeitkri-tische Migrationen auf Java und AJAX sicher und kostengünstig durchzuführen. Von 2007 bis 2008 war Markus Stiegler für die Produk-tion der Fernsehsendung XDEV TV zuständig, die XDEV Software Corp. zusammen mit dem Gaming-Sender GIGA Digital bis zu dessen Auf-lösung produzierte. Neben der Co-Moderation leitete er das Redaktionsteam.

56 |

iiiiii iii

iii

Intelligente Migration?Matthias Pfau, Zühlke Engineering GmbH und Berthold Maier, Oracle Deutschland

Oracles Smart Upgrade soll technologisch die Migration vom Oracle 10g Release zum 11g Release verein-fachen. Der folgende Artikel beschreibt, was des „intelligente“ Upgrade Tool wirklich leistet und mit welchen zusätzlichen Migrationstätigkeiten kalkuliert werden muss.

Die Vision vom Upgrade bestehender OC4J und SOA Applikationen lässt die Herzen der Anwendungsentwickler höher schla-gen. Schließlich müssen diese über kurz oder lang Bestandsanwendungen auf den WebLogic Server migrieren und benötigen dazu mehr als nur einen technischen Leit-faden.

Funktionsunfang des ToolsUm eins gleich Vorweg zu nehmen: Das Ziel von Smart Ugrade besteht nicht darin, die eigentlichen Migration durchzuführen. Vielmehr soll der Anwender darin unter-stützt werden, während der Migration die richtigen Entscheidungen zu treffen. Die Smart Upgrade-Funktionalitäten setzen sich wie folgt zusammen:

Abbildung 1: Der vom JDeveloper bereitgestellte Report nach Analyse eines Webservices

Analyse von gepackten Anwendungen •und Bibliotheken wie EAR, WAR und JAR-DateienAnalyse der Server-Konfiguration von •OC4J (Version 10.1.2 oder 10.1.3)Die Generierung von Webservice-Arte-•fakten Die Migration von BPEL-Artefakten zu •SCA

Die ersten beiden Funktionen erzeugen einen Report, wie er in den Abbildungen 1 und 3 dargestellt wird. Dieser Report listet alle während der Analyse mögliche Prob-lemfelder auf und bietet die dazu passen-den Lösungsmuster an.

Während der Generierung von Web-service-Artefakten werden WebLogic spe-

zifischen Konfigurationsdateien und Java-Klassen erzeugt.

Im Rahmen der BPEL zu SCA Migration wird die durch BPEL definierte Geschäfts-logik eines Services auf die Implementie-rung einer SCA-Komponente abgebildet.Das Smart Upgrade [1] ist grundsätzlich in zwei Varianten verfügbar:

Als Standalone Java-Anwendung•Als JDeveloper Plugin•

Bei der Verwendung des JDeveloper Plug-ins muss beachtet werden, dass Smart Up-grade zur Zeit ausschließlich mit der JDeve-loper-Version 11.1.1.1 oder 11.1.1.2 genutzt werden kann. Außerdem integriert das JDe-veloper Plugin nicht die vollständige Funk-tionalität des Upgrade Tools, so können z.B. keine WAR- und JAR-Archive analysiert werden. Daher beziehen sich die folgen-den Ausführungen auf die Standalone- Anwendung.

Innerhalb der nächsten Abschnitte wird anhand von Migrationsszenarien die Unterstützung durch den Upgrade Wizard skizziert.

EJB3-MigrationsbeispielEine Beispiel-Anwendung nutzt Entity-Beans zur Realisierung der Persistenz und Session- bzw. Message-Driven Beans zur Implementierung der Anwendungslogik.

Der Smart Upgrade Report bestätigt, dass OC4J spezifische APIs genutzt werden und die Anwendung frei von OC4J abhängigen Deployment-Deskriptoren ist. Der Report wird wie folgt erzeugt:

java -jar smartupgrade.jar -html --ears ${EAR_FILE}


iiiiii iii

iiiWebservice (JAX-RPC)Die Migration eines JAX-RPC Webservices ist komplizierter, da dieser in jedem Fall OC4J abhängige Konfigurationsdateien enthält. Mit folgendem Kommando kann ein WAR-Archiv untersucht werden:

java -jar smartupgrade.jar -html --wars ${WAR_FILE}

Der erzeugte Report weist z.B. darauf hin, dass die Inhalte bestimmter OC4J-Kon-figurationsdatein in die Weblogic-Welt übertragen werden müssen. Aufgrund der unterschiedlichen JAX-RPC Implemen-tierungen im OC4J bzw. WebLogic Server sind Code-Änderungen nötig. Doch auch auf dieses Problem wird man durch den ausführlichen Report hingewiesen.

Wie bereits angesprochen ist das Upgrade-Tool in der Lage Webservice-Artefakte zu generieren, um die Migration eines Webservices zu vereinfachen. Die gut gemeinte Funktionalität versteckt den ursprünglichen JAX-RPC Webservice hinter einer JAX-WS Implementierung.

Eine Migration durch Generierung des Codes ist erfahrungsgemäß problematisch. Diese zeigt sich z.B. in unserem Beispiel bei der unvollständigen und auch fehlerhaf-ten Generierung von Java-Klassen. Zudem hat generierter Code den entscheidenden Nachteil, dass er äußerst schlecht wartbar ist, sodass von der Nutzung der Funktio-nalität abgeraten wird. Besser man behilft sich heute mit den JEE-Annotations, die eine sehr einfache und standardkonforme WS-Generierung erlauben.

Server-KonfigurationDie Analyse von Server-Konfigurations-dateien führt zu einer umfangreichen Auflistung von Hinweisen, um die OC4J-Konfiguration auf den WebLogic Server zu übertragen. Der in Abbildung 2 dargestell-te Report kann wie folgt erzeugt werden:

java -jar smartupgrade.jar -html --server-config ${OC4J_HOME}/j2ee/home/config >

oc4jReport.html

Was wird nicht unterstützt...Das Upgrade Tool stellt keine Unterstüt-zung für die Migration von EJB-Clients zur

Verfügung, da diese ohnehin JEE-Stan-dardkonform sind. Gewöhnlich werden diese durch Ändern der JEE Factory-Clas-sen und Properties, sowie Anpassungen an den Projektabhängigkeiten ohne größere Aufwände migriert. Weitere Informationen zu diesem Thema sind in [4] zu finden.

Da neben der eigentlichen Anwen-dung hoffentlich ein automatisierter Build migriert werden muss, sollte hier mit zu-sätzlichen Aufwänden gerechnet werden. Häufig werden in Buildskripten, z.B. zum Deployment, Ant-Tasks des Application Servers verwendet. Diese müssen auf die vom WebLogic zur Verfügung gestellten Tasks migriert werden.

FazitDer intelligente Upgrade Wizard ist nicht in der Lage den Entwickler von sämtlichen, der aufwändigen und fehlerträchtigen, Migrationstätigkeiten zu befreien. Aller-dings bietet er eine sehr gute Unterstüt-zung während der Planungsphase; durch die Analyse von Java-Artefakten wie WAR-Dateien ist ein schneller Überblick über die zu erwartenden Migrationstätigkeiten möglich (Vgl. [2]). So können die Migrati-onsaufwände besser abgeschätzt und spä-ter systematisch abgearbeitet werden. Für die tatsächlichen Migrationstätigkeiten ist

des Smart Upgrade Tool hingegen nur ein-geschränkt geeignet. Die wichtigste Vor-aussetzung für eine erfolgreiche Migration sind umfangreiche Testfälle und ein gutes Verständnis der Unterschiede zwischen den beiden Application Servern OC4J und Weblogic (Vgl. [3]).

Referenzen [1] http://www.oracle.com/technology/software/

products/middleware/smartupgrade.html[2] Molter, Kücherer, Pfau: Migrationsstrategie für

Kernbestandteile der Fusion Middleware. In: DOAG News 03/2009

[3] Upgrading Custom Java EE Applications from Oracle Application Server to WebLogic Server. Oracle Whitepaper, July 2009

[4] http://blogs.oracle.com/WebLogicServ-er/2009/09/application_client_upgrades_fr.html

Kontakt: Matthias Pfau

[email protected]

Matthias Pfau ist als Software In-genieur bei der Zühlke Engineering GmbH tätig. Seine Schwerpunkt-themen sind agile Vorgehenswei-sen, testgetriebene Entwicklung und die Oracle Fusion Middleware.

Abbildung 2: Der HTML-Report für eine OC4J Serverkonfiguration

58 |

iiiiii iii

iii

GlassFish Open Source Server 3.0 – ein Vorgeschmack auf die Application-Server der nächsten GenerationPeter Doschkinow, ORACLE Deutschland B.V. & Co. KG

GlassFish ist ein beliebter und weit verbreiteter Open-Source-Application-Server, der seit 2006 als Referenz-Implementierung der Java-EE-Plattform von der GlassFish-Community und damals Sun – heute Oracle – ausgeliefert wird. Seine Popularität ist vor allem darin begründet, dass er die Bedürfnisse von Entwicklern, Administratoren und Betreibern gleichermaßen adressiert. Er ist leichtgewichtig und trotzdem voll produktionsfähig mit ausgereifter Unterstützung für Hochverfügbarkeit und hervorragender Performance. Seine letzte Version ist GlassFish v3.0.1, die Referenz-Implementierung von Java EE 6.

Die Java-EE-6-Spezifikation setzt den Pro-zess der Vereinfachung und Flexibilisie-rung der Java-EE-Plattform weiter fort und führt mit dem Konzept von Profiles (im All-gemeinen) und dem Web-Profile (im Spezi-ellen) zum ersten Mal die Möglichkeit ein, standardisierte Subsets als Plattform für die eigenen Anwendungen zu benutzen, auf unnötige Funktionalität zu verzichten und somit eine bessere Performance und Ausnutzung vorhandener Ressourcen zu erreichen. Die hohen Anforderungen an Flexibilität und Erweiterbarkeit, die Java EE 6 mit sich bringt, haben zu einer neuen Architektur in GlassFish v3 geführt, die auf ein neues Modulsystem und OSGi basiert und dadurch neue, ungeahnte Möglich-keiten für GlassFish-Anwender anbietet, die weit über Java EE 6 hinausgehen. Es ist sehr wahrscheinlich, dass auch andere Java-EE-Application-Server-Hersteller für ihre künftige Java-EE-6-Implementierung einen ähnlichen Weg wie GlassFish v3 einschlagen. Der Artikel zeigt einige der interessantesten Merkmale und Technolo-gien von GlassFish v3, die ihn klar als ein Applications-Umfeld-Server der nächsten Generation positionieren.

Architektur, Modularität, ErweiterbarkeitDie Hauptbestandteile in der Architektur von GlassFish v3 sind der HK2-Kernel, die Dienste, die er bereitstellt, und die Con-tainer, die von diesen Diensten Gebrauch machen (siehe Abbildung 1). HK2 steht

dabei für „Hundred Kilobyte Kernel“ und das Modul-System, das GlassFish v3 intern verwendet. Es hat eine Schnittstelle, über die andere Modul-Systeme angebunden werden können, etwa über OSGi, das als Standard-Implementierung mitgeführt wird. HK2 hat aber auch eine eigene, OSGi-unabhängige Implementierung, die vom GlassFish v3 im Embedded Mode verwen-det wird. Typischerweise ist ein HK2-Modul ein OSGi-Bundle, das zusätzliche Meta-In-formationen enthält.

Die Gesamtfunktionalität von Glass-Fish v3 ist in der Form von Diensten und entsprechend bewährten Methoden einer serviceorientierten Architektur bereit-gestellt. Diese können unterschiedliche Schnittstellen-Arten anbieten: den META-INF/services-Mechanismus von Java SE, eine OSGi- oder eine HK2-Schnittstelle. Um

System-Ressourcen zu schonen, kommt Lazy-Loading zum Einsatz, sodass Servi-ces nur dann geladen werden, wenn sie erforderlich sind. So wird zum Beispiel der EJB-Container erst beim Deployment der ersten EJB-Anwendung hochgefahren.

GlassFish v3 ist durch die Nutzung eige-ner APIs oder über OSGi erweiterbar. Man kann beispielsweise einen eigenen Cus-tom-Container über die Extension-API von Grizzly hinzufügen, der hochperformanten, NIO-basierten Netzwerk-Protokoll-Engine von GlassFish. Dieser Mechanismus wurde für die Implementierung der nativen Jru-by- und Jython-Container verwendet.

GlassFish v3 wird zusammen mit dem Felix-OSGi-Container ausgeliefert, könnte jedoch auch mit anderen OSGi-Contai-nern wie Equinox oder Knopflerfish un-modifiziert laufen. Eine Besonderheit der

Abbildung 1: Die Architektur von GlassFish v3


iiiiii iii

iiiIntegration mit OSGi besteht darin, dass die Visibilität von OSGi von den GlassFish-Entwicklern auf die GlassFish-Benutzer ausgedehnt wird. Java-EE-Anwendungs-entwickler können über Annotations und Resource-Injection transparent auf über OSGi definierte Services zugreifen, ohne jegliche Verwendung von GlassFish- oder OSGi-spezifischen APIs:

@Resource(mappedName=”checkOsgiService”)CheckService checkService;

Dies ermöglicht die Erstellung von soge-nannten „converged“ Java-EE-Anwendun-gen, bei denen OSGi zur Auflösung von Abhängigkeiten herangezogen wird. Das GlassFish-Team erwägt auch die ande-re Richtung: Java-EE-Komponenten und -Dienste künftig als OSGi-Services zugäng-lich zu machen.

Einfache EntwicklungEntwickler, die zum ersten Mal mit Glass-Fish v3 arbeiten, erleben eine angenehme Überraschung. Der Application-Server ist extrem leichtgewichtig und ressourcen-schonend. Das Web-Profile ist etwa 50 MB, das Full-Profile etwa 80 MB groß. Die Start-up-Zeit beträgt nur wenige Sekunden – auf gängigen Laptops unter zehn. Das hängt damit zusammen, dass die Services erst bei Bedarf hochgefahren werden, und wenn noch nichts deployed ist, ist auch kein Container gestartet. Die Dokumen-

tation ist ausführlich und übersichtlich. Es gibt zahlreiche Optionen für Manage-ment und Monitoring, wie nachfolgend beschrieben. Für Testzwecke besteht noch ein Maven-Plug-in für Embedded Glass-Fish mit Maven-Goals zum Starten/Stop-pen und zur Installation/Deinstallation von Anwendungen.

GlassFish bietet diverse Deployment-Op-tionen. Zu den weniger bekannten gehören automatisches Deployment, Dynamic Re-loading und Deployment von Java-EE-Ap-plication-Clients über Java Web Start. Eine Neuheit für Entwickler ist das sogenann-te „Keep-Session-on-Redeploy“-Feature. Wenn konfiguriert, serialisiert GlassFish die User-Sessions zwischen Redeployments, sodass sie erhalten bleiben, selbst wenn die Anwendung inzwischen modifiziert wird.

Der Spaß mit GlassFish kommt aber erst dann richtig auf, wenn man dabei eine ge-eignete Entwicklungsumgebung verwen-det. Für diejenigen, die mit den neuesten Java-EE-6-Features arbeiten wollen, ist NetBeans 6.9.1 die beste Wahl. In NetBeans kann man leicht GlassFish integrieren, ver-walten und debuggen. Der hervorragende Support von Java EE 6 in Form von Code-Completion und Wizards erleichtert den

Einstieg und steigert die Produktivität. Gute Unterstützung für GlassFish v3 und Java EE 6 bieten auch das Oracle Enterprise Pack für Eclipse, das Tools Bundle für Eclip-se und IntelliJ IDEA.

Embeddable GlassFishGlassFish v3 bietet die Möglichkeit, einge-bettet in einer beliebigen Java-Anwendung zu laufen. Dafür gibt es APIs, über die man den Application Server verwalten kann, wie starten, stoppen, konfigurieren sowie Anwendungen installieren und deinstal-lieren. Er kann einfach als Bibliothek und Bestandteil einer Anwendung ausgeliefert werden, was ihn für OEM-Hersteller sehr interessant macht. Für solche Szenarien wird GlassFish in Form eines JAR-Files, je-weils für das Web- oder Full-Profile oder alternativ dazu als Maven-Plug-in bereit-gestellt. Das Maven-Plug-in vereinfacht stark den Build- und Test-Prozess für An-wendungen, weil man dafür alles auf dem-selben Rechner abwickeln kann und nicht mal eine GlassFish-Installation braucht. Das folgende Code-Segment skizziert ei-nen JUnit-Test, bei dem eine Anwendung getestet wird, nachdem sie auf GlassFish in Embedded-Mode deployed wurde:

Management und MonitoringEs gibt umfangreiche Möglichkeiten für das Management und Monitoring von GlassFish v3: über die Admin-Konsole, ein intuitives und gut durchdachtes Web-In-terface, über das Command-Line-Interface, über Ant-Tasks, über JMX oder die AMX-API, eine GlassFish spezifische API, die den Umgang mit JMX und den Mbeans von GlassFish vereinfacht (siehe Abbildung 2). Abbildung 2: GlassFish v3 Monitoring

@BeforeClass public static void initContainer() { Server.Builder builder = new Server.Builder(); Server server = builder.build(); ContainerBuilder b = server.createConfig(ContainerBuilder.Type.web); server.addContainer(b); ... File archive = new File(„hello.war“); server.getDeployer().deploy(archive);}

@Test public static void pingApplication() { ...}

60 |

iiiiii iii

iiiEine sehr interessante Möglichkeit für Ma-nagement und Monitoring bietet das neue REST-Interface, das den Einsatz von Glass-Fish in Cloud-Umgebungen erleichtert. Jedes Konfigurationselement von Glass-Fish entspricht einem Knoten im Objekt-Graph einer GlassFish-Konfiguration, der als eine REST-Ressource über den URL http://host:port/management/domain/<path-in-object-tree> exponiert ist. Abhängig von dem Knoten-Typ ist die Zulässigkeit der http-Methoden GET, POST, DELETE, die zum Auslesen oder Manipulation des Konfigu-rationsgraphen dienen. Das REST-Interface macht es möglich, REST-basierte Manage-ment- und Monitoring-Clients für GlassFish v3 auch in anderen Sprachen zu schreiben. Das folgende Beispiel zeigt, wie man das bekannte cURL-Utility benutzen kann, um über das REST-Interface eine JDBC-Ressour-ce in GlassFish v3 zu deaktivieren:

curl -X POST -d „enabled=false“ http://localhost:4848/manage-ment/domain/resources/jdbc-resource/jdbc-sample

Das Monitoring in GlassFish v3 wurde komplett überarbeitet und erweitert. Es setzt auf ein BTrace-basiertes Framework auf, bei dem dynamisch und nicht-intrusiv von jeder GlassFish-Runtime-Klasse Events generiert werden können. Die Events wer-den dann von dynamisch registrierten Lis-tenern gesammelt, statistisch ausgewertet und über diverse APIs für verschiedene Monitoring-Clients bereitgestellt. Dank BTrace sind die BTrace-Probes, die als Er-eignis-Quelle dienen, dem DTrace-Frame-work unter Solaris zugänglich. DTrace ist ein umfangreiches Framework und Tool für dynamisches Tracing, das im Solaris-Kernel verankert ist und non-intrusive die gleichzeitige Untersuchung von Anwen-dungen und Betriebssystem im laufenden Produktionsbetrieb ermöglicht. Mit DTrace kann man sich durch dynamische Instru-mentierung ein komplettes Bild vom ge-samten Produktionssystem (Anwendung + Betriebssystem) machen und gegebenen-falls schnell Performance- und sonstige Problem-Quellen lokalisieren. Mit anderen Worten: Das neue Monitoring-Framework in GlassFish v3 ermöglicht eine feingranu-lare Analyse des Application-Servers durch

das mächtigste Tracing-Tool unter Solaris und leistet dadurch einen großen Beitrag für höhere Verfügbarkeit und Qualität sei-ner Dienste in der Produktion.

Unterstützung für ScriptingDynamische Scripting-Sprachen wie Jru-by, Groovy, Jython und Scala erfreuen sich zunehmend einer wachsenden Popularität und Verbreitung. Die Gründe dafür sind vielschichtig, aber zu den wichtigsten ge-hören die hohe Produktivität, der leichte Einstieg, die mächtigen und leicht ver-wendbaren Scaffolding-Frameworks, die sie begleiten, und nicht zuletzt die prag-matische Überlegung, dass sie sich für ein bestimmtes Projekt als schnell und gut ge-nug erweisen.

GlassFish v3 hat deutlich die Unterstüt-zung von dynamischen Scripting-Sprachen verbessert und bietet native Container für Jruby und Jython (siehe Abbildung 3). Wei-terhin unterstützt GlassFish Groovy/Grails, Scala/Lift und PHP. Scripting-Anwendun-gen, die auf GlassFish deployed werden, profitieren zunächst von der Infrastruktur eines Java-EE-Application-Servers – bes-sere Skalierbarkeit durch die Verwendung von Thread- und Datenbank-Connection-Pools, bessere Sicherheit und Wiederver-wendung seiner Management- und Moni-toring-Features. Als großer Vorteil erweist sich aber auch die modulare und erweiter-bare Architektur von GlassFish v3, da sie die Anbindung von anderen Containern und die Erweiterung der Admin-Console, etwa für Jruby-Spezifika, erleichtert. Über

Abbildung 3: Scripting-Frameworks auf GlassFish v3

das GlassFish-Update-Center kann zu je-dem Zeitpunkt eine bestehende GlassFish-Installation mit den notwendigen Modulen für die gewünschte Scripting-Unterstüt-zung nachgerüstet werden.

FazitGlassFish v3 ist ein sehr leichtgewichtiger, erweiterbarer, embeddable Application-Server, dessen Unterstützung für Web-2.0 -Anwendungen sich über Java hinaus auch auf andere moderne Scripting-Sprachen ausdehnt. GlassFish v3 bietet seinen Be-nutzern den vollständigen Support für Java EE 6, die benutzerfreundlichste, fle-xibelste und vollständigste aller bisheri-gen Java-EE-Plattformen. Mit GlassFish v3 können Unternehmen zwischen dem leichtgewichtigen Web-Profile und dem mächtigeren Full-Profile als standardisierte Laufzeit-Umgebungen für ihre Anwendun-gen wählen.

Kontakt:Peter Doschkinow

[email protected]

Peter Doschkinow arbeitet als Senior Java Architekt bei Oracle Deutschland. Er beschäftigt sich mit serverseitigen Java-Technologien und Frameworks, Web Services und Business Integration, die er in ver-schiedenen Kundenprojekten er-folgreich eingesetzt hat. Vor seiner Tätigkeit bei Oracle hat er wertvolle Erfahrungen als Java Architect and Consultant bei Sun Microsystems gesammelt.


iiiiii iii

iiiTesten mit JUnit für FortgeschritteneJens Schauder, LINEAS Informationstechnik GmbH

JUnit ist das bekannteste Test-Framework im Java-Umfeld. Ein Grund, warum es so beliebt ist, liegt darin, dass es recht klein und damit einfach zu erlernen ist. Dennoch bietet selbst diese kleine Bibliothek diverse Features, die nur wenig bekannt sind. Einige davon aus der aktuellen Version 4.8.2. werden nachfolgend vorgestellt.

Wer hatte nicht schon einmal eine Testklas-se, deren Testmethoden in etwa so aussa-hen (siehe Listing 1).

Eine Gruppe von Tests ist praktisch gleich und unterscheidet sich nur in we-nigen Parametern. Um zu vermeiden, im-mer wieder den gleichen Test schreiben zu müssen, gibt es in JUnit parametrisierte Tests. Um diese zu nutzen, benötigt die Testklasse einen öffentlichen Konstruktor, der die benötigten Parameter entgegen-nimmt.

Typischeweise speichert man die Pa-rameter in Feldern der Klasse, sodass sie dann in den Tests verfügbar sind.

Geliefert werden die Parameter von ei-ner öffentlichen statischen Methode, die eine „Collection“ von Arrays bereitstellt. Die Methode wird mit der Annotation „@Parameters“ versehen. Die gesamte Test-klasse muss mit dem „Parameterized Run-ner“ ausgeführt werden. Das Ganze sieht dann wie in Listing 2 aus.

Dieser Test wird bei der Ausführung durch JUnit nun dreimal instanziiert und jedes Mal mit einem anderen Satz Para-meter. Er verhält sich also im Prinzip genau wie die ursprüngliche Variante. Das Maß der Code-Duplizierung ist jedoch erheb-lich reduziert. Dies macht sich besonders bezahlt, wenn die Tests nicht ganz so trivial sind wie in diesem Beispiel oder es noch mehr verschiedene Werte für die Parame-ter gibt.

Obwohl dies sehr praktisch ist, sollen gewisse Nachteile und Beschränkungen dieses Ansatzes nicht unerwähnt bleiben. Vielleicht ist dem einen oder anderen schon aufgefallen, dass im Listing 2 Objek-te vom Typ „Character“ vorkommen, wäh-rend in den ursprünglichen Tests in Listing 1 der primitive Typ „char“ verwendet wur-de. Dies ist geschehen, da JUnit Arrays von Objekttypen benötigt.

@RunWith(Parameterized.class)public class SomethingParameterizedTest {

@Parameters public static Collection<Character[]> parameters() { return Arrays.asList(new Character[][] { { ‘a’, ‘b’ }, { ‘b’, ‘c’ }, { ‘c’, ‘d’ } }); }

private final char expectedResult; private final char parameterToTest;

public SomethingParameterizedTest(char aParameterToTest, char anExpectedResult) { expectedResult = anExpectedResult; parameterToTest = aParameterToTest; }

@Test public void something_returns_the_correct_valuse() {assertEquals(expectedResult,something(parameterToTest)); }}

Listing 2

public class SomethingTest{ @Test public void something_returns_B_for_A(){ assertEquals(‚B‘, something(‚A‘)); } @Test public void something_returns_C_for_D(){ assertEquals(‚C‘, something(‚B‘)); }

@Test public void something_returns_D_for_C(){ assertEquals(‚D‘, something(‚C‘)); } //...}

Listing 1

62 |

iiiiii iii

iiiDie unterschiedlichen Testdurchläufe wer-den nur durch Indizes unterschieden, das heißt, wenn von zwanzig derartigen Tests einer fehlschlägt, ist nicht ohne Weiteres zu erkennen, welche Parameterkombina-tion dafür verantwortlich ist. Es empfiehlt sich daher, die Meldungstexte von Asser-tions so zu gestalten, dass die verwende-ten Parameter erkennbar sind.

Die vielleicht schwerwiegendste Kritik ist die, dass der Mechanismus sehr unfle-xibel ist und sich selbst nicht gut für eine Wiederverwendung eignet. Am Ende die-ses Artikels wird ein anderes Feature vor-gestellt, das diesen Nachteil nicht hat.

RulesRules sind eine Möglichkeit, die Art und Weise, wie eine Testmethode ausgeführt wird, zu beeinflussen. Alles, was man dazu im Test tun muss, ist ein öffentliches sta-tisches Feld vom Typ „MethodRule“ oder von einem davon abgeleiteten Typ anzule-gen und dies mit der Annotation „@Rule“ zu versehen (siehe Listing 3).

Dieser Teil ist extrem einfach. Spannend wird das Ganze in der Implementierung der Rule, d.h. in dem Beispiel in der Klasse „SomeRule“ (siehe Listing 4).

Diese muss das Interface „MethodRule“ implementieren. Dies wiederum besteht aus einer einzigen Methode „apply“, von der wir zunächst nur den ersten Parameter und den Rückgabewert betrachten. Beides ist vom Typ „Statement“. Ein Statement ist ein Test, der bereit ist, ausgeführt zu werden. Eine Rule wird für jeden Test mit eben diesem Test als Statement-Parameter aufgerufen und muss ein Statement zu-rückliefern, welches dann tatsächlich aus-geführt wird. Die oben vorgestellt Imple-mentierung tut, wie man leicht erkennt, im Endeffekt nichts. Eine echte Rule wird typi-scherweise eine neue Statement-Instanz erzeugen, oft in Form eines anonymen Typs (siehe Listing 5).

„Statement“ selbst ist wiederum ein sehr einfaches Interface mit nur einer Me-thode „evaluate“, die zur Ausführung des Tests aufgerufen wird. Leider tut unsere Rule immer noch nichts Sinnvolles, aber wir haben den Aufruf des Tests nun in unserer Implementierung von „evaluate“ unter Kontrolle und können dort diverse Dinge tun, zum Beispiel einen eigenen

public class SomeRule implements MethodRule {

@Override public Statement apply(Statement statement, FrameworkMethod method, Object test) { return statement; }

}

Listing 4

@Override public Statement apply(final Statement statement, FrameworkMethod method, Object test) { return new Statement() {

@Override public void evaluate() throws Throwable { statement.evaluate(); } }; }

Listing 5

public interface Slow {}public interface NeedsDB {}public interface NeedsGUI {}

Einzelne Tests können mit der @Category Annotation mit einer oder mehreren Kategorien versehen werden.

public class CategoryTest { @Test @Category(Slow.class) public void slowTest() { // ... }

@Test @Category({ Slow.class, NeedsDB.class }) public void slowDbTest() { // ... }}

Listing 6

public class SomethingRuleTest {

@Rule public MethodRule rule = new SomeRule();

@Test public void testSomething() { assertEquals(‘y’, something(‘x’)); }}

Listing 3


iiiiii iii

iiiThread ausführen, etwa im Eventhandling-Thread, wenn wir Swing-Komponenten verwenden. Wir können die Zeit messen, die unser Test benötigt, und mit einer JU-nit-Assertion überprüfen, ob diese unter-halb eines bestimmten Schwellwertes liegt (siehe org.junit.rule.TimeOut). Wir können Ressourcen erzeugen, die vom Test benö-tigt werden, und diese anschließend wie-der entfernen. Wir können die Ausführung des Tests protokollieren, indem wir vor und nach dem Aufruf von „statement.evaluate“ Log-Ausgaben erzeugen.

Um alle Möglichkeiten von Rules nutzen zu können, schauen wir uns noch die ver-bleibenden Parameter der „apply“-Metho-de an. Die „FrameworkMethod“ ermöglicht „reflection“-artigen Zugriff auf die eigent-liche Testmethode, insbesondere auf den Namen und auf eventuell vorhandene An-notations. Dies kann sehr gut verwendet werden, um das Verhalten einer Rule für einzelne Tests durch Annotationen oder durch Namenskonventionen noch weiter zu beeinflussen. Der dritte Parameter ist die Test-Instanz selbst. Hierüber könnten Instanzvariablen manipuliert oder ausge-lesen werden.

Eine weitere beliebte Methode ist es, in den Tests auf die Rule-Instanz zuzugreifen, was natürlich problemlos möglich ist, da es ja einfach ein statisches Feld ist. JUnit selbst bringt einige Rules mit, die neben ihrem direkten praktischen Wert auch ex-zellente Codebeispiele für Rules liefern. Die „TimeOut“-Rule betrachtet einen Test als fehlgeschlagen, wenn er länger als eine im Konstruktor der Rule angegebene Zeitspanne benötigt. Wenn man seine As-sertions mit dem „ErrorCollector“ statt mit dem normalen „Assert“ schreibt, wird die Ausführung des Tests auch im Fehlerfall fortgeführt, und man bekommt am Ende alle fehlgeschlagenen Assertions anstatt nur der ersten. Diese Rule ist abgeleitet von der Rule „Verifier“, die es davon abgeleiteten Rules ermöglicht, im Anschluss eines Tests noch weitere Bedingungen zu prüfen. Mit „ExpectedException“ kann man erwartete Exceptions genauer prüfen als mit dem üb-lichen „@Test(expected=SomeException.class)“, welches nur den Typ der Excep- tion prüft. „ExternalResource“ bildet den bekannten „before/after“-Mechanismus als Rule ab und dient als Basisklasse für

weitere Rules, die dann nur jeweils „befo-re()“ und „after()“ implementieren müssen. „TemporaryFolder“ ist davon abgeleitet und erstellt einen temporären Ordner, in dem vom Test Dateien erzeugt werden können, die automatisch am Ende wieder weggeräumt werden.

„TestWatchman“ ist eine weitere Basis-klasse. Sie ist Basis für Rules, die die eigent-liche Testausführung nicht weiter verän-dern wollen, aber vor oder nach einem Test Aktionen ausführen wollen. „TestName“ ist eine davon abgeleitete Klasse, die sich einfach den Namen eines Tests merkt und diesen als Methode zur Verfügung stellt, sodass ein Test darauf zugreifen kann.

CategoriesDie Empfehlungen für gute Tests sind sich darin einig, dass diese schnell sein und un-abhängig von der Umgebung immer das gleiche Ergebnis liefern sollen. Leider sieht die Realität oft deutlich anders aus. Da gibt es langsame Tests, von denen ein paar hun-dert schon eine halbe Stunde benötigen. Andere benötigen eine Datenbank oder ein anderes Schnittstellensystem, und es gibt Tests, die eine GUI benötigen, wo-möglich ein bestimmtes Betriebssystem. Schnell ist man so weit, dass die gesamte Test-Suite nur noch selten ausführbar ist, weil die eine oder andere Bedingung nicht erfüllt ist. Mit Categories können Tests ka-tegorisiert und dann Tests bestimmter Ka-tegorien ausgeführt oder eben nicht aus-geführt werden. Als Marker für Kategorien dienen beliebige Klassen, typischerweise jedoch Marker-Interfaces, das heißt Inter-faces, die keine Methoden enthalten (siehe Listing 6).

Es kann auch eine ganze Testklasse wird mit einer solchen Annotation versehen werden, was den gleichen Effekt hat, als würde man die Annotation an jede Test-

methode der Klasse schreiben. Einzelne Tests können zusätzlich noch weitere Ka-tegorien zugewiesen bekommen (siehe Listing 7).

Was nun noch fehlt, ist ein Runner, der alle Tests bestimmter Kategorien ausführt. Der Runner „Categories. Categories“ ist vom „Suite“-Runner abgeleitet, kann also auf die gleiche Weise eingesetzt werden. Insbesondere werden die auszuführenden Testklassen mit der „@SuiteClasses“-Anno-tation angegeben. Es werden die auszu-führenden Kategorien über die Annotati-on „@IncludeCategory“ angegeben und über „@ExcludeCategory“ auszuschließen-de Kategorien aufgelistet. Als Argument akzeptieren beide Annotationen ein Array von Klassen. Fehlt „@IncludeCategory“, werden alle Kategorien inkludiert; fehlt „@ExcludeCategory“, werden keine Katego-rien exkludiert. So lässt sich zum Beispiel eine Testsuite definieren, die alle Tests aus-führt, die eine GUI benötigen, solange sie nicht langsam sind (siehe Listing 8).

@Category(NeedsGUI.class)public class CategoryGuiTest { @Test public void guiTestOne() { // ... }

@Test public void guiTestTwo() { // ... }

@Test @Category(Slow.class) public void slowGuiTest() { // ... }}

Listing 7

@RunWith(Categories.class)@IncludeCategory(NeedsGUI.class)@ExcludeCategory(Slow.class)@SuiteClasses({ CategoryGuiTest.class, CategoryTest.class })public class GuiNotSlowTestSuite {}

Listing 8

64 |

iiiiii iii

iii@SuiteClasses({ CategoryGuiTest.class, CategoryTest.class })public class AllTestSuite {}

@RunWith(Categories.class)@IncludeCategory(Slow.class)public class SlowTestSuite extends AllTestSuite {}

Listing 9

@RunWith(Theories.class)public class TheorieTest { @DataPoint public static String a = “a”; @DataPoint public static String b = “bb”; @DataPoint public static String c = “ccc”; @Theory public void stringTest(String x, String y) { System.out.println(x + “ “ + y); }}

Listing 10

Um die Auflistung aller Testklassen nicht immer wiederholen zu müssen, bie-tet es sich an, diese einmal in einer Test-Suite zu definieren, von der die anderen Tests dann abgeleitet werden können (siehe Listing 9).

Theories„Theories“ ähneln in ihrer Verwendung den parametrisierten Tests vom Anfang des Artikels. Auch Theories benötigen ihren eigenen Runner „Theories“. Jede Testme-thode muss mit der Annotation „@Theory“ gekennzeichnet sein, anstatt mit „@Test“. Diese Testmethoden können Parameter erwarten. Zur Verfügung gestellt werden diese Parameter dann durch sogenannte „Datapoints“, öffentliche statische Felder mit einer „@DataPoint“-Annotation. Jede Testmethode oder besser jede Theorie wird nun mit allen aus diesen DataPoints erzeugbaren Kombinationen von Daten-punkten aufgerufen, solange die Daten-typen kompatibel sind. Der Test (siehe Lis-ting 10) …

… liefert die Ausgabe:

a a a bb a ccc bb a bb bb bb ccc ccc a ccc bb ccc ccc

Interessieren bestimmte Parameterkom-binationen nicht, da für diese die Theorie nicht gilt, kann man dies durch Methoden der Klasse „Assume“ ausschließen. Diese ähneln stark den Methoden der Klasse „Assert“, ein Nichterfüllen der Bedingung führt aber nicht zu einem Fehler, sondern zum Ignorieren der entsprechenden Para-meterkombination (siehe Listing11).

Die Theorie „assumeTest“ führt daher in der Klasse „TheorieTest“ zu folgender Aus-gabe und wird weiterhin als grüner Test betrachtet:

bb abb bbbb cccccc accc bbccc ccc

Diese Art Tests zu schreiben ist sinnvoll, wenn man sich mit „Design by Contract“ beschäftigt, wenn man sich also bestimm-te Zusicherungen bewusst macht, die eine Klasse gibt. Eine Implementierung des „java.util.List“-Interface sichert zum Beispiel zu, dass man ein Objekt, das man erfolgreich mit „add“ hinzufügt (der Rück-gabewert ist „true“), sich anschließend in der Liste befindet („contains“ mit dem glei-chen Objekt als Argument liefert ebenfalls „true“). Dies lässt sich als Theory formulie-ren, die man dann mit beliebig vielen Da-tenpunkten überprüfen kann.

Die Definition der Datenpunkte − wie bisher geschehen − ist sehr wortreich. Dies stört, vor allem, da Theorien gerade dann sinnvoll sind, wenn es viele Datenpunkte gibt. Daher können alternativ auch Da-tenpunkte als Arrays angegeben werden. Wichtig ist dabei, dass man die Annotation „@Datapoints“ (Plural) verwendet, ansons-ten würde das gesamte Array als einzelner Array-wertiger Datenpunkt angegeben werden.

@DataPointspublic static Integer[] j = { 1, 2, 3 };

Das Vorgehen stößt mit den bisher vorge-stellten Mitteln an seine Grenzen, wenn man Parameter hat, die zwar vom gleichen Typ sind, die sich aber in ihrer Interpreta- tion unterscheiden. Wenn etwa zwei Argu-mente vom Typ „String“ vorliegen, von de-nen der eine aber Personennamen enthält und der andere Kreditkartenanbieter. Für diese Fälle sind „ParameterSupplier“ mög-lich (siehe Listing 12).

Die Klasse muss die Klasse „Parame-terSupplier“ erweitern und die einzige abstrakte Methode „getValueSource“ im-plementieren. Diese liefert eine Liste von „PotentialAssignments“. Sie bestehen aus dem eigentlichen Wert und einem Namen, der in Fehlerfällen verwendet werden kann. Als Parameter für „getValueSource“ wird die Signatur des Parameters überge-ben, für den der Parameter-Supplier einge-setzt wird. Dazu später mehr.

Um den Supplier an einen Parameter zu binden, muss zunächst noch eine Anno-tation definiert werden, die selbst mit der Annotation „@ParametersSuppliedBy“ den Parameter-Supplier referenziert:

@Retention(RetentionPolicy.RUNTIME)@ParametersSuppliedBy(NameSupplier.class)public @interface AllNames {}

Wichtig ist dabei die Retention „RUNTIME“, damit die Annotation auch zur Laufzeit wirklich zur Verfügung steht. In einem Test können dann Parameter von Theorien mit der neuen Annotation versehen werden. Diese Parameter werden dann vom Pa-rameter Supplier mit Werten versorgt. In dem Beispiel ist die Annotation „@AllCre-


iiiiii iii

iii@Theorypublic void assumeTest(String x, String y) { Assume.assumeTrue(x.length() > 1); System.out.println(x + “ “ + y);}

Listing 11

public class NameSupplier extends ParameterSupplier {

@Override public List<PotentialAssignment> getValueSources(ParameterSignature signature) { ArrayList<PotentialAssignment> result = new ArrayList<PotentialAssignment>(); result.add(PotentialAssignment.forValue(“Single Name”, “Martin”)); result.add(PotentialAssignment.forValue(“Two Names”, “Hans Martin”)); result.add(PotentialAssignment.forValue(“Weird Characters”, “André”)); // ... return result; }

}

Listing 12

@RunWith(Theories.class)public class SuppliedByTest {

@Theory public void supplierTest(@AllCreditCards String cc, @AllNames String name) { System.out.println(cc + “ “ + name); }}

Listing 13

ditCards“ analog zu „@AllNames“ imple-mentiert (siehe Listing 13).

Nun wird auch deutlich, dass man mit der „ParameterSignature“, die dem Para-meter-Supplier übergeben wird, diesem noch zusätzliche Informationen zukom-men lassen kann. So kann er zum Beispiel Werte für unterschiedliche Datentypen erzeugen oder aber die Annotation, über die der Parameter-Supplier an einen Pa-rameter gebunden wird, kann noch wei-tere Informationen aufnehmen, die vom Parameter-Supplier mit ausgewertet wer-den.

FazitEs ist doch erstaunlich, was sich alles in einer so kleinen und weit verbreiteten Bi-bliothek wie JUnit noch finden lässt. Auch wenn die Handhabung von Annotationen für manchen noch immer fremd ist, emp-

fehle ich dringend, diese Features im Kopf zu behalten, wenn es an das Schreiben von Tests geht, denn sie sind geeignet, Tests mit geringem Aufwand wesentlich gründ-licher, einfacher und letztendlich besser wartbar zu gestalten.

Kontakt:Jens Schauder

[email protected]

Unsere Inserenten

aformatik Training und Consulting GmbH & Co. KGwww.aformatik.deSeite 27

CaptainCasa Gmbhwww.CaptainCasa.comSeite 3

DOAG e.V.wwww.doag2011.orgSeite U 2

MATHEMA Software GmbHwww.mathema.deSeite U 3

ORACLE Deutschland GmbH www.oracle.com

Seite: U 4

66 |

iiiiii iii

iii

Eclipse Rich Client PlatformJürgen Thierack

Als der Autor vor zwei Jahren erstmals an einem Eclipse RCP-Projekt mitmachte, wurde ihm auf seine Frage, was es zum Thema zu lesen gebe, „der McAffer” empfohlen. Dieser sei zwar schon etwas veraltet, aber für praktische Belange das beste Buch am Markt. Es sei für Eclipse das, was „Rich Client Programming: Plugging into the NetBeans Platform von Tim Boudreau, Jaroslav Tulach, Geertjan Wielenga, Prentice Hall International, 2007“ für die Netbeans sei.

Kurz vor dem Helios-Release kam 2010 die zweite Auflage des „Definitive Guide to Ec-lipse Rich Client Development“ (Verlagstext) auf dem Stand von Eclipse 3.52 heraus. Die erste Auflage von 2005 war auf dem Level von Eclipse 3.1. Die Verfasser sind Projekt-leiter oder Committer im Eclipse-Projekt. Den Eclipse RCP-Anfänger erwartet eine verschachtelte API und eine ungewohnte Begrifflichkeit. Diverse „Berater“ (Advisors) steuern das Erscheinungsbild von Fenstern, Menüs, Toolbars und Perspektiven (Beispiel: Java- und Debug-Perspektiven in der Java-Entwicklung mit Eclipse): WorkbenchAd-visor, WorkbenchWindowAdvisor, ActionBa-rAdvisor. Die Darstellung von Informationen kann in Form sogenannten „Views“ erfolgen (Package Explorer, Type Hierarchy in der Ja-va-Entwicklung). Eine View („MyView“) wird erzeugt, indem ViewPart abgeleitet wird. Es ergibt sich eine nicht gerade selbstevidente Klassenhierarchie.

public class MyView extends ViewPart•public abstract class ViewPart extends •WorkbenchPart implements IViewPartpublic abstract class WorkbenchPart •extends EventManager implements IWorkbenchPart3, IExecutableExtension, IWorkbenchPartOrientation

public abstract class EventManager •(endlich von Object abgeleitet)

Mathias Fuchs, Leiter eines Projektes beim IT-Dienstleister Logica für den Kraftwerk-bauer Alstrom, antwortete auf die Frage, welche Schlüsse sich aus heutiger Sicht aus dem Projekt ziehen lassen: „Die Entscheide für Java und Eclipse RCP waren richtig, aber die Lernkurve war steiler, als wir uns das vorgestellt hatten. Selbst Spitzenpro-grammierer haben nach dem Einstieg bei solchen Projekten noch einiges vor sich. Das muss man bei der Release- und Kos-tenschätzung unbedingt berücksichtigen“ (Quelle: http://www.de.logica.ch).

Anstatt sich theoretisch in die Thematik einzuarbeiten, sollte man den ersten Satz von Buchabschnitt II („RCP by Example“) beherzigen: „The best way to learn about Eclipse as a rich client platform is to build a rich client application“. Und genau das ist der Schwerpunkt des Buches. Es wird eine Anwendung für Instant Messaging (sofor-tige Nachrichtenübermittlung) erstellt, welche auf den Namen Hyperbola (Hy-perbel) hört. Wenn Karl eine Nachricht in seinen Client tippt, erscheint diese im Cli-ent von Erna, sofern sich Erna ebenfalls am Server angemeldet hat. Die Applikation wird schrittweise erstellt, jedes Detail der Programmierung ausführlich besprochen, GUI, Events, Datenbindung, Erstellung als Stand-Alone Anwendung, Individuali-sierung mit Icons und Splash Screen, p2-Installer, Verwendung von Java Web Start (JNLP). Man lernt, indem man sich allmäh-lich an die Eclipse-RCP-Welt gewöhnt.

Mit http://eclipsercp.org gibt es eine Webseite zum Buch, auf der es neben den Errata auch den übrigens seit Erscheinen des Buches stark überarbeiteten Quell-

code von Hyperbola in seinen verschiede-nen Entwicklungsstufen gibt. Ferner findet sich dort ein Forum, das zur Zeit 49 Topics hat. Eines der Topics lautet Example-Code plugin does not install in Helios 3.6.1:

Hi folks,just downloaded the latest helios version of eclipse. Now, when installing the ex-ample plug-in provided by http://www.ecipsercp.org, I get: ... (Liste von Fehler-meldungen)... With galileo (3.5.2), I do not have this problem, everything works fine.Any suggestions?Cheers, Marcel

FazitEs besteht also die Hoffnung, dass dank Webseite und Forum auch die neueste Ec-lipse-Version Berücksichtigung findet und so das Schicksal aller Computer-Bücher, die schnelle Alterung, wenigstens verzögert wird. Zwar erfahren wir im Buch etwas zur Geschichte von Eclipse RCP, doch einen Ausblick auf Eclipse 4 sucht man vergebens, aber das ist kein Nachteil, denn es geht um das praktische Know-how, hier und jetzt er-folgreich Applikationen zu erstellen.

Kontakt:Jürgen Thierack

[email protected]

Eclipse Rich Client Platform, 2. AuflageJeff McAffer, Jean-Michel Lemieux, Chris AniszczykAddison-Wesley Professional, 2010Paperback; 552 Seiten, $ 49,99ISBN-10: 0321603788Sprache: Englisch

Jürgen Thierack. ist Diplomche-miker, wechselte aber in die Soft-ware-Branche, wo er freiberuflich unterwegs ist. Seit fast 10 Jahren liegt sein inhaltlicher Schwerpunkt bei Fragen der Finanzmathematik, darunter der Preisfindung für Opti-onen und Optionsscheine. Aktuelle Thematik: Trendfolgesysteme. Mit Java arbeitet er seit 2001.

Documents

Java aktuell