Sun Java logo     Zur�ck      Inhalt      Index      Weiter     

Sun logo
Sun Java Enterprise System 2005Q1 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 die gegenseitigen Abh�ngigkeiten der Komponenten werden 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™ Enterprise System basiert. Diese drei Pfeiler werden nachfolgend aufgef�hrt und sind zudem in Abbildung 4-1 dargestellt.

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 Zugriffszonen 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. Der Java Enterprise System Technical Overview, http://docs.sun.com/doc/819-0061, bietet zus�tzliche Informationen zu den Java Enterprise System-Komponenten und zu den von ihnen bereitgestellten Diensten.

Abbildung 4-2   Java Enterprise System-Komponenten

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

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 angeben. Wenn Sie beispielsweise Messaging Server als erforderliche Komponente in einer logischen Architektur bestimmen, muss die logische Architektur ebenfalls Directory Server und m�glicherweise auch 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 der Java Enterprise System-Komponenten aufgelistet. Eine bildliche Darstellung der Abh�ngigkeiten zwischen den Schl�sselkomponenten finden Sie in Abbildung 4-3. Verwenden Sie beim Entwurf einer logischen Architektur folgende Tabelle und die dazugeh�rige Abbildung, um abh�ngige Komponenten in Ihrer Struktur zu bestimmen.

Tabelle 4-1  Java Enterprise System Komponentenabh�ngigkeiten 

Java Enterprise System-Komponente

Ist abh�ngig von

Application Server

Message Queue
Directory 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 Server
Messaging Server
Instant Messaging
Web Server (f�r die Webschnittstelle)
Directory Server

Directory Proxy Server

Directory Server

Directory Server

Keine

Access Manager

Application Server oder Web Server
Directory 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 Server
Messaging Server
Instant Messaging

Access Manager (f�r Single Sign-On)
Application Server oder Web Server
Directory Server

Portal Server Secure Remote Access

Portal Server

Web Server

Access Manager (optional, f�r Zugriffssteuerung)


Hinweis

Die Abh�ngigkeiten zwischen den in Tabelle 4-1 aufgelisteten Java Enterprise System-Komponenten sind nicht vollst�ndig. In Tabelle 4-1 werden keine Abh�ngigkeiten angegeben, die bei der Planung der Installation zu ber�cksichtigen sind. Eine vollst�ndige Liste der Java Enterprise System-Abh�ngigkeiten finden Sie im Java Enterprise System-Installationshandbuch, http://docs.sun.com/doc/819-0805.


Abbildung 4-3   Java Enterprise System-Komponentenabh�ngigkeiten

In dieser Abbildung sind die in Tabelle 4-1 dargestellten 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 logisch eindeutigen Dienste konfiguriert werden:

Diese unterschiedlichen Konfigurationen von Messaging Server bieten Funktionen, die auf separaten physischen Servern bereitgestellt werden und in unterschiedlichen 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 Abschnitt Beispiele 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 einigen Konfigurationen von Messaging Server kann dar�ber hinaus der 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 ServerMessage 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 Zugriffszonen 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-4   Mehrschichtiges Architekturmodell

In diesen Abbildungen werden die Beziehungen der Dienste in einer mehrschichtigen Architektur dargestellt.[D]

In der folgenden Tabelle werden die in Abbildung 4-4 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 Dienste innerhalb der Pr�sentations- oder Gesch�ftsdienstschicht direkt f�r die Clients in der Client-Schicht abzurufen. 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 leichter 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.


Beispiele 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 unter Identit�tsbasiertes Kommunikationsbeispiel beschrieben.


Abbildung 4-5   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.[D]

In der folgenden Tabelle werden die in Abbildung 4-5 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 Abbildung 4-5 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�r Messaging Server. Sie zeigen die Interaktionen zwischen den logischen Komponenten.

Anwendungsfall 1: Ein Benutzer meldet sich erfolgreich bei Messaging Server an.
  1. Der E-Mail-Client sendet Anmeldeinformationen an den Messaging Server Multiplexor (MMP).
  2. MMP fordert die Best�tigung der Benutzer-ID und des Passworts von Directory Server an.
  3. Directory Server sendet die Best�tigung an MMP zur�ck.
  4. MMP fordert eine Nachrichtenliste des Messaging Server-Nachrichtenspeichers (STR) an.
  5. STR fordert den LDAP-Datensatz des Benutzers von Directory Server an.
  6. Directory Server sendet den LDAP-Datensatz des Benutzers an STR zur�ck.
  7. STR sendet die Nachrichtenliste an MMP zur�ck.
  8. MMP leitet die Nachrichtenliste an den E-Mail-Client weiter.
  9. Abbildung 4-6   Logische Architektur von Messaging Server, in der Anwendungsfall 1 dargestellt wird
    Diagramm, in dem der Datenstrom zwischen den Messaging Server-Komponenten f�r Anwendungsfall 1 dargestellt wird.

Anwendungsfall 2: Ein angemeldeter Benutzer liest und l�scht eine E-Mail
  1. Der E-Mail-Client fordert den Lesevorgang der Meldung aus Messaging Server Multiplexor (MMP) an.
  2. MMP fordert die Nachricht aus dem Messaging Server-Nachrichtenspeicher (STR) an.
  3. STR sendet die Nachricht an MMP zur�ck.
  4. MMP leitet die Nachricht an den E-Mail-Client weiter.
  5. Der E-Mail-Client sendet den Vorgang zum L�schen der Nachricht an MMP.
  6. MMP leitet den Vorgang zum L�schen der Nachricht an STR weiter.
  7. STR l�scht die Nachricht aus der Datenbank und sendet eine entsprechende Best�tigung an MMP.
  8. MMP leitet die Best�tigung des L�schvorgangs an den E-Mail-Client weiter.
  9. Abbildung 4-7   Logische Architektur von Messaging Server, in der Anwendungsfall 2 dargestellt wird
    Diagramm, in dem der Datenstrom zwischen den Messaging Server-Komponenten f�r Anwendungsfall 2 dargestellt wird.

Anwendungsfall 3: Ein angemeldeter Benutzer sendet eine E-Mail-Nachricht
  1. Der E-Mail-Client sendet eine im Client erstellte Nachricht an den Messaging Server Message Transfer Agent (MTA).
  2. MTA fordert die Best�tigung der Benutzer-ID und des Passworts von Directory Server an.
  3. Directory Server sendet die Best�tigung an MTA zur�ck.
  4. MTA �berpr�ft die Zieldom�ne f�r alle Empf�nger in Directory Server.
  5. Directory Server sendet die Zieldom�nen f�r alle Empf�nger an MTA zur�ck.
  6. MTA leitet die Nachricht an die einzelnen Empf�nger weiter.
  7. MTA leitet die Nachricht an den Messaging Server-Nachrichtenspeicher (STR) weiter, um die Nachricht im Postausgang zu speichern.
  8. MTA sendet eine Best�tigung an den E-Mail-Client.
  9. Abbildung 4-8   Logische Architektur von Messaging Server, in der Anwendungsfall 3 dargestellt wird
    Diagramm, in dem der Datenstrom zwischen den Messaging Server-Komponenten f�r Anwendungsfall 3 dargestellt wird.

Identit�tsbasiertes Kommunikationsbeispiel

In diesem Beispiel wird eine identit�tsbasierte Kommunikationsl�sung f�r ein Unternehmen mittlerer Gr��e mit etwa 1000 bis 5000 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:

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.

Abbildung 4-9   Logische Architektur f�r identit�tsbasiertes Kommunikationsszenario

Diagramm mit den logischen Komponenten eines in einer Architektur mit mehreren Schichten implementierten identit�tsbasierten Kommunikationsszenarios.[D]

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:

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
  1. Der Webbrowser-Client sendet die Benutzer-ID und das Passwort an Portal Server.
  2. Portal Server fordert die Authentifizierung von Access Manager an.
  3. Access Manager fordert die Best�tigung der Benutzer-ID und des Passworts von Directory Server an.
  4. Directory Server �berpr�ft die Benutzer-ID und das Passwort.
  5. Access Manager fordert das Benutzerprofil von Directory Server an.
  6. Directory Server sendet das Benutzerprofil zur�ck.
  7. Portal Server fordert das Anzeigeprofil des Benutzers von Access Manager an.
  8. Access Manager sendet die Portalkonfiguration zur�ck.
  9. Die Portalkonfiguration wird im Webbrowser-Client angezeigt.
  10. Abbildung 4-10   Logische Architektur des Kommunikationsszenarios, in der Anwendungsfall 1 dargestellt wird
    Diagramm, in dem der Datenstrom zwischen den Komponenten des identit�tsbasierten Kommunikationsszenarios f�r Anwendungsfall 1 dargestellt wird.

Anwendungsfall 2: Portal Server zeigt E-Mail- und Kalenderinformationen an
  1. Nach erfolgter Anmeldung, Authentifizierung und dem Abruf der Portalkonfiguration fordert Portal Server E-Mail-Nachrichten von Messaging Server MMP an.
  2. MMP fordert eine Nachrichtenliste von Messaging Server STR an.
  3. STR sendet die Nachrichtenliste an MMP zur�ck.
  4. MMP leitet die Nachrichten-Header an Portal Server weiter.
  5. Portal Server fordert Kalenderinformationen von Communications Express an.
  6. Communications Express fordert Kalenderinformationen vom Calendar Server-Back-End an.
  7. Calendar Server-Back-End sendet Kalenderinformationen an Communications Express zur�ck.
  8. Communications Express leitet Kalenderinformationen an Portal Server weiter.
  9. Portal Server sendet alle Kanalinformationen an den Webbrowser-Client.
  10. Abbildung 4-11   Logische Architektur des Kommunikationsszenarios, in der Anwendungsfall 2 dargestellt wird
    Diagramm, in dem der Datenstrom zwischen den Komponenten des identit�tsbasierten Kommunikationsszenarios f�r Anwendungsfall 2 dargestellt wird.


Zugriffszonen

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-12   In Zugriffszonen platzierte logische Komponenten

Diagramm, in dem die Platzierung der Java ES-Komponenten innerhalb von sicheren Zugriffszonen dargestellt wird.[D]

In der folgenden Tabelle werden die in Abbildung 4-12 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 Abbildung 4-12 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.



Zur�ck      Inhalt      Index      Weiter     


Teilenr.: 819-1916.   Copyright 2005 Sun Microsystems, Inc. Alle Rechte vorbehalten.