WikiDer > Java 2 Enterprise-Edition

Java 2 Enterprise Edition
Java-Plattformportal

Java 2 Enterprise-Edition(J2EE) ist eine Entwicklungsplattform der SoftwareunternehmenSonne Mikrosysteme. J2EE bietet eine Methode zum Entwerfen, Entwickeln, Kompilieren und Verwenden von Geschäftsanwendungen. Die Plattform bietet a mehrstufig, verteiltes Modell, wiederverwendbare Komponenten, ein Sicherheitsmodell, flexibles Transaktionsmanagement und Unterstützung für Internetdienste durch einen integrierten Datenaustausch auf Basis von XML.

Mit Hilfe von Java-Programmes ist soweit Server, J2EE wird häufig verwendet. J2EE ist eine Erweiterung des J2SDK, Java 2 Standard Edition, mit Bibliotheken, die eine große Anzahl von Klassen für die Programmierung von Serveranwendungen enthalten, die mit Datenbanken und die Nutzung aller Arten von generischen Diensten.

Die J2EE-Plattform ist ein plattformübergreifend, voll integrierte Lösung, die einen offenen Markt schafft, auf dem jeder Lieferant jeden Kunden beliefern kann. Ein solcher Markt ermutigt Anbieter zu Innovationen und verhindert, dass Kunden von proprietärer Technologie abhängig werden. Auf diese Weise profitieren Kunden mehr durch verbesserte Produkte und besseren Support.

Konzeptionelle Grundlage

Die Java 2 Enterprise Edition ist eine Erweiterung des StandardsJ2SDK die es einfacher machen soll verteilte Anwendungen einschreiben Java. Um dies zu erreichen, basiert J2EE auf dem Prinzip, die bereits vorhandene, "normale" Java-Sprache um APIs die eine Reihe von Dingen hinzufügen, die zum Schreiben verteilter Anwendungen für eine Geschäftsumgebung erforderlich sind. Zu den Dingen, die J2EE hinzufügt, gehören:

  • Unterstützung für eine verteilte Geschäftsanwendungsinfrastruktur,
  • Integrierte Authentifizierungsunterstützung
  • Integrierte Unterstützung für die gleichzeitige Nutzung durch mehrere Benutzer
  • Automatisierte Datenspeicherung
  • Integrierte Methoden zur Sicherstellung der Datenintegrität
  • Integrierte Unterstützung für die Integration von Unternehmensanwendungen, um Legacy-Anwendungen freizuschalten
  • Integrierte Unterstützung für support Namensdienste

Architektonische Basis

J2EE wurde um die Idee von a . gebaut dreistufig-Anwendung: eine vordere Abdeckung mit der Schnittstelle für den Nutzer eine Rückseite, in der Daten gespeichert werden (z.B. a Datenbank) und einer Zwischenschicht (oder mittlere Stufe) wo die eigentliche Arbeit der Anwendung verrichtet wird (die sog. Geschäftslogik). Dieser Aufbau folgt dem Prinzip der Model View ControllerArchitektur und das gesamte J2EE-Konzept basiert auf der Skalierbarkeit dieser Architektur.

Basierend auf dieser Architektur unterstützt J2EE die Entwicklung von zwei Anwendungsklassen: leichtere Anwendungen oder Webanwendungen und die sehr schweren Geschäftsanwendungen.

Kleinere, leichtere Anwendungen und Webanwendungen

Kleinere, leichtere Anwendungen in J2EE werden im Allgemeinen aus einem Ansichtsebene am Frontend bestehend aus Webseiten (eine Kombination aus HTML und Java Server-Seiten) und ein Modell-Stufe oder Datenbankebene hinten, auch in Kombination mit a Controller-Ebene besteht aus Servlets zwischen.

Die Schnittstelle zum Benutzer besteht in dieser Situation aus einer Kombination aus statischen Webseiten und Webseiten, die beim Laden vom Webserver (teilweise) dynamisch aufgebaut werden – letzteres übernimmt der JSPs (Webseiten mit verwobenen Codestücken) oder durch Servlets (Erweiterungen auf einem Webserver, die bei Bedarf ganze Webseiten auf einmal generieren können). Die dynamischen Webseiten sind grundsätzlich in der Lage, direkt mit der zugrunde liegenden Datenbank zu kommunizieren, enthalten dann auch die Geschäftslogik und damit eigentlich die mittlere Stufe "absorbieren".

Eine weitergehende Variante dieses Prinzips ist die, bei der Servlets als mittlere Stufe-Technologie. In diesem Setup existiert das Web/JSP-Frontend nur, um dem Benutzer Daten zu präsentieren, die eigentliche Arbeit wird von Servlets im mittlere Stufe. Es ist nun tatsächlich möglich, dass Servlets auch die endgültigen Webseiten generieren, aber häufiger wird gewählt, die Datenpräsentation rein in Webseiten/JSPs zu gießen und die Servlets nur die Daten erfassen zu lassen.

Das letztere Setup bietet eine Reihe von Vorteilen gegenüber dem ersteren. Diese Vorteile bestehen hauptsächlich in einer erhöhten Flexibilität der Anwendung (in Form der Möglichkeit, verschiedene Präsentationsformate oder JSPs mit denselben Daten zu kombinieren, die von einem Servlet bereitgestellt werden) und einer besseren Wartbarkeit und Skalierbarkeit (durch Aufteilen von Aufgaben auf mehrere separate Teile und Vermeidung von Spaghetti-Struktur, die reine Websites mit einem einzigen Stufe besitzen).

Schwerere Geschäftsanwendungen

Der besondere Nachteil des obigen Ansatzes besteht darin, dass der Entwickler einer solchen Anwendung darauf achten muss, dass sich seine Anwendung bei gleichzeitiger Nutzung durch mehrere Personen nicht selbst "beißt" (Transaktionalität etc. werden nicht in Servlets und JSPs einbacken).

Dies ist bei der Verwendung anders Enterprise JavaBeans (mehr oder weniger das Kronenstück des J2EE). EJBs sind als letzte Schicht zwischen den Servlets (oder JSPs) und der Modellschicht gedacht. EJBs sollen Dienste (interessant, Geschäftslogik) für eine interessierte Client-Anwendung bereitstellen und eine Abstraktion der Inhalte der Datenbank bilden. EJBs machen es einem Entwickler leicht, von Datenbanken und Datenbankstrukturen, von einer bestimmten Serverinfrastruktur und einem bestimmten Format zu abstrahieren. Und EJBs geben dem Entwickler die Möglichkeit, die Transaktionalität seiner Anwendungen zu handhaben, den gesamten Umgang mit der Datenbank zu automatisieren und seine Anwendungen perfekt zu integrieren ErbeSysteme und mit allen Arten von Systemen zu kommunizieren.

Um dies zu erreichen, nutzt ein EJB stark ein sogenanntes dekorieren Proxy, in J2EE-Begriffen a Container namens. In diesem System schreibt der Entwickler quasi nur die interessanten Teile des EJB und lässt seinen Code vom Anwendungsserver weiter in ein Paket packen, das ein Gateway zu seinem Code bildet. Der Zugang zu seinem Code ist nur durch das Tor möglich. Und natürlich kann der Port auch Funktionalitäten hinzufügen, wie transaktionale Kommunikation mit der Datenbank, synchronisierter Zugriff auf den Code of Interest und so weiter. Die genaue Funktionsweise des Ports selbst ist keine reine Programmierung, sondern gehört in den Bereich der deklarativen Entwicklung – dieses Verhalten wird ausschließlich durch Konfigurationsdateien bestimmt, nicht durch Code.

EJBs erleichtern den Aufbau zuverlässiger, skalierbarer Anwendungen in absehbarer Zeit erheblich. Der Nachteil dieses Systems besteht jedoch darin, dass es viel Konfigurationsarbeit und möglicherweise zusätzliche Netzwerkkommunikation (dh langsamer) erfordert. Der Einsatz ist daher nur für schwere Geschäftsanwendungen eine realistische Option, die viele Kunden erwarten oder sehr zuverlässig sein müssen.

Unterstützende APIs

Während J2EE als Plattform zweifellos vor allem für seine Komponententechnologien bekannt ist (EJB und Servlets Plus JSPs) die es dem Entwickler ermöglichen, eine verteilte Geschäftsanwendung aus konzeptionell sauberen, getrennten und wiederverwendbaren Komponenten zu erstellen, liegt die wahre Stärke von J2EE als Entwicklungsplattform nicht direkt im Vorhandensein dieser Komponententechnologien.

Viel wichtiger als das Vorhandensein der Komponenten selbst ist zweifellos, dass J2EE die Komponententechnologie mit component APIs um einiges zu kümmern, und nicht nur das, sondern diese APIs auch so zu integrieren, dass der Entwickler zumindest von EJBs kaum etwas davon mitbekommen muss (nun können sein, aber nicht brauchen zu sein) der Anwendung dieser APIs.

Zu den unterstützenden Technologien der J2EE-Plattform gehören: die JTA (Java-Transaktions-API), um die Interaktion mit Datenbanken und anderen Systemen transaktional zu gestalten; die API JDBC, um den Zugriff auf die Datenbank zu abstrahieren, um Anwendungen zu entwickeln, die direkt von einer beliebigen Datenbank auf eine andere Datenbank übertragen werden können; die API JNDIA, die es ermöglicht, mittels einer Art "Telefonbuch" schnell alle möglichen Dinge innerhalb eines Servers und Netzwerks zu finden; die API JMS, die den Datenaustausch mit unterschiedlichsten Anwendungen ermöglicht und somit Erbe- Entriegelungssysteme; die API JA, das einheitliche Sicherheit für den Zugriff auf Anwendungen bietet; und integrierte, umfassende Unterstützung für die Netzwerkkommunikation.

All diese APIs stehen dem J2EE-Entwickler zur Verfügung. Der Entwickler von EJBs kann viele davon oft sogar ohne darüber nachzudenken verwenden, da sie im Bean-Container versteckt sind.

Lieferantenneutral

Die J2EE-Spezifikation bietet eine umfassende Auflistung der Einrichtungen, die eine J2EE-Umgebung bereitstellen muss, einschließlich APIs und anderer Techniken. Wenn man sich nun nur die Spezifikation ansieht, kann ein Entwickler Anwendungen für eine generische J2EE-Umgebung entwickeln und sollte erwarten, dass diese Anwendung in jeder J2EE-Umgebung, die die Spezifikation unterstützt, einwandfrei läuft. Damit stellt J2EE prinzipiell nicht nur eine attraktive Entwicklungsplattform dar, sondern auch einen Mechanismus, der einen Anwender einer Anwendung und auch deren Entwickler von einer bestimmten Umgebung entkoppelt, was Vorteile hinsichtlich der zukünftigen Unterstützung und Anwendbarkeit alternder Anwendungen bietet gibt jedoch nicht an, wie es zu implementieren ist - das überlässt die Spezifikation dem Ersteller/Verkäufer der Umgebung. Dies hat in der Praxis zur Folge, dass die unterschiedlichen J2EE-Implementierungen der verschiedenen Anbieter nicht 100%ig miteinander kompatibel sind; Was auf einer Plattform entwickelt wird, läuft nicht unbedingt unverändert auf dem Anwendungsserver eines anderen Anbieters. Dies gefährdet den Anspruch von J2EE, eine Plattform zu sein, in der die Umgebung für die Softwareentwicklung und die für die Nutzung der Software vollständig voneinander getrennt sind und es eine Anbietersperre ("binden") lauert wieder.

Nachteile von J2EE

Der Hauptnachteil von J2EE ist zweifellos die Komplexität der Einrichtung und Verwaltung des Supportsystems. Servermaschinen, Anwendungsserver, Datenbankserver, Einstellungen all dieser Komponenten, das sind alles Dinge, die bis ins letzte Detail gepflegt werden müssen, um ein richtig funktionierendes System zu erhalten. Dies gilt sicherlich, wenn EJBs verwendet werden.

Bei der Betrachtung des Einsatzes von J2EE und EJBs ist daher sorgfältig abzuwägen, ob die Komplexität des Systems den Nutzen überwiegt. J2EE an sich eignet sich für die Entwicklung aller Arten von verteilten Anwendungen, aber gerade der Einsatz einer EJB-Architektur ist aufgrund der Komplexität eigentlich den schwereren Anwendungen vorbehalten, die viel Geld erfordern.

J2EE-Anwendungsserver

Zum Ausführen einer J2EE-Anwendung ist ein J2EE-Anwendungsserver erforderlich. Der Anwendungsserver implementiert die von der J2EE-Spezifikation beschriebenen APIs. Funktional besteht ein J2EE-Anwendungsserver aus zwei Behälter: ein Web-Container und ein EJB-Container. Der Web-Container wird verwendet, um Servlets und JSPs auszuführen, der EJB-Container führt die EJBs aus.

Es stehen verschiedene Anwendungsserver zur Verfügung: