![]() | |
Sun Java Enterprise System 2005Q1 Handbuch zur Bereitstellungsplanung |
Kapitel 4
Logisches KonzeptW�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 ArchitekturenIn 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.
- Infrastrukturdienst-Abh�ngigkeiten. Interagierende Softwarekomponenten, die von Enterprise Services 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 die Leistung, Verf�gbarkeit, Skalierbarkeit und sonstige Eigenschaften, die bestimmte Aspekte des Konzepts und der Funktion einer Softwarel�sung darstellen.
Abbildung 4-1 Die drei Pfeiler der Java Enterprise System-L�sungsarchitektur
[D]
Hinweis
Weitere Informationen zu den Konzepten der Java Enterprise System-Architektur erhalten Sie im Kapitel zur Java Enterprise System-Architektur im Java Enterprise System Technical Overview, http://docs.sun.com/doc/819-0061.
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 ArchitekturVerwenden 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
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.
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
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.
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.
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 der folgenden Tabelle werden die in Abbildung 4-4 dargestellten logischen Schichten beschrieben.
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 ArchitekturenIn 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
In der folgenden Tabelle werden die in Abbildung 4-5 dargestellten Komponenten beschrieben.
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.
- 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.
Abbildung 4-6 Logische Architektur von Messaging Server, in der Anwendungsfall 1 dargestellt wird
Anwendungsfall 2: Ein angemeldeter Benutzer liest und l�scht eine E-Mail
- 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.
Abbildung 4-7 Logische Architektur von Messaging Server, in der Anwendungsfall 2 dargestellt wird
Anwendungsfall 3: Ein angemeldeter Benutzer sendet eine E-Mail-Nachricht
- 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 leitet 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.
Abbildung 4-8 Logische Architektur von Messaging Server, in der 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:
- 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.
Abbildung 4-9 Logische Architektur f�r identit�tsbasiertes Kommunikationsszenario
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
- 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.
Abbildung 4-10 Logische Architektur des Kommunikationsszenarios, in der Anwendungsfall 1 dargestellt wird
Anwendungsfall 2: Portal Server zeigt E-Mail- und Kalenderinformationen an
- 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.
Abbildung 4-11 Logische Architektur des Kommunikationsszenarios, in der Anwendungsfall 2 dargestellt wird
ZugriffszonenEine 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
In der folgenden Tabelle werden die in Abbildung 4-12 dargestellten Zugriffszonen beschrieben.
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.
BereitstellungsszenarioDer 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.