|
| |
| Sun Java Enterprise System 2005Q2 - Technischer Überblick | |
Kapitel 2
Lösungsarchitekturen von Java Enterprise SystemDieses Kapitel enthält eine Übersicht der Architekturkonzepte, auf denen die Java Enterprise System-Lösungen (Java ES-Lösungen) basieren. In diesem Kapitel wird gezeigt, wie Java ES-Komponenten (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 Bereitstellungsarchitektur. 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 der logischen als auch in der Bereitstellungsarchitektur eine wichtige Rolle.
In diesem Kapitel wird ein Architekturframework für die Konzeption der Architektur von Java ES-Lösungen beschrieben, das anschließend in einer auf dem Architekturframework aufbauenden Beispiellösung dargestellt wird.
Das Kapitel behandelt folgende Themen:
Java Enterprise System-ArchitekturframeworkJava Enterprise System-Komponenten unterstützen die Bereitstellung verteilter Softwarelösungen für die Anforderungen von Unternehmen.
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 verteilter Softwarelö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:
- Infrastrukturdienstabhängigkeiten: Diese Dimension stellt die Rolle der Systemdienstkomponenten (siehe Systemdienstkomponenten) bei der Unterstützung verteilter Lösung in den Vordergrund.
- 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, wie 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 der Java ES-Lösungsarchitektur
Diese drei Dimensionen bilden zusammen ein einziges Framework, das die Beziehungen zwischen den Softwarekomponenten (Anwendungskomponenten und 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 eine Reihe von Basisinfrastrukturdiensten 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
Unabhängig davon, ob ein verteiltes Softwaresystem überwiegend aus selbst entwickelten oder fertigen Java ES-Komponenten besteht, müssen Sie bei der Konzeption einige Infrastrukturdienste berücksichtigen. Diese Dienste arbeiten auf vielen Ebenen.
Abbildung 2-2 illustriert die Dimension der Infrastrukturdienstabhängigkeiten in der Lösungsarchitektur. 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 bieten die konzeptionelle Grundlage, anhand der die Rolle der Java ES-Systemdienstkomponenten (siehe Systemdienstkomponenten) verständlich wird.
Im Allgemeinen können die in Abbildung 2-2 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
In den folgenden Absätzen werden die unterschiedlichen Infrastrukturdienstebenen beschrieben und, sofern relevant, der Bezug zu den Artefakten der Programmiersprache Java hergestellt. Die Beschreibung der Dienstebenen erfolgt, wie in Abbildung 2-2 dargestellt, von der niedrigsten Ebene bis hinauf zur höchsten Ebene:
- Betriebssystemplattformen: Bieten die Basisunterstützung für alle Prozesse, die auf einem Computer ausgeführt werden. Das Betriebssystem (wie Solaris™ Operating System, Linux oder Microsoft Windows) verwaltet die physischen Geräte sowie den Arbeitsspeicher, die Threads und andere Ressourcen, die zur Unterstützung der Java Virtual Machine (JVM™) 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 (beispielsweise von einem E-Mail- oder Kalenderserver) 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 allgemeine gegenseitige Abhängigkeit der verschiedenen 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 Enterprise System-Infrastrukturdienstkomponenten
Java ES-Komponenten implementieren die verteilten Infrastrukturdienstebenen, die in Abbildung 2-2 dargestellt sind. Die Positionierung der Java ES-Systemdienstkomponenten innerhalb der einzelnen Ebenen ist in Abbildung 2-3 dargestellt.
Abbildung 2-3 Java ES Systemdienstkomponenten
Hinweis
Die in Abbildung 2-3 dargestellten Betriebssystemplattformen sind kein formeller Bestandteil von Java Enterprise System. Sie sind jedoch darin enthalten, um die Betriebssystemplattformen darzustellen, auf denen die Java ES-Komponenten unterstützt werden.
Java Enterprise System 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.
Tabelle 2-1 zeigt die spezifischen Abhängigkeiten zwischen den Java ES-Systemdienstkomponenten, die in Abbildung 2-3 von oben nach unten verlaufend dargestellt sind.
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 Architektur ist in der folgenden Abbildung dargestellt.
Abbildung 2-4 Dimension 2: Logische Schichten für verteilte Unternehmensanwendungen
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. Das Konzept der logischen Schichten gilt jedoch ebenso für Systemdienstkomponenten, die Dienste auf Anwendungsebene bereitstellen, wie Messaging Server und Calendar Server.
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 mit einem auf der Java 2 Platform Enterprise Edition (J2EE™-Plattform) basierenden Komponentenmodell implementiert wurden. Andere verteilte Komponentenmodelle hingegen, beispielsweise CORBA, unterstützen ebenfalls diese Architektur.
- Client-Schicht: Die Client-Schicht umfasst 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 mobile Java 2 Platform Micro Edition-Clients (J2ME™-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 Geschäftsdienste 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 (MDBs). 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 Unternehmenskalenderserver oder Messaging-Server, erstellt werden.
- Datenschicht: Die Datenschicht besteht aus Diensten, die von der Geschäftslogik genutzte persistente Daten liefern. 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 illustrierte 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 die verschiedenen in einer Netzwerkumgebung vorhandenen 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 dargestellt, bieten Java ES-Infrastrukturdienstkomponenten die zugrundeliegende Infrastrukturunterstützung für verteilte Softwarelösungen. Einige dieser Lösungen enthalten jedoch Dienste der Anwendungsebene, die direkt von Java ES-Komponenten realisiert werden. Diese Lösungen verwenden den konzeptionellen Ansatz der logischen Schichten.
Beispiel: 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 einer Messaging-Lösung werden diese gesonderten Konfigurationen, wie die folgenden Abbildung zeigt, als separate Komponenten dargestellt, die sich auf unterschiedlichen logischen Schichten befinden.
Abbildung 2-5 Messaging Server: Beispiel für eine Schichtenarchitektur
Hinweis
Abbildung 2-3 darf nicht als vollständige logische Architektur verstanden werden. Einige Java ES-Komponenten wurden weggelassen, um die Abbildung zu vereinfachen. Die zwischen den Komponenten verlaufenden Linien stellen Interaktionen dar.
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. Die physische Trennung gestattet eine größere Flexibilität bei der Einhaltung der Dienstqualitätsanforderungen (siehe Dimension 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 jedoch 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.
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 Enterprise System-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 unter Dienstqualitätskomponenten vorgestellten Java ES-Dienstqualitätskomponenten können wie folgt zusammengefasst werden:
- Verfügbarkeitskomponenten: Diese Komponenten sorgen für eine nahezu kontinuierliche Betriebszeit der bereitgestellten Lösung.
- Zugriffskomponenten: Diese Komponenten sorgen für einen sicheren Internet-Zugriff auf Systemdienste und bieten häufig auch eine Routing-Funktion.
- Verwaltungskomponenten: Diese Komponenten sorgen für eine Verbesserung der Zweckmäßigkeit von Systemkomponenten.
Die folgende Tabelle enthält die wichtigsten Java ES-Dienstqualitätskomponenten aus der Perspektive der Architektur und zeigt, auf welche Systemqualitäten sie sich am meisten auswirken.
Sun Cluster-Software
Die Sun Cluster-Software bietet Hochverfügbarkeits- und Skalierbarkeitsdienste für Java ES sowie für Anwendungen, die von der Java ES-Infrastruktur unterstützt werden.
Ein Cluster besteht aus einer Reihe von lose miteinander verknüpfter Computern, die gemeinsam eine einzige Client-Ansicht für Dienste, Systemressourcen und Daten bereitstellen. 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, wobei die interne Redundanz genutzt wird, um einen nahezu kontinuierlichen Zugriff auf diese Ressourcen zu realisieren.
Die folgende Abbildung zeigt einen Zwei-Knoten Cluster, der Datenspeicherdienste für Messaging Server und Calendar Server unterstützt.
Abbildung 2-6 Verfügbarkeitskonzept mit Sun Cluster-Knoten
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. Deshalb muss die Sun Cluster-Software auf jedem, in einem Cluster vorhandenen Computer installiert werden.
Synthese der drei Architekturdimensionen
Zusammen genommen 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.
Wegen 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 würde schwerwiegende Auswirkungen auf ein Geschäftssystem haben, daher ist die Konzeption der Hochverfügbarkeit für diese Komponente sehr wichtig. Und da Directory Server zum Speichern sensibler Benutzer- oder Konfigurationsinformationen verwendet wird, ist für diese Komponente auch das Sicherheitskonzept 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.
Die detaillierte Beschreibung der Entwurfsmethodik für die Verwendung des in Abbildung 2-1 dargestellten Architekturframeworks würde den Rahmen dieses Handbuchs sprengen. 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.
Beispiel für Java Enterprise System-LösungsarchitekturJava Enterprise System unterstützt eine Vielzahl von Softwarelösungen.
Viele Lösungen können mit den in Java Enterprise System 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 die selbst entwickelten Komponenten als Webdienste zusammenfassen, die dem Schnittstellenstandard SOAP (Simple Object Access Protocol) 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 Enterprise System 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.
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 für die Bereitstellung der in Tabelle 2-4 aufgeführten Zugangs-, Kommunikations- und Identitätsdienste mit Java ES-Komponenten enthält die folgende Abbildung. Die Architektur behandelt logisch getrennte Konfigurationen von Messaging Server als separate Komponenten, da diese unterschiedliche Dienste bereitstellen.
Abbildung 2-7 Logische Architektur des Unternehmenskommunikationsszenarios
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, wenn es um die Authentifizierung und Autorisierung über Single Sign-On für den Portal Server und andere webbasierte Komponenten der Präsentationsschicht geht. 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 Java ES-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 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 Java Enterprise System Deployment Planning Guide.
In diesem Kapitel enthaltene SchlüsselbegriffeDieser Abschnitt erläutert in diesem Kapitel verwendete wichtige technische Begriffe, wobei der Schwerpunkt darauf liegt, die Beziehungen zwischen diesen Begriffen und ihrer Verwendung im Java Enterprise System-Kontext zu verdeutlichen.
Anwendungskomponente Eine kundenspezifisch entwickelte Software-Komponente, die einige spezifische Datenverarbeitungsfunktionen durchführt und Endbenutzer oder andere Anwendungskomponenten mit Geschäftsdiensten versorgt. Eine Anwendungskomponente entspricht in der Regel einem Modell verteilter Komponenten (wie CORBA und die J2EE™-Plattform). Diese Komponenten können einzeln oder kombiniert zu Webdiensten 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 die logische Architektur und die Bereitstellungsarchitektur der Anwendung.
Geschäftsdienst Eine Anwendungskomponente oder eine 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, die zu einem Webdienst zusammengefasst sind, oder ein eigenständiger Server sein.
Client Eine Software, die Software-Dienste anfordert. (Hinweis: Hierbei handelt es sich nicht um eine Person – siehe Endbenutzer.) Ein Client kann ein Dienst sein, der einen anderen Dienst anfordert, oder eine GUI-Komponente, auf die ein Endbenutzer zugreift.
Bereitstellungsarchitektur Ein starkes Konzept, das die logische Architektur einer physischen Computerumgebung zuordnet. Die physische Umgebung umfasst die in einer Intranet- oder Internetumgebung vorhandenen Computer, 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 Anwendungskomponenten als auch die Infrastrukturdienstkomponenten, die für deren Unterstützung erforderlich sind.
Server Ein Softwarevorgang mit mehreren Threads (im Gegensatz zu einem Hardwareserver), der einen verteilten Dienst 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 (Simple Object Access Protocol), die WSDL-Schnittstellendefinition (Web Service Definition Language) und der UDDI-Registrierungsstandard (Universal Discovery, Description and Integration).
