Ausgabe Frühjahr 2011 - Gedoplan

Das Kundenmagazin 

In dieser Ausgabe: 

Java-EE-6-Server im 

Überblick 

WebLogic: Oracles 

strategische Middleware- 

Plattform 

GlassFish 3.1: Das volle 

Programm Java EE 6 

JBoss 6.0.0: Der neue 

Chef mit dem roten Hut 

aktuell 

Ausgabe Frühjahr 2011 

www.gedoplan.de

EDITORIAL 

Liebe Leserin, lieber Leser, 

Middleware wird in vielen Unternehmen eingesetzt, 

aber sie wird weder richtig wahrgenommen 

noch ist sie ein zentrales Thema aktueller Diskussionen. 

Das heißt aber nicht, dass Applikationsserver 

sich zum einem Randthema entwickelt haben. 

Diese Situation verdeutlicht lediglich, dass 

Middleware sich mittlerweile etabliert hat. 

Warum haben wir uns dann aber genau dieses 

Thema für die zweite Ausgabe unserer Kundenzeitschrift 

gewählt? In der vorherigen Ausgabe 

haben wir das neue Release 6 der Java EE vorgestellt 

und Fortschritte sowie Vereinfachungen 

hinsichtlich der Softwareentwicklung deutlich 

gemacht. Daher lohnt es sich, mal genauer hinzuschauen 

und die Frage zu beantworten, welche der 

bekannten Applikationsserver dieses neue Release 

bereits implementiert haben und welche der neuen 

Möglichkeiten von ihnen angeboten werden. 

Wie immer bietet unser erster Artikel Ihnen die 

Möglichkeit, sich einen Überblick über das Thema 

zu verschaffen. Dirk Weil zeigt in seinem Artikel, 

dass noch einiger Nachholbedarf vor allem bei den 

etablierten, kommerziellen Servern besteht. Die 

folgenden Beiträge beschäftigen sich dann mit drei 

bekannten Applikationsservern. Klaus-Peter Lisson 

wagt einen Ausblick auf die Zukunft des Weblogic 

Servers aus dem Hause Oracle, Dominik Mathmann 

kennzeichnet Vor- und Nachteile der Referenzimplemetierung 

GlassFish und schließlich beschäftigt 

sich Klaus Bertelt mit dem neuesten Mitglied der 

Java-EE-6-Server-Familie: Red Hat JBoss. 

Eine spannende und lohnende Lektüre 

wünscht Ihnen Ihr 

Ulrich Hake | ulrich.hake@gedoplan.de 

2 

Termine 

Expertenkreis Java 

Thema: Monitoring und Profiling von Java-Anwendungen 

Ort: IPS Hannover, Bischofsholer Damm 89, 30173 Hannover 

Termin: Donnerstag, 20.01.2011 | 18:00-20:00 Uhr 

Referent: Rolf Kulemann, NEO Business Partners GmbH 

Thema: Java in the Cloud – am Beispiel der Google App Engine 

Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld 


Referent: Malte Jäger, brand´s mill GmbH 

Thema: Agiles BPM in der Praxis – mit BPMN 2.0 und Activiti 

zur lauffähigen Software 

Ort: IPS Hannover, Bischofsholer Damm 89, 30173 Hannover 


Referent: Bernd Rücker, camunda 

Thema: Monitoring und Profiling von Java-Anwendungen 

Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld 


Referent: Klaus-Peter Lisson, GEDOPLAN GmbH 

JAX 2011 

Thema: Vergleich von JPA-Providern 

Ort: JAX 2011, Mainz 

Termin: Dienstag, 03.05.2011 | 16:45-17:45 Uhr 

Referent: Dirk Weil, GEDOPLAN GmbH, Bielefeld 

Thema: Optimierung von JPA-Anwendungen 

Ort: JAX 2011, Mainz 

Termin: Mittwoch, 04.05.2011 | 8:30-9:45 Uhr, 

Referent: Dirk Weil, GEDOPLAN GmbH, Bielefeld

Java-EE-6-Server im Überblick 

In der letzten Ausgabe von GEDOPLAN aktuell haben sich gleich mehrere Artikel mit einem unserer 

Schwerpunktthemen beschäftigt: Java EE 6. Darin wurde auch deutlich, dass die Revolution der Plattform 

weg von unnötigem technischen Ballast hin zu einfacher und leichter Softwareentwicklung, die 

bereits mit der Version 5 begann, mit der aktuellen Version nochmals Fahrt aufgenommen hat. Gut ein 

Jahr nach dem offiziellen Release stellt sich nun die Frage nach den Trägersystemen: Welche Server 

sind heute in der Lage, Java-EE-6-Anwendungen zu tragen? 

Von Dirk Weil 

Trotz der relativ langen Wartezeit ist die Zahl verfügbarer Java- 

EE-6-Implementierungen recht überschaubar. Nur die Referenzimplementierung 

Oracle GlassFish bietet derzeit den vollen 

Umfang der Spezifikation – das sog. Full Profile – an. Für das eingeschränkte 

Web Profile gibt es nur einige wenige Anbieter, u. a. 

JBoss, SIwpas und Resin. Gründe für das zögerliche Erscheinen 

der Server könnten in der Einführung der erwähnten Profile liegen 

oder in aufwändigen Änderungen der Serverbasis, die bspw. durch 

die Integration von CDI erforderlich werden. 

Profilangelegenheiten 

Java-EE-Server brachten in der Vergangenheit immer den kompletten 

Umfang der Spezifikation mit, was für einen Großteil der 

Anwendungen nicht gebraucht wurde. So kommen Webanwendungen 

mit einem guten Drittel der in der Java EE 6 vereinigten 

Teilspezifikationen aus. Diese Erkenntnis nehmen die neu eingeführten 

Profile auf. Sie reduzieren den Gesamtumfang auf ein 

zielorientiertes Subset. 

Derzeit ist neben dem 

Full Profile nur ein eingeschränktes 

Profil definiert 

worden, das Web 

Profile. Die Grafik zeigt, 

welche Teilspezifikationen 

in den Profilen enthalten 

sind. 

Die vom Grundsatz her richtige Strategie, die Java EE durch die 

Einführung von Profilen überschaubarer und handhabbarer zu 

machen, kommt in erster Linie den Serveranbietern entgegen: Sie 

können dadurch einen standardkonformen Server anbieten, ohne 

alle Teile der Gesamtspezifikation implementieren zu müssen. 

So erklärt sich sicher, dass es deutlich mehr Implementierungen 

des Web-Profils gibt, zumal der überwiegende Teil der Enterprise-Anwendungen 

mit diesem Subset auskommt. Aus Sicht der 

Anwendungsentwicklung sind die Profile allerdings kritischer 

zu betrachten: War der Entwickler früher durch den immer vorhandenen 

vollen Umfang verwöhnt, muss er sich heute auf ein 

Zielprofil einschränken. Die Entscheidung für ein Profil lässt sich 

während der Erstentwicklung einer Anwendung sicherlich lange 

verzögern. Spätestens ab dem ersten Release ist man aber nicht 

mehr so flexibel. 

CDI – das neue Getriebe im System 

Wenn Java EE 5/6 eine Revolution zugunsten der Einfachheit der 

Softwareentwicklung ist, so stellt CDI (Contexts and Dependency 

Injection for the Java EE platform) zweifellos eine Revolution im 

Inneren eines Servers dar. Die Geschichte um CDI ist durchaus bewegt 

und spiegelt wider, wie durch Einflüsse u. a. konkurrierender 

Frameworks Standards entwickelt werden und reifen. 

Eine der Aufgaben eines Applikationsservers ist es, den Lebenszyklus 

serverseitiger Programmkomponenten zu steuern und die 

Instanzen dieser Komponenten miteinander zu verknüpfen. Dies 

geschah bis zur Version 1.4 der EE-Plattform über sog. Container- 

Contract-Methoden, d. h. es mussten technische Methoden zum 

Aufruf der entsprechenden Serverfunktionalität in die Komponenten 

eingebaut bzw. von dort aufgerufen werden. Dadurch ergab 

sich eine starke Bindung der Komponenten an den Container, 

was eine Verwendung außerhalb des Servers – z. B. für Testzwecke 

– unmöglich machte. 

Abhilfe schafft hier die Umkehrung der Zuständigkeiten: Die Komponenten 

nutzen nicht explizit den Container, sonder der Container 

liefert ihnen die benötigten Dinge. Über Annotationen oder 

hilfsweise XML-Deskriptoren lässt sich diese Inversion of Control 

(IoC) mit Dependency Injection (DI) kombinieren. Hierbei werden 

die vom Container bereitgestellten Werte bspw. in Instanzvariablen 

den Komponenten injiziert. Die Kenntnis der Komponenten 

über den Container oder andere Komponenten wird durch diese 

Vorgehensweise minimiert, wodurch ein Ablauf in einer anderen 

Umgebung und im Zusammenspiel mit anderen Komponenten- 

bspw. in einer Testumgebung mit Mock-Objekten – problemlos 

möglich wird. 

Ein Vorreiter im Bereich IoC und DI war sicher das Spring-Framework, 

dessen Core-Anteil i. W. einen Dependecy-Injection-Container 

darstellt. Google Guice stellt ebenfalls ein DI-Framework 

zur Verfügung. Hier hat auch der JSR 330 – Dependency Injection 

for Java – seinen Ursprung. Ähnliche Eigenschaften fanden 

sich in JBoss Seam, allerdings mit dem zusätzlichen Fokus auf 

der Steuerung des Lebenzyklus der Komponenten. Hieraus wurde 

der JSR 299 – zunächst unter dem Namen Web Beans, später 

in CDI umbenannt – abgeleitet. Die Diskussion, welcher Ansatz 

der bessere sei, wurde einige Zeit lang recht religiös geführt. 

3

Glücklicherweise wurden die beiden JSRs zusammengeführt, so 

dass CDI die Annotationen des JSR 330 (aus dem Paket javax. 

inject) verwendet. 

CDI ist ein äußerst leistungsfähiger Teil der Java EE 6, der darüber 

hinaus auch recht einfach zu verwenden ist. Unglücklicherweise 

existieren in der EE-Welt historisch bedingt weitere DI-Möglichkeiten, 

die sich weitgehend mit CDI überschneiden. So finden sich 

in JSR 250 (Common Annotations for the Java Platform), JPA, JSF 

und EJB diverse spezialisierte Injektionsmöglichkeiten, die teilweise 

schon heute durch CDI abgelöst werden können. Hier ist 

ein weiteres Entschlacken des Standards – vielleicht im Zuge der 

Entwicklung der Java EE 7 – wünschenswert. 

Ja, wo bleiben sie denn? 

Trotz der relativ großen Umbauten, die die Version 6 des 

EE-Standards auslöst, stellt sich die Frage, wo die entsprechenden 

Implementierungen bleiben. Es sind schließlich schon knapp 

1¼ Jahre seit dem Release der Java EE 6 vergangen und dennoch 

sind bislang nur die oben erwähnten Open-Source-Server – teilweise 

mit kommerziellen Brüdern – verfügbar. 

Aus den Lagern der Big Player ist bisher nichts Endgültiges zu vernehmen: 

Man munkelt über eine neue Version von Oracles Web- 

4 

logic in diesem Jahr, weiß aber nicht Genaues. Für SAP scheint 

Java EE 6 kein Thema zu sein. IBM hat immerhin eine Beta-Version 

des WebSphere Application Server freigegeben. 

Die Plattform Java EE hat mit der aktuellen Version 6 die sehr 

gute Chance, in der Vergangenheit aufgrund der zu hohen Komplexität 

verlorenen Boden wieder gut zu machen. Java EE macht 

wieder Spaß, ist wieder cool. Der einzelne Entwickler hat nicht 

mehr das Gefühl, seine Ressourcen für eine Legacy-Technologie 

zu verschwenden, sondern nutzt eine (wieder) zukunftsfähig gewordene 

Technologie. Um diese Chance zu nutzen ist es äußerst 

wichtig, neben den erwähnten Open-Source-Systemen auch aktuelle 

Versionen der großen kommerziellen Server zur Verfügung 

zu haben. Denn: Was hilft dem Entwickler ein noch so schöner 

GlassFish, wenn sein Arbeitgeber firmenweit auf IBM-Produkte 

setzt? 

Dirk Weil [ dirk.weil@gedoplan.de ] 

Geschäftsführer GEDOPLAN GmbH, darüber hinaus ist er Autor in Fachmagazinen, 

hält Vorträge und leitet Seminare und Workshops aus einem eigenen Java-Curriculum.

WebLogic: Oracles strategische Middleware- 

Plattform 

Durch die Übernahme von BEA Systems, Inc. im Frühjahr 2008 sicherte sich Oracle einen der führenden 

kommerziellen Application Server. Mit der Akquise von Sun Microsystems Anfang 2010 hat Oracle auch 

die Basistechnologie Java übernommen und ist für die Java EE Spezifikation sowie den Java Community 

Process verantwortlich. Was bedeutet dies für die Weiterentwicklung des Oracle WebLogic Servers? 

Von Klaus-Peter Lisson 

Eine berechtigte Hoffnung wäre, dass durch diese Konzentration 

von Technologien in einem Unternehmen der WebLogic Server 

zeitnah die neuesten Spezifikationen erfüllt. Um die Spannung 

nicht ins Unerträgliche zu steigern: Zum aktuellen Zeitpunkt gibt 

es von Oracle keine verbindlichen Aussagen, wann eine Java EE 6 

zertifizierte Version des WebLogic Servers auf den Markt kommen 

wird. Ein entsprechendes Release (WebLogic 11 R2, eher WebLogic 

12) ungefähr Mitte 2011 ist wahrscheinlich – allein, um der 

Konkurrenz wie dem bereits erhältlichen JBoss 6 (wenn auch nur 

mit Web-Profil) oder dem in Entwicklung befindlichen WebSphere 

8 nicht zu viel Vorsprung zu lassen. 

Die Schweigsamkeit von Oracle bezüglich eines Releasetermins 

kommt nicht von ungefähr – für den quelloffenen GlassFish 

(ebenfalls im Oracle Portfolio) findet sich im Web eine Roadmap 

über die weitere, wenn auch grobe, Releaseplanung [1]. Für den 

kommerziellen WebLogic Server, der als dedizierte Basis für unternehmenskritische 

IT-Projekte vermarktet wird, kann und will 

Oracle aufgrund von Rechtssicherheit keine Schätzungen abgeben. 

Hier gilt Oracles Leitlinie, zu solchen Produkten nur dann mit 

einer Ankündigung in den Markt zu gehen, wenn die Produktplanung 

gefestigt und ein Release zu den genannten Terminen auch 

garantiert werden kann. 

Aber auch wenn ein Java EE 6-zertifizierter WebLogic wünschenswert 

ist: das aktuelle Release (10.3.4) ist eine ebenso exzellente 

Basis für Unternehmensanwendungen. Durch zukünftige 

Patches und Zwischenversionen sollen neue Versionen der Java EE 

APIs nach ihrer Implementierung im WLS zeitnah zur Verfügung 

stehen. 

Stand der Dinge heute 

Unter [2] kann eine voll funktionsfähige Version des WebLogic Servers 

heruntergeladen werden, wobei neben angepassten Varianten 

für Windows und Linux auch ein generischer Installer (nur ein JDK 

wird benötigt) verfügbar ist. Da der WebLogic Server in Java programmiert 

ist, reicht zum Betrieb eine vorhandene, kompatible Java- 

Installation. Bei den plattformspezifischen Installern sind passende 

JDK/JRockit-Versionen mit enthalten; darüber hinaus werden bei 

ihnen betriebssystem¬spezifische „Performance-Packs“ installiert, 

mit denen u.a. durch natives Thread- und I/O-Handling deutliche 

Performance-Steigerungen im Server ermöglicht werden. 

Tabelle 1 zeigt den – etwas unfairen – Vergleich an unterstützten 

APIs im WebLogic Server 10 zur aktuellen Java EE 6. Viele der 

Programmierschnittstellen befinden sich in einer evolutionären Phase, 

so dass – wenn überhaupt – nur kleinere Versionsupdates als 

Unterschiede auftreten. Hingegen fehlen natürlich die zentralen, 

umwälzenden Veränderungen wie die Einführung von Dependency 

Injection komplett (die sich leider manchmal in genauso kleinen Versionsupdates 

wie EJB 3.1 zu 3.0 verstecken). 

JavaEE 6 WLS 10.3.4 / Java EE 5 

EJB 3.1 3.0 

Servlet 3.0 2.5 

JSP 2.2 2.1 

JMS 1.1 1.1 

JTA 1.1 1.2 

Connector 1.6 1.5 

Java EE Web Services 1.3 1.2 

JAX-RPC 1.1 1.1 

JAX-WS 2.2 2.1 

Web Services Metadata 2.1 2.0 

JSF 2.0 1.2 

Java Persistence 2.0 teils in EJB/JDO2.0 

Bean Validation 1.0 - 

Interceptors 1.1 - 

CDI 1.0 - 

Tabelle 1 – Unterstützte Java EE APIs 

Alleinstellungsmerkmale Administration, Clustering 

und Monitoring 

Den WebLogic-Server zeichnete schon seit jeher seine durchdachte, 

bequeme Administration aus. Sämtliche Ressourcen, Parameter und 

Deployments im Server sind in einer JSF-basierten Weboberfläche 

konfigurierbar (siehe Abb. 1). Für nicht maus-affine Administratoren 

steht aber auch eine jython-basierte Scripting-Umgebung zur Verfügung, 

die via JMX Zugriff auf alle Aspekte einer WebLogic-Domäne 

hat. Insbesondere das Aufsetzen größerer Cluster mit einer Vielzahl 

von homogen konfigurierten Servern lässt sich hierrüber hervorragend 

automatisieren. Zusätzlichen Nutzen gewinnt man dadurch, 

dass solche Admin-Skripte anschaulich die Deltas der eigenen Konfiguration 

gegenüber einer Standardkonfiguration dokumentieren. 

5

Neben der komfortablen Administration zeichnet sich der Web- 

Logic Server durch weitreichende Cluster-Features aus. Generell 

gilt, dass Standard-Java-EE-Anwendungen im WebLogic ohne 

großes Zutun direkt clusterfähig sind und per Lastverteilung von 

weiteren Clusterknoten profitieren. Natürlich sind (mit minimalem 

Aufwand) auch diverse Strategien für Hochverfügbarkeit 

oder automatische Ausfallsicherung konfigurierbar. Durch Utilities 

wie den WebLogic NodeManager bleiben dabei selbst größere 

Clusterarchitekturen handhabbar: per zentraler Admin-Oberfläche 

können einzelne Server, Servergruppen oder auch komplette 

Cluster gesteuert werden; zusätzlich kann durch kontinuierliches 

Health-Monitoring der NodeManager auch ausgefallene/instabile 

Server kontrolliert herunterfahren und – so gewünscht – neu 

durchstarten. 

Bei Betrieb eines Application Servers interessieren neben einer 

einfachen Administration aber auch die „inneren Werte“ – diese 

reichen von einfachen Laufzeitdaten wie dem aktuellen Speicherverbrauch, 

der Anzahl Request pro Sekunde oder der Anzahl 

offener Sessions bis zu detaillierteren Debugdaten wie den einzelnen, 

auf einer Datasource ausgeführten SQL-Statements oder 

dem konkreten Pfad eines Clientrequests durch die verschiedenen 

Servlet-/EJB-Schichten im Application Server. Mit dem WebLogic 

Diagnostic Framework (WLDF) unterstützt Oracle das Sammeln, 

Archivieren und Analysieren solcher Informationen. Der aktuell 

geltende Debug-Level als auch die vollständige WLDF-Konfigurationen 

(welche Daten werden wann wie und wie oft erfasst und 

archiviert) lassen sich zur Laufzeit des WebLogic Servers ändern, 

so dass z. B. bei Auftreten eines Produktionsproblems ohne Neustart 

des Servers weiterführende Daten zur Analyse gesammelt 

werden können. 

Ausblick auf Oracles WebLogic-Strategie 

Bedingt durch die zentrale Rolle der Java EE Spezifikation war es für 

Application Server Hersteller schon immer schwierig, sich auf funktionaler 

Ebene von der Konkurrenz abzugrenzen. Alleinstellungsmerkmale 

sind immer primär Performance, Clusterfähigkeiten und 

Administrationsmöglichkeiten der jeweiligen Server gewesen. Reine 

Performance-Benchmarks wie jAppServer von spec.org haben dabei 

in den letzten Jahren an Bedeutung verloren – vielmehr steht oft 

die Integration der Middleware in zentrale Monitoring-Lösungen auf 

Unternehmensebene im Vordergrund. 

6 

Durch die Übernahme BEAs durch Oracle wird dieser Prozess beschleunigt: 

Tools wie der Enterprise Manager binden den WebLogic 

enger in Oracles Business-Software-Portfolio ein. Natürlich soll dies 

eine stärkere Bindung an Oracle als Hersteller fördern. Die Oracle- 

Landschaft als „Habitat“ für den WebLogic Server hat jedoch weitere 

Vorteile: durch die z. B. ebenfalls akquirierte Firma Tangosol ist deren 

Coherence Cache als In-Memory Data Grid verfügbar – mit dem Vorteil, 

dass eine solche „best of breed“-Lösung jetzt standardmäßig zusammen 

mit dem WebLogic ausgeliefert und dort somit ein (bislang 

nicht vorhandener) clusterweiter Cache verfügbar wird. 

Mit GlassFish und WebLogic unter einem Dach – wie sieht da Oracles 

Strategie im Application Server Umfeld aus? Der WebLogic Server 

wird als das strategische Produkt für den unternehmensweiten Einsatz 

vermarktet, der GlassFish hingegen als Referenz-Implementierung 

der Java EE und als mögliche „Insel-Lösung“ für einzelne Abteilungen 

in einem Unternehmen. Die strategische Bedeutung des 

WebLogic für Oracle ist auch daran erkennbar, dass er die technologische 

Basis für weitere Enterprise-Software wie Oracle Portal/Web- 

Center oder Oracle SOA Suite darstellt (siehe Abb. 2). Insofern darf 

man von Oracle auf kommende Neuerungen im WebLogic-Umfeld 

gespannt sein. 

Abbildung 2: Oracle Portfolio Stack 

Abbildung 1: AdminConsole 

URLs: 

[1] GlassFish Roadmap: 

http://glassfish.java.net/roadmap 

[2] WebLogic Download: 

http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html 

Klaus-Peter Lisson [ klaus-peter.lisson@gedoplan.de ] 

Seniorberater bei der GEDOPLAN GmbH mit mehr als 10 Jahren Erfahrung in der 

professionellen Softwareentwicklung. Seine Schwerpunkte sind Anforderungsanalyse, 

Architektur und Realisierung von Java-EE-Anwendungen.

JBoss 6.0.0: Der neue Chef mit dem roten Hut 

Quasi auf den letzten Drücker hat JBoss/Red Hat den Applikationsserver JBoss 6.0.0 fertiggestellt. Seit 

dem 28.12.2010 ist der JBoss 6.0.0 in der Final Version veröffentlicht. Damit ist der kleine, aber feine 

Kreis der Java-EE-6-Implementierungen um einen wichtigen Kandidaten gewachsen. Auf jeden Fall 

ein Grund, sich den neuen JBoss einmal näher anzusehen. 

Von Klaus Bertelt 

Mit dem neuen JBoss werden die Java-EE-6-Web-Profile-Anforderungen 

erstmals nativ unterstützt. Zwar war die Nutzung einzelner Komponenten 

schon auf den 5.x-Versionen möglich, setzte aber einiges an 

Bastelei und Geduld voraus. Mit der neuen Version gehört dies endlich 

der Vergangenheit an. Folgende Anforderungen wurden umgesetzt: 

Servlet 3.0 

JavaServer Pages (JSP) 2.2 

Expression Language (EL) 2.2 

Debugging Support for Other Languages (JSR-45) 1.0 

Standard Tag Library for JavaServer Pages (JSTL) 1.2 

JavaServer Faces (JSF) 2.0 

Common Annotations for the Java Platform (JSR-250) 1.1 

Enterprise JavaBeans (EJB) 3.1 Lite 

Java Transaction API (JTA) 1.1 

Java Persistence API (JPA) 2.0 

Bean Validation 1.0 

Managed Beans 1.0 

Interceptors 1.1 

Contexts and Dependency Injection for the Java EE Platform 1.0 

Dependency Injection for Java 1.0 

Quelle: Java Platform, Enterprise Edition 6(Java EE 6) Web Profile Specification 

Da eine ausführliche Behandlung diesen Artikel um ein Vielfaches 

sprengen würde, sollen nachfolgend nur einige Teilbereiche mit den 

wichtigsten Neuerungen angesprochen werden. 

Neuigkeiten im Detail 

EJB 3.1 

Um die Unterstützung von EJB 3.1 zu gewährleisten wurde nicht 

etwa wie gefordert, „nur“ die Lite Version der Enterprise Java Beans 

implementiert, sondern ein kompletter Container mit allen Features. 

Wichtige Bestandteile dieser Komponente sind zum Beispiel: 

Singleton: Mit Hilfe der Annotation @Singleton kann eine EJB 

programmiert werden, von der zur Laufzeit nur eine Instanz erzeugt 

wird. Dies war bis zur Version 3.0 nur mit Umwegen und 

Fallstricken über serverspezifische Deskriptorparameter möglich 

oder durch Umgehung des Standards und Nutzung des Java-SE- 

Singleton-Patterns. Eine Singleton Bean entspricht grob einer 

Stateful Bean, allerdings mit dem großen, konzeptionellen Unterschied, 

dass Singletons von mehreren User-Threads konkurrierend 

aufgerufen werden können. Die Serialisierung der Zugriffe übernimmt 

per Default der Container. 

Scheduler: Neidische Blicke auf Uralt-Werkzeuge wie cron sind 

seit EJB 3.1 nicht mehr nötig, denn der Timer-Service wurde um 

sehr umfangreiche Scheduling-Möglichkeiten erweitert. Eine Bean 

kann nun ein oder mehrere Methoden enthalten, die mit @Schedule 

annotiert sind. Über die Parameter der Annotation können 

die Aufruftermine sehr flexibel spezifiziert werden. 

7

JSF 2.0 

Nicht nur im Bereich der EJB 3.1 hat JBoss einiges an Boden gutgemacht. 

Mit dem neuen Applikationsserver wird JSF 2.0 unterstützt. 

Um einen großen Pool an Features abzudecken wurden mit Mojarra 

1.2.15, Mojarra 2.0.3 und Apache MyFaces 2.0.1 gleich mehrere Implementierungen 

integriert. Eines der wichtigsten Features stellt hier 

wohl die Umsetzung der Managed Beans dar: 

Managed Beans dienen als Gateway zwischen der JSF-Oberfläche 

und der Verarbeitung der Daten. Sie bieten für alle Properties Zugriffsmethoden 

an, die zur Übernahme von Eingabewerten und zur 

Bereitstellung von Anzeigewerten genutzt werden. Ebenso können 

Action- und Event-Methoden vorhanden sein. Seit JSF 2.0 ist 

die Auszeichnung der Managed Beans mittels der Annotation @ 

javax.faces.bean.ManagedBean möglich. Über den Parameter 

name ist die Angabe eines Namens möglich, mit dem die Bean 

u. a. aus den Seiten referenziert werden kann. Als Default gilt der 

einfache Klassenname mit kleinem Anfangsbuchstaben. In den 

Vorversionen mussten Managed Beans in der Konfigurationsdatei 

faces-config.xml aufgeführt werden. Dies ist in JSF 2.0 weiterhin 

möglich, wenn keine Annotationen verwendet werden können 

oder sollen. 

JPA 2.0 

Da aller guten Dinge ja bekanntlich drei sind, soll nachfolgend noch 

ein weiteres Highlight des JBoss kurz angerissen werden: JPA 2.0, das 

in der aktuellen JBoss-Version mithilfe von Hibernate 3.6.0 realisiert 

wird: 

Collections: Seit JPA 2.0 sind Attribute möglich, die vom Typ 

java.util.Collection oder einem davon abgeleiteter Typ sind 

und deren einzelne Elemente einen einfachen Typ haben oder einbettbar 

sind. Das Attribut (Feld oder Property) muss mit @ElementCollection 

versehen werden. Damit wird erreicht, dass die 

Collection mit Hilfe einer zweiten Tabelle realisiert wird. 

Relationen als Id-Attribut: Im Zusammenhang mit mehrteiligen 

Schlüsseln kommt es häufig vor, dass ein Teil des Schlüssels eine 

n:1-Relation zu einer anderen Entity modelliert. Seit JPA 2.0 ist 

es erlaubt, Id-Felder zu verwenden, die zudem mit @ManyToOne 

8 

annotiert sind. Relationen im Schlüssel können auch mit eingebetteten 

Schlüsselklassen realisiert werden. Die Schlüsselklasse muss 

dann wie gewohnt mit @Embeddable ausgezeichnet sein, damit 

ein entsprechendes Attribut mittels @EmbeddedId in die Entity- 

Klasse aufgenommen werden kann. Die Relation muss in diesem 

Fall zusätzlich deklariert werden. Die Zuordnung zum zugehörigen 

Feld des Schlüssels stellt die Annotation @MapsId her. 

Was gibt’s sonst noch? 

Als wären die Implementierung des neuen Standards nicht schon 

Neuerungen genug, hat der neue JBoss noch mit einem weiteren 

Schmankerl aufzuwarten: ein neuer JMS Provider. In der neuen Version 

ist jetzt Hornetq 2.1.1 integriert, welches den vorherigen Provider 

ersetzt. Auch hier ist der Trend zur klaren, leichten Programmierung 

zu erkennen: 

In einer neuen Konfigurationsdatei *hornetq-jms.xml können Factories, 

Queues und Topics nun ähnlich einfach eingetragen werden, wie 

Beans in einen Deskriptor: 

… 

… 

 

 

 

 

 

 

… 

 

 

… 

 

 

 

 

 

Die hier eingetragenen Parameter finden Ihre Entsprechung im Code 

beim Lookup des JNDI-Context: 

… 

QueueConnectionFactory queueConnectionFactory = 

(QueueConnectionFactory) 

jndiContext.lookup(„TestConnectionFactory“); 

Queue queue 

= (Queue) jndiContext.lookup(„testQueue“); 

… 

Ein Blick in die Maschine 

Nach der theoretischen Erklärung der Neuigkeiten soll nun kurz der 

Server an sich betrachtet werden. Herunterladen und installieren 

lässt sich der Server wie in den vorangegangenen Versionen denkbar 

einfach. Auch beim Starten des Servers wird Bewährtes weitergeführt, 

das Deployment läuft ebenfalls wie in den vorherigen Versionen. 

Eine Sichtung der Verzeichnisstruktur lässt den erfahrenen 

Anwender auf den ersten Blick auch kalt: Alles beim Alten. Alles? 

Spätestens wenn man sich unterhalb des server-Verzeichnisses in 

den verschiedenen Konfigurationen befindet, werden Änderungen 

sichtbar: 

Abbildung 1: JBoss 5.1.0 Abbildung 2: JBoss 6.0.0 

Abbildung 3: 

Roadmap (Stand Februar 2011) 

Auch ein Blick auf die Administrationskonsole unter server:8080 

macht schnell eines deutlich: Minimalismus ist nicht tot! Zwar lassen 

sich die verschiedensten Werte und Einstellungen ablesen, aber 

Editierfunktionen sucht man vielerorts vergeblich. Es hält sich wie 

mit den älteren Versionen: Entweder man leistet sich die Unterstützungstools, 

oder editiert auch weiterhin die verschiedenen XML- 

Dateien händisch. 

Wo soll‘s hingehen? 

Nach dem Server ist bekanntlich ja immer vor dem Server. Aus diesem 

Grund sind die Veröffentlichungstermine der neuen JBoss-Versionen 

auch eng miteinander verzahnt, wie Abbildung 3 zeigen soll. 

Eine Unterstützung der für den 28.07.2011 (Stand Februar 2011) geplanten 

Veröffentlichung von Java 7 ist vorgesehen. Hier kann man 

erkennen, dass sich die JBoss Inc. dieses Mal vorgenommen hat, 

durch die zeitige Veröffentlichung der 7.0.0 final gleich von Anfang 

an im Kreis der großen Applikationsserver eine wichtige Rolle zu 

spielen. 

Bleibt zu hoffen, dass bei allem Termindruck eine saubere, gut 

durchdachte neue Version des großen Bosses mit dem roten Hut 

erscheint. 

Links und Verweise: 

http://gedoplan.de/javaseminare, 01.02.2011 

http://jboss.org/, 01.02.2011 

http://jcp.org/aboutJava/communityprocess/final/jsr316/index.html, 01.02.2011 

http://it-republik.de/jaxenter/artikel/JBoss-AS6-Treffen-der-sechsten-Generationen-3511.html, 

„Bernhard Löwenstein, Oliver Kraft“, 01.02.2011 

Abbildungsverzeichnis: 

Abbildung 1: JBoss 5.1.0 

Abbildung 2: JBoss 6.0.0 

Abbildung 3: Roadmap (Stand Februar 2011) 

Klaus Bertelt [ klaus.bertelt@gedoplan.de ] 

Consultant und Trainer im Bereich Java EE und agiles Projektmanagement, insbesondere 

Scrum. 

9

GlassFish 3.1: Das volle Programm Java EE 6 

Java EE 6 ist in aller Munde, die neuen Spezifikationen versprechen eine flexible und „lightweight“ 

Entwicklung und ein JSR Highlight folgt auf das nächste. Zeit, einen Moment zu Atem zu kommen und 

sich auf die Basis zu konzentrieren, die das alles möglich machen soll. Bereits seit Dezember 2009 steht 

die erste 3er Version des GlassFish in der finalen Version bereit, die einen genaueren Blick rechtfertigt. 

Von Dominik Mathmann 

GlassFish in der aktuellen Version 3.1 stellt die Referenzimplementierung 

von Java EE 6 dar und bietet somit den vollen Umfang an 

Verbesserungen und neuen Features, die seit der Java EE Version 5 in 

den Standard eingeflossen sind. Neben den neuen Versionen von EJB 

(3.1), JSP (2.2), JPA (2.0) und JSF (2.0) wird somit die lange Liste von 

Technologien um viele weitere Punkte ergänzt, wie zum Beispiel die 

Unterstützung von CDI und die Möglichkeit der BeanValidation (für 

die komplette Liste siehe: [1]). 

Ein Blick durch die Administrator-Brille 

Wo früher aufwendige Konfigurationen und Installationsroutinen warteten, 

kommt die neue Version des GlassFish ganz der Philosophie entsprechend 

„leichtgewichtig“ daher. Ein kurzer Blick auf die Seite von 

Oracle lässt die Wahl zwischen der Open Source- und der Oracle-Edition, 

die sich im Kern lediglich im Punkt der Support-Unterstützung unterscheiden. 

Nach Auswahl der gewünschten Zielplattform und Download 

des entsprechenden Bundles ist der größte Schritt in Richtung 

der eigenen GlassFish-Installation bereits getan. Abhängig vom ausgewählten 

Bundle führt entweder ein Installationsassistent über die 

anfängliche Konfiguration, in der z. B. Login-Daten und Ports definiert 

werden können, oder obliegt es dem Entwickler selbst, entsprechende 

Anpassungen nach dem Entpacken des Archivs durchzuführen. Ganz 

nach dem Leitsatz „Configuration by Exception“ ist der Server jedoch 

auch ohne explizite Konfiguration startbereit und lässt sich über das 

mitgelieferte Commandline-Tool ([install]/bin/asadmin) mit dem Befehl 

„asadmin start-domain domain1“ mit der default Domain starten 

und über den Standard-Port „8080“ aufrufen (http://localhost:8080, 

weitere Default-Werte siehe: Tabelle 1, Konfiguration – Defaults). 

Was nicht passt wird passend gemacht 

Zur Konfiguration stehen dem User generell zwei unterschiedliche 

Varianten zur Verfügung. Zum einen dient auch das bereits verwendete 

asadmin-Tool zur Pflege der Einstellungen, welches über diverse 

Parameter per Kommandozeile zum Ziel führt. Auf der anderen 

Seite besteht die Möglichkeit, die komfortable Weboberfläche zur 

Änderungen von Parametern zu verwenden. Diese erreicht man bequem 

über den Browser unter Verwendung des Ports 4848 (http:// 

localhost:4848). Unabhängig von der verwendeten Methode spiegeln 

sich alle Änderungen in der domain-abhängigen Konfigurationsdatei 

wieder ([install]/domains/[domainName]/config/domain.xml), die 

zwar auch direkt verändert werden kann, was aber von Seiten des 

Herstellers nicht empfohlen wird. 

10 

Deployment 

Auch beim Deployment lässt der GlassFish dem User die Wahl und ist 

nicht auf ein Vorgehen beschränkt. Die beiden bereits angesprochenen 

Methoden zur Konfiguration beinhalten ebenfalls entsprechende 

Funktionen zum Bereitstellen von Anwendungen (in der Admin- 

Console über den Menüpunkt „Applications“ oder über den asadmin 

Befehl „deploy“). Darüber hinaus existiert eine weitere Variante, die 

zwar keine Möglichkeit zur Parametrisierung des Deployvorgangs 

bietet, dafür jedoch durch seine Einfachheit besticht. Dazu wird das 

entsprechende Archiv (EAR für EE-Anwendungen oder WAR für Web 

Applicationen) lediglich in das so genannte Autodeploy-Verzeichnis 

kopiert ([install]/domains/[domainName]/autodeploy/), was den Server 

dazu veranlasst, die entsprechende Anwendung automatisch bereitzustellen. 

Eine Übersicht über die installierten Applikationen und 

deren Komponenten bietet erneut die Admin-Console, in der auch 

der Context-Pfad von Web-Anwendungen verändert oder aktive Deployment 

Descriptoren angezeigt werden können. 

Zum Test bitte! 

Seit der Java EE Version 6 wird dem Entwickler ein weiteres Features 

in die Hände gelegt, welches in Kombination mit JUnit und/ 

oder anderen Testframeworks das alltägliche Testen erleichtert: 

Die standardisierte Schnittstelle für Embedded Server ist auch im 

GlassFish verfügbar und ermöglicht eine einfache und vor allen 

Dingen zeitsparende Verwendung in Testfällen. Zur Verwendung 

des Embedded-GlassFish stehen drei unterschiedliche Ausführungen 

als JAR-Dateien bereit, die in den Classpath des Projektes 

eingebunden werden können: GlassFish-embedded-web.jar – zum 

Deploy von reinen Webanwendungen, GlassFish-embedded-all.jar 

– zum Deploy von Anwendung jeglichen EE-Typs und GlassFishembedded-static-shell.jar 

– zum Standalone-Deploy ohne vorhandene 

GlassFish Installation. Bevor der Server nun in Testfällen 

verwendet werden kann, bedarf es einiger Konfigurationen, die 

im Fall des GlassFish zur Laufzeit (über den so genannten CommandRunner) 

oder aber über eine eigene Domain-XML durchgeführt 

werden können. Die zweite Variante hat dabei den Charme, 

dass die vorhandene Domain-XML des Entwicklungs- oder Test- 

Systems verwendet werde kann. Dabei hat man die Möglichkeit, 

beim Start des Servers den Installationspfad auf eine lokale 

GlassFish-Installation verweisen zu lassen. Wesentlich flexibler 

ist hierbei jedoch, eine entsprechende Ordner-Struktur direkt im 

Projekt abzubilden, die abgesehen von der domain.xml im Ordner

Abbildung 2: Test-Quelltext 

der Konfiguration (s. Abbildung 1, Embedded-Projektstruktur) leer 

sein kann. Das bringt auf der einen Seite den großen Vorteil, dass 

dieses Abbild einer GlassFishinstallation nun projekt-abhängig 

angepasst werden kann. Hier bieten sich neben Veränderungen 

an den zu verwendeten Ports (um eine Kollision mit einer lokal 

laufenden Entwicklungsmaschine zu vermeiden) besonders die 

verwendeten DataSources an, um z. B. anstatt einer installierten 

MySQL in Testfällen eine In-Memory-DB zu verwenden. Auf der 

anderen Seite fügt sich der Embedded-Server mit einer im Projekt 

befindlichen Konfiguration nahtlos in Continous Integration 

Systeme wie z. B. Hudson ein, die somit keine eigene Installation 

bereitstellen müssen. Bei der Implementierung der Tests bietet es 

sich nun an, z. B. im Falle von JUnit mit einer so genannten Test- 

Suite zu arbeiten, die den Start und Stopp des Servers regelt und 

die einzelnen Testfälle aufruft. Hierbei genügen einige Zeilen Code, 

um den Server zu starten und entsprechende Testfälle auszuführen 

(s. Abbildung 2, Test-Quelltext). 

Fazit 

Der GlassFish 3 wartet mit allen Neuerung auf, die Java EE 6 zu bieten 

hat, und das derzeit als einziger Application Server auf dem Markt. 

Wenngleich der JBoss laut Ankündigung bald ebenfalls im vollen 

Umfang folgen soll, braucht der GlassFish sich nicht zu verstecken 

und besticht vor allem durch die intuitive Weboberfläche und die 

Vielzahl an weiteren Möglichkeiten zur Konfiguration und des Deployments. 

Abzuwarten bleibt, ob der Standard in Sachen Embedded 

Server API das hält was er verspricht und die Entwicklung von applicationserver-unabhängigen 

Testfällen ermöglicht. 

Ports 

Admin Console 4848 

HTTP 8080 

HTTP 8181 

JMX 8686 

IIOP (+SSL/mutual authentication) 

Domain-Daten 

3700 (3820/3920) 

Domain Name domain1 

Master Passwort changeit 

Administrator Passwort 

Pfade 

admin 

asadmin-Commandline-Tool [install]/bin 

Domain-Konfigurationsdatei 

(domain.xml) 

[install]/domains/[domain]/config 

Domain-Autodeploy 

[install]/domains/[domain]/autodeploy 

Log-Files [install]/domains/[domain]/logs 

Upgrade Tool [install]/bin 

Update Tool + pkg Command [install-parent]/bin 

Tabelle 1: Konfiguration – Defaults 

Abbildung 1: Embedded-Projektstruktur 

Links 

#1 http://docs.sun.com/app/docs/doc/821-1759 (Kapitel „Java EE Standards“ ) 

Dominik Mathmann [ dominik.mathmann@gedoplan.de ] 

Entwickler und Berater bei Gedoplan im Bereich Java. Tätigkeitsschwerpunkte sind 

Java basierte Webanwendungen und Application Server. 

11

GEDOPLAN 

Unternehmensberatung und 

EDV-Organisation GmbH 

Stieghorster Straße 60 

33605 Bielefeld 

Fon: 0521 2 08 89 10 

Fax: 0521 2 08 89 45 

E-Mail: info@gedoplan.de 

Herausgeber: GEDOPLAN Unternehmensberatung und EDV-Organisation GmbH | Stieghorster Straße 60 | 33605 Bielefeld 

Verantwortlich: Dipl.-Inform. Dirk Weil | Redaktionsleitung: Ulrich Hake | Fon: 0521 2088910 | E-Mail: info@gedoplan.de 

Produktion: networker Medienfabrik GmbH | Nachdruck, auch auszugsweise, nur nach Rücksprache mit der Redaktion. 

GEDOPLAN ist seit über 30 Jahren spezialisiert auf die Entwicklung 

von IT-Systemen. Unsere Experten haben langjährige Erfahrung in 

der Analyse, Konzeption und Realisierung von Unternehmenssoftware. 

Individuallösungen realisieren wir auf Basis objektorientierter Techniken. 

Die leistungsfähige und umfangreiche Plattform Java EE bildet 

dafür schon seit über 10 Jahren einen unserer Schwerpunkte. Es ist 

unser Anspruch, gut strukturierte und wartbare Anwendungen zu 

entwickeln. Mit modernen Entwicklungsumgebungen und entwicklungsbegleitenden, 

automatisierten Tests stellen wir eine hohe Softwarequalität 

sicher. 

Im Bereich der Standardsoftware unterstützen wir Sie bei der Einführung 

und Anpassung von SAP®-Lösungen, insbesondere in Fragen 

der Basis-Administration und des Personalmanagements. Anpassungen 

oder Erweiterungen können wir mit ABAP und Java auf Basis 

von SAP® NetWeaver durchführen. 

Wir entwickeln IT-Systeme als Komplettpakete, unterstützen unsere 

Kunden aber auch vor Ort. Unsere Experten geben ihr Wissen gerne 

weiter – in Form von projektbegleitenden Coachings oder Seminaren 

bei unseren Schulungspartnern. 

www.gedoplan.de

Ausgabe Frühjahr 2011 - Gedoplan

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?