Sun Java Enterprise System 2005Q4 Technischer Überblick

Kapitel 2 Lösungsarchitekturen von Java Enterprise System

Dieses Kapitel bietet eine Übersicht über die Architekturkonzepte, auf denen die Java Enterprise System-(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.

architectures 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 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-Architekturframework

Java ES-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 (sieheSystemdienstkomponenten) bei der Unterstützung verteilter Lösungen 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 (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

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

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.

Abbildung 2–2 zeigt die Dimension der Dienstabhä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 derer 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

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

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 zur höchsten Ebene:

Betriebssystemplattformen. Bieten die Basisunterstützung für alle Prozesse, die auf einem Computer ausgeführt werden. Das Betriebssystem (wie Solaris^TM 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^TM) 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.
Runtime. 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^TM-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

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

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.

Tabelle 2–1 Beziehungen zwischen Java ES-Systemdienstkomponenten


Komponente	Ist abhängig von	Bietet Unterstützung für
Portal Server	Application Server oder Web Server Access Manager Directory Server Wenn zur Verwendung von entsprechenden Kanälen konfiguriert: Calendar Server Messaging Server Instant Messaging
Messaging Server	Directory Server Access Manager (für Single Sign-On)	Calendar Server (für E-Mail-Benachrichtigungen) Portal Server (für Messaging-Kanal)
Instant Messaging	Directory Server Access Manager (für Single Sign-On)	Portal Server (für den Instant Messaging-Kanal)
Calendar Server	Directory Server Messaging Server (für den E-Mail-Benachrichtigungsdienst) Access Manager (für Single Sign-On)	Portal Server (für den Kalenderkanal)
Access Manager	Application Server oder Web Server Directory Server	Portal Server Wenn konfiguriert für Single Sign-On: Calendar Server Messaging Server Instant Messaging
Application Server	Message Queue Directory Server (für verwaltete Objekte)	Portal Server Access Manager
Message Queue	Directory Server (für verwaltete Objekte)	Application Server
Web Server	Access Manager (für die Zugriffssteuerung)	Portal Server Access Manager
Directory Server	Keine	Portal Server Calendar Server Messaging Server Instant Messaging Access Manager
Service Registry	Keine	Application Server-basierte Komponenten

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. 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^TM-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^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 web servicesn zusammengefasst werden, die dem Schnittstellenstandard SOAP (Simple Object Access Protocol) entsprechen. Geschäftsdienste können auch als eigenständige servers, 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 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 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 gezeigt, 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.

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

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

Hinweis –

Abbildung 2–5 soll keine vollständige logische Architektur darstellen. 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. 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 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.

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. Die Skalierbarkeit umfasst in der Regel das Hinzufügen von Ressourcen zum System, sollte jedoch keine Änderungen an der Bereitstellungsarchitektur erfordern.
Latente Kapazität	Die Fähigkeit eines Systems, eine außergewöhnliche Spitzenauslastung ohne zusätzliche Ressourcen zu bewältigen.
Zweckmäßigkeit	Die Einfachheit der Wartung eines bereitgestellten Systems, einschließlich der Überwachung des Systems, der Behebung von auftretenden Problemen und der Aufrüstung der Hardware- und Softwarekomponenten.

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

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


Komponente	Beeinflusste Systemqualitäten
Communications Express	Sicherheit Skalierbarkeit
Directory Proxy Server	Sicherheit Skalierbarkeit
High Availability Session Store	Verfügbarkeit
Portal Server Secure Remote Access	Sicherheit Skalierbarkeit
Sun Cluster	Verfügbarkeit Skalierbarkeit
Web Proxy Server	Sicherheit Leistung Zweckmäßigkeit

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

Abbildung mit redundanten Computern, Datenspeichern und Interconnects im Sun Cluster-Verfügbarkeitskonzept.

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.

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

Eine detaillierte Beschreibung der Entwurfsmethodik für die Verwendung des unter Java Enterprise System-Architekturframework 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ösungsarchitektur

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

Tabelle 2–4 Zusammenfassung der Geschäftsanforderungen: Kommunikationsszenario


Unternehmens- anforderung	Beschreibung	Erforderliche Java ES-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 Kalender	E-Mail-Messaging zwischen Mitarbeitern und mit der Außenwelt. Elektronische Kalendereinträge und Terminvereinbarungen für Mitarbeiter.	Kommunikations- und Zusammenarbeitsdienste
Portal-Zugriff	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

In der folgenden Abbildung ist eine logische Architektur für die Bereitstellung der in Tabelle 2–4 aufgeführten Zugangs-, Kommunikations- und Identitätsdienste mit Java ES-Komponenten dargestellt. 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 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 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 Sun Java Enterprise System 2005Q4 Handbuch zur Bereitstellungsplanung.

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 2005Q4 Handbuch zur Bereitstellungsplanung.

In diesem Kapitel enthaltene Schlüsselbegriffe

Dieser Abschnitt erläutert in diesem Kapitel verwendete wichtige technische Begriffe, wobei der Schwerpunkt darauf liegt, zu verdeutlichen, welche Beziehung zwischen diesen Begriffen im Java Enterprise System-Kontext vorliegt.

Anwendungs- komponente: Eine kundenspezifisch entwickelte Software-Komponente, die einige spezifische Datenverarbeitungsfunktionen durchführt und end users oder andere Anwendungskomponenten mit business services versorgt. Eine Anwendungskomponente entspricht normalerweise einem verteilten Komponentenmodell (z. B. CORBA und der J2EE^TM-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 Unternehmens- anwendung umfasst das Architekturkonzept im Allgemeinen sowohl dieLogische Architektur als auch die Bereitstellungs- architektur der Anwendung.
Geschäftsdienst: Eine Anwendungs- komponente 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, die zu einem Webdienst zusammengefasst sind, oder ein eigenständiger Server sein.
Client: Eine Software, die Software- services anfordert. (Hinweis: Es handelt sich hierbei 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.
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 (Simple Object Access Protocol), die WSDL-Schnittstellendefinition (Web Service Definition Language) und der UDDI-Registrierungsstandard (Universal Discovery, Description and Integration).