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.
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.
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.
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.
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.
|