Java Enterprise oder Java EE
Es gibt zwei weit verbreitete Versionen der Java-Umgebung, die Java Enterprise Edition, meist mit dem Kürzel Java EE oder JEE bezeichnet, sowie die Standard Edition, abgekürzt Java SE. SE ist die Standardausgabe, die alle grundlegenden Klassen enthält, die man für die Entwicklung von Standalone, beziehungsweise Desktop-Anwendungen einsetzen würde. Die Java Enterprise Edition ist dagegen für mehrstufige Unternehmensanwendungen und verteilte Anwendungen ausgelegt. Sie beinhaltet einen weitaus größeren Funktionsumfang als das in Java Enterprise Edition vollständig enthaltene Java SE.
Java Enterprise Edition – Java für Unternehmensanwendungen
Java SE ist der grundsätzliche Sprachumfang von Java, wenn man so will. Die Java Enterprise Edition ist dagegen für mehrstufige Unternehmensanwendungen und verteilte Anwendungen ausgelegt. Sie beinhaltet einen weitaus größeren Funktionsumfang als das in Java Enterprise Edition vollständig enthaltene Java SE. Unternehmensanwendungen (Enterprise Applications) laufen auf Application Servern wie GlassFish und WildFly, oder mit Einschränkungen (der EJB-Container fehlt) auch Tomcat. Der Vollständigkeit halber sei erwähnt, dass es neben SE und EE noch zwei weitere Java-Plattformen gibt, namentlich Java ME und JavaFX – diese sind jedoch im Kontext dieses Beitrags nicht relevant und haben eine geringere Bedeutung. In der Vergangenheit war das Kürzel für Java Enterprise Edition J2EE, wobei die eingeschobene “2” lediglich aufgrund von Marketing-Überlegungen heraus eingefügt wurde und keine besondere Bedeutung hat. Dieser Tage ist das offizielle Kürzel für die Java Enterprise Edition schlicht JEE.
Mehrstufige, verteilte Client/Server Anwendungen für Unternehmen
Was kann man nun konkret mit der Java Enterprise Edition anstellen, was sich nicht auch mit der Standard Edition bewerkstelligen ließe? Eine ganze Menge. Mit der Standard Edition kannst du Dich nicht auf einen Anwendungsserver verlassen, um Transaktionen oder Persistenzkontexte zu verwalten. Ohne Java EE hast Du auch keine Anwendungsserver, die EJB-Dependency Injections unterstützen. Ohne Java EE steht Dir auch kein benutzerverwalteter Timer-Dienst zur Verfügung. Die Java Enterprise Edition (JEE) ist eine Sammlung von Spezifikationen und darauf basierenden Technologien und APIs für die Java Plattform, die insbesondere daraufhin konzipiert sind, sogenannte Enterprise Applications zu unterstützen. Diese Enterprise Applikationen zeichnen sich im Allgemeinen dadurch aus, dass sie einen hohen Funktionsumfang mitbringen, viele Benutzer und Daten verwalten können, sowie transaktionssicher und hochverfügbar sind. Sie werden entworfen, um das Erreichen unternehmsspezifischer Ziele zu ermöglichen oder zu unterstützen. Unternehmensanwendungen (Enterprise Applications) werden auf Servern gehostet, die die Funktionalität dieser Anwendungen zur Verfügung stellen und erweitern. Die Schlüsseltechnologien und -konzepte, die zusammengefasst als Java Enterprise Edition bezeichnet werden umfassen die folgenden Dienste, APIs und Protokolle:
-JDBC (Java DataBase Connectivity)
-JNDI (Java Naming and Directory Interface)
-EJBs (Enterprise Java Beans)
-RMI (Java Remote Method Invocation)
-JSP (Java Server Pages)
-JSF (Java Server Faces)
-Servlets
-XML (Extensible Markup Language)
-JMS (Java Message Service)
-Java IDL (Java Interface Definition Language)
-JTS (JTS Topology Suite; früher Java Topology Suite)
-JTA (Java Transaction API)
-JavaMail
-JAF (JavaBeans Activation Framework)
Mehrstufigkeit bedeutet in Java EE, dass die eingesetzten Technologien nach “Stufen” oder Ebenen (engl. Tiers) gruppiert werden können. Im Fall der Java Enterprise Edition kann im wesentlichen zwischen drei Tiers unterschieden werden, denen die oben genannten Technologien zugeordnet sind – der Enterprise Information Systems Tier (EIS), der Web Tier, und der Business Tier.
EIS (Enterprise Information Systems) Tier
Die Enterprise Information Systems (EIS) Tier von Java EE besteht aus Datenbankservern, ERP-Systemen und gegebenenfalls Legacy-Datenquellen wie Mainframes. Diese Ressourcen befinden sich typischerweise auf einem separaten Rechner und werden von Komponenten der Business-Ebene verwendet. Die Java Database Connectivity API (JDBC) ist eine Low-Level-API für den Zugriff auf Daten aus den zugrunde liegenden Datenspeichern. Ein typisches Einsatzgebiet von JDBC ist zum Beispiel die Ausführung von SQL-Abfragen auf einer bestimmten Datenbank. Mit der Java Persistence API kannst du bestimmte Daten einer Quelle Java-Objekten zuordnen und sie danach über diese verwalten. Die Java Persistenz-API ist eine der JDBC übergeordnete Schicht. Die Java EE Connector Architecture vereinfacht die Anbindung an weitere Ressourcen wie ERP- oder CRM-Systeme. Für die Definition und Verwaltung von Transaktionen, einschließlich verteilter Transaktionen, können und sollten wir die Java Transaction API (JTA) nutzen.
Web Tier
Die Web-Tier von Java Enterprise Edition enthält jene Komponenten, die die Interaktion zwischen zugreifenden Clients und Business-Tier verwalten. Dazu werden dynamisch Inhalte in verschiedenen Formaten zur Darstellung in den Clients generiert, Benutzereingaben entgegengenommen und entsprechende Resultate von Client Anforderungen aus der Business-Ebene zurückgegeben. Auch grundlegende Logik und die vorübergehende Datenhaltung in JavaBeans-Komponenten können in dieser Tier der Java Enterprise Edition realisiert werden. Auf der Web-Ebene wird zudem die Folge von Oberflächen-Darstellungen gesteuert. In der Web Tier kommen im Wesentlichen die folgenden Technologien zum Einsatz: Servlets sind Klassen, die dynamisch Anfragen verarbeiten und Antworten erstellen, meist für HTML-Seiten. Mit der Java Server Faces-Technologie enthält die Web-Ebene ein Framework für Web-UI-Komponenten wie Eingabefelder und Schaltflächen, die du auf Webseiten verwenden kannst. Umfangreiche, komponentenspezifische Funktionalität unterstützt Validierung und Konvertierung von Daten aus UI-Komponenten ebenso wie das serverseitige, permanente speichern von Eingabe-Daten und die Verwaltung des Zustands eines UI-Elements. Facelets sind eine Art von Java Server Faces Anwendungen, die anstelle von JSP-Seiten XHTML-Seiten zur Darstellung verwenden. Die Java EE Expression Language ist ein Satz von Standard-Tags, die in JSP- und Facelets-Quellcode eingesetzt werden, um Java EE-Komponenten zu referenzieren. Java Server Pages (JSP), gleichermaßen eine Technologie aus der Web-Tier, sind textbasierte Dokumente, die zu Servlets kompiliert werden und definieren, wie dynamische, zur Laufzeit erzeugte Inhalte zu statischen Seiten wie HTML-Seiten hinzugefügt werden können. Mit JavaBeans-Komponenten können temporäre Datenspeicher für die einzelnen Seiten einer Anwendung realisiert werden.
Business Tier
Die Business-Tier der Java Enterprise Edition besteht aus den Komponenten, die die Geschäftslogik einer Anwendung bereitstellen. Business-Logik ist Code, der Funktionalität zur Unterstützung eines bestimmten Geschäftsbereichs, gegebenenfalls einer bestimmten Branche wie die Finanzindustrie oder eine E-Commerce-Website implementiert. In einer ordnungsgemäß gestalteten Unternehmensanwendung ist die Kernfunktionalität immer in den Business-Tier-Komponenten enthalten. Enterprise JavaBeans (Enterprise Bean) Komponenten, oft abgekürzt mit EJB, sind verwaltete Komponenten(Managed Components), die die Kernfunktionalität einer Anwendung kapseln. Mit JAX-RS RESTful Web Services steht eine API zum Erstellen von Web Services, die auf HTTP-Methoden reagieren (zum Beispiel GET- oder POST-Methoden), zur Verfügung. JAX-RS Web Services werden nach den REST(REpresentational State Transfer) Prinzipien entwickelt. JAX-WS Web-Service-Endpoints ist eine API zum Erstellen und Konsumieren von SOAP-Webservices und ebenfalls der Java EE Business-Schicht zuzurechnen. Die Java Persistence API unterstützt den Zugriff auf Daten in den zugrunde liegenden Datenspeichern und die Zuordnung dieser Daten zu Java-Objekten. Java EE Managed Beans sind verwaltete Komponenten, die die Geschäftslogik einer Anwendung bereitstellen können, jedoch nicht die Transaktions- oder Sicherheitsmerkmale von Enterprise-Beans aufweisen.
Spezifikation der Java Enterprise Edition und deren Implementierungen
Java Enterprise Edition bezog sich ursprünglich auf von Sun (heute Oracle) veröffentlichte Produkte und Standards. Wer eine Standard-Java EE-Webanwendung entwickelt hat, würde EJBs und Java Server Faces einsetzen, die in einem dafür entworfenen, den J2EE Standard implementierenden Anwendungsserver laufen. Allerdings existiert eine Fülle von Open-Source-Bibliotheken und Produkten, die die gleichen Anforderungen ebenso gut (manche behaupten besser) erfüllen wie die Angebote von Sun/Oracle – In der Alltagssprache der meisten Entwickler bezieht sich der Term Java EE daher in der Regel auf die Gesamtheit dieser Umgebungen, zum Beispiel auch auf eine Spring / Tomcat / Hibernate Lösung, die nicht in allen Einzelheiten der ursprünglichen Spezifikation genügt. Java EE ist eine abstrakte Spezifikation, das bedeutet Jeder kann eine funktionierende Umsetzung der Spezifikation entwickeln und bereitstellen. Diese konkreten Implementierungen sind die sogenannten Applikationsserver wie WildFly, TomEE, GlassFish, Liberty, WebLogic und Weitere. Servlet Container implementieren dabei nur den JSP / Servlet Teil der äußerst umfangreichen Java EE API, Beispiele für solche Servlet Container sind etwa Tomcat und Jetty.
Wir als Java EE-Entwickler sollten Code schreiben, der die Spezifikation verwendet (konkret bedeutet das etwa: importiere nur javax. Klassen in Deinem Code anstelle von implementierungsspezifischen Klassen wie org.jboss.wildfly. , com.sun.glassfish. *, etc). So können wir unseren Code dann in jeder Implementierung (also auf jedem Applikationsserver) ausführen, falls du mit JDBC vertraut bist – es ist im Grunde das gleiche Konzept, nach dem auch die JDBC-Treiber funktionieren. Der Java Enterprise Edition SDK Download von der Webseite des Anbieters enthält grundsätzlich den GlassFish Server nebst einer Reihe von Dokumentationen und Beispielen und optional auch die NetBeans IDE. Du kannst jedoch ohne Weiteres einen anderen Server und / oder IDE verwenden.
Nun fragst Du Dich vielleicht: “Warum sind die Bibliotheken der Java Enterprise Edition nicht “Standard” und im regulären JVM und / oder dem SDK Download enthalten?” Die Java Enterprise Edition war in gewisser Weise einer der ersten Versuche, das bereits sehr umfangreiche JDK in Bereiche aufzuteilen, die einfacher zu verwalten und herunterzuladen sind. Viele Entwickler finden es bereits unangemessen, dass die grafischen Klassen (AWT, Swing) oder Applets in der JRE enthalten sind. Diese sind immer mit in der JRE enthalten, auch wenn alles, was diese in einem konkreten Szenario leisten muss, die Ausführung einiger trivialer Befehle auf einem Server ist. Für diese Art Anwendung würden erst recht keine Java EE spezifischen Klassen benötigt, aus diesem Grund ist die Aufteilung in Pakete sinnvoll.
Java Enterprise Edition und Container
In Java EE dreht sich alles um das zugrunde liegende Containerkonzept. Ein Container ist der Ausführungskontext, in dem Du Deine Anwendungen und Webservices ausführst und der eine Reihe vorgeschriebener Dienste beinhaltet, auf die Du zurückgreifen kannst. Jede Art dieser Dienste ist durch eine Spezifikation namens JSR definiert. JSR 907 beschreibt zum Beispiel die JTA (Java Transaction API), ein Standard-Verfahren um verteilte Transaktion auf verschiedenen, verteilten Ressourcen zu verwalten. Es gibt in der Regel viele verschiedene Implementierungen für eine gegebene JSR, die Implementierung, die Du verwendest, hängt vom jeweiligen Container-Anbieter ab. Welchen Container welches Anbieters Du verwendest sollte für Dich als Entwickler im Regelfall jedoch unerheblich sein, da Du davon ausgehen kannst, dass diese sich alle an einen vordefinierten Vertrag halten: die JSR-API. Um den Funktionsumfang von Java Enterprise Edition nutzen zu können, müssen Deine Anwendungen in einem solchen Container ausgeführt werden. Die beiden wichtigsten Container sind EJB- und Servlet-Container, sie sind auf jedem Application Server, der die Java EE Spezifikation einhält, vorhanden. Das Ziel von all dem ist es, eine Standard-Ausführungsumgebung zu definieren, damit Du das Paket Deiner Anwendung nur mit dem Wesentlichen erstellen kannst, etwa der Geschäftslogik, die Du programmiert hast. Damit wird unter anderem vermieden, dass man auf unbekannte und beliebige Bibliotheken von Drittanbietern zurückgreift, die man jeweils mit der eigentlichen Anwendung paketieren und ausliefern müsste, was insbesondere die Gefahr von Konflikten mit anderen Anwendungen auf diesem Server mit sich bringen würde. In Java Enterprise Edition kannst Du dich darauf verlassen, dass alle standardmäßigen und nicht-funktionalen Anforderungen wie Sicherheit, Transaktionen, Skalierbarkeit, Remote-Aufruf und vieles mehr vom Container zur Verfügung gestellt werden – Deine Programme müssen lediglich darauf aufbauen.