Structure architecturale de Java Enterprise System

Les composants de Java ES prennent en charge le déploiement de solutions logicielles d'entreprise distribuées.

Pour satisfaire aux exigences de performances, de disponibilité, de sécurité, d'évolutivité et d'entretien requises par l'entreprise, les solutions logicielles doivent être correctement conçues.

Un certain nombre de paramètres entrent en jeu dans la conception de solutions logicielles d'entreprise distribuées. Ces paramètres représentent les différents aspects des interactions entre les composants logiciels utilisés pour la création de tels systèmes. La conception de systèmes distribués comprend les trois dimensions architecturales suivantes :

• Dépendances des services d'infrastructure : Cette dimension met l'accent sur le rôle des composants de service du système (voir Composants de service du système) dans les solutions distribuées de support.

• Niveaux logiques : cette dimension souligne l'importance de l'indépendance logique et physique des composants de solution dans le but de les déployer dans un environnement réseau ou Internet.

• Qualité de service : cette dimension insiste sur la manière dont les exigences de qualité de service, telles que la disponibilité, la sécurité, l'évolutivité et l'entretien, sont atteintes, y compris sur l'importance du rôle des composants de qualité de service (voir la section Composants de qualité de service).

Ces trois dimensions sont illustrées dans la figure suivante.

Figure 2–1 Dimensions de l'architecture de la solution Java ES

La combinaison de ces trois dimensions représente une structure unique qui intègre les relations entre les composants logiciels (composants d'application et composants d'infrastructure) nécessaires à l'obtention des fonctions de service et de la qualité de service requises pour une solution logicielle.

Les sections suivantes décrivent ces trois dimensions individuellement, puis elles présentent une synthèse de ces trois dimensions sous la forme d'une structure unifiée.

Dimension 1 : dépendances des services d'infrastructure

Les composants logiciels communicants des applications d'entreprise distribuées nécessitent un jeu de services d'infrastructure sous-jacent, permettant aux composants distribués de communiquer entre eux, de coordonner leur travail, d'implémenter un accès sécurisé, etc. Cette section explique le rôle essentiel joué par un certain nombre de composants de Java ES dans la prestation de ces services d'infrastructure.

Niveaux de services d'infrastructure

Lorsque vous concevez un système logiciel distribué, qu'il s'agisse essentiellement de composants au développement personnalisé ou de composants Java ES standard, vous devez incorporer un certain nombre de services d'infrastructure. Ces services fonctionnent sur plusieurs niveaux.

La dimension de dépendance des services d'infrastructure de l'architecture de solution est illustrée dans la Figure 2–2. Les niveaux représentés sur cette figure correspondent à une vue développée de la couche de service d'infrastructure de la Figure 1–1.

La hiérarchie des services de la Figure 2–2 et les dépendances entre eux constituent une dimension importante de l'architecture logique d'une solution. Ces services d'infrastructure fournissent la base conceptuelle pour comprendre le rôle des composants de service du système Java ES (voir Composants de service du système).

En général, les services présentés dans la Figure 2–2 se répartissent en trois grands groupes : les services de plate-forme du niveau inférieur, les services d'application du niveau supérieur et un groupe de services intermédiaires, ainsi nommés d'après leur emplacement entre les deux autres groupes.

Figure 2–2 Dimension 1 : niveaux des services d'infrastructure

Les paragraphes suivants décrivent les différents niveaux de services d'infrastructure et se réfèrent aux artefacts du langage de programmation Java, le cas échéant. Les niveaux de service sont décrits du niveau le plus bas au niveau le plus élevé, comme illustré dans la Figure 2–2:

• Plates-formes de système d'exploitation : assure la prise en charge de base de tout processus exécuté sur l'ordinateur. Le système d'exploitation (tel que Solaris^TM, Linux ou Microsoft Windows) gère les périphériques physiques ainsi que la mémoire, les threads et les autres ressources requises pour la prise en charge de Java Virtual Machine (machine JVM^TM).

• Transport réseau : assure la prise en charge réseau de base pour les communications entre les composants d'application distribués exécutés sur des ordinateurs différents. Ces services incluent la prise en charge des protocoles, tels que TCP et HTTP. Les autres protocoles de communication de niveau élevé (voir le niveau messagerie) dépendent de ces services de transport de base.

• Persistance : assure la prise en charge pour les accès et le stockage des données statiques (informations sur l'utilisateur, le répertoire ou la configuration) et des données d'application dynamiques (informations fréquemment mises à jour).

• Messagerie : assure la prise en charge de la communication synchrone et asynchrone entre les composants d'applications. La messagerie synchrone correspond à l'envoi et à la réception de messages en temps réel. Elle comporte également une fonction d'invocation de méthode distante (RMI) entre les composants J2EE et des interactions SOAP avec les services Web. La messagerie asynchrone, quant à elle, correspond à une communication pour laquelle l'envoi d'un message ne dépend pas de la capacité du destinataire à le recevoir immédiatement. Les spécifications de messagerie asynchrone, par exemple Java Message Service (JMS) et ebXML, prennent en charge une fiabilité garantie et d'autres sémantiques de messagerie.

• Exécution : assure la prise en charge requise par tout modèle de composant distribué, tel qu'un modèle J2EE ou CORBA. Outre l'invocation de méthode distante requise pour les composants distribués de couplage étroit, les services d'exécution incluent la gestion de l'état du composant (cycle de vie), la gestion de pools de threads, la synchronisation (verrouillage mutex), les services de persistance, le contrôle des transactions distribuées et le traitement des exceptions distribuées. Dans un environnement J2EE, ces services d'exécution sont fournis par des conteneurs EJB^TM, Web et des beans gérés par message dans un serveur d'applications ou un serveur Web.

• Sécurité et stratégie : assure la prise en charge des accès sécurisés aux ressources d'application. Ces services incluent la prise en charge des stratégies régissant les accès des groupes ou par rôles aux ressources distribuées, ainsi que les possibilités de connexion unique. La connexion unique permet que l'authentification d'un utilisateur sur un service d'un système distribué soit appliquée automatiquement aux autres services (composants J2EE, services métier et services Web) du système.

• Collaboration utilisateur : fournit des services qui jouent un rôle essentiel dans la prise en charge de la communication directe entre les utilisateurs et dans la prise en charge de la collaboration entre les utilisateurs d'environnements d'entreprise et Internet. Ces services sont des services d'entreprise de niveau application, fournis en principe par des serveurs autonomes (par exemple, un serveur de courrier ou un serveur de calendrier).

• Intégration : fournit les services qui regroupent les services d'exploitation existants. L'intégration fournit une interface commune qui permet d'accéder aux services comme dans un portail ou en intégrant ces services au moyen d'un moteur de processus qui les coordonne au sein d'un flux de production. L'intégration peut également avoir lieu sous forme d'interactions interentreprises entre différentes entreprises.

Les niveaux de service présentés dans la Figure 2–2 reflètent une dépendance générale de différents services d'infrastructure les uns par rapport aux autres, des services de système d'exploitation de bas niveau aux services d'intégration et d'application de plus haut niveau. En règle générale, chaque service dépend des services situés en aval et prend en charge les services en amont.

Toutefois, la Figure 2–2, ne représentent pas une couche stricte de services d'infrastructure. Les services de niveau supérieur peuvent interagir directement avec les services de niveau inférieur sans dépendre des niveaux intermédiaires. Par exemple, certains services exécutables peuvent dépendre directement de services de plate-forme, sans nécessiter le moindre niveau de service intermédiaire. De plus, d'autres niveaux de services, tels que le contrôle ou le service de gestion, peuvent être inclus dans cette illustration conceptuelle.

Composants de service d'infrastructure Java Enterprise System

Les composants de Java ES implémentent les niveaux de services d'infrastructure distribués illustrés à la Figure 2–2. Le positionnement des composants de service système Java ES au sein des différents niveaux est illustré dans la Figure 2–3.

Figure 2–3 Composants de service système Java ES

---

Remarque –

Les plates-formes de système d'exploitation illustrées dans la Figure 2–3 ne font pas véritablement partie de Java Enterprise System ; toutefois, elles sont été incluses afin de montrer les plates-formes de système d'exploitation sur lesquelles les composants Java ES sont pris en charge.

---

Dépendances de service d'infrastructure Java Enterprise System

En général, chaque composant de service système Java ES présenté dans la Figure 2–3 dépend des composants situés au-dessous de lui dans l'infrastructure et prend en charge les composants se trouvant au-dessus. Ces relations de dépendance et de prise en charge sont un facteur clé dans la conception d'architectures logiques.

Le Tableau 2–1 montre les relations spécifiques entre les composants de service système Java ES, en partant du haut vers le bas, comme illustré dans la Figure 2–3.

Tableau 2–1 Relations entre les composants de service système Java ES

Composant	Dépend de	Prend en charge
Portal Server	Application Server ou Web Server   Access Manager  Directory Server  Si configuré pour utiliser les canaux correspondants : Calendar Server Messaging Server Instant Messaging
Messaging Server	Directory Server  Access Manager (pour la connexion unique)	Calendar Server (pour les notifications par e-mail)  Portal Server (pour le canal de messagerie)
Instant Messaging	Directory Server  Access Manager (pour la connexion unique)	Portal Server (pour le canal de messagerie instantanée)
Calendar Server	Directory Server  Messaging Server (pour le service de notification par e-mail)  Access Manager (pour la connexion unique)	Portal Server (pour le canal de calendrier)
Access Manager	Application Server ou Web Server   Directory Server	Portal Server  Si configuré pour une connexion unique : Calendar Server Messaging Server Instant Messaging
Application Server	Message Queue  Directory Server (pour les objets gérés)	Portal Server  Access Manager
Message Queue	Directory Server (pour les objets gérés)	Application Server
Web Server	Access Manager (pour le contrôle d'accès)	Portal Server  Access Manager
Directory Server	aucune.	Portal Server  Calendar Server  Messaging Server  Instant Messaging  Access Manager
Registre de service	Aucune dépendance	Composants basés sur Applcation Server

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. Toutefois, les concepts de niveau logique s'appliquent également aux composants de service système assurant des services de niveau application, comme Messaging Server et Calendar Server.

Description des niveaux logiques

Cette section fournit une brève description des quatre niveaux logiques représentés dans la Figure 2–4. Cette description concernent les composants d'applications implémentés à l'aide du modèle de composant de la plate-forme Java 2, Enterprise Edition (plate-forme J2EE^TM). 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 2, Micro Edition plate-forme 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 service d'enterprise : 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, protocole SOAP). 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. Toutefois, certaines de ces solutions englobent des services de niveau application fournis directement par les composants de 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é à la figure suivante.

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

---

Remarque –

La Figure 2–5 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. Les lignes reliant les composants représentent les interactions.

---

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.

Dimension 3 : qualité de service

Les deux dimensions architecturales précédentes (dépendances des services d'infrastructure et niveaux logiques) concernent surtout les aspects logiques de l'architecture, notamment les composants et interactions requis pour fournir des services aux utilisateurs finals. Toutefois, la capacité d'une solution à satisfaire aux exigences de qualité de service constitue une dimension tout aussi importante en matière de déploiement.

La dimension de la qualité de service dans l'architecture de la solution met en évidence le rôle joué par les composants de qualité de service de Java ES.

Qualités de service

Compte tenu de l'importance prise par les services Web et d'e-commerce dans les opérations des entreprises, les performances, la sécurité, l'évolutivité et l'entretien de ces services sont devenus des exigences clés en termes de qualité de service pour les architectures de déploiement à grande échelle et de haute performance.

Pour concevoir une solution logicielle réussie, vous devez établir des exigences de qualité de service pertinentes et concevoir une architecture qui satisfait ces exigences. Certaines qualités de service importantes sont utilisées pour spécifier les exigences de qualité de service. Ces qualités de service sont répertoriées dans le tableau suivant.

Tableau 2–2 Qualités de service affectant l'architecture de la solution

Qualités de service du système	Description
Performances	Mesure du temps de réponse et de la latence par rapport aux conditions de chargement de l'utilisateur.
Disponibilité	Mesure de la fréquence à laquelle les ressources et services d'un système sont accessibles aux utilisateurs finals (temps d'activité d'un système).
Sécurité	Combinaison complexe de facteurs décrivant l'intégrité d'un système et de ses utilisateurs. La sécurité implique la sécurité physique des systèmes, la sécurité du réseau, la sécurité des applications et des données (authentification et autorisation des utilisateurs) ainsi que le transport sécurisé des informations.
Évolutivité	Possibilité d'ajouter de la capacité à un système déployé dans le temps. En principe, l'évolutivité implique l'ajout de ressources au système, mais elle ne doit pas requérir de changements au niveau de l'architecture du déploiement.
Capacité latente	Aptitude d'un système à traiter une utilisation de charge de pointe inhabituelle sans ressources supplémentaires.
Facilité de maintenance	Facilité avec laquelle un système déployé peut être entretenu. Cela comprend le contrôle du système, la réparation des problèmes se produisant et la mise à niveau des composants matériels et logiciels.

La dimension de la qualité de service a un impact considérable sur l'architecture de déploiement d'une solution : à savoir, la manière dont les composants d'applications et les composants d'infrastructure sont déployés dans un environnement physique.

Les qualités de service qui affectent l'architecture de déploiement sont étroitement liées : les exigences inhérentes à une qualité du système ont souvent une influence sur la conception des autres qualités de service. Par exemple, des niveaux de sécurité relativement élevés peuvent affecter les performances qui, à leur tour, sont susceptibles d'avoir une influence sur la disponibilité. L'ajout d'ordinateurs supplémentaires pour traiter les problèmes de disponibilité par la redondance affecte souvent les frais de maintenance (entretien).

Il est capital de comprendre la manière dont les qualités de service sont liées et de savoir quels compromis sont à faire pour concevoir des architectures de déploiement qui satisfont les exigences et les contraintes d'entreprise.

Composants de qualité de service de Java Enterprise System

Plusieurs composants de Java ES sont utilisés principalement pour améliorer la qualité des services fournis par les composants de service du système ou les composants d'applications distribuées. Ces composants logiciels sont fréquemment utilisés en association avec des composants matériels tels les équilibreurs de charge et les pare-feux.

Les composants de qualité de service de Java ES, présentés dans la section Composants de qualité de service, sont récapitulés ci-après :

• Composants de disponibilité : ces composants assurent un temps d'activité quasi continu d'une solution déployée.

• Composants d'accès : ces composants fournissent un accès Internet sécurisé aux services système ainsi qu'une fonction de routage.

• Composants administratifs : ces composants assurent un entretien amélioré des composants système.

Le tableau ci-dessous répertorie les composants de qualité de service de Java ES les plus importants d'un point de vue architectural avec les qualités système sur lesquelles ils ont la plus grande influence.

Tableau 2–3 Composants de qualité de service et qualités système influencées

Composant	Qualités système influencées
Communications Express	Sécurité Évolutivité
Directory Proxy Server	Sécurité Évolutivité
High Availability Session Store	Disponibilité
Portal Server Secure Remote Access	Sécurité Évolutivité
Sun Cluster	Disponibilité Évolutivité
Web Proxy Server	Sécurité Performances Facilité de maintenance

Logiciel Sun Cluster

Le logiciel Sun Cluster offre des services haute disponibilité Évolutivité pour les composants Java ES et pour les applications prises en charge par l'infrastructure Java ES.

Un cluster est un ensemble d'ordinateurs interconnectés fournissant conjointement une vue client unique des services, ressources du système et données. Au niveau interne, le cluster utilise les ordinateurs redondants, les interconnexions, le stockage de données et les interfaces réseau pour assurer une haute disponibilité aux données et services basés sur le cluster.

Le logiciel Sun Cluster contrôle en permanence l'état des nœuds membres et des autres ressources du cluster. En cas d'échec, Sun Cluster intervient pour initier le basculement des ressources qu'il contrôle en utilisant la redondance interne pour assurer un accès quasi continu à ces ressources.

La figure suivante représente un cluster à deux nœuds prenant en charge les services de magasins de données pour Messaging Server et Calendar Server.

Figure 2–6 Conception de disponibilité à l'aide des nœuds Sun Cluster

Des packages de services de données Sun Cluster (parfois appelés agents Sun Cluster) sont disponibles pour tous les composants de service Java ES. Vous pouvez également écrire des agents pour les composants d'applications personnalisées.

Compte tenu du contrôle que procure le logiciel Sun Cluster, il peut également fournir des services évolutifs. Le renforcement du système de fichiers globaux d'un cluster et la capacité de plusieurs nœuds d'un cluster à exécuter des services d'infrastructure ou des services applicatifs permettent de répartir la demande accrue de ces services sur plusieurs instances simultanées. S'il est configuré convenablement, le logiciel Sun Cluster peut par conséquent assurer aussi bien une disponibilité élevée qu'une importante évolutivité dans une application d'entreprise distribuée.

Du fait de la redondance nécessaire à la prise en charge des environnements Sun Cluster, l'intégration de Sun Cluster dans une solution fait considérablement augmenter le nombre d'ordinateurs et de liaisons réseau requis dans votre environnement physique.

Contrairement aux services fournis par les composants de Java ES, les services de disponibilité de Sun Cluster sont distribués sous la forme de services entre homologues. Le logiciel Sun Cluster doit donc être installé sur tous les ordinateurs d'un cluster.

Synthèse des trois dimensions architecturales

Considérées conjointement, les trois dimensions architecturales présentées dans la Figure 2–1 et étudiées dans les sections précédentes forment une structure pour la conception de solutions logicielles distribuées. Ces trois dimensions (dépendances des services d'infrastructure, niveaux logiques et qualité de service) soulignent le rôle joué par les composants de Java ES dans les architectures de solution.

Chaque dimension représente un aspect d'architecture spécifique. Toute architecture de solution doit prendre en compte la totalité de ces dimensions. Par exemple, les composants distribués de chaque niveau logique d'une architecture de solution (dimension 2) doivent être pris en charge par les composants d'infrastructure appropriés (dimension 1) et les composants de qualité de service adéquats (dimension 3).

De même, tout composant d'une architecture de solution joue des rôles différents par rapport aux diverses dimensions architecturales. Par exemple, Directory Server peut être considéré comme un composant d'arrière-plan du niveau données (dimension2) et comme prestataire de services de persistance (dimension1).

Du fait de la position centrale de Directory Server par rapport à ces deux dimensions, les problèmes de qualité de service (dimension3) sont d'une importance capitale pour ce composant de Java ES. Une panne de Directory Server pouvant avoir un impact énorme sur le système d'entreprise, la conception de haute disponibilité est très importante pour ce composant. De plus, sachant que Directory Serverest utilisé pour le stockage d'informations sensibles sur les utilisateurs ou la configuration, la conception de sécurité pour ce composant revêt également une importance capitale.

L'interaction de ces trois dimensions par rapport aux composants de Java ES influence la conception des architectures logiques et de déploiement de la solution.

Toutefois, ce manuel n'a pas pour objectif de détailler les différentes méthodologies de conception basées sur la structure architecturale représentée par Structure architecturale de Java Enterprise System . Toutefois, la structure d'architecture tridimensionnelle souligne les aspects de conception importants pour comprendre le déploiement des solutions logicielles basées sur Java Enterprise System.