Sun Java Enterprise System 5 - Technische Übersicht

Kapitel 2 Java ES-Lösungsarchitekturen

Dieses Kapitel bietet eine Übersicht über die Architekturkonzepte, auf denen die Java ES-Lösungen basieren. In diesem Kapitel wird gezeigt, wie Systemdienstkomponenten und Dienstqualitätskomponenten eingesetzt werden, um verteilte Unternehmenslösungen zu unterstützen.

Architekturen von Java ES-Lösungen bieten zwei Aspekte: Eine Logische Architektur und eine Bereitstellungs- architektur. Die logische Architektur stellt die Interaktionen zwischen den logischen Modulblöcken (den Softwarekomponenten) einer Lösung dar. Die Bereitstellungsarchitektur stellt die Zuordnung der logischen Architektur zu einer physischen Computerumgebung dar. Java ES-Komponenten spielen sowohl in logischen Architekturen als auch in Bereitstellungsarchitekturen eine wichtige Rolle.

In diesem Kapitel werden ein Architektur-Framework für die Konzeption der Architektur von Java ES-Lösungen sowie eine Beispiellösung, die auf diesem Framework aufbaut, beschrieben. Das Kapitel enthält die folgenden Abschnitte:

Java ES-Architektur-Framework

Java ES-Komponenten unterstützen die Bereitstellung verteilter Softwarelösungen. Damit die benötigte Funktionalität auf der von den Geschäftsanforderungen vorgegebenen Ebene der Leistung, Verfügbarkeit, Sicherheit, Skalierbarkeit und Zweckmäßigkeit erreicht wird, müssen solche Softwarelösungen korrekt entworfen werden.

Bei der Konzeption von Lösungen in Unternehmensstärke sind verschiedene Architekturdimensionen zu berücksichtigen. Diese Dimensionen repräsentieren unterschiedliche Perspektiven, aus denen die Interaktionen der vielen, solche Systeme bildenden Softwarekomponenten betrachtet werden. Insbesondere bei der Konzeption verteilter Systeme sind die drei folgenden Architekturdimensionen zu berücksichtigen:

Infrastrukturdienst-Abhängigkeiten. Diese Dimension hebt die Rolle von Systemdienstkomponenten bei der Unterstützung verteilter Lösungen hervor (siehe Systemdienst- komponenten).
Logische Schichten. Diese Dimension stellt die logische und physische Unabhängigkeit von Lösungskomponenten in den Vordergrund, die in einer Netzwerk- oder Internetumgebung bereitgestellt werden sollen.
Dienstqualität. Diese Dimension stellt dar, wie Dienstqualitätsanforderungen (Verfügbarkeit, Sicherheit, Skalierbarkeit und Zweckmäßigkeit) erreicht werden, wobei die Rolle der Dienstqualitätskomponenten berücksichtigt wird (siehe Dienstqualitätskomponenten).

In der folgenden Abbildung sind diese drei Dimensionen der Lösungsarchitektur dargestellt.

Abbildung 2–1 Dimensionen einer Java ES-Lösungsarchitektur

Dieses Diagramm stellt das dreidimensionale Framework mit logischen Schichten, Infrastrukturdienstebenen und Dienstqualitäten dar.

Diese drei Dimensionen bilden zusammen ein einziges Framework, das die Beziehungen zwischen den Softwarekomponenten (sowohl application components als auch Infrastrukturkomponenten) berücksichtigt, die für das Erreichen der für eine Softwarelösung benötigten Dienstfunktionen und der Dienstqualität erforderlich sind.

In den folgenden Abschnitten werden die drei Dimensionen nacheinander beschrieben. Anschließend wird eine Synthese der drei Dimensionen in einem zusammengeführten Framework vorgenommen.

Dimension 1: Infrastrukturdienstabhängigkeiten

Die interagierenden Softwarekomponenten verteilter Unternehmensanwendungen setzen Basisinfrastrukturdienste voraus, die den verteilten Komponenten die Kommunikation untereinander, die Koordination ihrer Arbeit, die Implementierung eines sicheren Zugriffs usw. ermöglichen. In diesem Abschnitt wird die Schlüsselrolle einiger Java ES-Komponenten bei der Bereitstellung dieser Infrastrukturdienste erläutert.

Infrastrukturdienstebenen

Bei der Konzeption eines verteilten Softwaresystems müssen Sie unabhängig davon, ob das Softwaresystem überwiegend aus selbst entwickelten oder fertigen Java ES-Komponenten besteht, einige Infrastrukturdienste berücksichtigen. Diese Dienste arbeiten auf vielen Ebenen.

Die Infrastrukturdienstabhängigkeiten der Lösungsarchitektur werden in Abbildung 2–2 dargestellt. Die in dieser Abbildung dargestellten Ebenen sind eine vergrößerte Ansicht der in Abbildung 1–1 gezeigten Infrastrukturdienstebene. Die Hierarchie der in Abbildung 2–2 dargestellten Dienste und die Abhängigkeiten zwischen den Diensten bilden eine wichtige Dimension der logischen Architektur der Lösung. Diese Infrastrukturdienste liefern das Grundprinzip für Java ES-Systemdienstkomponenten (siehe Systemdienst- komponenten).

Im Allgemeinen können die in der folgenden Abbildung dargestellten Dienste in drei große Gruppen unterteilt werden: Plattformdienste auf niedrigster Ebene , Anwendungsdienste auf höchster Ebene und eine Gruppe von Middleware-Diensten , die ihren Namen ihrer Position zwischen den beiden anderen Gruppen verdanken.

Abbildung 2–2 Dimension 1: Infrastrukturdienstebenen

Dieses Diagramm zeigt die verteilten Dienstinfrastrukturebenen von der untersten Ebene der Betriebssystemplattform-Dienste bis hinauf zur höchsten Ebene der Integrationsdienste.

Die folgenden Beschreibungen der verschiedenen Infrastrukturdienstebenen beziehen sich, wenn relevant, auf Java-Programmiersprachenprodukte und werden von der niedrigsten bis zur höchsten Ebene aufgeführt, wie in Abbildung 2–2 dargestellt:

Betriebssystemplattformen. Bieten die Basisunterstützung für alle Prozesse, die auf einem Computer ausgeführt werden. Das Betriebssystem verwaltet die physischen Geräte sowie den Arbeitsspeicher, die Threads und andere Ressourcen, die zur Unterstützung der Java Virtual Machine (JVM^TM-Machine) erforderlich sind.
Netzwerktransport. Bietet die grundlegende Netzwerkunterstützung für die Kommunikation zwischen den verteilten Anwendungskomponenten, die auf den verschiedenen Computern ausgeführt werden. Zu diesen Diensten gehört auch die Unterstützung von Protokollen wie TCP und HTTP. Andere Kommunikationsprotokolle auf höheren Ebenen (siehe Messaging-Ebene) sind von diesen grundlegenden Transportdiensten abhängig.
Persistenz. Bietet Unterstützung für den Zugriff auf und die Speicherung von statischen Daten (wie Benutzer-, Verzeichnis- oder Konfigurationsinformationen) und dynamischen Anwendungsdaten (Informationen, die häufig aktualisiert werden).
Messaging: Bietet Unterstützung für die synchrone und asynchrone Kommunikation zwischen den Anwendungskomponenten. Synchrones Messaging besteht im Senden und Empfangen von Nachrichten in Echtzeit und umfasst Remote-Methodenaufrufe (RMI) zwischen J2EE-Komponenten und SOAP-Interaktionen zwischen Webdiensten. Asynchrones Messaging besteht in einer Kommunikation, bei der das Senden einer Nachricht nicht davon abhängt, ob der Konsument bereit ist, diese sofort zu empfangen. Die Spezifikationen für asynchrones Messaging, beispielsweise Java Message Service (JMS) und ebXML, sorgen für garantierte Zuverlässigkeit und andere Aspekte der Messaging-Semantik.
Laufzeit: Bietet die Unterstützung, die für jedes verteilte Komponentenmodell, beispielsweise J2EE- oder CORBA-Modelle, erforderlich ist. Neben dem Remote-Methodenaufruf, der für eng miteinander verknüpfte verteilte Komponenten benötigt wird, umfassen die Laufzeitdienste die Komponentenstatusverwaltung (Lebenszyklusverwaltung), die Thread-Pool-Verwaltung, die Synchronisierung (Mutex-Sperrung), Persistenzdienste, die verteilte Transaktionsüberwachung und die verteilte Ausnahmenverarbeitung. In einer J2EE-Umgebung werden diese Laufzeitdienste von EJB-Containern, Webcontainern und nachrichtengesteuerten Bean-Containern (MDB-Containern) auf einem Anwendungs- oder Webserver bereitgestellt.
Sicherheit und Richtlinie. Bietet Unterstützung für den sicheren Zugriff auf Anwendungsressourcen. Diese Dienste umfassen die Unterstützung für Richtlinien, die den gruppen- oder rollenbasierten Zugriff auf verteilte Ressourcen steuern, sowie Single Sign-On -Funktionen. Single Sign-On ermöglicht, dass die Authentifizierung eines Benutzers bei einem Dienst in einem verteilten System automatisch auf andere Dienste (J2EE-Komponenten, Geschäftsdienste und Webdienste) in diesem System angewendet wird.
Benutzerzusammenarbeit: Bietet Dienste, die bei der Unterstützung der direkten Kommunikation zwischen den Benutzern und der Zusammenarbeit der Benutzer in Unternehmens- und Internetumgebungen eine wichtige Rolle spielen. Diese Dienste sind Geschäftsdienste auf Anwendungsebene, die in der Regel von eigenständigen Servern, wie beispielsweise von einem E-Mail- oder einem Calendar Server, bereitgestellt werden.
Integration: Stellt die Dienste für die Aggregation vorhandener Geschäftsdienste bereit. Bietet eine gemeinsame Schnittstelle für den Zugriff auf die Dienste, wie dies in einem Portal der Fall ist, indem die Dienste über eine Prozess-Engine integriert werden, die diese innerhalb eines Produktionsworkflows koordiniert. Die Integration kann auch in Form von Business-to-Business-Interaktionen zwischen verschiedenen Unternehmen erfolgen.

Die in Abbildung 2–2 dargestellten Dienstebenen spiegeln die gegenseitige Abhängigkeit der Infrastrukturdienste wider, von der untersten Ebene der Betriebssystemdienste bis hinauf zur höchsten Ebene der Anwendungs- und Integrationsdienste. Im Allgemeinen ist jeder Dienst von untergeordneten Diensten abhängig und unterstützt selbst übergeordnete Dienste. Abbildung 2–2 stellt jedoch keine strenge Ebenenschichtung der Infrastrukturdienste dar. Dienste höherer Ebenen können direkt mit Diensten niedrigerer Ebenen interagieren, ohne von Zwischenebenen abhängig zu sein. So sind beispielsweise bestimmte Laufzeitdienste direkt von den Plattformdiensten abhängig, ohne eine der dazwischen liegenden Dienstebenen zu benötigen. Zusätzlich könnten auch andere Dienstebenen, wie Überwachungs- oder Verwaltungsdienste, ebenfalls in diese Konzeptdarstellung aufgenommen werden.

Java ES-Infrastrukturdienstkomponenten

Java ES-Komponenten implementieren die verteilten Infrastrukturdienstebenen, die in Abbildung 2–2 dargestellt sind. Die Positionierung der Systemdienstkomponenten innerhalb der verschiedenen Ebenen wird in der folgenden Abbildung dargestellt:

Abbildung 2–3 Java ES-Systemdienstkomponenten

Dieses Diagramm zeigt die Position der einzelnen Java ES-Systemdienstkomponenten in den verschiedenen Ebenen der verteilten Infrastrukturdienste.

Hinweis –

Die in der Abbildung schattiert dargestellten Kästchen verweisen auf Komponenten, die nicht in Java ES enthalten sind. Zwar sind Benutzerzusammenarbeitskomponenten nicht Bestandteil von Java ES, sie werden jedoch oftmals gemeinsam mit Java ES-Komponenten bereitgestellt und innerhalb von Java ES-Architekturen verwendet. Diese Komponenten sind Teil der Sun Java Communications Suite und werden in diesem Dokument nur zu Darstellungszwecken referenziert. Betriebssystemplattformen sind darüber hinaus formell betrachtet nicht Teil von Java ES, sie sind jedoch in der Abbildung aufgeführt, um die Betriebssystemplattformen aufzuzeigen, auf denen Java ES-Komponenten unterstützt werden.

Java ES-Infrastrukturdienstabhängigkeiten

Im Allgemeinen ist jede der in Abbildung 2–3 dargestellten Java ES-Systemdienstkomponenten von in der Infrastruktur unter ihr liegenden Komponenten anhängig und unterstützt darüber liegende Komponenten. Diese Beziehung von Abhängigkeit und Unterstützung bildet einen Schlüsselfaktor bei der Konzeption logischer Architekturen.

Die folgende Abbildung zeigt die spezifischen Abhängigkeiten zwischen den Java ES-Systemdienstkomponenten, die in Abbildung 2–3 von oben nach unten verlaufend dargestellt werden.

Tabelle 2–1 Beziehungen zwischen Java ES-Systemdienstkomponenten


Komponente	Abhängig von	Bietet Unterstützung für
Portal Server	Anwendungsserver oder Web Server Access Manager Directory Server Wenn zur Verwendung von entsprechenden Kanälen konfiguriert: Calendar Server, Messaging Server und Instant Messaging [Calendar Server, Messaging Server und Instant Messaging-Komponenten sind als Teil der Sun Java Communications Suite verfügbar.]	Keine
Access Manager	Anwendungsserver oder Web Server Directory Server	Portal Server Wenn konfiguriert für Single Sign-On: Calendar Server, Messaging Server und Instant Messaging
Anwendungsserver	Message Queue Directory Server (für verwaltete Objekte)	Portal Server Access Manager
Message Queue	Directory Server (für verwaltete Objekte)	Anwendungsserver
Web Server	Access Manager (für die Zugriffssteuerung)	Portal Server Access Manager
Directory Server	Keine	Portal Server Access Manager Calendar Server Messaging Server Instant Messaging
Service Registry	Java-DB	Application Server-basierte Komponenten
Java-DB	Keine	Service Registry

Dimension 2: Logische Schichten

Die interagierenden Softwarekomponenten verteilter Unternehmensanwendungen können logischen Schichten zugeordnet werden. Diese Schichten stellen die logische und physische Unabhängigkeit von Softwarekomponenten auf der Grundlage der Art der von ihnen angebotenen Dienste dar.

Die Dimension der logischen Schichten in einer Lösungsarchitektur ist in der folgenden Abbildung dargestellt.

Abbildung 2–4 Dimension 2: Logische Schichten für verteilte Unternehmensanwendungen

Die Abbildung zeigt vier logische Schichten. Von links nach rechts: Client-Schicht, Präsentationsschicht, Geschäftsdienstschicht und Datenschicht.

Logische Schichtenarchitekturen stellen überwiegend die in Abbildung 1–1 dargestellte Ebene der verteilten Unternehmensanwendung dar. Die unter Infrastrukturdienstebenen behandelten Java ES-Systemdienstkomponenten unterstützen Anwendungskomponenten aller in Abbildung 2–4 dargestellten logischen Schichten. Während sich logische Schichtenkonzepte vorwiegend auf benutzerdefinierte Unternehmensanwendungen beziehen, beziehen sie sich darüber hinaus auf Dienste, die von Komponenten der Sun Java Communications Suite und einigen Zugangsdiensten bereitgestellt werden.

Beschreibung der logischen Schichten

Dieser Abschnitt enthält Kurzbeschreibungen der vier logischen Schichten, die in Abbildung 2–4 dargestellt sind. Die Beschreibungen beziehen sich auf Anwendungskomponenten, die mithilfe eines auf der J2EE-Plattform basierenden Komponentenmodells implementiert wurden. Andere verteilte Komponentenmodelle hingegen, beispielsweise CORBA, unterstützen ebenfalls diese Architektur.

Client-Schicht: Die Client-Schicht umfasst die Anwendungslogik, auf die ein Endbenutzer über eine Benutzeroberfläche direkt zugreift. Die Logik in der Client-Schicht kann browserbasierte Clients, auf einem Desktop-Computer ausgeführte Java-Komponenten oder auf einem Handheld-Gerät ausgeführte mobileJava^TM 2 Platform Micro Edition-Clients (J2ME^TM-Plattform) enthalten.
Präsentationsschicht: Die Präsentationsschicht umfasst Anwendungslogik, die Daten für die Zustellung an die Client-Schicht vorbereitet und Anforderungen der Client-Schicht für die Zustellung an die Back-End-Geschäftslogik verarbeitet. Die Logik in der Präsentationsschicht umfasst in der Regel J2EE-Komponenten, wie Java Servlet-Komponenten oder JSP-Komponenten, die Daten für die Zustellung im HTML- oder XML-Format vorbereiten oder Verarbeitungsanforderungen empfangen. Diese Schicht kann auch einen Zugangsdienst enthalten, der einen personalisierten, sicheren und benutzerdefinierten Zugriff auf die in der Geschäftsdienstschicht vorhandenen business services ermöglichen kann.
Geschäftsdienstschicht: Die Geschäftsdienstschicht umfasst die Logik, die die Hauptfunktionen der Anwendung ausführt: Datenverarbeitung, Implementierung der Geschäftsregeln, Koordination mehrerer Benutzer und Verwaltung externer Ressourcen, wie Datenbanken oder Legacy-Systeme. In der Regel umfasst diese Schicht eng miteinander verknüpfte Komponenten, die dem verteilten J2EE-Komponentenmodell entsprechen, wie Java-Objekte, EJB-Komponenten oder nachrichtengesteuerte Beans. Einzelne J2EE-Komponenten können für die Bereitstellung komplexer Geschäftsdienste, beispielsweise Inventardienste oder Steuerberechnungsdienste, zusammengefügt werden. Einzelne Komponenten und Dienstgruppen können in einem dienstorientierten Architekturmodell zu lose miteinander verknüpften Webdiensten zusammengefasst werden, die dem Schnittstellenstandard SOAP (Simple Object Access Protocol) entsprechen. Geschäftsdienste können auch als eigenständige Server, beispielsweise als Unternehmens-Calendar Server oder Messaging Server, erstellt werden.
Datenschicht: Die Datenschicht umfasst Dienste, durch die persistente Daten bereitgestellt werden, die von der Geschäftslogik verwendet werden. Die Daten können Anwendungsdaten sein, die in einem Datenbankverwaltungssystem gespeichert sind, oder Ressourcen- und Verzeichnisinformationen, die in einem Lightweight Directory Access Protocol-Datenspeicher (LDAP-Datenspeicher) gespeichert sind. Die Datendiensten können auch Daten aus externen Quellen oder Daten aus Legacy-Computersystemen enthalten.

Logische und physische Unabhängigkeit

Die in Abbildung 2–4 gezeigte Architekturdimension betrachtet vor allem die logische und physische Unabhängigkeit von Komponenten, die durch vier separate Schichten dargestellt wird. Diese Schichten stellen die Partitionierung der Anwendungslogik über verschiedene in einer Netzwerkumgebung vorhandene Computer hinweg dar:

Logische Unabhängigkeit: Die vier Schichten des Architekturmodells stellen die logische Unabhängigkeit dar: Sie können die Anwendungslogik in einer Schicht (beispielsweise in der Geschäftsdienstschicht) unabhängig von der Logik in den anderen Schichten ändern. Genauso können Sie Ihre Implementierung der Geschäftslogik ändern, ohne die Logik in der Präsentations- oder Client-Schicht ändern oder aktualisieren zu müssen. Diese Unabhängigkeit bedeutet, dass Sie beispielsweise neue Typen von Client-Komponenten aufnehmen können, ohne die Geschäftsdienstkomponenten zu ändern.
Physische Unabhängigkeit: Die vier Schichten stellen auch die physische Unabhängigkeit dar: Sie können die Logik in vier verschiedenen Schichten auf verschiedenen Hardwareplattformen (verschiedene CPU-Konfigurationen, Chipsätze und Betriebssysteme) bereitstellen. Diese Unabhängigkeit ermöglicht es, verteilte Anwendungskomponenten auf den Computern auszuführen, die den einzelnen Computeranforderungen am ehesten entsprechen und am besten zur Maximierung der Netzwerkbandbreite geeignet sind.

Wie Sie Anwendungs- oder Infrastrukturkomponenten auf eine Hardwareumgebung (Ihre Bereitstellungsarchitektur) abbilden, hängt von vielen Faktoren ab, die durch die Größe und Komplexität Ihrer Softwarelösung bestimmt werden. Bei sehr kleinen Bereitstellungen kann eine Bereitstellungsarchitektur nur wenige Computer betreffen. Bei großen Bereitstellungen kann die Zuordnung von Komponenten zu einer Hardwareumgebung Faktoren wie Geschwindigkeit und Leistung einzelner Computer, Geschwindigkeit und Bandbreite von Netzwerkleitungen, Sicherheits- und Firewall-Aspekte sowie Replikationsstrategien für Komponenten berücksichtigen.

Auf Systemkomponenten angewendete geschichtete Architektur

Wie in Abbildung 2–3 gezeigt, bieten Java ES-Infrastrukturdienstkomponenten die zugrundeliegende Infrastrukturunterstützung für verteilte Softwarelösungen. Einige dieser Lösungen beinhalten Dienste auf Anwendungsebene, die von Komponenten der Sun Java Communications Suite und einigen Java ES-Komponenten bereitgestellt werden. Diese Lösungen verwenden den konzeptionellen Ansatz der logischen Schichten.

Die von Messaging Server bereitgestellten E-Mail-Kommunikationsdienste sind so implementiert, dass sie bestimmte logisch gesonderte Konfigurationen von Messaging Server verwenden. Diese gesonderten Konfigurationen bieten jeweils einen gesonderten Satz von Diensten. Bei der Konzeption von Messaging-Lösungen werden diese gesonderten Konfigurationen in Form von separaten Komponenten dargestellt, die sich in verschiedenen logischen Schichten befinden, wie in der folgenden Abbildung dargestellt, in der die Verbindungslinien von Komponenten Interaktionen darstellen.

Hinweis –

In der folgenden Abbildung soll keine vollständige logische Architektur dargestellt werden. Zur vereinfachten Darstellung wurden einige Java ES-Komponenten ausgelassen.

Abbildung 2–5 Messaging Server : Beispiel für eine Schichtenarchitektur

Dieses Diagramm zeigt Messaging Server-Komponenten, die auf vier logische Schichten aufgeteilt sind:

Hinweis –

Zwar sind Kommunikationskomponenten nicht Teil von Java ES, sie werden jedoch häufig mit Java ES-Komponenten und innerhalb von Java ES-Architekturen verwendet. Diese Kommunikationskomponenten sind Teil der Sun Java Communications Suite und werden in diesem Dokument nur zu Darstellungszwecken referenziert.

Die logische Trennung von Messaging Server -Funktionen in verschiedene Schichten erlaubt logisch unterschiedliche Konfigurationen von Messaging Server , die auf verschiedenen Computern in einer physischen Umgebung bereitgestellt werden. Durch die physische Trennung wird eine größere Flexibilität bei der Einhaltung der Dienstqualitätsanforderungen ermöglicht (sieheDimension 3: Dienstqualität). Dies bietet beispielsweise unterschiedliche Verfügbarkeitslösungen für unterschiedliche Instanzen und unterschiedliche Sicherheitsimplementierungen für unterschiedliche Messaging Server -Funktionen.

Dimension 3: Dienstqualität

Die beiden vorherigen Architekturdimensionen (Infrastrukturdienstabhängigkeiten und logische Schichten) betreffen überwiegend die logischen Aspekte der Architektur, nämlich, welche Komponenten auf welche Weise für die Interaktion erforderlich sind, um Dienste für Endbenutzer bereitzustellen. Eine ebenso wichtige Dimension jeder bereitgestellten Lösung ist die Fähigkeit, Dienstqualitätsanforderungen zu erfüllen.

Die Dimension der Dienstqualität einer Lösungsarchitektur stellt die Rolle der Java ES-Dienstqualitätskomponenten in den Vordergrund.

Dienstqualitäten

Aufgrund der Tatsache, dass Internet- und E-Commerce-Dienste für Geschäftsvorgänge immer wichtiger werden, stellt die Leistung, Verfügbarkeit, Sicherheit, Skalierbarkeit und Zweckmäßigkeit dieser Dienste eine der wichtigsten Dienstqualitätsanforderungen umfangreicher, extrem leistungsstarker Bereitstellungsarchitekturen dar.

Für die Konzeption einer erfolgreichen Softwarelösung müssen Sie relevante Dienstqualitätsanforderungen aufstellen und eine Architektur entwerfen, die diese erfüllt. Um Dienstqualitätsanforderungen zu definieren, werden einige wichtige Dienstqualitäten verwendet. Die folgende Tabelle führt diese Dienstqualitäten auf.

Tabelle 2–2 Dienstqualitäten mit Auswirkung auf die Lösungsarchitektur


Systemdienstqualitäten	Beschreibung
Leistung	Die Messung der Antwortzeit und -latenz in Bezug auf die Benutzerladebedingungen.
Verfügbarkeit	Ein Maß dafür, wie oft die Ressourcen und Dienste eines Systems für Endbenutzer verfügbar sind (die Betriebszeit eines Systems).
Sicherheit	Eine komplexe Kombination von Faktoren, die die Integrität eines Systems und seiner Benutzer beschreibt. Zur Sicherheit gehören die physische Sicherheit der Systeme, die Netzwerksicherheit, die Anwendungs- und Datensicherheit (Authentifizierung und Autorisierung der Benutzer) sowie der sichere Transport von Informationen.
Skalierbarkeit	Die Möglichkeit, einem bereitgestellten System im Laufe der Zeit Kapazität hinzuzufügen. Skalierbarkeit beinhaltet üblicherweise das Hinzufügen von Ressourcen zum System, ohne dass Änderungen an der Bereitstellungsarchitektur vorgenommen werden müssen.
Latente Kapazität	Die Fähigkeit eines Systems, eine außergewöhnliche Spitzenauslastung ohne zusätzliche Ressourcen zu bewältigen.
Zweckmäßigkeit	Die Leichtigkeit, mit der ein bereitgestelltes System gewartet werden kann, einschließlich der Systemüberwachung, Problembehebung und Aktualisierung von Soft- und Hardwarekomponenten.

Die Dimension der Dienstqualität wirkt sich stark auf die Bereitstellungsarchitektur einer Lösung aus: Wie Anwendungskomponenten und Infrastrukturkomponenten in einer physischen Umgebung bereitgestellt werden.

Die Dienstqualitäten, die die Bereitstellungsarchitektur beeinflussen, sind eng miteinander verbunden: Anforderungen an eine Systemqualität wirken sich häufig auf die Konzeption der anderen Dienstqualitäten aus. So kann beispielsweise ein höheres Sicherheitsniveau die Leistung beeinträchtigen, was wiederum die Verfügbarkeit beeinflusst. Das Hinzufügen weiterer Computer, um Verfügbarkeitsprobleme durch Redundanz zu beheben, wirkt sich häufig auf die Wartungskosten (Zweckmäßigkeit) aus.

Das Verständnis der Beziehungen zwischen den Dienstqualitäten und ihre Abstimmung ist eine wichtige Voraussetzung für die Konzeption von Architekturen, die sowohl die Geschäftsanforderungen als auch die Geschäftsbeschränkungen einhalten.

Java ES-Dienstqualitätskomponenten

Einige Java ES-Komponenten werden hauptsächlich verwendet, um die Dienstqualitäten von Systemdienstkomponenten oder verteilten Anwendungskomponenten zu verbessern. Diese Softwarekomponenten werden oft zusammen mit Hardwarekomponenten, wie Lastausgleichsmodulen und Firewalls, eingesetzt.

Die unterDienstqualitätskomponenten vorgestellten Java ES-Dienstqualitätskomponenten können wie folgt zusammengefasst werden:

Verfügbarkeitskomponenten: Bieten eine beinahe unterbrechungsfreie Betriebszeit für bereitgestellte Lösungen.
Zugangskomponenten: Sorgen für einen sicheren Internetzugriff auf Systemdienste und bieten häufig auch eine Routing-Funktion.
Überwachungskomponenten: Liefern Echtzeitinformationen zu Java ES-Komponenten

Die folgende Tabelle führt die wichtigsten Java ES-Dienstqualitätskomponenten aus der Perspektive der Architektur auf und zeigt, auf welche Systemqualitäten sie sich am meisten auswirken.

Tabelle 2–3 Dienstqualitätskomponenten und die beeinflussten Systemqualitäten


Komponente	Beeinflusste Systemqualitäten
High Availability Session Store	Verfügbarkeit
Monitoring Console	Zweckmäßigkeit
Portal Server, Secure Remote Access	Sicherheit Skalierbarkeit
Sun Cluster	Verfügbarkeit Skalierbarkeit
Sun Cluster Geographic Edition	Verfügbarkeit Skalierbarkeit
Web Proxy Server	Sicherheit Leistung Skalierbarkeit

Sun Cluster-Software

Sun Cluster-Software bietet Hochverfügbarkeits- und Skalierbarkeitsdienste für Java ES-Komponenten sowie für Anwendungen, die von der Java ES-Infrastruktur unterstützt werden. Ein Cluster besteht aus lose miteinander verbundenen Computern, die zusammen eine einzelne Client-Ansicht der Dienste, Systemressourcen und Daten bieten. Intern verwendet der Cluster redundante Computer, Interconnects, Datenspeicher und Netzwerkschnittstellen zur Bereitstellung der Hochverfügbarkeit für clusterbasierte Dienste und Daten.

Die Sun Cluster-Software überwacht permanent den Zustand der Mitgliedsknoten und anderer Cluster-Ressourcen. Im Fehlerfall greift die Sun Cluster-Software ein und löst das Failover der überwachten Ressourcen aus und nutzt dabei die interne Redundanz, um einen nahezu kontinuierlichen Zugriff auf diese Ressourcen zu realisieren.

Sun Cluster-Datendienstpakete (auch als Sun Cluster Agenten bezeichnet) sind für alle Java ES-Systemdienstkomponenten verfügbar. Sie können auch für selbst entwickelte Anwendungskomponenten Agenten schreiben.

Aufgrund der Steuerung durch die Sun Cluster-Software kann ein Cluster auch skalierbare Dienste bereitstellen. Durch Nutzung des globalen Dateisystems des Clusters und wegen der Fähigkeit, Infrastruktur- oder Anwendungsdienste auf mehreren Knoten in einem Cluster auszuführen, kann eine verstärkte Anforderung dieser Dienste auf mehrere Instanzen der Dienste aufgeteilt werden. Daher kann Sun Cluster-Software bei richtiger Konfigurierung in einer verteilten Unternehmensanwendung gleichzeitig Hochverfügbarkeit und Skalierbarkeit gewährleisten.

Aufgrund der für eine Sun Cluster-Umgebung erforderlichen Redundanz sorgt die Aufnahme von Sun Cluster in einer Lösung für eine merkliche Erhöhung der in der physischen Umgebung benötigten Anzahl von Computern und Netzwerkverbindungen.

Anders als die von anderen Java ES-Komponenten bereitgestellten Dienste, handelt es sich bei den Verfügbarkeitsdiensten von Sun Cluster um verteilte Peer-to-Peer-Dienste. Daher muss die Sun Cluster-Software auf jedem Computer in einem Cluster installiert werden.

Eine Erweiterung auf Sun Cluster-Software wird durch Sun Cluster Geographic Edition bereitgestellt, durch die Anwendungen mithilfe von mehreren geografisch voneinander getrennten Clustern und einer Infrastruktur, die Daten zwischen den Clustern repliziert, vor unerwarteten Störungen geschützt werden.

Hinweis –

Sun Cluster und Sun Cluster Geographic Edition werden nur auf Solaris^TM-Betriebssystemen (Solaris OS) unterstützt.

Synthese der drei Architekturdimensionen

Zusammengenommen bilden die drei in Abbildung 2–1 dargestellten und in den letzten Abschnitten besprochenen Architekturdimensionen ein Framework für die Konzeption verteilter Softwarelösungen. Die drei Dimensionen (Infrastrukturdienstabhängigkeiten, logische Schichten und Dienstqualität) verdeutlichen die von den Java ES-Komponenten in Lösungsarchitekturen gespielte Rolle.

Jede Dimension steht für eine unterschiedliche Architekturperspektive. Eine Lösungsarchitektur muss alle Dimensionen berücksichtigen. Beispiel: Verteilte Komponenten in jeder logischen Schicht einer Lösungsarchitektur (Dimension 2) müssen durch entsprechende Infrastrukturkomponenten (Dimension 1) und entsprechende Dienstqualitätskomponenten (Dimension 3) unterstützt werden.

Entsprechend spielt jede in einer Lösungsarchitektur vorhandene Komponente hinsichtlich der verschiedenen Architekturdimensionen unterschiedliche Rollen. Directory Server kann beispielsweise sowohl als Back-End-Komponente der Datenschicht (Dimension 2) als auch als Anbieter von Persistenzdiensten (Dimension 1) angesehen werden. Aufgrund der Zentralität von Directory Server hinsichtlich dieser beiden Dimensionen stehen Dienstqualitätsprobleme (Dimension 3) für diese Java ES-Komponente an höchster Stelle. Ein Directory Server-Ausfall hätte schwerwiegende Auswirkungen auf ein Geschäftssystem, sodass ein Hochverfügbarkeitskonzept für diese Komponente von großer Wichtigkeit ist. Da Directory Server zur Speicherung geheimer Benutzer- oder Konfigurationsinformationen verwendet wird, ist ein Sicherheitskonzept für diese Komponente ebenfalls sehr wichtig.

Das Zusammenspiel der drei Dimensionen hinsichtlich der Java ES-Komponenten wirkt sich auf die Konzeption der logischen Architektur und der Bereitstellungsarchitektur der Lösungen aus.

Detaillierte Entwurfsmethodiken, die auf diesem durch Java ES-Architektur-Framework dargestellen Architektur-Framework basieren, werden in diesem Handbuch nicht beschrieben. Das dreidimensionale Architekturframework hebt jedoch Aspekte der Konzeption hervor, die für das Verständnis des Bereitstellens von auf Java Enterprise System basierenden Softwarelösungen wichtig sind.

Java ES-Lösungsarchitektur – Beispiel

Java ES unterstützt eine Vielzahl von Softwarelösungen. Viele Lösungen können mit den in Java ES enthaltenen Komponenten ohne Entwicklungsaufwand direkt konzipiert und bereitgestellt werden. Bei anderen Lösungen können umfangreiche Entwicklungsarbeiten notwendig sein, bei denen Sie eigene J2EE-Komponenten entwickeln müssen, die neue Geschäfts- oder Präsentationsdienste bereitstellen. Sie können diese benutzerdefinierten Komponenten in Form von Webdiensten zusammenfassen, die den SOAP-Schnittstellenstandards entsprechen. Bei vielen Lösungen ist eine Kombination dieser beiden Ansätze erforderlich.

In diesem Abschnitt finden Sie ein aus den im letzten Abschnitt beschriebenen Architekturkonzepten abgeleitetes Beispiel, das verdeutlicht, wie Java ES eine Out-of-the-Box-Lösung unterstützt.

Szenario der Unternehmenskommunikation

Unternehmen müssen in der Regel die Kommunikation zwischen Ihren Mitarbeitern, insbesondere durch E-Mail- und Kalenderdienste sicherstellen. Solche Unternehmen wollen, dass ihre Mitarbeiter einen personalisierten Zugang zu internen Websites und anderen Ressourcen besitzen, der auf den unternehmensweiten Authentifizierungs- und Autorisierungsdiensten basiert. Zusätzlich wollen diese Unternehmen, dass die Identität der Mitarbeiter über alle Unternehmensdienste hinweg protokolliert wird, damit eine einzige Webanmeldung (Single Sign-On) den Zugriff auf alle Dienste bietet.

Diese spezifischen Geschäftsanforderungen, die lediglich eine Beispielmenge der gesamten Geschäftsanforderungen darstellen, sind in der folgenden Tabelle zusammengefasst.

Tabelle 2–4 Zusammenfassung der Geschäftsanforderungen: Kommunikationsszenario


Geschäftsanforderung	Beschreibung	Erforderliche Dienste
Single Sign-On	Zugang zu sicheren Unternehmensressourcen und -diensten auf der Grundlage einer einzigen Identität mit Single Sign-On für Webzugang.	Identitätsdienste
Messaging Calendar	E-Mail-Messaging zwischen Mitarbeitern und mit der Außenwelt. Elektronische Kalendereinträge und Terminvereinbarungen für Mitarbeiter.	Kommunikations- und Zusammenarbeitsdienste:
Portalzugriff	Einzelner, webbasierter, personalisierter Zugangspunkt für Kommunikationsdienste, wie E-Mail und Kalender sowie interne Webseiten.	Zugangsdienste

Außerdem hat ein Unternehmen darüber hinaus Anforderungen hinsichtlich der Leistung, Verfügbarkeit, Netzwerksicherheit und Skalierbarkeit des Softwaresystems, das diese Dienste bereitstellt.

Logische Architektur des Beispielszenarios

Eine logische Architektur, mit der die in Tabelle 2–4 identifizierten Portal-, Kommunikations- und Identitätsdienste mithilfe von Java ES-Komponenten und Komponenten der Sun Java Communications Suite (Messaging Server, Calendar Server, Instant Messaging usw.) bereitgestellt werden, wird in folgender Abbildung dargestellt. Die Architektur behandelt logisch getrennte Konfigurationen von Messaging Server als separate Komponenten, da diese unterschiedliche Dienste bereitstellen.

Abbildung 2–6 Logische Architektur des Unternehmenskommunikationsszenarios

Die Abbildung zeigt die logische Architektur des Beispielsszenarios für die Unternehmenskommunikation.

Die Komponenten sind in einer horizontalen Dimension platziert, die die standardmäßigen logischen Schichten darstellen. Die vertikale Dimension stellt die Infrastrukturdienstebenen dar. Die Interaktionen zwischen den Komponenten hängen entweder von ihrer Funktion als verteilte Infrastrukturdienste ab (Interaktionen zwischen Infrastrukturdienstebenen) oder von ihrer Rolle in einer Schichtenarchitektur der Anwendung (Interaktionen innerhalb und zwischen logischen Schichten).

In dieser Architektur arbeitet Access Manager, der auf die in Directory Server gespeicherten Benutzerinformationen zugreift, als Schiedsrichter hinsichtlich der Authentifizierung und Autorisierung über Single Sign-On für den Portal Server und andere webbasierte Komponenten der Präsentationsschicht. Zu den Messaging Server -Komponenten gehört in der Datenschicht ein Nachrichtenspeicher (Messaging Server -STR), der Komponenten der Geschäftsdienstschicht sendet und abruft, sowie in der Präsentationsschicht eine HTTP-Zugangskomponente und Communications Express.

Die logische Architektur zeigt außerdem die Infrastrukturdienstabhängigkeiten zwischen den verschiedenen Komponenten. So hängt beispielsweise Portal Server für die Messaging- und Kalenderkanäle von Communications Express ab und für die Authentifizierungs- und Autorisierungsdienste von Access Manager. Diese Komponenten hängen wiederum von Directory Server ab, von dem Sie Benutzerinformationen und Konfigurationsdaten erhalten. Einige Komponenten benötigen Webcontainerdienste, die Web Server bereitstellt.

Weitere Informationen über das logische Konzept der Java ES-Lösung finden Sie im Sun Java Enterprise System Deployment Planning Guide.

Bereitstellungsarchitektur des Beispielszenarios

Beim Übergang von der logischen Architektur zur Bereitstellungsarchitektur sind die Dienstqualitätsanforderungen von größter Bedeutung. So können beispielsweise geschützte Subnetze und Firewalls genutzt werden, um eine Sicherheitsbarriere zum Back-End-Bereich zu erzeugen. Für viele Komponenten müssen Verfügbarkeits- und Skalierbarkeisanforderungen erfüllt werden, indem diese auf mehreren Computern bereitgestellt und die Anfragen über ein Lastausgleichsmodul an die replizierten Komponenten verteilt werden.

Wenn jedoch strengere Verfügbarkeitsanforderungen vorliegen und wenn sehr viel Festplattenspeicher benutzt wird, dann sind andere Verfügbarkeitslösungen besser geeignet. Für den Messaging Server -Speicher kann beispielsweise Sun Cluster und für Directory Server die Multi-Master-Replikation genutzt werden.

Weitere Informationen über das Bereitstellungskonzept der Java ES-Lösung finden Sie im Sun Java Enterprise System Deployment Planning Guide.

In diesem Kapitel enthaltene Schlüsselbegriffe

In diesem Abschnitt werden die wichtigsten in diesem Kapitel verwendeten technischen Bedingungen erläutert, wobei auf die Verwendung dieser Bedingungen im Zusammenhang mit Java ES besonders eingegangen wird.

Anwendungskomponente: Eine kundenspezifisch entwickelte Software-Komponente, die eine spezifische Datenverarbeitungsfunktionen durchführt und Endbenutzer oder andere Anwendungskomponenten mit Geschäftsdiensten versorgt. Eine Anwendungskomponente entspricht normalerweise einem verteilten Komponentenmodell (z. B. CORBA und der J2EE-Plattform). Diese Komponenten können (einzeln oder kombiniert) als web services zusammengefasst werden.
Architektur: Ein Konzept, das die logischen und physischen modularen Blöcke einer verteilten Anwendung (oder eines anderen Softwaresystems) sowie ihre Beziehungen untereinander darstellt. Für eine Verteilte Unternehmensanwendung umfasst das Architekturkonzept im Allgemeinen sowohl die Logische Architektur als auch die Bereitstellungs- architektur der Anwendung.
Geschäftsdienst: Eine Anwendungskomponente oder Komponentengruppe, die die Geschäftslogik im Namen mehrerer Clients ausführt (und daher einen Vorgang mit mehreren Threads darstellt). Ein Geschäftsdienst kann auch eine Gruppe von verteilten Komponenten sein, die zu einem Webdienst oder zu einem eigenständigen Server zusammengefasst sind.
Client: Eine Software, die Software dienste anfordert. Ein Client kann ein Dienst sein, der einen anderen Dienst anfordert, oder eine GUI-Komponente, auf die ein Endbenutzer zugreift.
Bereitstellungs- architektur: Ein starkes Konzept, das die Logische Architektur einer physischen Computerumgebung zuordnet. Die physische Umgebung umfasst die Computer in einer Intranet- oder Internetumgebung, die Netzwerkverbindungen zwischen ihnen sowie andere physische Geräte, die zur Unterstützung der Software erforderlich sind.
Logische Architektur: Ein Konzept, das die logischen modularen Blöcke einer verteilten Anwendung sowie ihre Beziehungen untereinander (bzw. ihre Schnittstellen) darstellt. Die logische Architektur umfasst sowohl die verteilten application components als auch die Infrastrukturdienste, die für deren Unterstützung erforderlich sind.
Server: Ein Softwarevorgang mit mehreren Threads (im Gegensatz zu einem Hardwareserver), der einen verteilten service oder eine geschlossene Gruppe von Diensten für clients bereitstellt, die über eine externe Schnittstelle auf den Dienst zugreifen
Webdienst: Ein Dienst, der den standardisierten Internetprotokollen für Verfügbarkeit, Dienstintegrierung und Erkennung entspricht. Zu diesen Standards gehören das SOAP-Nachrichtenprotokoll, die WSDL-Schnittstellendefinition (Web Service Definition Language) und der UDDI-Registrierungsstandard (Universal Discovery, Description and Integration).