Chapitre 4 Conception logique

La phase de conception logique du cycle de vie de la solution consiste à définir une architecture logique qui décrit les relations existant entre les composants logiques de la solution. Cette architecture, associée à l'analyse d'utilisation établie lors de la phase de spécification technique, constitue un scénario de déploiement, qui sert de base pour la phase de conception du déploiement.

Ce chapitre se compose des sections suivantes :

• À propos des architectures logiques

• Conception d'une architecture logique

• Composants Java Enterprise System

• Exemple d'architecture logique

• Zones d'accès

• Scénario de déploiement

À propos des architectures logiques

L'architecture logique identifie les composants logiciels nécessaires à l'implémentation d'une solution et décrit les relations existant entre ces composants. L'architecture logique et les exigences de qualité de service définies lors de la phase de spécification technique constituent un scénario de déploiement. Celui-ci sert de base pour concevoir l'architecture de déploiement intervenant au cours de la phase suivante, à savoir la conception du déploiement.

Lorsque vous développez une architecture logique, vous devez identifier non seulement les composants qui fournissent des services aux utilisateurs, mais également ceux qui fournissent les logiciels intermédiaires et les services de plateforme requis. Vous pouvez également identifier les dépendances des services d'infrastructure et les niveaux logiques.

Les dépendances des services d'infrastructure et les niveaux logiques sont deux des trois dimensions de l'architecture de la solution sur lesquelles Sun Java^TM Enterprise System repose. Ces trois dimensions sont répertoriées ci-dessous et représentées à la section À propos des architectures logiques.

• Dépendances des services d'infrastructure : composants logiciels en interaction qui fournissent des services d'entreprise. Ces composants nécessitent un ensemble sous-jacent de services d'infrastructure qui permettent aux composants distribués de communiquer les uns avec les autres et d'interagir.

• Niveaux logiques : organisation logique des composants logiciels par niveaux représentant l'indépendance logique et physique des composants logiciels selon la nature des services qu'ils fournissent.

• Qualité de service : qualités de service système, telles les performances, la disponibilité, l'évolutivité et d'autres qualités illustrant divers aspects de la conception et du fonctionnement d'une solution logicielle.

  

---

Remarque –

Pour plus d'informations sur les concepts d'architecture de Java Enterprise System, consultez le chapitre “Java Enterprise System Architecture” du manuel Présentation technique de Sun Java Enterprise System 2005Q4.

---

Une architecture logique illustre les niveaux de service d'infrastructure en décrivant les composants nécessaires et leurs dépendances. Elle répartit également les composants sur des niveaux logiques qui correspondent aux services de présentation, d'entreprise et de données accessibles au niveau client. Les exigences de qualité de service ne sont pas modélisées dans l'architecture logique, mais associées à cette dernière dans un scénario de déploiement.

Conception d'une architecture logique

Lors de la conception d'une architecture logique, tenez compte des cas d'utilisation identifiés au cours de la phase de spécification technique pour déterminer les composants de Java Enterprise System qui fournissent les services requis par la solution. Vous devez également déterminer les composants qui fournissent des services aux composants préalablement identifiés.

Les composants de Java Enterprise System sont positionnés dans une architecture à plusieurs niveaux en fonction du type de service qu'ils fournissent. Cette approche vous permettra de définir la manière dont les services fournis par les composants doivent être distribués et d'élaborer une stratégie d'implémentation des exigences de qualité de service (évolutivité, disponibilité, etc.)

Vous pouvez également répartir les composants logiques dans des zones d'accès sécurisé. À la section Zones d'accès, vous trouverez des exemples de ces zones.

Composants Java Enterprise System

Java Enterprise System est constitué de composants logiciels en interaction fournissant des services d'entreprise à utiliser pour créer votre solution. Le schéma ci-dessous illustre les principaux composants logiciels de Java Enterprise System. Le manuel Présentation technique de Sun Java Enterprise System 2005Q4 fournit des informations complémentaires sur les composants Java Enterprise System et leurs services.

Figure 4–1 Composants Java Enterprise System

Dépendances entre composants

Lorsque vous identifiez les composants Java Enterprise System d'une architecture logique, vous devez également identifier les composants qui les prennent en charge. Par exemple, si vous identifiez Messaging Server en tant que composant requis d'une architecture logique, cette architecture doit également comprendre Directory Server et, éventuellement, Access Manager. En effet, Messaging Server dépend de Directory Server pour les services d'annuaire et d'Access Manager pour les solutions exigeant une connexion unique.

Le tableau ci-dessous répertorie les dépendances entre les composants de Java Enterprise System. Reportez-vous à la section Dépendances entre composants pour une représentation visuelle des dépendances entre les composants clés. Lors de la conception d'une architecture logique, utilisez ce tableau et le schéma associé pour identifier les composants dépendants dans votre conception.

Tableau 4–1 Dépendances entre composants de Java Enterprise System

Composant Java Enterprise System	Dépendant de
Application Server	Message Queue ; Directory Server (facultatif)
Calendar Server	Messaging Server (pour le service de notification par e-mail) ; Access Manager (pour la connexion unique) ; Web Server (pour l'interface Web) ; Directory Server
Communications Express	Access Manager (pour la connexion unique) ; Calendar ServerMessaging Server ; Instant Messaging ; Web Server (pour l'interface Web) ; Directory Server
Directory Proxy Server	Directory Server
Directory Server	Aucune
Access Manager	Application Server ou Web Server ; Directory Server
Instant Messaging	Access Manager (pour la connexion unique) ; Directory Server
Message Queue	Directory Server (facultatif)
Messaging Server	Access Manager (pour la connexion unique) ; Web Server (pour l'interface Web) ; Directory Server
Portal Server	S'il est configuré en vue de l'utilisation de canaux Portal Server :  Calendar Server ; Messaging Server ; Instant Messaging  Access Manager (pour la connexion unique) ; Application Server ou Web Server ; Directory Server
Portal Server Secure Remote Access	Portal Server
Web Server	Access Manager (facultatif, pour le contrôle d'accès)

---

Remarque –

La liste des dépendances entre composants de Java Enterprise System figurant à la section Dépendances entre composants n'est pas exhaustive. En effet, les dépendances que vous devez prendre en compte lors de la planification de l'installation n'y sont pas répertoriées. Pour une liste complète des dépendances de composants Java Enterprise System, reportez-vous au manuel Guide d’installation de Sun Java Enterprise System 2005Q4 pour UNIX.

---

Figure 4–2 Dépendances entre composants de Java Enterprise System

Prise en charge d'un conteneur Web

La section Dépendances entre composants précédente ne fait pas état du conteneur Web au sein duquel s'exécutent Portal Server et Access Manager. Ce conteneur peut être fourni par Application Server, Web Server ou un produit tiers. Si votre architecture logique inclut Portal Server ou Access Manager, veillez à utiliser le conteneur Web nécessaire à ces composants.

Services logiques distincts fournis par Messaging Server

Le composant Messaging Server de Java Enterprise System peut être configuré pour exécuter des instances séparées fournissant les services logiques distincts suivants :

• Message Transfer Agent

• Message Multiplexor

• Message Express Multiplexor

• Message Store

Ces différentes configurations de Messaging Server offrent des fonctionnalités pouvant être déployées sur des serveurs physiques distincts et être présentes à différents niveaux d'une architecture logique. Étant donné que ces configurations de Messaging Server correspondent à des services logiques distincts sur différents niveaux, elles doivent être considérées comme des composants logiques distincts dans l'architecture logique. La section Exemple d'architecture logique propose un exemple de composants logiques distincts.

Le tableau ci-dessous décrit les configurations logiques distinctes de Messaging Server.

Tableau 4–2 Configurations de Messaging Server

Sous-composant	Description
Message Transfer Agent (MTA)	Prend en charge l'envoi de messages en traitant les connexions SMTP, en acheminant les messages et en les livrant aux mémoires de messages appropriées. Les composants MTA peuvent être configurés pour la prise en charge des messages provenant de l'extérieur (entrants) ou envoyés de l'entreprise (sortants).
Message Store (STR)	Permet la récupération et le stockage des messages.
Message Multiplexor (MMP)	Prend en charge la récupération des messages en accédant aux mémoires de messages des clients de messagerie à l'aide du protocole IMAP ou POP.
Messenger Express Multiplexor (MEM)	Prend en charge la récupération des messages en accédant aux mémoires de messages pour le compte de clients Web (HTTP).

Composants d'accès

Java Enterprise System fournit également des composants qui assurent un accès aux services système, souvent depuis des sites situés hors du pare-feu de l'entreprise. Certaines configurations de Messaging Server peuvent également fournir un accès réseau lorsque Messaging Server est configuré pour le multiplexeur de messages, par exemple). Le tableau ci-dessous répertorie les composants de Java Enterprise System qui assurent un accès distant aux services système.

Tableau 4–3 Composants de Java Enterprise System fournissant un accès distant

Composant	Description
Directory Proxy Server	Fournit des services améliorés d'accès aux annuaires, de compatibilité de schéma, de routage et d'équilibrage de charge pour des plusieurs instances de Directory Server.
Portal Server, Portal Server Secure Remote Access	Fournit un accès Internet sécurisé de l'extérieur d'un pare-feu d'entreprise au contenu et aux services de Portal Server, y compris les portails internes et les applications Internet.
Portal Server, Portal Server Mobile Access	Fournit un accès sans fil depuis des périphériques mobiles et un accès vocal à Portal Server.
Messaging Server Message Multiplexor (MMP)	Prend en charge la récupération des messages en accédant aux mémoires de messages pour le compte de clients Web (HTTP).

Les composants fournissant un accès distant sont généralement déployés dans des zones d'accès sécurisé, comme l'illustre l'exemple de la section Zones d'accès.

Conception d'architecture à plusieurs niveaux

Java Enterprise System est adapté à la conception d'architectures à plusieurs niveaux, où les services sont répartis selon les fonctionnalités qu'ils proposent. Chaque service est logiquement indépendant et accessible par des services situés au même niveau ou sur un autre niveau. Le schéma ci-dessous décrit un modèle d'architecture à plusieurs niveaux pour des applications d'entreprise, modèle comportant les niveaux client, présentation, services d'entreprise et données.

Figure 4–3 Modèle d'architecture à plusieurs niveaux

Le tableau suivant fait un récapitulatif des niveaux logiques décrits à la section Conception d'architecture à plusieurs niveaux.

Tableau 4–4 Niveaux logiques dans une architecture à plusieurs niveaux

Niveau	Description
Niveau client	Contient les applications clientes qui présentent des informations aux utilisateurs finals. Dans le cas de Java Enterprise System, il s'agit généralement de clients de messagerie, de navigateurs Web ou de clients d'accès mobile.
Niveau présentation	Fournit les services qui présentent des données aux utilisateurs finals et permet à ceux-ci de traiter et de manipuler la présentation de ces données. Par exemple, un client de messagerie Web ou le composant Portal Server permettent aux utilisateurs de modifier la présentation des informations qu'ils reçoivent.
Niveau services d'entreprise	Fournit des services d'arrière-plan chargés de récupérer les données du niveau correspondant et de les fournir aux autres services des niveaux présentation ou services d'entreprise, ou directement aux clients du niveau client. Par exemple, Access Manager fournit des services d'identité aux autres composants de Java Enterprise System.
Niveau données	Fournit des services de base de données aux services des niveaux présentation ou services d'entreprise. Par exemple, Directory Server fournit un accès à l'annuaire LDAP pour les autres services.

Une conception d'architecture à plusieurs niveaux offre plusieurs avantages. Au cours de la phase de conception du déploiement, la répartition des services selon leur fonctionnalité vous permet de déterminer la façon dont vous allez les distribuer au sein de votre réseau. De plus, vous pouvez voir comment les composants de l'architecture accèdent aux services des autres composants. Cette transparence vous permet de planifier les solutions de qualité de service en termes de disponibilité, d'évolutivité, de sécurité, etc.

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.

   

Zones d'accès

Les composants d'une architecture logique peuvent également être placés dans des zones d'accès décrivant la façon dont l'architecture fournit un accès sécurisé. Le schéma suivant décrit les zones d'accès pour le déploiement. Chacune d'entre elles décrit la façon dont les composants fournissent un accès sécurisé à Internet et à l'intranet.

Figure 4–5 Composants logiques placés dans des zones d'accès

le tableau ci-dessous décrit les zones présentées dans la section consacrée aux Zones d'accès.

Tableau 4–6 Zones d'accès sécurisé et leurs composants

Zone d'accès	Description
Zone d'accès interne (intranet) :	accès à Internet régi par des règles appliquées via un pare-feu entre l'intranet et Internet. La zone d'accès interne sert généralement aux utilisateurs finals pour la navigation sur le Web et l'envoi de messages.  Dans certains cas, l'accès direct à Internet pour la navigation sur le Web est autorisé. Toutefois, l'accès sécurisé à et depuis Internet est généralement assuré via la zone d'accès externe.
Zone d'accès externe (DMZ)	Fournit un accès sécurisé à Internet en jouant le rôle de tampon de sécurité entre le Web et les services d'arrière-plan stratégiques.
Zone d'accès sécurisé (arrière-plan)	Fournit un accès restreint aux services d'arrière-plan stratégiques, accessibles uniquement par la zone d'accès externe.

Le schéma des Zones d'accès ne correspond pas aux niveaux logiques décrits dans les exemples précédents, mais fait apparaître en détail les composants qui fournissent un accès distant et interne, ainsi que les relations entre ces composants et les mesures de sécurité telles que les pare-feux. Il fournit une représentation visuelle des règles d'accès à appliquer. Combinez la conception d'architecture à plusieurs niveaux et celle des zones d'accès pour obtenir un modèle logique de votre déploiement planifié.

Scénario de déploiement

La conception de l'architecture de déploiement terminée ne suffit pas pour passer à la phase de conception du déploiement dans le cycle de vie de la solution. Vous devez l'associer aux exigences de qualité de service identifiées au cours de la phase de spécification technique. Pour constituer un scénario de déploiement valable, vous devez associer architecture logique et exigences de qualité de service. Ce scénario sert de point de départ pour concevoir l'architecture de déploiement, comme l'explique le Chapitre 5, Conception du déploiement.