Ausgabe Frühjahr 2011 - Gedoplan
Ausgabe Frühjahr 2011 - Gedoplan
Ausgabe Frühjahr 2011 - Gedoplan
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Das Kundenmagazin<br />
In dieser <strong>Ausgabe</strong>:<br />
Java-EE-6-Server im<br />
Überblick<br />
WebLogic: Oracles<br />
strategische Middleware-<br />
Plattform<br />
GlassFish 3.1: Das volle<br />
Programm Java EE 6<br />
JBoss 6.0.0: Der neue<br />
Chef mit dem roten Hut<br />
aktuell<br />
<strong>Ausgabe</strong> <strong>Frühjahr</strong> <strong>2011</strong><br />
www.gedoplan.de
EDITORIAL<br />
Liebe Leserin, lieber Leser,<br />
Middleware wird in vielen Unternehmen eingesetzt,<br />
aber sie wird weder richtig wahrgenommen<br />
noch ist sie ein zentrales Thema aktueller Diskussionen.<br />
Das heißt aber nicht, dass Applikationsserver<br />
sich zum einem Randthema entwickelt haben.<br />
Diese Situation verdeutlicht lediglich, dass<br />
Middleware sich mittlerweile etabliert hat.<br />
Warum haben wir uns dann aber genau dieses<br />
Thema für die zweite <strong>Ausgabe</strong> unserer Kundenzeitschrift<br />
gewählt? In der vorherigen <strong>Ausgabe</strong><br />
haben wir das neue Release 6 der Java EE vorgestellt<br />
und Fortschritte sowie Vereinfachungen<br />
hinsichtlich der Softwareentwicklung deutlich<br />
gemacht. Daher lohnt es sich, mal genauer hinzuschauen<br />
und die Frage zu beantworten, welche der<br />
bekannten Applikationsserver dieses neue Release<br />
bereits implementiert haben und welche der neuen<br />
Möglichkeiten von ihnen angeboten werden.<br />
Wie immer bietet unser erster Artikel Ihnen die<br />
Möglichkeit, sich einen Überblick über das Thema<br />
zu verschaffen. Dirk Weil zeigt in seinem Artikel,<br />
dass noch einiger Nachholbedarf vor allem bei den<br />
etablierten, kommerziellen Servern besteht. Die<br />
folgenden Beiträge beschäftigen sich dann mit drei<br />
bekannten Applikationsservern. Klaus-Peter Lisson<br />
wagt einen Ausblick auf die Zukunft des Weblogic<br />
Servers aus dem Hause Oracle, Dominik Mathmann<br />
kennzeichnet Vor- und Nachteile der Referenzimplemetierung<br />
GlassFish und schließlich beschäftigt<br />
sich Klaus Bertelt mit dem neuesten Mitglied der<br />
Java-EE-6-Server-Familie: Red Hat JBoss.<br />
Eine spannende und lohnende Lektüre<br />
wünscht Ihnen Ihr<br />
Ulrich Hake | ulrich.hake@gedoplan.de<br />
2<br />
Termine<br />
Expertenkreis Java<br />
Thema: Monitoring und Profiling von Java-Anwendungen<br />
Ort: IPS Hannover, Bischofsholer Damm 89, 30173 Hannover<br />
Termin: Donnerstag, 20.01.<strong>2011</strong> | 18:00-20:00 Uhr<br />
Referent: Rolf Kulemann, NEO Business Partners GmbH<br />
Thema: Java in the Cloud – am Beispiel der Google App Engine<br />
Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld<br />
Termin: Donnerstag, 17.02.<strong>2011</strong> | 18:00-20:00 Uhr<br />
Referent: Malte Jäger, brand´s mill GmbH<br />
Thema: Agiles BPM in der Praxis – mit BPMN 2.0 und Activiti<br />
zur lauffähigen Software<br />
Ort: IPS Hannover, Bischofsholer Damm 89, 30173 Hannover<br />
Termin: Donnerstag, 14.04.<strong>2011</strong> | 18:00-20:00 Uhr<br />
Referent: Bernd Rücker, camunda<br />
Thema: Monitoring und Profiling von Java-Anwendungen<br />
Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld<br />
Termin: Donnerstag, 19.05.<strong>2011</strong> | 18:00-20:00 Uhr<br />
Referent: Klaus-Peter Lisson, GEDOPLAN GmbH<br />
JAX <strong>2011</strong><br />
Thema: Vergleich von JPA-Providern<br />
Ort: JAX <strong>2011</strong>, Mainz<br />
Termin: Dienstag, 03.05.<strong>2011</strong> | 16:45-17:45 Uhr<br />
Referent: Dirk Weil, GEDOPLAN GmbH, Bielefeld<br />
Thema: Optimierung von JPA-Anwendungen<br />
Ort: JAX <strong>2011</strong>, Mainz<br />
Termin: Mittwoch, 04.05.<strong>2011</strong> | 8:30-9:45 Uhr,<br />
Referent: Dirk Weil, GEDOPLAN GmbH, Bielefeld
Java-EE-6-Server im Überblick<br />
In der letzten <strong>Ausgabe</strong> von GEDOPLAN aktuell haben sich gleich mehrere Artikel mit einem unserer<br />
Schwerpunktthemen beschäftigt: Java EE 6. Darin wurde auch deutlich, dass die Revolution der Plattform<br />
weg von unnötigem technischen Ballast hin zu einfacher und leichter Softwareentwicklung, die<br />
bereits mit der Version 5 begann, mit der aktuellen Version nochmals Fahrt aufgenommen hat. Gut ein<br />
Jahr nach dem offiziellen Release stellt sich nun die Frage nach den Trägersystemen: Welche Server<br />
sind heute in der Lage, Java-EE-6-Anwendungen zu tragen?<br />
Von Dirk Weil<br />
Trotz der relativ langen Wartezeit ist die Zahl verfügbarer Java-<br />
EE-6-Implementierungen recht überschaubar. Nur die Referenzimplementierung<br />
Oracle GlassFish bietet derzeit den vollen<br />
Umfang der Spezifikation – das sog. Full Profile – an. Für das eingeschränkte<br />
Web Profile gibt es nur einige wenige Anbieter, u. a.<br />
JBoss, SIwpas und Resin. Gründe für das zögerliche Erscheinen<br />
der Server könnten in der Einführung der erwähnten Profile liegen<br />
oder in aufwändigen Änderungen der Serverbasis, die bspw. durch<br />
die Integration von CDI erforderlich werden.<br />
Profilangelegenheiten<br />
Java-EE-Server brachten in der Vergangenheit immer den kompletten<br />
Umfang der Spezifikation mit, was für einen Großteil der<br />
Anwendungen nicht gebraucht wurde. So kommen Webanwendungen<br />
mit einem guten Drittel der in der Java EE 6 vereinigten<br />
Teilspezifikationen aus. Diese Erkenntnis nehmen die neu eingeführten<br />
Profile auf. Sie reduzieren den Gesamtumfang auf ein<br />
zielorientiertes Subset.<br />
Derzeit ist neben dem<br />
Full Profile nur ein eingeschränktes<br />
Profil definiert<br />
worden, das Web<br />
Profile. Die Grafik zeigt,<br />
welche Teilspezifikationen<br />
in den Profilen enthalten<br />
sind.<br />
Die vom Grundsatz her richtige Strategie, die Java EE durch die<br />
Einführung von Profilen überschaubarer und handhabbarer zu<br />
machen, kommt in erster Linie den Serveranbietern entgegen: Sie<br />
können dadurch einen standardkonformen Server anbieten, ohne<br />
alle Teile der Gesamtspezifikation implementieren zu müssen.<br />
So erklärt sich sicher, dass es deutlich mehr Implementierungen<br />
des Web-Profils gibt, zumal der überwiegende Teil der Enterprise-Anwendungen<br />
mit diesem Subset auskommt. Aus Sicht der<br />
Anwendungsentwicklung sind die Profile allerdings kritischer<br />
zu betrachten: War der Entwickler früher durch den immer vorhandenen<br />
vollen Umfang verwöhnt, muss er sich heute auf ein<br />
Zielprofil einschränken. Die Entscheidung für ein Profil lässt sich<br />
während der Erstentwicklung einer Anwendung sicherlich lange<br />
verzögern. Spätestens ab dem ersten Release ist man aber nicht<br />
mehr so flexibel.<br />
CDI – das neue Getriebe im System<br />
Wenn Java EE 5/6 eine Revolution zugunsten der Einfachheit der<br />
Softwareentwicklung ist, so stellt CDI (Contexts and Dependency<br />
Injection for the Java EE platform) zweifellos eine Revolution im<br />
Inneren eines Servers dar. Die Geschichte um CDI ist durchaus bewegt<br />
und spiegelt wider, wie durch Einflüsse u. a. konkurrierender<br />
Frameworks Standards entwickelt werden und reifen.<br />
Eine der Aufgaben eines Applikationsservers ist es, den Lebenszyklus<br />
serverseitiger Programmkomponenten zu steuern und die<br />
Instanzen dieser Komponenten miteinander zu verknüpfen. Dies<br />
geschah bis zur Version 1.4 der EE-Plattform über sog. Container-<br />
Contract-Methoden, d. h. es mussten technische Methoden zum<br />
Aufruf der entsprechenden Serverfunktionalität in die Komponenten<br />
eingebaut bzw. von dort aufgerufen werden. Dadurch ergab<br />
sich eine starke Bindung der Komponenten an den Container,<br />
was eine Verwendung außerhalb des Servers – z. B. für Testzwecke<br />
– unmöglich machte.<br />
Abhilfe schafft hier die Umkehrung der Zuständigkeiten: Die Komponenten<br />
nutzen nicht explizit den Container, sonder der Container<br />
liefert ihnen die benötigten Dinge. Über Annotationen oder<br />
hilfsweise XML-Deskriptoren lässt sich diese Inversion of Control<br />
(IoC) mit Dependency Injection (DI) kombinieren. Hierbei werden<br />
die vom Container bereitgestellten Werte bspw. in Instanzvariablen<br />
den Komponenten injiziert. Die Kenntnis der Komponenten<br />
über den Container oder andere Komponenten wird durch diese<br />
Vorgehensweise minimiert, wodurch ein Ablauf in einer anderen<br />
Umgebung und im Zusammenspiel mit anderen Komponenten-<br />
bspw. in einer Testumgebung mit Mock-Objekten – problemlos<br />
möglich wird.<br />
Ein Vorreiter im Bereich IoC und DI war sicher das Spring-Framework,<br />
dessen Core-Anteil i. W. einen Dependecy-Injection-Container<br />
darstellt. Google Guice stellt ebenfalls ein DI-Framework<br />
zur Verfügung. Hier hat auch der JSR 330 – Dependency Injection<br />
for Java – seinen Ursprung. Ähnliche Eigenschaften fanden<br />
sich in JBoss Seam, allerdings mit dem zusätzlichen Fokus auf<br />
der Steuerung des Lebenzyklus der Komponenten. Hieraus wurde<br />
der JSR 299 – zunächst unter dem Namen Web Beans, später<br />
in CDI umbenannt – abgeleitet. Die Diskussion, welcher Ansatz<br />
der bessere sei, wurde einige Zeit lang recht religiös geführt. <br />
3
Glücklicherweise wurden die beiden JSRs zusammengeführt, so<br />
dass CDI die Annotationen des JSR 330 (aus dem Paket javax.<br />
inject) verwendet.<br />
CDI ist ein äußerst leistungsfähiger Teil der Java EE 6, der darüber<br />
hinaus auch recht einfach zu verwenden ist. Unglücklicherweise<br />
existieren in der EE-Welt historisch bedingt weitere DI-Möglichkeiten,<br />
die sich weitgehend mit CDI überschneiden. So finden sich<br />
in JSR 250 (Common Annotations for the Java Platform), JPA, JSF<br />
und EJB diverse spezialisierte Injektionsmöglichkeiten, die teilweise<br />
schon heute durch CDI abgelöst werden können. Hier ist<br />
ein weiteres Entschlacken des Standards – vielleicht im Zuge der<br />
Entwicklung der Java EE 7 – wünschenswert.<br />
Ja, wo bleiben sie denn?<br />
Trotz der relativ großen Umbauten, die die Version 6 des<br />
EE-Standards auslöst, stellt sich die Frage, wo die entsprechenden<br />
Implementierungen bleiben. Es sind schließlich schon knapp<br />
1¼ Jahre seit dem Release der Java EE 6 vergangen und dennoch<br />
sind bislang nur die oben erwähnten Open-Source-Server – teilweise<br />
mit kommerziellen Brüdern – verfügbar.<br />
Aus den Lagern der Big Player ist bisher nichts Endgültiges zu vernehmen:<br />
Man munkelt über eine neue Version von Oracles Web-<br />
4<br />
logic in diesem Jahr, weiß aber nicht Genaues. Für SAP scheint<br />
Java EE 6 kein Thema zu sein. IBM hat immerhin eine Beta-Version<br />
des WebSphere Application Server freigegeben.<br />
Die Plattform Java EE hat mit der aktuellen Version 6 die sehr<br />
gute Chance, in der Vergangenheit aufgrund der zu hohen Komplexität<br />
verlorenen Boden wieder gut zu machen. Java EE macht<br />
wieder Spaß, ist wieder cool. Der einzelne Entwickler hat nicht<br />
mehr das Gefühl, seine Ressourcen für eine Legacy-Technologie<br />
zu verschwenden, sondern nutzt eine (wieder) zukunftsfähig gewordene<br />
Technologie. Um diese Chance zu nutzen ist es äußerst<br />
wichtig, neben den erwähnten Open-Source-Systemen auch aktuelle<br />
Versionen der großen kommerziellen Server zur Verfügung<br />
zu haben. Denn: Was hilft dem Entwickler ein noch so schöner<br />
GlassFish, wenn sein Arbeitgeber firmenweit auf IBM-Produkte<br />
setzt? <br />
Dirk Weil [ dirk.weil@gedoplan.de ]<br />
Geschäftsführer GEDOPLAN GmbH, darüber hinaus ist er Autor in Fachmagazinen,<br />
hält Vorträge und leitet Seminare und Workshops aus einem eigenen Java-Curriculum.
WebLogic: Oracles strategische Middleware-<br />
Plattform<br />
Durch die Übernahme von BEA Systems, Inc. im <strong>Frühjahr</strong> 2008 sicherte sich Oracle einen der führenden<br />
kommerziellen Application Server. Mit der Akquise von Sun Microsystems Anfang 2010 hat Oracle auch<br />
die Basistechnologie Java übernommen und ist für die Java EE Spezifikation sowie den Java Community<br />
Process verantwortlich. Was bedeutet dies für die Weiterentwicklung des Oracle WebLogic Servers?<br />
Von Klaus-Peter Lisson<br />
Eine berechtigte Hoffnung wäre, dass durch diese Konzentration<br />
von Technologien in einem Unternehmen der WebLogic Server<br />
zeitnah die neuesten Spezifikationen erfüllt. Um die Spannung<br />
nicht ins Unerträgliche zu steigern: Zum aktuellen Zeitpunkt gibt<br />
es von Oracle keine verbindlichen Aussagen, wann eine Java EE 6<br />
zertifizierte Version des WebLogic Servers auf den Markt kommen<br />
wird. Ein entsprechendes Release (WebLogic 11 R2, eher WebLogic<br />
12) ungefähr Mitte <strong>2011</strong> ist wahrscheinlich – allein, um der<br />
Konkurrenz wie dem bereits erhältlichen JBoss 6 (wenn auch nur<br />
mit Web-Profil) oder dem in Entwicklung befindlichen WebSphere<br />
8 nicht zu viel Vorsprung zu lassen.<br />
Die Schweigsamkeit von Oracle bezüglich eines Releasetermins<br />
kommt nicht von ungefähr – für den quelloffenen GlassFish<br />
(ebenfalls im Oracle Portfolio) findet sich im Web eine Roadmap<br />
über die weitere, wenn auch grobe, Releaseplanung [1]. Für den<br />
kommerziellen WebLogic Server, der als dedizierte Basis für unternehmenskritische<br />
IT-Projekte vermarktet wird, kann und will<br />
Oracle aufgrund von Rechtssicherheit keine Schätzungen abgeben.<br />
Hier gilt Oracles Leitlinie, zu solchen Produkten nur dann mit<br />
einer Ankündigung in den Markt zu gehen, wenn die Produktplanung<br />
gefestigt und ein Release zu den genannten Terminen auch<br />
garantiert werden kann.<br />
Aber auch wenn ein Java EE 6-zertifizierter WebLogic wünschenswert<br />
ist: das aktuelle Release (10.3.4) ist eine ebenso exzellente<br />
Basis für Unternehmensanwendungen. Durch zukünftige<br />
Patches und Zwischenversionen sollen neue Versionen der Java EE<br />
APIs nach ihrer Implementierung im WLS zeitnah zur Verfügung<br />
stehen.<br />
Stand der Dinge heute<br />
Unter [2] kann eine voll funktionsfähige Version des WebLogic Servers<br />
heruntergeladen werden, wobei neben angepassten Varianten<br />
für Windows und Linux auch ein generischer Installer (nur ein JDK<br />
wird benötigt) verfügbar ist. Da der WebLogic Server in Java programmiert<br />
ist, reicht zum Betrieb eine vorhandene, kompatible Java-<br />
Installation. Bei den plattformspezifischen Installern sind passende<br />
JDK/JRockit-Versionen mit enthalten; darüber hinaus werden bei<br />
ihnen betriebssystem¬spezifische „Performance-Packs“ installiert,<br />
mit denen u.a. durch natives Thread- und I/O-Handling deutliche<br />
Performance-Steigerungen im Server ermöglicht werden.<br />
Tabelle 1 zeigt den – etwas unfairen – Vergleich an unterstützten<br />
APIs im WebLogic Server 10 zur aktuellen Java EE 6. Viele der<br />
Programmierschnittstellen befinden sich in einer evolutionären Phase,<br />
so dass – wenn überhaupt – nur kleinere Versionsupdates als<br />
Unterschiede auftreten. Hingegen fehlen natürlich die zentralen,<br />
umwälzenden Veränderungen wie die Einführung von Dependency<br />
Injection komplett (die sich leider manchmal in genauso kleinen Versionsupdates<br />
wie EJB 3.1 zu 3.0 verstecken).<br />
JavaEE 6 WLS 10.3.4 / Java EE 5<br />
EJB 3.1 3.0<br />
Servlet 3.0 2.5<br />
JSP 2.2 2.1<br />
JMS 1.1 1.1<br />
JTA 1.1 1.2<br />
Connector 1.6 1.5<br />
Java EE Web Services 1.3 1.2<br />
JAX-RPC 1.1 1.1<br />
JAX-WS 2.2 2.1<br />
Web Services Metadata 2.1 2.0<br />
JSF 2.0 1.2<br />
Java Persistence 2.0 teils in EJB/JDO2.0<br />
Bean Validation 1.0 -<br />
Interceptors 1.1 -<br />
CDI 1.0 -<br />
Tabelle 1 – Unterstützte Java EE APIs<br />
Alleinstellungsmerkmale Administration, Clustering<br />
und Monitoring<br />
Den WebLogic-Server zeichnete schon seit jeher seine durchdachte,<br />
bequeme Administration aus. Sämtliche Ressourcen, Parameter und<br />
Deployments im Server sind in einer JSF-basierten Weboberfläche<br />
konfigurierbar (siehe Abb. 1). Für nicht maus-affine Administratoren<br />
steht aber auch eine jython-basierte Scripting-Umgebung zur Verfügung,<br />
die via JMX Zugriff auf alle Aspekte einer WebLogic-Domäne<br />
hat. Insbesondere das Aufsetzen größerer Cluster mit einer Vielzahl<br />
von homogen konfigurierten Servern lässt sich hierrüber hervorragend<br />
automatisieren. Zusätzlichen Nutzen gewinnt man dadurch,<br />
dass solche Admin-Skripte anschaulich die Deltas der eigenen Konfiguration<br />
gegenüber einer Standardkonfiguration dokumentieren. <br />
5
Neben der komfortablen Administration zeichnet sich der Web-<br />
Logic Server durch weitreichende Cluster-Features aus. Generell<br />
gilt, dass Standard-Java-EE-Anwendungen im WebLogic ohne<br />
großes Zutun direkt clusterfähig sind und per Lastverteilung von<br />
weiteren Clusterknoten profitieren. Natürlich sind (mit minimalem<br />
Aufwand) auch diverse Strategien für Hochverfügbarkeit<br />
oder automatische Ausfallsicherung konfigurierbar. Durch Utilities<br />
wie den WebLogic NodeManager bleiben dabei selbst größere<br />
Clusterarchitekturen handhabbar: per zentraler Admin-Oberfläche<br />
können einzelne Server, Servergruppen oder auch komplette<br />
Cluster gesteuert werden; zusätzlich kann durch kontinuierliches<br />
Health-Monitoring der NodeManager auch ausgefallene/instabile<br />
Server kontrolliert herunterfahren und – so gewünscht – neu<br />
durchstarten.<br />
Bei Betrieb eines Application Servers interessieren neben einer<br />
einfachen Administration aber auch die „inneren Werte“ – diese<br />
reichen von einfachen Laufzeitdaten wie dem aktuellen Speicherverbrauch,<br />
der Anzahl Request pro Sekunde oder der Anzahl<br />
offener Sessions bis zu detaillierteren Debugdaten wie den einzelnen,<br />
auf einer Datasource ausgeführten SQL-Statements oder<br />
dem konkreten Pfad eines Clientrequests durch die verschiedenen<br />
Servlet-/EJB-Schichten im Application Server. Mit dem WebLogic<br />
Diagnostic Framework (WLDF) unterstützt Oracle das Sammeln,<br />
Archivieren und Analysieren solcher Informationen. Der aktuell<br />
geltende Debug-Level als auch die vollständige WLDF-Konfigurationen<br />
(welche Daten werden wann wie und wie oft erfasst und<br />
archiviert) lassen sich zur Laufzeit des WebLogic Servers ändern,<br />
so dass z. B. bei Auftreten eines Produktionsproblems ohne Neustart<br />
des Servers weiterführende Daten zur Analyse gesammelt<br />
werden können.<br />
Ausblick auf Oracles WebLogic-Strategie<br />
Bedingt durch die zentrale Rolle der Java EE Spezifikation war es für<br />
Application Server Hersteller schon immer schwierig, sich auf funktionaler<br />
Ebene von der Konkurrenz abzugrenzen. Alleinstellungsmerkmale<br />
sind immer primär Performance, Clusterfähigkeiten und<br />
Administrationsmöglichkeiten der jeweiligen Server gewesen. Reine<br />
Performance-Benchmarks wie jAppServer von spec.org haben dabei<br />
in den letzten Jahren an Bedeutung verloren – vielmehr steht oft<br />
die Integration der Middleware in zentrale Monitoring-Lösungen auf<br />
Unternehmensebene im Vordergrund.<br />
6<br />
Durch die Übernahme BEAs durch Oracle wird dieser Prozess beschleunigt:<br />
Tools wie der Enterprise Manager binden den WebLogic<br />
enger in Oracles Business-Software-Portfolio ein. Natürlich soll dies<br />
eine stärkere Bindung an Oracle als Hersteller fördern. Die Oracle-<br />
Landschaft als „Habitat“ für den WebLogic Server hat jedoch weitere<br />
Vorteile: durch die z. B. ebenfalls akquirierte Firma Tangosol ist deren<br />
Coherence Cache als In-Memory Data Grid verfügbar – mit dem Vorteil,<br />
dass eine solche „best of breed“-Lösung jetzt standardmäßig zusammen<br />
mit dem WebLogic ausgeliefert und dort somit ein (bislang<br />
nicht vorhandener) clusterweiter Cache verfügbar wird.<br />
Mit GlassFish und WebLogic unter einem Dach – wie sieht da Oracles<br />
Strategie im Application Server Umfeld aus? Der WebLogic Server<br />
wird als das strategische Produkt für den unternehmensweiten Einsatz<br />
vermarktet, der GlassFish hingegen als Referenz-Implementierung<br />
der Java EE und als mögliche „Insel-Lösung“ für einzelne Abteilungen<br />
in einem Unternehmen. Die strategische Bedeutung des<br />
WebLogic für Oracle ist auch daran erkennbar, dass er die technologische<br />
Basis für weitere Enterprise-Software wie Oracle Portal/Web-<br />
Center oder Oracle SOA Suite darstellt (siehe Abb. 2). Insofern darf<br />
man von Oracle auf kommende Neuerungen im WebLogic-Umfeld<br />
gespannt sein. <br />
Abbildung 2: Oracle Portfolio Stack<br />
Abbildung 1: AdminConsole<br />
URLs:<br />
[1] GlassFish Roadmap:<br />
http://glassfish.java.net/roadmap<br />
[2] WebLogic Download:<br />
http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html<br />
Klaus-Peter Lisson [ klaus-peter.lisson@gedoplan.de ]<br />
Seniorberater bei der GEDOPLAN GmbH mit mehr als 10 Jahren Erfahrung in der<br />
professionellen Softwareentwicklung. Seine Schwerpunkte sind Anforderungsanalyse,<br />
Architektur und Realisierung von Java-EE-Anwendungen.
JBoss 6.0.0: Der neue Chef mit dem roten Hut<br />
Quasi auf den letzten Drücker hat JBoss/Red Hat den Applikationsserver JBoss 6.0.0 fertiggestellt. Seit<br />
dem 28.12.2010 ist der JBoss 6.0.0 in der Final Version veröffentlicht. Damit ist der kleine, aber feine<br />
Kreis der Java-EE-6-Implementierungen um einen wichtigen Kandidaten gewachsen. Auf jeden Fall<br />
ein Grund, sich den neuen JBoss einmal näher anzusehen.<br />
Von Klaus Bertelt<br />
Mit dem neuen JBoss werden die Java-EE-6-Web-Profile-Anforderungen<br />
erstmals nativ unterstützt. Zwar war die Nutzung einzelner Komponenten<br />
schon auf den 5.x-Versionen möglich, setzte aber einiges an<br />
Bastelei und Geduld voraus. Mit der neuen Version gehört dies endlich<br />
der Vergangenheit an. Folgende Anforderungen wurden umgesetzt:<br />
Servlet 3.0<br />
JavaServer Pages (JSP) 2.2<br />
Expression Language (EL) 2.2<br />
Debugging Support for Other Languages (JSR-45) 1.0<br />
Standard Tag Library for JavaServer Pages (JSTL) 1.2<br />
JavaServer Faces (JSF) 2.0<br />
Common Annotations for the Java Platform (JSR-250) 1.1<br />
Enterprise JavaBeans (EJB) 3.1 Lite<br />
Java Transaction API (JTA) 1.1<br />
Java Persistence API (JPA) 2.0<br />
Bean Validation 1.0<br />
Managed Beans 1.0<br />
Interceptors 1.1<br />
Contexts and Dependency Injection for the Java EE Platform 1.0<br />
Dependency Injection for Java 1.0<br />
Quelle: Java Platform, Enterprise Edition 6(Java EE 6) Web Profile Specification<br />
Da eine ausführliche Behandlung diesen Artikel um ein Vielfaches<br />
sprengen würde, sollen nachfolgend nur einige Teilbereiche mit den<br />
wichtigsten Neuerungen angesprochen werden.<br />
Neuigkeiten im Detail<br />
EJB 3.1<br />
Um die Unterstützung von EJB 3.1 zu gewährleisten wurde nicht<br />
etwa wie gefordert, „nur“ die Lite Version der Enterprise Java Beans<br />
implementiert, sondern ein kompletter Container mit allen Features.<br />
Wichtige Bestandteile dieser Komponente sind zum Beispiel:<br />
Singleton: Mit Hilfe der Annotation @Singleton kann eine EJB<br />
programmiert werden, von der zur Laufzeit nur eine Instanz erzeugt<br />
wird. Dies war bis zur Version 3.0 nur mit Umwegen und<br />
Fallstricken über serverspezifische Deskriptorparameter möglich<br />
oder durch Umgehung des Standards und Nutzung des Java-SE-<br />
Singleton-Patterns. Eine Singleton Bean entspricht grob einer<br />
Stateful Bean, allerdings mit dem großen, konzeptionellen Unterschied,<br />
dass Singletons von mehreren User-Threads konkurrierend<br />
aufgerufen werden können. Die Serialisierung der Zugriffe übernimmt<br />
per Default der Container.<br />
Scheduler: Neidische Blicke auf Uralt-Werkzeuge wie cron sind<br />
seit EJB 3.1 nicht mehr nötig, denn der Timer-Service wurde um<br />
sehr umfangreiche Scheduling-Möglichkeiten erweitert. Eine Bean<br />
kann nun ein oder mehrere Methoden enthalten, die mit @Schedule<br />
annotiert sind. Über die Parameter der Annotation können<br />
die Aufruftermine sehr flexibel spezifiziert werden. <br />
7
JSF 2.0<br />
Nicht nur im Bereich der EJB 3.1 hat JBoss einiges an Boden gutgemacht.<br />
Mit dem neuen Applikationsserver wird JSF 2.0 unterstützt.<br />
Um einen großen Pool an Features abzudecken wurden mit Mojarra<br />
1.2.15, Mojarra 2.0.3 und Apache MyFaces 2.0.1 gleich mehrere Implementierungen<br />
integriert. Eines der wichtigsten Features stellt hier<br />
wohl die Umsetzung der Managed Beans dar:<br />
Managed Beans dienen als Gateway zwischen der JSF-Oberfläche<br />
und der Verarbeitung der Daten. Sie bieten für alle Properties Zugriffsmethoden<br />
an, die zur Übernahme von Eingabewerten und zur<br />
Bereitstellung von Anzeigewerten genutzt werden. Ebenso können<br />
Action- und Event-Methoden vorhanden sein. Seit JSF 2.0 ist<br />
die Auszeichnung der Managed Beans mittels der Annotation @<br />
javax.faces.bean.ManagedBean möglich. Über den Parameter<br />
name ist die Angabe eines Namens möglich, mit dem die Bean<br />
u. a. aus den Seiten referenziert werden kann. Als Default gilt der<br />
einfache Klassenname mit kleinem Anfangsbuchstaben. In den<br />
Vorversionen mussten Managed Beans in der Konfigurationsdatei<br />
faces-config.xml aufgeführt werden. Dies ist in JSF 2.0 weiterhin<br />
möglich, wenn keine Annotationen verwendet werden können<br />
oder sollen.<br />
JPA 2.0<br />
Da aller guten Dinge ja bekanntlich drei sind, soll nachfolgend noch<br />
ein weiteres Highlight des JBoss kurz angerissen werden: JPA 2.0, das<br />
in der aktuellen JBoss-Version mithilfe von Hibernate 3.6.0 realisiert<br />
wird:<br />
Collections: Seit JPA 2.0 sind Attribute möglich, die vom Typ<br />
java.util.Collection oder einem davon abgeleiteter Typ sind<br />
und deren einzelne Elemente einen einfachen Typ haben oder einbettbar<br />
sind. Das Attribut (Feld oder Property) muss mit @ElementCollection<br />
versehen werden. Damit wird erreicht, dass die<br />
Collection mit Hilfe einer zweiten Tabelle realisiert wird.<br />
Relationen als Id-Attribut: Im Zusammenhang mit mehrteiligen<br />
Schlüsseln kommt es häufig vor, dass ein Teil des Schlüssels eine<br />
n:1-Relation zu einer anderen Entity modelliert. Seit JPA 2.0 ist<br />
es erlaubt, Id-Felder zu verwenden, die zudem mit @ManyToOne<br />
8<br />
annotiert sind. Relationen im Schlüssel können auch mit eingebetteten<br />
Schlüsselklassen realisiert werden. Die Schlüsselklasse muss<br />
dann wie gewohnt mit @Embeddable ausgezeichnet sein, damit<br />
ein entsprechendes Attribut mittels @EmbeddedId in die Entity-<br />
Klasse aufgenommen werden kann. Die Relation muss in diesem<br />
Fall zusätzlich deklariert werden. Die Zuordnung zum zugehörigen<br />
Feld des Schlüssels stellt die Annotation @MapsId her.<br />
Was gibt’s sonst noch?<br />
Als wären die Implementierung des neuen Standards nicht schon<br />
Neuerungen genug, hat der neue JBoss noch mit einem weiteren<br />
Schmankerl aufzuwarten: ein neuer JMS Provider. In der neuen Version<br />
ist jetzt Hornetq 2.1.1 integriert, welches den vorherigen Provider<br />
ersetzt. Auch hier ist der Trend zur klaren, leichten Programmierung<br />
zu erkennen:<br />
In einer neuen Konfigurationsdatei *hornetq-jms.xml können Factories,<br />
Queues und Topics nun ähnlich einfach eingetragen werden, wie<br />
Beans in einen Deskriptor:<br />
…<br />
…<br />
<br />
<br />
<br />
<br />
<br />
<br />
…<br />
<br />
<br />
…<br />
<br />
<br />
<br />
<br />
<br />
Die hier eingetragenen Parameter finden Ihre Entsprechung im Code<br />
beim Lookup des JNDI-Context:<br />
…<br />
QueueConnectionFactory queueConnectionFactory =<br />
(QueueConnectionFactory)<br />
jndiContext.lookup(„TestConnectionFactory“);<br />
Queue queue<br />
= (Queue) jndiContext.lookup(„testQueue“);<br />
…<br />
Ein Blick in die Maschine<br />
Nach der theoretischen Erklärung der Neuigkeiten soll nun kurz der<br />
Server an sich betrachtet werden. Herunterladen und installieren<br />
lässt sich der Server wie in den vorangegangenen Versionen denkbar<br />
einfach. Auch beim Starten des Servers wird Bewährtes weitergeführt,<br />
das Deployment läuft ebenfalls wie in den vorherigen Versionen.<br />
Eine Sichtung der Verzeichnisstruktur lässt den erfahrenen<br />
Anwender auf den ersten Blick auch kalt: Alles beim Alten. Alles?<br />
Spätestens wenn man sich unterhalb des server-Verzeichnisses in<br />
den verschiedenen Konfigurationen befindet, werden Änderungen<br />
sichtbar:<br />
Abbildung 1: JBoss 5.1.0 Abbildung 2: JBoss 6.0.0<br />
Abbildung 3:<br />
Roadmap (Stand Februar <strong>2011</strong>)<br />
Auch ein Blick auf die Administrationskonsole unter server:8080<br />
macht schnell eines deutlich: Minimalismus ist nicht tot! Zwar lassen<br />
sich die verschiedensten Werte und Einstellungen ablesen, aber<br />
Editierfunktionen sucht man vielerorts vergeblich. Es hält sich wie<br />
mit den älteren Versionen: Entweder man leistet sich die Unterstützungstools,<br />
oder editiert auch weiterhin die verschiedenen XML-<br />
Dateien händisch.<br />
Wo soll‘s hingehen?<br />
Nach dem Server ist bekanntlich ja immer vor dem Server. Aus diesem<br />
Grund sind die Veröffentlichungstermine der neuen JBoss-Versionen<br />
auch eng miteinander verzahnt, wie Abbildung 3 zeigen soll.<br />
Eine Unterstützung der für den 28.07.<strong>2011</strong> (Stand Februar <strong>2011</strong>) geplanten<br />
Veröffentlichung von Java 7 ist vorgesehen. Hier kann man<br />
erkennen, dass sich die JBoss Inc. dieses Mal vorgenommen hat,<br />
durch die zeitige Veröffentlichung der 7.0.0 final gleich von Anfang<br />
an im Kreis der großen Applikationsserver eine wichtige Rolle zu<br />
spielen.<br />
Bleibt zu hoffen, dass bei allem Termindruck eine saubere, gut<br />
durchdachte neue Version des großen Bosses mit dem roten Hut<br />
erscheint. <br />
Links und Verweise:<br />
http://gedoplan.de/javaseminare, 01.02.<strong>2011</strong><br />
http://jboss.org/, 01.02.<strong>2011</strong><br />
http://jcp.org/aboutJava/communityprocess/final/jsr316/index.html, 01.02.<strong>2011</strong><br />
http://it-republik.de/jaxenter/artikel/JBoss-AS6-Treffen-der-sechsten-Generationen-3511.html,<br />
„Bernhard Löwenstein, Oliver Kraft“, 01.02.<strong>2011</strong><br />
Abbildungsverzeichnis:<br />
Abbildung 1: JBoss 5.1.0<br />
Abbildung 2: JBoss 6.0.0<br />
Abbildung 3: Roadmap (Stand Februar <strong>2011</strong>)<br />
Klaus Bertelt [ klaus.bertelt@gedoplan.de ]<br />
Consultant und Trainer im Bereich Java EE und agiles Projektmanagement, insbesondere<br />
Scrum.<br />
9
GlassFish 3.1: Das volle Programm Java EE 6<br />
Java EE 6 ist in aller Munde, die neuen Spezifikationen versprechen eine flexible und „lightweight“<br />
Entwicklung und ein JSR Highlight folgt auf das nächste. Zeit, einen Moment zu Atem zu kommen und<br />
sich auf die Basis zu konzentrieren, die das alles möglich machen soll. Bereits seit Dezember 2009 steht<br />
die erste 3er Version des GlassFish in der finalen Version bereit, die einen genaueren Blick rechtfertigt.<br />
Von Dominik Mathmann<br />
GlassFish in der aktuellen Version 3.1 stellt die Referenzimplementierung<br />
von Java EE 6 dar und bietet somit den vollen Umfang an<br />
Verbesserungen und neuen Features, die seit der Java EE Version 5 in<br />
den Standard eingeflossen sind. Neben den neuen Versionen von EJB<br />
(3.1), JSP (2.2), JPA (2.0) und JSF (2.0) wird somit die lange Liste von<br />
Technologien um viele weitere Punkte ergänzt, wie zum Beispiel die<br />
Unterstützung von CDI und die Möglichkeit der BeanValidation (für<br />
die komplette Liste siehe: [1]).<br />
Ein Blick durch die Administrator-Brille<br />
Wo früher aufwendige Konfigurationen und Installationsroutinen warteten,<br />
kommt die neue Version des GlassFish ganz der Philosophie entsprechend<br />
„leichtgewichtig“ daher. Ein kurzer Blick auf die Seite von<br />
Oracle lässt die Wahl zwischen der Open Source- und der Oracle-Edition,<br />
die sich im Kern lediglich im Punkt der Support-Unterstützung unterscheiden.<br />
Nach Auswahl der gewünschten Zielplattform und Download<br />
des entsprechenden Bundles ist der größte Schritt in Richtung<br />
der eigenen GlassFish-Installation bereits getan. Abhängig vom ausgewählten<br />
Bundle führt entweder ein Installationsassistent über die<br />
anfängliche Konfiguration, in der z. B. Login-Daten und Ports definiert<br />
werden können, oder obliegt es dem Entwickler selbst, entsprechende<br />
Anpassungen nach dem Entpacken des Archivs durchzuführen. Ganz<br />
nach dem Leitsatz „Configuration by Exception“ ist der Server jedoch<br />
auch ohne explizite Konfiguration startbereit und lässt sich über das<br />
mitgelieferte Commandline-Tool ([install]/bin/asadmin) mit dem Befehl<br />
„asadmin start-domain domain1“ mit der default Domain starten<br />
und über den Standard-Port „8080“ aufrufen (http://localhost:8080,<br />
weitere Default-Werte siehe: Tabelle 1, Konfiguration – Defaults).<br />
Was nicht passt wird passend gemacht<br />
Zur Konfiguration stehen dem User generell zwei unterschiedliche<br />
Varianten zur Verfügung. Zum einen dient auch das bereits verwendete<br />
asadmin-Tool zur Pflege der Einstellungen, welches über diverse<br />
Parameter per Kommandozeile zum Ziel führt. Auf der anderen<br />
Seite besteht die Möglichkeit, die komfortable Weboberfläche zur<br />
Änderungen von Parametern zu verwenden. Diese erreicht man bequem<br />
über den Browser unter Verwendung des Ports 4848 (http://<br />
localhost:4848). Unabhängig von der verwendeten Methode spiegeln<br />
sich alle Änderungen in der domain-abhängigen Konfigurationsdatei<br />
wieder ([install]/domains/[domainName]/config/domain.xml), die<br />
zwar auch direkt verändert werden kann, was aber von Seiten des<br />
Herstellers nicht empfohlen wird.<br />
10<br />
Deployment<br />
Auch beim Deployment lässt der GlassFish dem User die Wahl und ist<br />
nicht auf ein Vorgehen beschränkt. Die beiden bereits angesprochenen<br />
Methoden zur Konfiguration beinhalten ebenfalls entsprechende<br />
Funktionen zum Bereitstellen von Anwendungen (in der Admin-<br />
Console über den Menüpunkt „Applications“ oder über den asadmin<br />
Befehl „deploy“). Darüber hinaus existiert eine weitere Variante, die<br />
zwar keine Möglichkeit zur Parametrisierung des Deployvorgangs<br />
bietet, dafür jedoch durch seine Einfachheit besticht. Dazu wird das<br />
entsprechende Archiv (EAR für EE-Anwendungen oder WAR für Web<br />
Applicationen) lediglich in das so genannte Autodeploy-Verzeichnis<br />
kopiert ([install]/domains/[domainName]/autodeploy/), was den Server<br />
dazu veranlasst, die entsprechende Anwendung automatisch bereitzustellen.<br />
Eine Übersicht über die installierten Applikationen und<br />
deren Komponenten bietet erneut die Admin-Console, in der auch<br />
der Context-Pfad von Web-Anwendungen verändert oder aktive Deployment<br />
Descriptoren angezeigt werden können.<br />
Zum Test bitte!<br />
Seit der Java EE Version 6 wird dem Entwickler ein weiteres Features<br />
in die Hände gelegt, welches in Kombination mit JUnit und/<br />
oder anderen Testframeworks das alltägliche Testen erleichtert:<br />
Die standardisierte Schnittstelle für Embedded Server ist auch im<br />
GlassFish verfügbar und ermöglicht eine einfache und vor allen<br />
Dingen zeitsparende Verwendung in Testfällen. Zur Verwendung<br />
des Embedded-GlassFish stehen drei unterschiedliche Ausführungen<br />
als JAR-Dateien bereit, die in den Classpath des Projektes<br />
eingebunden werden können: GlassFish-embedded-web.jar – zum<br />
Deploy von reinen Webanwendungen, GlassFish-embedded-all.jar<br />
– zum Deploy von Anwendung jeglichen EE-Typs und GlassFishembedded-static-shell.jar<br />
– zum Standalone-Deploy ohne vorhandene<br />
GlassFish Installation. Bevor der Server nun in Testfällen<br />
verwendet werden kann, bedarf es einiger Konfigurationen, die<br />
im Fall des GlassFish zur Laufzeit (über den so genannten CommandRunner)<br />
oder aber über eine eigene Domain-XML durchgeführt<br />
werden können. Die zweite Variante hat dabei den Charme,<br />
dass die vorhandene Domain-XML des Entwicklungs- oder Test-<br />
Systems verwendet werde kann. Dabei hat man die Möglichkeit,<br />
beim Start des Servers den Installationspfad auf eine lokale<br />
GlassFish-Installation verweisen zu lassen. Wesentlich flexibler<br />
ist hierbei jedoch, eine entsprechende Ordner-Struktur direkt im<br />
Projekt abzubilden, die abgesehen von der domain.xml im Ordner
Abbildung 2: Test-Quelltext<br />
der Konfiguration (s. Abbildung 1, Embedded-Projektstruktur) leer<br />
sein kann. Das bringt auf der einen Seite den großen Vorteil, dass<br />
dieses Abbild einer GlassFishinstallation nun projekt-abhängig<br />
angepasst werden kann. Hier bieten sich neben Veränderungen<br />
an den zu verwendeten Ports (um eine Kollision mit einer lokal<br />
laufenden Entwicklungsmaschine zu vermeiden) besonders die<br />
verwendeten DataSources an, um z. B. anstatt einer installierten<br />
MySQL in Testfällen eine In-Memory-DB zu verwenden. Auf der<br />
anderen Seite fügt sich der Embedded-Server mit einer im Projekt<br />
befindlichen Konfiguration nahtlos in Continous Integration<br />
Systeme wie z. B. Hudson ein, die somit keine eigene Installation<br />
bereitstellen müssen. Bei der Implementierung der Tests bietet es<br />
sich nun an, z. B. im Falle von JUnit mit einer so genannten Test-<br />
Suite zu arbeiten, die den Start und Stopp des Servers regelt und<br />
die einzelnen Testfälle aufruft. Hierbei genügen einige Zeilen Code,<br />
um den Server zu starten und entsprechende Testfälle auszuführen<br />
(s. Abbildung 2, Test-Quelltext).<br />
Fazit<br />
Der GlassFish 3 wartet mit allen Neuerung auf, die Java EE 6 zu bieten<br />
hat, und das derzeit als einziger Application Server auf dem Markt.<br />
Wenngleich der JBoss laut Ankündigung bald ebenfalls im vollen<br />
Umfang folgen soll, braucht der GlassFish sich nicht zu verstecken<br />
und besticht vor allem durch die intuitive Weboberfläche und die<br />
Vielzahl an weiteren Möglichkeiten zur Konfiguration und des Deployments.<br />
Abzuwarten bleibt, ob der Standard in Sachen Embedded<br />
Server API das hält was er verspricht und die Entwicklung von applicationserver-unabhängigen<br />
Testfällen ermöglicht. <br />
Ports<br />
Admin Console 4848<br />
HTTP 8080<br />
HTTP 8181<br />
JMX 8686<br />
IIOP (+SSL/mutual authentication)<br />
Domain-Daten<br />
3700 (3820/3920)<br />
Domain Name domain1<br />
Master Passwort changeit<br />
Administrator Passwort<br />
Pfade<br />
admin<br />
asadmin-Commandline-Tool [install]/bin<br />
Domain-Konfigurationsdatei<br />
(domain.xml)<br />
[install]/domains/[domain]/config<br />
Domain-Autodeploy<br />
[install]/domains/[domain]/autodeploy<br />
Log-Files [install]/domains/[domain]/logs<br />
Upgrade Tool [install]/bin<br />
Update Tool + pkg Command [install-parent]/bin<br />
Tabelle 1: Konfiguration – Defaults<br />
Abbildung 1: Embedded-Projektstruktur<br />
Links<br />
#1 http://docs.sun.com/app/docs/doc/821-1759 (Kapitel „Java EE Standards“ )<br />
Dominik Mathmann [ dominik.mathmann@gedoplan.de ]<br />
Entwickler und Berater bei <strong>Gedoplan</strong> im Bereich Java. Tätigkeitsschwerpunkte sind<br />
Java basierte Webanwendungen und Application Server.<br />
11
GEDOPLAN<br />
Unternehmensberatung und<br />
EDV-Organisation GmbH<br />
Stieghorster Straße 60<br />
33605 Bielefeld<br />
Fon: 0521 2 08 89 10<br />
Fax: 0521 2 08 89 45<br />
E-Mail: info@gedoplan.de<br />
Herausgeber: GEDOPLAN Unternehmensberatung und EDV-Organisation GmbH | Stieghorster Straße 60 | 33605 Bielefeld<br />
Verantwortlich: Dipl.-Inform. Dirk Weil | Redaktionsleitung: Ulrich Hake | Fon: 0521 2088910 | E-Mail: info@gedoplan.de<br />
Produktion: networker Medienfabrik GmbH | Nachdruck, auch auszugsweise, nur nach Rücksprache mit der Redaktion.<br />
GEDOPLAN ist seit über 30 Jahren spezialisiert auf die Entwicklung<br />
von IT-Systemen. Unsere Experten haben langjährige Erfahrung in<br />
der Analyse, Konzeption und Realisierung von Unternehmenssoftware.<br />
Individuallösungen realisieren wir auf Basis objektorientierter Techniken.<br />
Die leistungsfähige und umfangreiche Plattform Java EE bildet<br />
dafür schon seit über 10 Jahren einen unserer Schwerpunkte. Es ist<br />
unser Anspruch, gut strukturierte und wartbare Anwendungen zu<br />
entwickeln. Mit modernen Entwicklungsumgebungen und entwicklungsbegleitenden,<br />
automatisierten Tests stellen wir eine hohe Softwarequalität<br />
sicher.<br />
Im Bereich der Standardsoftware unterstützen wir Sie bei der Einführung<br />
und Anpassung von SAP®-Lösungen, insbesondere in Fragen<br />
der Basis-Administration und des Personalmanagements. Anpassungen<br />
oder Erweiterungen können wir mit ABAP und Java auf Basis<br />
von SAP® NetWeaver durchführen.<br />
Wir entwickeln IT-Systeme als Komplettpakete, unterstützen unsere<br />
Kunden aber auch vor Ort. Unsere Experten geben ihr Wissen gerne<br />
weiter – in Form von projektbegleitenden Coachings oder Seminaren<br />
bei unseren Schulungspartnern.<br />
www.gedoplan.de