Sun Java Enterprise System 2005Q4 Handbuch zur Bereitstellungsplanung

Kapitel 4 Logisches Konzept

Während der Phase des logischen Konzepts im Lebenszyklus einer Lösung entwerfen Sie eine logische Architektur, in der die gegenseitigen Abhängigkeiten der logischen Komponenten der Lösung dargestellt werden. Die logische Architektur und die Anwendungsanalyse aus der Phase der technischen Anforderungen bilden ein Bereitstellungsszenario, das als Ausgangspunkt für die Konzeptphase der Bereitstellung dient.

Dieses Kapitel enthält die folgenden Abschnitte:

Informationen zu logischen Architekturen

In einer logischen Architektur werden die Softwarekomponenten identifiziert, die für die Implementierung einer Lösung erforderlich sind, und in ihrer gegenseitigen Abhängigkeit dargestellt. Die logische Architektur und die Dienstqualitätsanforderungen, die während der Phase der technischen Anforderungen bestimmt wurden, bilden ein Bereitstellungsszenario. Das Bereitstellungsszenario bildet die Grundlage für den Entwurf der Bereitstellungsarchitektur, der in der nächsten Phase im Rahmen des Bereitstellungskonzepts stattfindet.

Bei der Entwicklung einer logischen Architektur müssen nicht nur die Komponenten identifiziert werden, die Dienste für die Benutzer bereitstellen, sondern auch Komponenten, die die erforderlichen Middleware- und Plattformdienste zur Verfügung stellen. Infrastrukturdienst-Abhängigkeiten und logische Schichten bieten zwei einander ergänzende Möglichkeiten zur Durchführung dieser Analyse.

Infrastrukturdienst-Abhängigkeiten und logische Schichten sind zwei von drei Pfeilern der Lösungsarchitektur, auf denen Sun Java^TM Enterprise System basiert. Diese drei Pfeiler werden nachfolgend aufgeführt und werden zudem in Informationen zu logischen Architekturen dargestellt.

Infrastrukturdienst-Abhängigkeiten. Interagierende Softwarekomponenten, mit denen Unternehmensdienste bereitgestellt werden. Für die Softwarekomponenten ist eine Reihe von zugrunde liegenden Infrastrukturdiensten erforderlich, über die die verteilten Komponenten miteinander kommunizieren und interagieren können.
Logische Schichten. Eine logische Anordnung von Softwarekomponenten in Schichten, die die logische und physische gegenseitige Abhängigkeit der Softwarekomponenten auf der Grundlage der von ihnen bereitgestellten Dienste darstellen.
Dienstqualität. Dienstqualitäten des Systems, wie Leistung, Verfügbarkeit, Skalierbarkeit und sonstige Eigenschaften, die bestimmte Aspekte des Konzepts und der Funktion einer Softwarelösung darstellen.

Hinweis –

Weitere Informationen zu den Java Enterprise System-Architekturkonzepten finden Sie in Kapitel "Java Enterprise System Architecture“ im Sun Java Enterprise System 2005Q4 Technischer Überblick.

In einer logischen Architektur werden Dienstebenen dargestellt, indem die erforderlichen Komponenten und deren jeweilige Abhängigkeiten abgebildet werden. In einer logischen Architektur werden zudem die Komponenten in logische Schichten aufgeteilt, in denen Präsentations-, Geschäfts- und Datendienste dargestellt werden, auf die über eine Client-Schicht zugegriffen werden kann. Die Dienstqualitätsanforderungen werden in der logischen Architektur nicht entworfen, sie werden jedoch im Bereitstellungsszenario mit der logischen Architektur kombiniert.

Entwurf einer logischen Architektur

Verwenden Sie zum Entwerfen einer logischen Architektur die Anwendungsfälle, die während der Phase der technischen Anforderungen bestimmt wurden, um die Java Enterprise System-Komponenten zu identifizieren, die die für die Lösung erforderlichen Dienste bereitstellen. Zudem müssen Sie alle Komponenten bestimmen, die Dienste für die ursprünglich identifizierten Komponenten bereitstellen.

Sie platzieren die Java Enterprise System-Komponenten entsprechend der von Ihnen bereitgestellten Art von Diensten innerhalb des Kontexts einer mehrschichtigen Architektur. Das Verständnis der Komponenten als Bestandteil einer mehrschichtigen Architektur hilft Ihnen später dabei, die Verteilung der von den Komponenten bereitgestellten Dienste zu bestimmen und eine Strategie zur Implementierung der Dienstqualität festzulegen (wie z. B. Skalierbarkeit, Verfügbarkeit usw.).

Zusätzlich können Sie eine andere Ansicht der logischen Komponenten angeben, in der diese innerhalb sicherer Zugriffszonen platziert werden. Im Abschnitt Zugriffzonen finden Sie ein Beispiel für sichere Zugriffszonen.

Java Enterprise System-Komponenten

Java Enterprise System besteht aus interagierenden Softwarekomponenten, die Dienste bereitstellen, die Sie zur Erstellung Ihrer Unternehmenslösung verwenden können. In der folgenden Abbildung werden die wichtigsten in Java Enterprise System enthaltenen Softwarekomponenten dargestellt. Im Handbuch Sun Java Enterprise System 2005Q4 Technischer Überblick finden Sie zusätzliche Informationen zu Java Enterprise System-Komponenten und zu den durch die Komponenten bereitgestellten Dienste.

Abbildung 4–1 Java Enterprise System-Komponenten

Diagramm, das die Beziehung der Komponenten von Java Enterprise System darstellt.

Komponentenabhängigkeiten

Bei der Identifizierung der Java Enterprise System-Komponenten für eine logische Architektur müssen Sie auch die Komponenten für die Unterstützung ermitteln. Wenn Sie beispielsweise Messaging Server als eine erforderliche Komponente in einer logischen Architektur ermitteln, muss die logische Architektur ebenfalls Directory Server und möglicherweise Access Manager enthalten. Messaging Server ist hinsichtlich der Verzeichnisdienste von Directory Server und für Lösungen, die Single Sign-On erfordern, von Access Manager abhängig.

In der folgenden Tabelle werden die Abhängigkeiten von Java Enterprise System-Komponenten aufgelistet. Eine grafische Darstellung der Abhängigkeiten zwischen den Schlüsselkomponenten finden Sie unter Komponentenabhängigkeiten. Verwenden Sie beim Entwurf einer logischen Architektur folgende Tabelle und die dazugehörige Abbildung, um abhängige Komponenten in Ihrem Konzept zu bestimmen.

Tabelle 4–1 Java Enterprise System-Komponentenabhängigkeiten


Java Enterprise System-Komponente	Ist abhängig von
Application Server	Message QueueDirectory Server (optional)
Calendar Server	Messaging Server (für den E-Mail-Benachrichtigungsdienst) Access Manager (für Single Sign-on) Web Server (für die Webschnittstelle) Directory Server
Communications Express	Access Manager (für Single Sign-on) Calendar ServerMessaging ServerInstant MessagingWeb Server (für die Webschnittstelle) Directory Server
Directory Proxy Server	Directory Server
Directory Server	Keine
Access Manager	Application Server oder Web ServerDirectory Server
Instant Messaging	Access Manager (für Single Sign-On) Directory Server
Message Queue	Directory Server (optional)
Messaging Server	Access Manager (für Single Sign-On) Web Server (für die Webschnittstelle) Directory Server
Portal Server	Wenn zur Verwendung von Portal Server-Kanälen konfiguriert: Calendar ServerMessaging ServerInstant Messaging Access Manager (für Single Sign-On) Application Server oder Web ServerDirectory Server
Portal Server Secure Remote Access	Portal Server
Web Server	Access Manager (optional, für die Zugriffssteuerung)

Hinweis –

Die Abhängigkeiten zwischen den in der TabelleKomponentenabhängigkeiten aufgelisteten Java Enterprise System-Komponenten sind nicht vollständig. In der TabelleKomponentenabhängigkeiten werden keine Abhängigkeiten aufgelistet, die bei der Planung der Installation zu berücksichtigen sind. Eine vollständige Liste der Java Enterprise System-Abhängigkeiten finden Sie im Sun Java Enterprise System 2005Q4 Installationshandbuch für UNIX.

Abbildung 4–2 Java Enterprise System-Komponentenabhängigkeiten

In dieser Abbildung sind die in Tabelle 4-1 beschriebenen Abhängigkeiten grafisch dargestellt.

Webcontainer-Unterstützung

Im vorigen Abschnitt Komponentenabhängigkeiten wurde der Webcontainer, in dem Portal Server und Access Manager ausgeführt werden, nicht berücksichtigt. Dieser Webcontainer kann durch Application Server, Web Server oder ein Drittanbieterprodukt bereitgestellt werden. Beim Entwurf einer logischen Architektur, die Portal Server oder Access Manager enthält, sollten Sie sicherstellen, dass der für diese Komponenten erforderliche Webcontainer berücksichtigt wird.

Von Messaging Server bereitgestellte logisch eindeutige Dienste

Der Java Enterprise System Messaging Server kann für die Bereitstellung der folgenden logischen eindeutigen Dienste konfiguriert werden:

Message Transfer Agent
Message Multiplexor
Message Express Multiplexor
Nachrichtenspeicher

Diese unterschiedliche Konfigurationen von Messaging Server bieten Funktionen, die auf separaten physischen Servern bereitgestellt und in verschiedenen Schichten einer logischen Architektur dargestellt werden können. Da diese Konfigurationen für Messaging Server logisch eindeutige Dienste in separaten Schichten darstellen, können Sie diese beim Entwurf einer logischen Architektur als logisch eindeutige Komponenten betrachten. Im AbschnittBeispiel für logische Architekturen finden Sie ein Beispiel für logisch eindeutige Komponenten.

In der folgenden Tabelle werden die logisch eindeutigen Konfigurationen von Messaging Server beschrieben.

Tabelle 4–2 Messaging Server-Konfigurationen


Unterkomponente	Beschreibung
Message Transfer Agent (MTA)	Unterstützt das Senden von E-Mails durch das Bearbeiten von SMTP-Verbindungen, die Weiterleitung von E-Mails und die Zustellung von Nachrichten an die richtigen Nachrichtenspeicher. Die MTA-Komponenten können für die Unterstützung von E-Mails konfiguriert werden, die von Standorten außerhalb des Unternehmens (eingehend) oder die von Standorten innerhalb des Unternehmens (ausgehend) gesendet werden.
Nachrichtenspeicher (STR)	Ermöglicht das Abrufen und Speichern von E-Mail-Nachrichten.
Message Multiplexor (MMP)	Unterstützt das Abrufen von E-Mails durch Zugriff auf den Nachrichtenspeicher für E-Mail-Clients unter Verwendung des IMAP- oder POP-Protokolls.
Messenger Express Multiplexor (MEM)	Unterstützt den Abruf von E-Mails durch Zugriff auf den Nachrichtenspeicher im Namen webbasierter (HTTP)-Clients.

Zugriffskomponenten

Java Enterprise System enthält zudem Komponenten, die häufig von außerhalb der Firewall eines Unternehmens Zugriff auf Systemdienste bieten. Mit manchen Konfigurationen von Messaging Server kann darüber hinaus Netzwerkzugriff gewährt werden, beispielsweise wenn Messaging Server für Message Multiplexor konfiguriert wird. In der folgenden Tabelle werden die Java Enterprise System-Komponenten aufgeführt, die Remote-Zugriff auf Systemdienste gewähren.

Tabelle 4–3 Java Enterprise System-Komponenten, die Remote-Zugriff bieten


Komponente	Beschreibung
Directory Proxy Server	Bietet eine verbesserte Steuerung des Verzeichniszugriffs, der Schemakompatibilität, der Weiterleitung und Lastenverteilung für mehrere Directory Server-Instanzen.
Portal Server, Portal Server Secure Remote Access	Ermöglicht außerhalb einer Unternehmens-Firewall den sicheren Internetzugriff auf den Inhalt und die Dienste von Portal Server, einschließlich interne Portale und Internetanwendungen.
Portal Server, Portal Server Mobile Access	Bietet drahtlosen Zugriff über mobile Geräte und Sprachzugriff auf Portal Server.
Messaging Server Message Multiplexor (MMP)	Unterstützt den Abruf von E-Mails durch Zugriff auf den Nachrichtenspeicher im Namen webbasierter (HTTP-)Clients.

Komponenten, die Remote-Zugriff ermöglichen, werden in der Regel in sicheren Zugriffszonen bereitgestellt, wie im Beispiel in Abschnitt Zugriffzonen angegeben.

Entwurf einer mehrschichtigen Architektur

Java Enterprise System eignet sich für den Entwurf einer mehrschichtigen Architektur, in der Dienste entsprechend den von ihnen bereitgestellten Funktionen in Schichten platziert werden. Alle Dienste sind logisch unabhängig und können von Diensten aufgerufen werden, die sich entweder in derselben oder in einer anderen Schicht befinden. In der folgenden Abbildung wird ein mehrschichtiges Architekturmodell für Unternehmensanwendungen dargestellt, in dem der Client, die Präsentation, der Geschäftsdienst und die Datenschichten enthalten sind.

Abbildung 4–3 Mehrschichtiges Architekturmodell

In dieser Abbildung werden die Beziehungen der Dienste in einer mehrschichtigen Architektur dargestellt.

In der folgenden Tabelle werden die in Entwurf einer mehrschichtigen Architektur dargestellten logischen Schichten beschrieben.

Tabelle 4–4 Logische Schichten in einer mehrschichtigen Architektur


Schicht	Beschreibung
Client-Schicht	Enthält die Client-Anwendungen, die den Endbenutzern Informationen anzeigen. Für Java Enterprise System sind diese Anwendungen in der Regel Mail-Clients, Webbrowser oder Mobile Access-Clients.
Präsentationsschicht	Stellt Dienste bereit, die Endbenutzern Daten anzeigen und ihnen die Verarbeitung und Änderung der Präsentation ermöglichen. Mit einem Webmail-Client oder einer Portal Server-Komponente können die Benutzer beispielsweise die Darstellung der empfangenen Informationen ändern.
Geschäftsdienstschicht	Bietet Back-End-Dienste, mit denen in der Regel Daten aus der Datenschicht abgerufen werden, um die Daten für andere Dienste innerhalb der Präsentations- oder Geschäftsdienstschicht oder direkt für Clients in der Client-Schicht bereitzustellen. Access Manager stellt beispielsweise die Identity Services für andere Java Enterprise System-Komponenten bereit.
Datenschicht	Bietet Datenbankdienste, auf die andere Dienste innerhalb der Präsentationsschicht oder der Geschäftsdienstschicht zugreifen können. Directory Server bietet beispielsweise LDAP-Verzeichniszugriff auf andere Dienste.

Eine mehrschichtige Architekturstruktur bietet mehrere Vorteile. Während der Phase des Bereitstellungskonzepts können Sie durch die Platzierung der Dienste entsprechend der Funktionalität in einer mehrschichtigen Architektur bestimmen, wie die Dienste in Ihrem Netzwerk verteilt werden sollen. Zudem können Sie feststellen, wie Komponenten innerhalb der Architektur auf Dienste anderer Komponenten zugreifen. Dank dieser Visualisierung können Sie die Verfügbarkeit, Skalierbarkeit, Sicherheit und andere Dienstqualitätslösungen leichter planen.

Beispiel für logische Architekturen

In diesem Abschnitt werden einige Beispiele logischer Architekturen für Java Enterprise System-Lösungen angegeben. In diesen Beispielen werden die Platzierung logischer Komponenten innerhalb der entsprechenden Schichten einer mehrschichtigen Architektur und die anschließende Analyse der Beziehungen zwischen den Komponenten durch Prüfung der Anwendungsfälle dargestellt. Verwenden Sie die Beispiele für logische Architekturen in diesem Abschnitt als Wissensgrundlage für den Entwurf logischer Architekturen in Java Enterprise System-Lösungen.

Beim ersten Beispiel handelt es sich um eine grundlegende Messaging Server-Lösung, die verdeutlicht, wie logisch eindeutige Komponenten von Messaging Server mit anderen Komponenten interagieren. Im zweiten Beispiel wird eine logische Architektur für eine identitätsbasierte Bereitstellungslösung dargestellt, die für ein Unternehmen mittlerer Größe mit etwa 1000 bis 5000 Angestellten geeignet ist.

Messaging Server-Beispiel

In der folgenden Abbildung wird eine grundlegende logische Architektur für die Bereitstellung von Messaging Server dargestellt. In dieser logischen Architektur werden nur die logisch eindeutigen Komponenten angegeben, die für Messaging Server erforderlich sind. In späteren Abbildungen werden die Beziehungen zwischen diesen Komponenten dargestellt.

Hinweis –

In der Regel ist die Bereitstellung von Messaging Server Bestandteil einer Unternehmenslösung, die auch andere Java Enterprise System-Komponenten enthält, wie unterIdentitätsbasiertes Kommunikationsbeispiel beschrieben.

Abbildung 4–4 Logische Architektur für die Messaging Server-Bereitstellung

Diagramm, in dem die logischen Komponenten für ein in einer mehrschichtigen Architektur bereitgestelltes Messaging Server-Szenario dargestellt werden.

In der folgenden Tabelle werden die inMessaging Server-Beispiel dargestellten Komponenten beschrieben.

Tabelle 4–5 Komponenten in der logischen Architektur von Messaging Server


Komponente	Beschreibung
E-Mail-Clients	Client-Anwendungen zum Lesen und Senden von E-Mails.
Messaging Server MTA	Messaging Server konfiguriert als Message Transfer Agent (MTA) für den Empfang, die Weiterleitung, den Transport und die Zustellung von E-Mail-Nachrichten.
Messaging Server MMP	Messaging Server konfiguriert als Message Multiplexor (MMP) für die Weiterleitung von Verbindungen an entsprechende Nachrichtenspeicher zum Abrufen und Speichern. MMP greift auf Directory Server zu, um Verzeichnisinformationen nachzuschlagen, über die der richtige Nachrichtenspeicher bestimmt wird.
Messaging Server STR	Messaging Server konfiguriert als Nachrichtenspeicher zum Abrufen und Speichern von E-Mail-Nachrichten.
Directory Server	Bietet Zugriff auf LDAP-Verzeichnisdaten.

In der logischen Architektur wird die Replikation der Dienste für die Messaging Server-Komponenten nicht angegeben. Bei Unternehmensbereitstellungen werden in der Regel separate MTA-Instanzen für den Eingang und für den Ausgang erstellt, in Messaging Server-Beispiel wird jedoch nur eine MTA-Komponente aufgeführt. Die Replikation der logischen Komponenten in mehreren Instanzen ist eine strukturelle Entscheidung, die Sie während der Phase des Bereitstellungskonzepts treffen.

Messaging Server-Anwendungsfälle

Mithilfe von Anwendungsfällen können Sie Beziehungen zwischen den logischen Komponenten einer Architektur bestimmen. Durch die Zuordnung der Interaktionen zwischen den Komponenten entsprechend den Anwendungsfällen erhalten Sie eine visuelle Darstellung der Komponenteninteraktion, die hilfreich für die Erstellung einer Bereitstellungsstruktur ist.

In der Regel analysieren Sie die einzelnen Anwendungsfälle, um die Interaktion der Komponenten vor der Erstellung der Bereitstellungsstruktur zu bestimmen. Die folgenden drei Anwendungsfälle sind charakteristisch fürMessaging Server. Sie zeigen die Interaktionen zwischen den logischen Komponenten.

Anwendungsfall 1: Ein Benutzer meldet sich erfolgreich bei Messaging Server an

Schritte

Der E-Mail-Client sendet Anmeldeinformationen an den Messaging Server Multiplexor (MMP).

MMP fordert die Bestätigung der Benutzer-ID und des Passworts von Directory Server an.

Directory Server sendet die Bestätigung an MMP zurück.

MMP fordert eine Nachrichtenliste des Messaging Server-Nachrichtenspeichers (STR) an.

STR fordert den LDAP-Datensatz des Benutzers von Directory Server an.

Directory Server sendet den LDAP-Datensatz des Benutzers an STR zurück.

STR sendet die Nachrichtenliste an MMP zurück.

MMP leitet die Nachrichtenliste an den E-Mail-Client weiter.

Anwendungsfall 2: Ein angemeldeter Benutzer liest und löscht eine E-Mail

Schritte

Der E-Mail-Client fordert den Lesevorgang der Meldung aus Messaging Server Multiplexor (MMP) an.

MMP fordert die Nachricht aus dem Messaging Server-Nachrichtenspeicher (STR) an.

STR sendet die Nachricht an MMP zurück.

MMP leitet die Nachricht an den E-Mail-Client weiter.

Der E-Mail-Client sendet den Vorgang zum Löschen der Nachricht an MMP.

MMP leitet den Vorgang zum Löschen der Nachricht an STR weiter.

STR löscht die Nachricht aus der Datenbank und sendet eine entsprechende Bestätigung an MMP.

MMP leitet die Bestätigung des Löschvorgangs an den E-Mail-Client weiter.

Anwendungsfall 3: Ein angemeldeter Benutzer sendet eine E-Mail-Nachricht

Schritte

Der E-Mail-Client sendet eine im Client erstellte Nachricht an den Messaging Server Message Transfer Agent (MTA).

MTA fordert die Bestätigung der Benutzer-ID und des Passworts von Directory Server an.

Directory Server sendet die Bestätigung an MTA zurück.

MTA überprüft die Zieldomäne für alle Empfänger in Directory Server.

Directory Server sendet die Zieldomänen für alle Empfänger an MTA zurück.

MTA leitet die Nachricht an die einzelnen Empfänger weiter.

MTA eitet die Nachricht an den Messaging Server-Nachrichtenspeicher (STR) weiter, um die Nachricht im Postausgang zu speichern.

MTA sendet eine Bestätigung an den E-Mail-Client.

Identitätsbasiertes Kommunikationsbeispiel

In diesem Beispiel wird eine identitätsbasierte Kommunikationslösung für ein Unternehmen mittlerer Größe mit etwa 1.000 bis 5.000 Mitarbeitern dargestellt. In der Regel ist eine ausführliche Geschäftsanalyse mit anschließender detaillierter Bestimmung der technischen Anforderungen erforderlich, um die logische Architektur zu entwerfen. Da es sich hierbei jedoch um ein theoretisches Beispiel handelt, wird davon ausgegangen, dass die folgenden Geschäftsanforderungen bestimmt wurden:

Die Mitarbeiter des Unternehmens benötigen persönlichen Zugriff auf interne Websites, Kommunikationsdienste, Kalenderdienste und andere Ressourcen.
Die unternehmensweite Authentifizierung und Autorisierung bietet Zugriff auf interne Websites und andere Dienste.
Einzelne Identitäten werden für alle Unternehmensdienste verfolgt. Dies ermöglicht einen Single Sing-On (SSO), welcher den Zugriff auf die internen Websites und andere Dienste ermöglicht.

In den Anwendungsfällen für dieses Beispiel würden die Anmeldeverfahren, das Lesen und Senden von E-Mails, die persönliche Anpassung des Portals, die Synchronisierung von Kalendern und andere ähnliche Benutzeraktivitäten detailliert beschrieben.

In der folgenden Abbildung wird eine logische Architektur für diese Art von identitätsbasierter Kommunikationslösung dargestellt.

Diagramm mit den logischen Komponenten eines in einer mehrschichtigen Architektur implementieren identitätsbasierten Kommunikationsszenarios.

Anwendungsfälle für identitätsbasiertes Kommunikationsbeispiel

Für eine Bereitstellungslösung dieser Art werden in der Regel mehrere detaillierte Anwendungsfälle erstellt, in denen die Interaktion der Benutzer mit den durch die Lösung bereitgestellten Diensten beschrieben wird. Bei diesem Beispiel steht die Interaktion der Komponenten bei der Anmeldung eines Benutzers an einem Portal über einen Webbrowser-Client im Vordergrund. In diesem Beispiel wird das Anmeldungsszenario in zwei Anwendungsfälle unterteilt:

Der Benutzer meldet sich an, wird authentifiziert und Portal Server ruft die Portalkonfiguration des Benutzers ab.
Portal Server ruft E-Mail- und Kalenderinformationen zur Anzeige im Web-Client ab.

Die beiden Anwendungsfälle können als ein erweiterter Anwendungsfall betrachtet werden. In diesem Beispiel werden die Anwendungsfälle der Einfachheit halber separat dargestellt.

Anwendungsfall 1: Ein Benutzer meldet sich erfolgreich an und das Portal ruft die Konfiguration des Benutzers ab

Schritte

Der Webbrowser-Client sendet die Benutzer-ID und das Passwort an Portal Server.

Portal Server fordert die Authentifizierung von Access Manager an.

Access Manager fordert die Bestätigung der Benutzer-ID und des Passworts von Directory Server an.

Directory Server überprüft die Benutzer-ID und das Passwort.

Access Manager fordert das Benutzerprofil von Directory Server an.

Directory Server sendet das Benutzerprofil zurück.

Portal Server fordert das Anzeigeprofil des Benutzers von Access Manager an.

Access Manager sendet die Portalkonfiguration zurück.

Die Portalkonfiguration wird im Webbrowser-Client angezeigt.

Anwendungsfall 2: Portal Server zeigt E-Mail- und Kalenderinformationen an

Schritte

Nach erfolgter Anmeldung, Authentifizierung und dem Abruf der Portalkonfiguration fordert Portal Server E-Mail-Nachrichten von Messaging Server MMP an.

MMP fordert eine Nachrichtenliste von Messaging Server STR an.

STR sendet die Nachrichtenliste an MMP zurück.

MMP leitet die Nachrichten-Header an Portal Server weiter.

Portal Server fordert Kalenderinformationen von Communications Express an.

Communications Express fordert Kalenderinformationen vom Calendar Server-Back-End an.

Calendar Server-Back-End sendet Kalenderinformationen an Communications Express zurück.

Communications Express leitet Kalenderinformationen an Portal Server weiter.

Portal Server sendet alle Kanalinformationen an den Webbrowser-Client.

Zugriffzonen

Eine weitere Möglichkeit, die Komponenten einer logischen Architektur darzustellen, ist deren Platzierung in Zugriffszonen, die anzeigen, auf welche Weise die Architektur einen sicheren Zugriff bereitstellt. In der folgenden Abbildung werden die Zugriffszonen für die Bereitstellung der Java Enterprise System-Komponenten dargestellt. Für jede Zugriffszone wird angezeigt, auf welche Weise die Komponenten einen sicheren Remote-Zugriff auf und über das Internet bzw. Intranet bieten.

Abbildung 4–5 In Zugriffszonen platzierte logische Komponenten

Diagramm, in dem die Platzierung der Java ES-Komponenten innerhalb sicherer Zugriffszonen dargestellt wird.

In der folgenden Tabelle werden die in der Abbildung Zugriffzonen dargestellten Zugriffszonen beschrieben.

Tabelle 4–6 Sichere Zugriffszonen und darin platzierte Komponenten


Zugriffszone	Beschreibung
Interne Zugriffszone (Intranet)	Der Internetzugang über Richtlinien, die mit einer Firewall zwischen Intranet und Internet durchgesetzt werden. Die interne Zugriffszone wird in der Regel von Endbenutzern zum Browsen im Internet und zum Senden von E-Mails verwendet. In einigen Fällen ist der direkte Zugriff auf das Internet zum Browsen zulässig. In der Regel wird jedoch der sichere Zugriff auf das und aus dem Internet über die externe Zugriffszone ermöglicht.
Externe Zugriffszone (DMZ)	Bietet sicheren Zugriff auf das und aus dem Internet und fungiert als Sicherheitspuffer für wichtige Back-End-Dienste.
Sichere Zugriffszone (Back-End)	Bietet eingeschränkten Zugriff auf wichtige Back-End-Dienste, auf die ausschließlich von einer externen Zugriffszone aus zugegriffen werden kann.

In der Abbildung Zugriffzonen sind die in den vorherigen Beispielen aufgeführten logischen Schichten nicht dargestellt, sondern im Mittelpunkt stehen die Komponenten, die den Remote-Zugriff und den internen Zugriff ermöglichen, die Beziehung dieser Komponenten zu Sicherheitsmaßnahmen, wie Firewalls und eine bildliche Darstellung der umzusetzenden Zugriffsregeln. Verwenden Sie die mehrschichtige Architekturstruktur in Kombination mit der Struktur, in der die Zugriffszonen dargestellt werden, um ein logisches Modell Ihrer geplanten Bereitstellung zu erstellen.

Bereitstellungsszenario

Der fertige Entwurf der logischen Architektur allein reicht nicht aus, um zur Phase der Bereitstellungsstruktur im Lösungszyklus überzugehen. Sie müssen die logische Architektur mit den Dienstqualitätsanforderungen (QoS) kombinieren, die in der Phase der technischen Anforderungen bestimmt wurden. Die Kombination der logischen Architektur und der QoS-Anforderungen stellt ein Bereitstellungsszenario dar. Das Bereitstellungsszenario ist der Ausgangspunkt für den Entwurf der Bereitstellungsarchitektur, wie in Kapitel 5, Bereitstellungskonzept beschrieben.