Konzept: J2EE-Implementierungskonfigurationen
Diese Richtlinie erörtert die Vor- und Nachteile der verschiedenen Implementierungskonfigurationen für die J2EE-Plattform.
Beziehungen
Hauptbeschreibung

Einführung

Die J2EE-Plattform unterstützt die Entwicklung und Implementierung einer Vielzahl von Standardimplementierungskonfigurationen. Dank solcher Standardimplementierungskonfigurationen kann die Anwendungsentwicklung größtenteils ohne Mutmaßungen auskommen. In den folgenden Abschnitten finden Sie Beschreibungen der häufigsten Implementierungskonfigurationen sowie deren Vor- und Nachteile.

Wenn Sie mit den Konzepten von J2EE nicht vertraut sind, sollten Sie zunächst die in der Dokumentation Überblick über Java 2 Platform Enterprise Edition (J2EE) beschriebene Übersicht über J2EE lesen, bevor Sie fortfahren.

Eigenständige Implementierungskonfiguration

Die erste Implementierungskonfiguration wird in Abbildung 1 dargestellt. In dieser Konfiguration ist weder ein Webcontainer noch ein EJB-Container vorhanden, sondern der Client greift direkt auf die EIS-Ressourcen zu und ist selbst zuständig für Darstellungslogik, Geschäftslogik und Integrationslogik.

Im Begleittext beschriebenes Diagramm.

Abbildung 1: Eigenständige Implementierungskonfiguration

Auf den ersten Blick scheint diese Konfiguration eine attraktive Lösung für Anwendungen zu sein, die eine einfache Manipulation der in den EIS-Ressourcen enthaltenen Daten ermöglichen. Allerdings hat diese Konfiguration eine Reihe von potenziellen Nachteilen.

Änderungen an den EIS-Ressourcen können schwer wiegende Auswirkungen auf die Implementierung der Anwendung haben, die häufig unmittelbarer abhängig ist von der internen Struktur jeder EIS-Ressource, z. B. der Struktur von Datenbanktabellen. Jede Änderung an der Anwendung selbst macht ein vollständiges Rollout an jeden Benutzer erforderlich, da kein zentraler Server existiert auf dem die Anwendung implementiert ist, damit die Clients unmittelbaren Zugriff auf die neuesten Änderungen haben.

Außerdem wird in dieser Implementierungskonfiguration die Aufteilung der Zuständigkeiten nicht gefördert. Beispielsweise sind Darstellungslogik und Geschäftslogik häufig sehr eng miteinander verbunden, wodurch eine Unterstützung der Weiterentwicklung und Pflege der Anwendung nur schwer realisiert werden können.

Die echten Probleme werden allerdings erst dann erkennbar, wenn Sie die Anwendung skalieren möchten. Client-Workstations haben nur begrenzte Leistungsmöglichkeiten, daher sollte die Verarbeitung idealerweise auf mehrere Maschinen verteilt werden. Die eigenständige Konfiguration ist jedoch nicht für die Unterstützung der verteilten Verarbeitung vorgesehen. Wenn Sie versuchen, mehrere Clients mit gleichzeitigem Zugriff auf EIS-Ressourcen zu unterstützen, könnten Sie feststellen, dass Ihre Anwendungen durch die EIS-Ressource selbst eingeschränkt werden, beispielsweise bezüglich der Anzahl an gleichzeitig unterstützten Datenbankverbindungen.

EJB-zentrierte Implementierungskonfiguration

Die EJB-zentrierte Implementierungskonfiguration wird in Abbildung 2 dargestellt. In dieser Konfiguration befindet sich zwischen dem Clientcontainer und der EIS-Ressource ein EJB-Container - ein Webcontainer ist nicht vorhanden. Die Darstellungslogik befindet sich im Client, während die Geschäftslogik in EJBs enthalten ist. Statt direkt auf EIS-Ressourcen zuzugreifen, werden alle Clientanfragen von den passenden EJBs gesteuert. Die Clients sind daher von Änderungen in den EIS-Ressourcen abgeschirmt.

Im Begleittext beschriebenes Diagramm.

Abbildung 2: EJB-zentrierte Implementierungskonfiguration

Die EJB-zentrierte Implementierungskonfiguration ist so gestaltet, dass sie viele Probleme löst, die in der eigenständigen Implementierungskonfiguration existieren. Wenn man sie vom Blickwinkel der Skalierbarkeit aus betrachtet, dann kann die J2EE-Plattformimplementierung die Verarbeitung auf mehrere Maschinen verteilen. Darüber hinaus sorgt ein EJB-Container dafür, dass begrenzt verfügbare Ressourcen, beispielsweise Datenbankverbindungen, effizient genutzt werden. Bezüglich der Weiterentwicklung und Pflege der Anwendung unterstützt diese Konfiguration außerdem eine Trennung der Darstellungslogik von der Geschäftslogik.

Einer der Nachteile der EJB-zentrierten Implementierungskonfiguration besteht jedoch darin, dass selbst geringfügige Änderungen an der Benutzerschnittstelle ein vollständiges Rollout der Anwendung an jeden Benutzer erforderlich machen. Obwohl die in EJBs eingebundene Geschäftslogik auf dem Server erneut implementiert werden kann (so dass die Benutzer sofort Zugriff auf alle Änderungen haben), gilt dies nicht für die Darstellungslogik. Dies ist ein Nachteil, weil Darstellung und Funktionsweise (Look-and-feel) einer Anwendung häufigen Änderungen unterworfen sein können.

Webzentrierte Implementierungskonfiguration

Die webzentrierte Implementierungskonfiguration ist in Abbildung 3 dargestellt. In dieser Konfiguration befindet sich zwischen dem Clientcontainer und der EIS-Ressource ein Webcontainer - ein EJB-Container ist nicht vorhanden. Sowohl die Darstellungslogik als auch die Geschäftslogik werden von Elementen im Webcontainer (JSPs und Servlets) gesteuert. In dieser Konfiguration wird im Client eine einfache Markup-Sprache verwendet, z. B. HTML, obwohl die Verwendung von XML oder WML ebenfalls möglich ist.

Im Begleittext beschriebenes Diagramm.

Abbildung 3: Webzentrierte Implementierungskonfiguration

Eine webzentrierte Implementierungskonfiguration führt in der Regel dazu, dass insbesondere der Darstellung und Funktionsweise (Look-and-feel) der Anwendung besondere Bedeutung zukommen, während die Geschäftslogik in geringerem Maße unterstützt wird. Eine solche Konfiguration unterstützt häufige Änderungen in der Darstellung einer Anwendung und ist heute weit verbreitet.

Eine webzentrierte Implementierungskonfiguration bietet eine Reihe von Vorteilen. Erstens sind die Clients nicht von Änderungen an EIS-Ressourcen betroffen, weil sie nicht direkt auf diese Ressourcen zugreifen. Zweitens ist es möglich, die gesamte Anwendung erneut zu implementieren, ohne dass ein Rollout an die Benutzer erforderlich ist, weil sich die Anwendung vollständig auf einem Server befindet.

Allerdings ist zu bedenken, dass die Verwendung von EJBs in Bezug auf den auszuführenden Job zwar manchmal als Overkill betrachtet wird, das Weglassen von EJBs jedoch zu einigen der Problemen führt, die bei der eigenständigen Implementierungskonfiguration genannt wurden. Insbesondere unterstützt diese Konfiguration keine klare Trennung der Zuständigkeiten von Darstellungslogik und Geschäftslogik, so dass diese häufig sehr eng miteinander verbunden sind und die Weiterentwicklung und Pflege der Anwendung behindern. Außerdem gelten alle für die eigenständige Implementierungskonfiguration genannten Nachteile bezüglich der Skalierbarkeit auch für eine webzentrierte Architektur.

Mehrschichtige Implementierungskonfiguration

Die mehrschichtige Implementierungskonfiguration ist in Abbildung 4 dargestellt. Diese Konfiguration beinhaltet sowohl einen Webcontainer als auch einen EJB-Container und besitzt alle Vorteile der anderen Implementierungskonfigurationen ohne deren Nachteile. Die Darstellungslogik wird von Elementen im Webcontainer gesteuert und die Geschäftslogik von EJBs im EJB-Container.

Im Begleittext beschriebenes Diagramm.

Abbildung 4: Mehrschichtige Implementierungskonfiguration

Die Clients sind von Änderungen an EIS-Ressourcen nicht betroffen, weil sie nicht direkt auf diese Ressourcen zugreifen. Außerdem ist es möglich, die gesamte Anwendung erneut zu implementieren, ohne dass ein Rollout an die Benutzer erforderlich ist, weil sich die Anwendung vollständig auf dem Server befindet.

Unter dem Gesichtspunkt der Skalierbarkeit betrachtet, kann die Verarbeitung verteilt werden, so dass eine gleichzeitig ablaufende Verarbeitung unterstützt wird. Darüber hinaus sorgt ein EJB-Container dafür, dass begrenzt verfügbare Ressourcen, beispielsweise Datenbankverbindungen, effizient genutzt werden.

Unter dem Gesichtspunkt der Weiterentwicklung und Pflege der Anwendung betrachtet, unterstützt diese Konfiguration außerdem eine klare Trennung der Zuständigkeiten. Die Darstellungslogik ist von EIS-Ressourcen abgekoppelt, und die Geschäftslogik ist von der Darstellung und Funktionsweise (Look-and-feel) der Anwendung abgekoppelt. Eine klare Trennung kann dazu beitragen, dass die Arbeiten Entwicklern mit unterschiedlichen Qualifikationen zugeteilt werden, so dass Darstellungslogik und Geschäftslogik gleichzeitig entwickelt werden können.

Die mehrschichtige Implementierungskonfiguration kann außerdem die Migration von einer Clienteinheit (z. B. einem Webbrowser) auf eine andere (z. B. eine PDA) vereinfachen. Eine vollständige Umprogrammierung der Anwendung ist nicht erforderlich, weil die in EJBs eingebundene Geschäftslogik unverändert bleibt und auch so verwendet werden kann.

Zusammenfassend lässt sich schließen, dass eine Reihe von Implementierungskonfigurationen existieren, von denen jede ihre Vor- und Nachteile hat. Eine Zielsetzung der J2EE-Plattform ist es, so flexibel zu sein, dass sie jede Implementierungskonfiguration unterstützt, die für ein Unternehmen geeignet zu sein scheint, und gleichzeitig geeignet ist, um die Problemstellungen in diesem Unternehmen zu lösen.