Dimension 2 : niveaux logiques

Les composants logiciels en interaction des applications d'entreprise distribuées peuvent être considérés comme des éléments figurant dans plusieurs niveaux logiques. Ces niveaux représentent l'indépendance logique et physique des composants logiciels, selon la nature des services qu'ils fournissent.

La dimension de niveau logique de l'architecture de la solution est illustrée dans la figure suivante.

Figure 2–4 Dimension 2 : niveaux logiques pour les applications d'entreprise distribuées

Pour l'essentiel, les architectures de niveau logique correspondant à la couche d'application d'entreprise distribuée de la Figure 1–1 . Les composants de service système Java ES étudiés dans la section Niveaux de services d'infrastructure assurent la prise en charge des composants d'application dans tous les niveaux logiques illustrés dans la Figure 2–4. Si les concepts de niveau logique s'appliquent essentiellement aux applications d'entreprise personnalisées, ils s'appliquent également aux services de collaboration fournis par les composants Sun Java Communications Suite et certains services de portail.

Description des niveaux logiques

Cette section fournit une brève description des quatre niveaux logiques représentés dans la Figure 2–4. Ces descriptions concernent les composants d'application implémentés à l'aide du modèle de composant de la plate-forme J2EE. Cependant, d'autres modèles de composants distribués, tels que CORBA, prennent également en charge cette architecture.

• Niveau client : le niveau client représente une logique d'application à laquelle un utilisateur final peut accéder directement par le biais d'une interface utilisateur. La logique du niveau client peut inclure les clients basés sur le navigateur, les composants Java s'exécutant sur un ordinateur de bureau ou les clients mobiles de la plate-forme Java^TM 2, Micro Edition (J2ME^TM) fonctionnant sur un périphérique de poche.

• Niveau présentation : le niveau présentation comprend la logique d'application qui prépare les données en vue de leur livraison au niveau client et traite les requêtes émanant du niveau client en vue de les livrer à la logique d'entreprise d'arrière-plan. La logique du niveau présentation comprend généralement des composants J2EE tels que les composants Java servlet ou les composants JSP qui préparent les données en vue de leur livraison en format HTML ou XML ou qui reçoivent les requêtes de traitement. Ce niveau doit également inclure un service de portail pouvant fournir un accès personnalisé et sûr aux services d'entreprise dans le niveau service d'entreprise.

• Niveau services d'entreprise : le niveau service d'entreprise comprend la logique qui exécute les fonctions principales de l'application : traitement des données, implémentation des règles d'entreprise, coordination de plusieurs utilisateurs et gestion des ressources externes, telles que les bases de données et les systèmes existants. En général, ce niveau se compose de composants étroitement associés conformes au modèle de composant distribué J2EE, par exemple, les objets Java, les composants EJB ou les beans gérés par messages. Il est possible d'assembler les composants J2EE pour fournir des services d'entreprise complexes, tels qu'un service d'inventaire ou un service de calcul de taxe. Les composants individuels et assemblages de services peuvent être encapsulés sous la forme de services Web associés au sein d'un modèle d'architecture orienté service et respectant les normes d'interface SOAP (Simple Object Access Protocol). Les services d'entreprise peuvent également être élaborés sous la forme de serveurs autonomes, tels qu'un serveur de calendrier d'entreprise ou un serveur de messagerie.

• Niveau données : le niveau données se compose de services qui fournissent des données persistantes pour la logique d'entreprise. Ces données peuvent correspondre à des données d'application stockées dans un système de gestion de base de données ou il peut s'agir d'informations de ressources et de répertoires stockées dans un magasin de données LDAP (Lightweight Directory Access Protocol, protocole LDAP). Les services de données peuvent également comporter des données provenant de sources externes ou des données accessibles à partir de systèmes informatiques existants.

Indépendance physique et logique

La dimension architecturale illustrée dans la Figure 2–4 met en évidence l'indépendance logique et physique des composants, représentés par quatre niveaux distincts. Ces niveaux reflètent le partitionnement de la logique d'application sur les divers ordinateurs d'un réseau :

• Indépendance logique : les quatre niveaux du modèle architectural représentent l'indépendance logique. Vous pouvez modifier la logique d'application sur un niveau (par exemple, sur le niveau service d'entreprise) indépendamment de la logique sur les autres niveaux. Vous pouvez changer l'implémentation de la logique d'entreprise sans avoir à modifier ou à mettre à niveau la logique du niveau présentation ou du niveau client. Cette indépendance signifie, par exemple, que vous pouvez introduire de nouveaux types de composants clients sans avoir à modifier les composants de service d'entreprise.

• Indépendance physique : les quatre niveaux représentent également l'indépendance physique. Vous pouvez déployer la logique dans différents niveaux et sur plusieurs types de plates-forme matérielle (c'est-à-dire différentes configurations de processeur, différents chipset et systèmes d'exploitation). Cette indépendance permet d'exécuter des composants d'applications distribuées sur les ordinateurs qui sont le mieux adaptés à leurs exigences individuelles et à l'optimisation de la bande passante réseau.

  La méthode de mappage des composants d'application ou d'infrastructure avec un environnement matériel (c'est-à-dire votre architecture de déploiement) dépend de plusieurs facteurs, notamment l'échelle et la complexité de votre solution logicielle. Pour de très petits déploiements, une architecture de déploiement peut comprendre un nombre réduit d'ordinateurs. Pour les déploiements à grande échelle, le mappage des composants sur un environnement matériel peut prendre en compte des facteurs comme la vitesse et la puissance des ordinateurs, la vitesse et la bande passante des liaisons réseau, les impératifs en termes de sécurité et de pare-feu, ainsi que les stratégies de réplication des composants pour une évolutivité et une disponibilié élevées.

Architecture à plusieurs niveaux appliquée aux composants système

Comme indiqué dans la Figure 2–3, les composants de service d'infrastructure de Java ES fournissent l'infrastructure de support sous-jacente pour les solutions logicielles distribuées. Certaines de ces solutions englobent des services de niveau application fournis directement par les composants Sun Java Communications Suite et certains composants Java ES. Ces solutions utilisent des approches de conception de niveau logique.

Par exemple, les services de communication par e-mail fournis par Messaging Server sont implémentés à l'aide d'un certain nombre de configurations logiques distinctes de Messaging Server . Ces configurations distinctes offrent chacune un ensemble de services distinct. Lors de la conception de ces solutions de messagerie, ces configurations distinctes sont représentées sous forme de composants séparés situés sur différents niveaux logiques, comme illustré dans la figure suivante, où les lignes reliant les composants représentent les interactions.

La figure suivante ne représente pas une architecture logique complète. Un certain nombre de composants Java ES ont été omis afin de simplifier le schéma.

Figure 2–5 Messaging Server  : exemple d'architecture à plusieurs niveaux

Les composants de communication ne font pas partie de Java ES mais sont souvent déployés avec les composants Java ES et utilisés au sein d'architectures Java ES. Ces composants de communication font partie de Sun Java Communications Suite et sont cités dans ce document à des fins d'illustration uniquement.

La séparation logique des fonctions de Messaging Server sur différents niveaux permet de déployer les configurations de Messaging Server logiquement distinctes sur différents ordinateurs d'un environnement physique. La séparation physique offre la souplesse nécessaire pour répondre aux exigences de qualité de service (voir Dimension 3 : qualité de service). Par exemple, elle fournit diverses solutions de disponibilité pour les différentes instances ainsi que diverses implémentations de sécurité pour les différentes fonctions de Messaging Server .