Workshop Java EE 7 - Ein praktischer Einstieg in die Java Enterprise Edition mit dem Web Profile

1 Ein Einstieg mit Profil

1.1 Java EE 7 – der Standard für Enterprise Java

Oracle wirbt für Java mit dem Hinweis: »3 Milliarden Geräte verwenden Java.« Offensichtlich haben sie recht damit: Auf nahezu jedem PC ist eine Java-Laufzeitumgebung (Java Runtime Environment) installiert. Java ist zwar überall präsent – es stellt sich allerdings die Frage: Ist es wirklich in jedem Fall die dominierende Plattform?

Dies kann von Fall zu Fall (Desktop, Server, mobile Geräte, Blu-Ray-Player etc.) sicher kontrovers diskutiert werden. Bei kritischen Geschäftsanwendungen hat sich Java jedoch zweifelsfrei durchgesetzt.

Sicherlich hat zu diesem Erfolg beigetragen, dass Java von Beginn an auf zukunftsfähige Konzepte wie Objektorientierung und Plattformunabhängigkeit setzte, die Wartung und Verteilung einer Anwendung vereinfachten. Außerdem ließen sich bereits in frühen Versionen komplexe Funktionalitäten umsetzen, da hierzu umfangreiche Klassenbibliotheken mitgeliefert wurden, u. a. für Threads, entfernte Methodenaufrufe, Datenstrukturen, grafische Benutzeroberflächen und I/O.

Diese Basis wurde schnell um weitere Aspekte von Geschäftsanwendungen wie z. B. Transaktionsmanagement, Sicherheitsmechanismen und Webtechnologien erweitert und zeichnete damit den Weg zur Standardisierung und Etablierung der Java-Plattform im Feld des Enterprise Computing vor – auch wenn der Weg dahin in den letzten Jahren nicht immer geradlinig war.

1.1.1 Struktur einer Enterprise-Java-Anwendung

Im Unterschied zu gewöhnlichen Java-Programmen werden Enterprise-Java-Anwendungen für verteilte, mehrschichtige Architekturen entwickelt. Das heißt, Anwendungsteile werden in der Regel auf unterschiedlichen Rechnern ausgeführt. Java-EE-Anwendungen für diese Architekturen teilen sich logisch in bis zu vier Schichten auf: Client-, Web-, Business- und Persistenzschicht. Die Clientschicht enthält die Teile der Anwendung, die der Benutzer zur Interaktion mit der Anwendung benötigt. Bei Webanwendungen ist der Client ein Browser. Die Realisierung der Ablaufsteuerung und die Erzeugung der Webseiten ist Aufgabe der Webschicht. Dadurch kann der Nutzer indirekt die Geschäftslogik der Businessschicht nutzen. Wird keine Webanwendung realisiert, so wird die Webschicht nicht benötigt. Stattdessen kann ein Application-Client, z. B. eine Desktop-Java-Anwendung mit grafischer Oberfläche, verwendet werden. Ein Application-Client realisiert die Ablaufsteuerung der Anwendung selbst und verwendet dabei die bereitgestellte Geschäftslogik durch direkte Benutzung der Businessschicht oder indirekt durch den Aufruf von Webservices, die die Geschäftslogik der Businessschicht kapseln. Die zur Realisierung der Geschäftslogik in der Businessschicht zu verarbeitenden Daten werden in der Persistenzschicht dauerhaft gespeichert. In der Regel kommen dabei Datenbanksysteme inklusive deren Abstraktionen zum Einsatz, sodass sie einfach in die Businessschicht eingebunden werden können. Die Daten können aber auch in anderen, externen Systemen abgelegt werden, die sich auf verschiedene Weise (z. B. durch Nachrichtenkommunikation) einbinden lassen.

Enterprise-Java-Anwendungen werden über einen Java-Applikationsserver bereitgestellt und verwaltet. Neben entsprechenden Laufzeitumgebungen für die verschiedenen Teile der Anwendung, auch Container genannt, stellt er auch Querschnittsdienste bereit, die von allen Anwendungen verwendet werden können. Dazu zählt z. B. das Transaktionsmanagement, Authentifizierung, Autorisierung, Namens- und Verzeichnisdienste oder auch der standardisierte Zugriff auf Datenbanken, verteilte Warteschlangen (engl. message queues) und andere externe Systeme.

Wichtige Eigenschaften von Geschäftsanwendungen wie Synchronisation, Lastverteilung und Verfügbarkeit werden ebenfalls vom Applikationsserver garantiert und damit von der Anwendungslogik entkoppelt. Dadurch erleichtert der Applikationsserver die Entwicklung von Geschäftsanwendungen, da der Programmierer sich voll auf die funktionale Gestaltung der eigentlichen Anwendung konzentrieren kann.

Eine Anwendung ist aus Komponenten aufgebaut, die einen klar definierten Zweck innerhalb der Anwendung erfüllen und einer Schicht der Anwendung zugeordnet sind. Ziel des Komponentenmodells sind klare Strukturen und damit einhergehend eine höhere Transparenz, bessere Verständlichkeit sowie eine einfachere Wartbarkeit und Erweiterbarkeit der Anwendung.

1.1.2 Die Java Enterprise Edition (Java EE)

Der Java-Standard für mehrschichtige Geschäftsanwendungen firmiert unter dem Namen Java Platform Enterprise Edition 7 (Java EE 7) und wird durch die Spezifikation JSR-342 (http://jcp.org/en/jsr/detail?id=342) des Java Community Process (JCP) definiert (DeMichiel & Shannon, 2013).

Der Standard basiert auf der Java Platform Standard Edition (Java SE) sowie zusätzlichen APIs, die entweder das Komponentenmodell realisieren (z. B. Enterprise JavaBeans) oder spezielle Aspekte einer Geschäftsanwendung adressieren (z. B. Transaktionen mit der Java Transaction API). Diese APIs werden (wie alle offiziellen Java-APIs) durch den JCP standardisiert und unter einer eigenen JSR-Nummer (Java Specification Request) veröffentlicht.

Es handelt sich um einen wichtigen Aspekt, da dadurch sowohl Herstellern von Applikationsservern oder Bibliotheken als auch Entwicklern eine Vorgabe für ihre Arbeit gegeben wird. Die Hersteller wissen dadurch genau, was von ihrem Produkt verlangt wird, und die Entwickler wissen, was sie bei der Programmierung ihrer Applikation voraussetzen können. Auf diese Weise können Applikationsserver auch für Java-EE-Versionen zertifiziert werden. Alle Spezifikationen sind öffentlich über das Internet (http://jcp.org) zugänglich.

Im Verlauf der Geschichte des Java-EE-Standards gab es diverse Hochs und Tiefs. Zu Beginn des neuen Jahrtausends wich die anfängliche Begeisterung schnell der Ernüchterung, da der Standard (damals kurz J2EE genannt) selbst zu umständlich und komplex für den Programmierer war.

Das Resultat war die Entwicklung zahlreicher (erfolgreicher) Frameworks, die quasi in Konkurrenz zu Teilen bzw. zum Standard im Ganzen entstanden, etwa Spring, Seam, Hibernate oder Struts. Dies führte natürlich nicht zur Vereinfachung der Java-Landschaft in den Unternehmen, war aber eine logische Konsequenz, die aus der Praxis heraus resultierte.

Auch heute gilt deshalb noch, dass nicht jede Enterprise-Java-Anwendung auf Java EE basiert. Letztendlich stand in dieser Zeit nicht mehr und nicht weniger als die Existenz des Java-EE-Standards auf dem Spiel. Am Scheideweg stehend wurde 2006 mit Java EE 5 (Motto: »Ease of Development«) die Wende eingeleitet, indem ein Weg eingeschlagen wurde, der eine Vereinfachung des Standards zum Ziel hatte und damit die Arbeit des Entwicklers wieder in den Mittelpunkt stellte.

In diesem Sinne wurden mit Java EE 6 (2009) und aktuell mit Java EE 7 (2013) viele Ideen und Best Practices aus den diversen Java-Frameworks einvernehmlich übernommen. Der Standard wurde dadurch wieder konkurrenzfähig und zukunftsweisend.

1.1.3 Anatomie einer Java-EE-Anwendung

Java-EE-Anwendungen unterscheiden sich von gewöhnlichen Java-Programmen. Zwar werden sie größtenteils ebenfalls mit der Programmiersprache Java erstellt, der Programmierer orientiert sich jedoch an einem durch die Spezifikation vorgegebenen Komponentenmodell.

Java EE definiert Webkomponenten, die innerhalb von Java-EE-Webanwendungen verantwortlich sind für die Generierung von Webseiten für den Browser. Für die Realisierung der Komponenten der Webschicht stellt der Standard die Technologien Java Servlets, JavaServer Pages (JSP) und JavaServer Faces (JSF) zur Verfügung.

Des Weiteren definiert Java EE die Komponententechnologie Enterprise JavaBeans (EJBs) für die Businessschicht. Mit den EJBs wird die Geschäftslogik realisiert. Sie bringen von Haus aus transaktionales Verhalten und Sicherheitsmechanismen mit. Eine neuere Technologie unter dem Namen Contexts and Dependency Injection (CDI) ermöglicht mit seinen Eigenschaften die Konstruktion einer sehr flexiblen Softwarearchitektur für die Anwendung.

Eine Komponente kann aus unterschiedlichen technischen Artefakten (z. B. XML-Dateien, Schnittstellen oder Klassen) bestehen. Für jeden Komponententyp gibt es einen eigenen Container innerhalb des Applikationsservers, der verantwortlich für die Überwachung des Lebenszyklus der Komponenten ist. Abbildung 1–1 veranschaulicht die Situation. Im Folgenden gehen wir genauer auf die skizzierte Komponentenarchitektur der Java EE ein.

Abb. 1–1 Skizze der Ausführungsumgebung von Java-EE-Anwendungen

1.2 Die Komponentenarchitektur von Java EE 7