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

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

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.

   

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

Schritte

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.

   

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

Schritte

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

   

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.

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

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.

   

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

Schritte

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.