Einführung in Java EE

Heute werden wir darüber sprechen, was es ist – Java EE: woraus es besteht, welche Merkmale die Architektur von Java EE-Anwendungen aufweist und wir werden Beschreibungen der verschiedenen Technologien dieser Plattform bereitstellen. Das Thema selbst ist umfangreich, aber wir bleiben nicht bei den Grundlagen stehen. Am Ende machen wir einen kleinen Vergleich von Java EE mit dem Spring Framework und beantworten die Frage: „Was ist besser zu lernen?“ (Spoiler: Natürlich muss man alles lernen =) ) Beginnen wir mit den Grundlagen.

Java EE – was ist das?

Java EE ist eine auf Java SE aufbauende Plattform, die eine API und Laufzeitumgebung für die Entwicklung und Ausführung umfangreicher, mehrschichtiger, skalierbarer, zuverlässiger und sicherer Netzwerkanwendungen bereitstellt. Solche Anwendungen werden Unternehmensanwendungen genannt, weil sie Probleme lösen, mit denen große Unternehmen konfrontiert sind. Allerdings können nicht nur große Unternehmen und Regierungsbehörden von solchen Anwendungen und den Vorteilen von Java EE profitieren. Die Lösungen, die die Java EE-Plattform bietet, sind für einzelne Entwickler und kleine Organisationen nützlich und manchmal einfach notwendig.

Java EE-Entwicklung

Java EE wird durch den 1998 gegründeten Java Community Process (JCP) entwickelt. Es ermöglicht interessierten Parteien, sich an der Gestaltung zukünftiger Versionen der Spezifikationen der Java-Sprachplattform zu beteiligen. Grundlage dieses Prozesses ist der JSR (Java Specification Request), formelle Dokumente, die die Spezifikationen und Technologien beschreiben, die zur Java-Plattform hinzugefügt werden sollen. Solche Anfragen werden von Community-Mitgliedern gestellt – normalen Entwicklern und Unternehmen. Zu letzteren zählen Oracle, Red Hat, IBM, Apache und viele andere. Diese. Die Jungs schlagen neue Funktionen und Extras zur Prüfung vor, die sie gerne in Java integrieren würden. Und dann führen sie eine Abstimmung durch, auf deren Grundlage entschieden wird, was in die nächste Version aufgenommen werden soll. Der Java EE-Versionsverlauf sieht folgendermaßen aus:

• J2EE 1.2 (Dezember 1999)
• J2EE 1.3 (September 2001)
• J2EE 1.4 (November 2003)
• Java EE 5 (Mai 2006)
• Java EE 6 (Dezember 2009)
• Java EE 7 (Mai)
• Java EE 8 (August 2017)
• Jakarta EE 8 (September 2019)

Im Jahr 2017 erfolgte ein neuer Meilenstein in der Entwicklung der Plattform: Oracle übertrug die Kontrolle über die Entwicklung von Java EE an die Eclipse Foundation. Und im April 2018 wurde Java EE in Jakarta EE umbenannt, das vollständig mit Java EE 8 kompatibel ist.

Java EE-Anwendungsarchitektur

Eine kurze Einführung. Um das Verständnis zu erleichtern, sprechen wir über die Struktur von Java EE-Anwendungen und einige der Begriffe, die wir später verwenden werden. Java EE-Anwendungen haben eine Struktur mit zwei Haupteigenschaften:

• Erstens mehrstufig. Java EE-Anwendungen sind mehrschichtig, und wir werden ausführlicher darauf eingehen.
• zweitens, Verschachtelung. Es gibt einen Java EE-Server (oder Anwendungsserver), in dem sich Komponentencontainer befinden. Diese Behälter enthalten (Bingo!) Komponenten.

Um die Architektur von Java EE-Anwendungen zu erklären, sprechen wir zunächst über Schichten. Was sind die Level? Welche Java EE-Technologien werden auf verschiedenen Ebenen verwendet? Als Nächstes besprechen wir, wie Anwendungsserver, Komponentencontainer und die Komponenten selbst miteinander verbunden sind. Bedenken Sie jedoch, dass es sich bei all diesen Betrachtungen um Ansichten aus unterschiedlichen Blickwinkeln derselben Sache handelt und die Reihenfolge hier nicht so wichtig ist.

Anwendungsebenen

Unter Multi-Tier-Anwendungen versteht man Anwendungen, die nach Funktionsprinzipien in isolierte Module (Ebenen, Schichten) unterteilt sind. Typischerweise (auch im Kontext der Java EE-Entwicklung) werden Unternehmensanwendungen in drei Ebenen unterteilt:

• Klient;
• Durchschnittsniveau;
• Datenzugriffsebene.

1. Die Clientschicht ist eine Anwendung, die Daten vom Java EE-Server (mittlere Schicht) anfordert. Der Server wiederum verarbeitet die Anfrage des Clients und gibt eine Antwort darauf zurück. Die Clientanwendung kann ein Browser, eine eigenständige Anwendung (mobil oder Desktop) oder eine andere Serveranwendung ohne grafische Oberfläche sein.

2. Die mittlere Ebene gliedert sich wiederum in die Web-Ebene und die Geschäftslogik-Ebene.

   1. Die Webschicht besteht aus einigen Komponenten, die die Interaktion zwischen Clients und der Geschäftslogikschicht ermöglichen.

      Auf Webebene kommen folgende Java-EE-Technologien zum Einsatz:

      • JavaServer Faces-Technologie (JSF);
      • Java Server Pages (JSP);
      • Ausdruckssprache (EL);
      • Servlets;
      • Kontexte und Abhängigkeitsinjektion für Java EE (CDI).

   2. Die Geschäftslogikschicht besteht aus Komponenten, die die gesamte Geschäftslogik der Anwendung implementieren. Geschäftslogik ist Code, der Funktionen bereitstellt, die die Anforderungen eines bestimmten Geschäftsbereichs (Finanzindustrie, Bankwesen, E-Commerce) abdecken. Diese Ebene kann als Kern des gesamten Systems betrachtet werden.

      Technologien, die auf dieser Ebene beteiligt sind:

      • Enterprise JavaBeans (EJB);
      • JAX-RS RESTful-Webdienste;
      • Java Persistence API-Entitäten;
      • Java-Nachrichtendienst.

3. Datenzugriffsebene. Diese Ebene wird manchmal als Ebene der Unternehmensinformationssysteme (EIS) bezeichnet. EIS besteht aus verschiedenen Datenbankservern, ERP-Systemen (Enterprise Resource Planning) und anderen Datenquellen. Die Geschäftslogikschicht greift für Daten auf diese Schicht zu.

   Auf dieser Ebene finden Sie Technologien wie:

   • Java Database Connectivity API (JDBC);
   • Java-Persistenz-API;
   • Java-EE-Connector-Architektur;
   • Java Transaction API (JTA).

Anwendungsserver, Container, Komponenten

Werfen wir einen Blick auf die Definition von Java EE aus Wikipedia. Java EE ist eine Reihe von Spezifikationen und zugehöriger Dokumentation für die Java-Sprache, die die Architektur der Serverplattform für die Aufgaben mittlerer und großer Unternehmen beschreiben. Um besser zu verstehen, was ein „Satz von Spezifikationen“ in diesem Zusammenhang bedeutet, ziehen wir eine Analogie zu einer Java-Schnittstelle. Die Java-Schnittstelle selbst ist ohne Funktionalität. Es definiert lediglich einen Vertrag, gemäß dem einige Funktionen implementiert werden. Aber auch andere Klassen implementieren die Schnittstelle. Darüber hinaus kann eine Schnittstelle mehrere Implementierungen haben, die sich in einigen Details voneinander unterscheiden können. Mit der Spezifikation ist alles genau gleich. Bei Naked Java EE handelt es sich lediglich um eine Reihe von Spezifikationen. Diese Spezifikationen werden von verschiedenen Java EE-Servern implementiert. Ein Java-EE-Server ist eine Serveranwendung, die die Java-EE-Plattform-APIs implementiert und Standard-Java-EE-Dienste bereitstellt. Java EE-Server werden manchmal als Anwendungsserver bezeichnet. Serverdaten können Anwendungskomponenten enthalten, die jeweils einer eigenen Ebene in einer mehrstufigen Hierarchie entsprechen. Der Java EE-Server stellt diesen Komponenten verschiedene Dienste in Form eines Containers zur Verfügung. Container sind die Schnittstelle zwischen den von ihnen gehosteten Komponenten und der plattformunabhängigen Low-Level-Funktionalität, die die Komponente unterstützt. Container stellen den von ihnen gehosteten Komponenten spezifische Dienste zur Verfügung. Zum Beispiel Entwicklungslebenszyklusmanagement, Abhängigkeitsinjektion, Parallelität usw. Container verbergen technische Komplexität und erhöhen die Portabilität. In Java EE gibt es vier verschiedene Arten von Containern :

1. Applet-Container werden von den meisten Browsern implementiert. Bei der Entwicklung von Applets können Sie sich auf die visuelle Seite der Anwendung konzentrieren, während der Container eine sichere Umgebung bietet.

2. Der Application Client Container (ACC) enthält eine Reihe von Java-Klassen, Bibliotheken und anderen Dateien, die zum Implementieren von Funktionen wie Injektion, Sicherheitsverwaltung und Benennungsdiensten in Java SE-Anwendungen erforderlich sind.

3. Der Webcontainer stellt die Kerndienste zum Verwalten und Ausführen von Webkomponenten (Servlets, EJB Lite-Komponenten, JSP-Seiten, Filter, Listener, JSF-Seiten und Webdienste) bereit. Es ist für die Instanziierung, Initialisierung und den Aufruf von Servlets sowie für die Unterstützung der HTTP- und HTTPS-Protokolle verantwortlich. Dieser Container wird verwendet, um Webseiten an Client-Browser bereitzustellen.

4. Der EJB-Container (Enterprise Java Bean) ist für die Verwaltung und Ausführung der EJB-Modellkomponenten verantwortlich, die die Geschäftslogikschicht der Anwendung enthalten. Es erstellt neue EJB-Bean-Entitäten, verwaltet ihren Lebenszyklus und stellt Dienste wie Transaktionen, Sicherheit, Parallelität, Verteilung, Benennung oder asynchrone Aufruffunktionen bereit.

Auch in Java EE gibt es vier Arten von Komponenten , die eine Implementierung der Java EE-Spezifikation unterstützen muss:

1. Applets sind grafische Benutzeroberflächenanwendungen (GUI), die in einem Browser ausgeführt werden. Sie nutzen die umfangreiche Swing-API, um leistungsstarke Benutzeroberflächen zu erstellen.

2. Anwendungen sind Programme, die auf der Clientseite ausgeführt werden. Typischerweise handelt es sich dabei um grafische Benutzeroberflächen (GUI), die für die Stapelverarbeitung verwendet werden.

3. Webanwendungen (bestehend aus Servlets und ihren Filtern, Web-Event-Listenern, JSP- und JSF-Seiten) – werden in einem Webcontainer ausgeführt und reagieren auf HTTP-Anfragen von Webclients. Servlets unterstützen auch SOAP- und RESTful-Webservice-Endpunkte.

4. Unternehmensanwendungen (erstellt mit Enterprise Java Beans, Java Message Service, Java Transaction API, Asynchronous Calls, Time Services) werden in einem EJB-Container ausgeführt. Containerverwaltete EJBs verarbeiten transaktionale Geschäftslogik. Der Zugriff kann entweder lokal oder remote über RMI (oder HTTP für SOAP- und RESTful-Webdienste) erfolgen.

Das folgende Diagramm zeigt eine typische Java EE-Anwendungsarchitektur:

Technologien

Also haben wir die Architektur geklärt. Die Gesamtstruktur sollte klar sein. Bei der Beschreibung der Architekturkomponenten haben wir einige Java EE-Technologien wie EJB, JSP usw. angesprochen. Schauen wir sie uns genauer an. Die folgende Tabelle zeigt die Technologien, die hauptsächlich auf Client-Ebene eingesetzt werden: Die folgende Tabelle zeigt die auf der Ebene der Geschäftslogik verwendeten Technologien: Die folgende Tabelle zeigt die auf der Datenzugriffsebene verwendeten Technologien:

Java EE vs. Spring

Das Spring Framework gilt als Konkurrent von Java EE. Betrachtet man die Entwicklung dieser beiden Plattformen, ergibt sich ein interessantes Bild. Die ersten Versionen von Java EE entstanden unter Beteiligung von IBM. Sie erwiesen sich als cool, aber unhandlich, schwer und unpraktisch in der Handhabung. Entwickler hatten Schwierigkeiten, weil sie eine große Anzahl von Konfigurationsdateien verwalten mussten und andere Gründe die Entwicklung erschwerten. Gleichzeitig wurde Spring IoC geboren. Es war eine kleine, schöne und benutzerfreundliche Bibliothek. Es wurde auch eine Konfigurationsdatei verwendet, aber im Gegensatz zu Java EE gab es nur eine. Die Einfachheit von Spring hat dazu geführt, dass fast jeder begann, dieses Framework in seinen Projekten zu verwenden. Und dann begannen Spring und Java EE ihren Weg zum selben Ziel, aber von unterschiedlichen Enden aus. Pivotal Software, der Entwickler von Spring, begann, ein Projekt nach dem anderen zu veröffentlichen, um alle möglichen und unmöglichen Anforderungen von Java-Entwicklern abzudecken. Nach und nach wurde das, was zuvor Spring hieß, zunächst zu einem der Projekte und verschmolz dann vollständig mit mehreren anderen Projekten in Spring Core. All dies führte zu der unvermeidlichen Komplikation des Frühlings im Vergleich zu dem, was er ursprünglich war. Mit der Zeit wurde es sehr schwierig, den Überblick über das gesamte Gewirr der Spring-Abhängigkeiten zu behalten, und es entstand der Bedarf an einer separaten Bibliothek, die alles selbst laden und ausführen konnte (jetzt ist der beliebte Spring Boot irgendwo ins Stocken geraten). Während dieser ganzen Zeit hat JCP an einem Ziel gearbeitet: die größtmögliche Vereinfachung aller Möglichkeiten in Java EE zu erreichen. Daher reicht es in einem modernen EJB zur Beschreibung einer Bean aus, eine Annotation über der Klasse anzugeben, wodurch der Entwickler Zugriff auf die volle Leistungsfähigkeit der Enterprise Java Beans-Technologie erhält. Und ähnliche Vereinfachungen haben sich auf jede Spezifikation innerhalb von Java EE ausgewirkt. Daher sind Spring und Java EE hinsichtlich der Funktionalität in etwa gleichwertig. Manches ist besser, manches schlechter, aber wenn man global schaut, gibt es keine großen Unterschiede. Das Gleiche gilt für die Komplexität der Aufgabe. Sowohl Spring als auch Java EE sind hervorragende Tools. Vielleicht das Beste, was es derzeit zum Erstellen von Unternehmensnetzwerkanwendungen in Java gibt. Java EE kann jedoch im Allgemeinen nur innerhalb des Enterprise Application Servers funktionieren (Tomcat ist keiner), und eine Anwendung auf dem Spring-Stack kann auf allem (auf demselben Tomcat) und sogar ohne Server ausgeführt werden (da sie ausgeführt wird). es in sich selbst unabhängig). Dies macht Spring zu einem idealen Werkzeug für die Entwicklung kleiner Front-End-GUI-Anwendungen oder Microservice-Architekturen. Doch die Beseitigung der Abhängigkeit von Anwendungsservern wirkte sich negativ auf die Skalierbarkeit von Spring-Anwendungen aus. Und Java EE eignet sich gut für die Implementierung einer skalierbaren monolithischen Clusteranwendung. Entwickler, die mit dem Spring Framework vertraut sind, sind derzeit auf dem Arbeitsmarkt stärker gefragt. Historisch gesehen geschah das so: Zu einer Zeit, als Java EE übermäßig kompliziert war, „gewinnte Spring einen Kundenstamm“. Und doch gibt es keine klare Antwort auf die Frage, was man Spring oder Java EE lernen soll. Einem Anfänger kann der folgende Rat gegeben werden. Machen Sie sich (zumindest oberflächlich) mit beiden Plattformen vertraut. Schreiben Sie ein kleines Heimprojekt in Java EE und Spring. Und dann tiefer in die Rahmenbedingungen eintauchen, die bei der Arbeit benötigt werden. Dadurch wird der Wechsel zwischen Spring und Java EE nicht schwierig sein.

Ergebnisse

Ein umfangreiches Thema kann natürlich nicht in einem Artikel behandelt werden! Nach einer Menge neuer Begriffe möchten Sie dieses Wissen wahrscheinlich auf ein Beispiel aus der Praxis „anwenden“. Deshalb werden wir uns weiterhin mit Java EE beschäftigen: Im nächsten Artikel finden Sie praktische Lektionen zum Einrichten einer lokalen Umgebung für die Java EE-Entwicklung.