Exemple d'architecture logique

Dans cette section, vous trouverez des exemples d'architectures logiques pour des solutions Java Enterprise System. Ces exemples indiquent comment répartir des composants logiques sur les niveaux appropriés de l'architecture et comment analyser des relations entre composants en examinant des cas d'utilisation. Utilisez les exemples d'architectures logiques de cette section pour mieux comprendre la conception d'architectures logiques dans les solutions Java Enterprise System.

Le premier exemple correspond à une solution de Messaging Server élémentaire illustrant les interactions entre les composants logiques distincts de Messaging Server et les autres composants. Le second exemple montre l'architecture logique d'une solution de déploiement basée sur les identités pouvant convenir à une entreprise de taille moyenne (de 1 000 à 5 000 employés).

Exemple de Messaging Server

Le schéma ci-dessous illustre une architecture logique de base pour un déploiement de Messaging Server. Cette architecture comporte uniquement les composants logiques distincts requis pour Messaging Server. Les relations entre ces composants sont présentées dans les schémas apparaissant plus bas.

---

Remarque –

Généralement, un déploiement de Messaging Server fait partie d'une solution d'entreprise incluant d'autres composants de Java Enterprise System, comme indiqué à la section Exemple de communications basées sur les identités.

---

Figure 4–4 Architecture logique d'un déploiement Messaging Server

Le tableau ci-dessous décrit les composants présentés dans la section Exemple de Messaging Server.

Tableau 4–5 Composants de l'architecture logique de Messaging Server

Composant	Description
Clients de messagerie	Applications clientes pour la lecture et l'envoi de messages.
Messaging Server MTA	Configuration de Messaging Server en tant qu'agent de transfert de messages (MTA) pour recevoir, acheminer, transporter et livrer des messages.
Messaging Server MMP	Configuration de Messaging Server en tant que multiplexeur de messages (MMP) en vue d'acheminer les connexions vers les mémoires de messages appropriées pour la récupération et le stockage. MMP accède à Directory Server pour rechercher les informations d'annuaire afin d'identifier la mémoire de messages adéquate.
Messaging Server STR	Configuration de Messaging Server en tant que mémoire de messages pour la récupération et le stockage de messages.
Directory Server	Fournit l'accès aux données d'annuaire LDAP.

L'architecture ne définit pas la réplication des services pour les composants de Messaging Server. En général, dans les déploiements d'entreprise, des instances de MTA entrant et sortant distinctes sont créées mais seul un composant MTA apparaît dans le schéma de l'Exemple de Messaging Server. La décision de répliquer les composants logiques en plusieurs instances se prend lors de la phase de conception du déploiement.

Cas d'utilisation de Messaging Server

Les cas d'utilisation permettent d'identifier les relations entre les composants logiques d'une architecture. En mappant les interactions entre composants en fonction des cas d'utilisation, vous obtenez une représentation visuelle de ces interactions s'avérant très utile pour la conception du déploiement.

Avant de commencer la conception du déploiement, il est préférable d'analyser des cas d'utilisation pour déterminer les interactions entre composants. Les trois cas d'utilisation ci-dessous, propres à Messaging Server, illustrent les interactions entre composants logiques.

Cas d'utilisation n°1 : connexion utilisateur à Messaging Server réussie

Étapes

1. Le client de messagerie transmet les informations de connexion à Messaging Server Multiplexor (MMP).

2. MMP demande la vérification de l'ID utilisateur et du mot de passe à Directory Server.

3. Directory Server renvoie la vérification à MMP.

4. MMP demande la liste de messages à Messaging Server Message Store (STR).

5. STR demande l'enregistrement LDAP de l'utilisateur à Directory Server.

6. Directory Server renvoie l'enregistrement LDAP de l'utilisateur à STR.

7. STR renvoie la liste de messages à MMP.

8. MMP transfère la liste de messages au client de messagerie.

   

Cas d'utilisation n°2 : lecture et suppression de messages par l'utilisateur connecté

Étapes

1. Le client de messagerie demande le message à lire à Messaging Server Multiplexor (MMP).

2. MMP demande la liste de messages à Messaging Server Message Store (STR).

3. STR renvoie le message à MMP.

4. MMP transfère le message au client de messagerie.

5. Le client de messagerie transmet l'action de suppression de message à MMP.

6. MMP transfère l'action de suppression de message à STR.

7. STR supprime le message de la base de données et en envoie la confirmation à MMP.

8. MMP transfère la confirmation de suppression au client de messagerie.

   

Cas d'utilisation n°3 : envoi d'un message par un utilisateur connecté

Étapes

1. Un message, composé dans le client de messagerie, est envoyé par ce dernier à Messaging Server Message Transfer Agent (MTA).

2. MTA demande la vérification de l'ID utilisateur et du mot de passe à Directory Server.

3. Directory Server renvoie la vérification au MTA.

4. MTA vérifie le domaine de destination de chaque destinataire auprès de Directory Server.

5. Directory Server renvoie le domaine de destination de chaque destinataire au MTA.

6. MTA transfère le message à chaque destinataire.

7. MTA achemine le message vers Messaging Server Message Store (STR) pour qu'il soit stocké dans la boîte d'envoi.

8. MTA envoie la confirmation au client de messagerie.

   

Exemple de communications basées sur les identités

Cet exemple illustre une solution de communications basées sur les identités pour une entreprise de taille moyenne (1 000 à 5 000 employés). Une analyse d'exploitation exhaustive, suivie d'une analyse détaillée des exigences techniques, est requise pour concevoir l'architecture logique. Cet exemple étant théorique, supposons que les exigences d'entreprise suivantes ont été définies :

• Les salariés de l'entreprise doivent disposer d'un accès personnalisé aux sites Web internes, aux services de communication, aux services de calendrier et à d'autres ressources.

• L'authentification et l'autorisation au niveau de l'entreprise fournissent l'accès aux sites Web internes et à d'autres services.

• Un suivi de toutes les identités uniques est effectué dans l'ensemble des services de l'entreprise, ce qui permet une connexion unique (Single Sign-On ou SSO) fournissant l'accès aux sites Web internes et à d'autres services.

Les cas d'utilisation associés à cet exemple détailleraient les procédures de connexion, la lecture et l'envoi de messages, la personnalisation du portail, la synchronisation des calendriers et d'autres activités utilisateur du même type.

Le shcéma ci-dessous illustre une architecture logique pour ce type de solution de communications basées sur les identités.

Cas d'utilisation pour l'exemple de communications basées sur les identités

Pour une solution de déploiement de ce type, il existe de nombreux cas d'utilisation détaillés décrivant les interactions utilisateur avec les services fournis par la solution. Cet exemple détaille les interactions entre composants lors de la connexion d'un utilisateur à un portail à partir d'un client Web. Il divise ce scénario de connexion en deux cas d'utilisation :

• L'utilisateur se connecte, est authentifié, puis Portal Server récupère sa configuration de portail.

• Portal Server récupère les informations de messagerie et de calendrier afin de les afficher dans le client Web.

Ces deux cas d'utilisation peuvent être considérés comme un seul cas étendu. Toutefois, dans cet exemple, les cas d'utilisation ont été séparés dans un souci de simplification.

Cas d'utilisation n°1 : l'utilisateur se connecte correctement et le portail récupère sa configuration

Étapes

1. Le client Web envoie l'ID utilisateur et le mot de passe à Portal Server.

2. Portal Server fait une demande d'authentification auprès d'Access Manager.

3. Access Manager demande la vérification de l'ID utilisateur et du mot de passe à Directory Server.

4. Directory Server vérifie l'ID utilisateur et le mot de passe.

5. Access Manager demande le profil utilisateur à Directory Server.

6. Directory Server renvoie le profil utilisateur.

7. Portal Server demande le profil d'affichage utilisateur à Access Manager.

8. Access Manager renvoie la configuration du portail.

9. La configuration du portail s'affiche dans le client de navigation Web.

   

Cas d'utilisation n°2 : Portal Server affiche les informations de messagerie et de calendrier

Étapes

1. Une fois la connexion, l'authentification et la récupération de la configuration du portail correctement effectuées, Portal Server lance une requête pour récupérer les messages auprès de Messaging Server MMP.

2. MMP demande la liste des messages à Messaging Server STR.

3. STR renvoie la liste des messages à MMP.

4. MMP transfère les en-têtes de messages à Portal Server.

5. Portal Server lance une requête pour récupérer les informations de calendrier au près de Communications Express.

6. Communications Express lance une requête pour récupérer les informations de calendrier auprès du composant d'arrière-plan Calendar Server.

7. Le composant d'arrière-plan Calendar Server renvoie les informations de calendrier à Communications Express.

8. Communications Express transfère les informations de calendrier à Portal Server.

9. Portal Server envoie les informations de canal au client de navigation Web.