Chapitre 2 Architectures de solutions Java ES
Ce chapitre fournit un aperçu des concepts architecturaux sur lesquels sont basées les solutions Java ES. Il explique comment les composants de services système et de qualité de service sont utilisés pour prendre en charge les solutions d'entreprise distribuées.
Les architectures de solution Java ES ont deux aspects : une logical architecture (architecture logique) et une deployment architecture (architecture de déploiement). La première illustre les interactions entre les blocs fonctionnels logiques (composants logiciels) d'une solution, tandis que la seconde représente le mappage de l'architecture logique sur un environnement informatique physique. Les composants Java ES jouent un rôle important à la fois dans les architectures logiques et les architectures de déploiement.
Ce chapitre décrit une structure architecturale destinée à la conception d'architectures de solution Java ES, et un exemple d'architecture s'appuyant sur cette structure. Le chapitre se compose des sections suivantes :
Structure architecturale Java ES
Les composants Java ES prennent en charge le déploiement de solutions logicielles 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 d'entreprise. 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 souligne l'importance du rôle des composants de services système dans la prise en charge de solutions distribuées (voir la section Composants de services système).
-
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 d'une 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 en interaction des applications d'entreprise distribuées nécessitent des services d'infrastructure sous-jacents, 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.
Les dépendances des services d'infrastructure de l'architecture d'une solution sont illustrées 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 constituent la principale dimension de ces composants de services système Java ES (voir la section Composants de services système).
En général, les services présentés dans la figure ci-après 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 descriptions suivantes des différents niveaux de services d'infrastructure font référence aux artefacts du langage de programmation Java, le cas échéant ; ils sont répertoriés 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 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 JVMTM).
-
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'application. 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, 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 les accès basés sur les 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 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 travaux. 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 des 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 des services d'architecture Java ES
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 services système au sein des différents niveaux est illustré dans la figure ci-après.
Figure 2–3 Composants de service système Java ES
Remarque –
Les boîtes grisées dans la figure signalent des composants qui ne sont pas inclus dans Java ES. Les composants de collaboration utilisateur 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 font partie de Sun Java Communications Suite et sont cités dans ce document à des fins d'illustration uniquement. Par ailleurs, les plates-formes de systèmes d'exploitation ne font pas véritablement partie de Java ES ; toutefois, elles ont été incluses afin de montrer les plates-formes de systèmes d'exploitation sur lesquelles les composants Java ES sont pris en charge.
Dépendances des services d'infrastructure Java ES
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 ci-après montre les relations spécifiques entre les composants de services 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
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 JavaTM 2, Micro Edition (J2METM) 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.
Remarque –
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
Remarque –
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 .
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. 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 |
|---|---|
|
Mesure du temps de réponse et de la latence par rapport aux conditions de chargement de l'utilisateur. |
|
|
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). |
|
|
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. |
|
|
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 ne doit pas entraîner de changements au niveau de l'architecture du déploiement. |
|
|
Aptitude d'un système à traiter une utilisation de charge de pointe inhabituelle sans ressources supplémentaires. |
|
|
Facilité avec laquelle un système déployé peut être entretenu. Cela inclut le contrôle du système, la résolution des problèmes 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'influer 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 Java ES
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-feu.
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é : assurent un temps d'activité quasi continu d'une solution déployée.
-
Composants d'accès : fournissent un accès Internet sécurisé aux services système ainsi qu'une fonction de routage.
-
Composants de contrôle : fournissent des informations en temps réel sur les composants Java ES.
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 |
|---|---|
|
High Availability Session Store |
Disponibilité |
|
Console de contrôle |
Entretien |
|
Sécurité Extensibilité |
|
|
Sun Cluster |
Disponibilité Extensibilité |
|
Édition géographique de Sun Cluster |
Disponibilité Extensibilité |
|
Serveur Web Proxy |
Sécurité Performances Extensibilité |
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 de panne, 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.
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.
Une extension au logiciel Sun Cluster software est fournie par Sun Cluster Geographic Edition, qui protège les applications contre les arrêts brutaux à l'aide de plusieurs clusters répartis dans des emplacements géographiques différents et d'une infrastructure assurant la réplication des données entre les clusters.
Remarque –
Sun Cluster et Sun Cluster Geographic Edition sont pris en charge sur le système d'exploitation SolarisTM (SE Solaris) uniquement.
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 (dimension 3) sont d'une importance capitale pour ce composant Java ES. Une panne de Directory Server pouvant avoir un impact énorme sur un système d'entreprise, la conception de haute disponibilité est très importante pour ce composant. De plus, sachant que Directory Server est 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.
Ce manuel ne détaille pas les différentes méthodologies de conception basées sur la structure architecturale représentée par la section Structure architecturale Java ES. Toutefois, la structure d'architecture tridimensionnelle souligne les aspects de conception importants pour comprendre le déploiement des solutions logicielles basées sur Logiciel Java Enterprise System.
Exemple d'architecture de solution Java ES
Java ES prend en charge une large gamme de solutions logicielles. De nombreuses solutions peuvent être conçues et déployées en version standard, sans développement supplémentaire, en utilisant les composants fournis avec Java ES. D'autres solutions peuvent exiger des efforts de développement considérables, nécessitant le développement de composants J2EE personnalisés afin de fournir de nouveaux services d'entreprise ou de présentation. Vous pouvez encapsuler ces composants personnalisés sous la forme de services Web conformes aux normes d'interface SOAP. La plupart de ces solutions impliquent une combinaison de ces deux approches.
Cette section fournit un exemple illustrant la prise en charge par Java ES d'une solution standard, bâtie autour des concepts d'architecture décrits dans la section précédente.
Scénario de communication d'entreprise
Généralement, les entreprises ont besoin de prendre en charge la communication entre leurs employés, en particulier les services de courrier et de calendrier. Ces entreprises pensent qu'il est avantageux pour leurs employés d'avoir un accès personnalisé aux sites Web internes et aux autres ressources basées sur les services d'autorisation et d'authentification de l'entreprise. De plus, ces entreprises souhaitent que l'identité des employés soit suivie dans tous les services de l'entreprise afin qu'une connexion Web unique permette d'accéder à ces services.
Ces exigences d'entreprise spécifiques, qui ne constituent qu'un exemple parmi d'autres, sont résumées dans le tableau ci-dessous.
Tableau 2–4 Récapitulatif des besoins d'entreprise : scénario de communications|
Exigence de l'entreprise |
Description |
Services requis |
|---|---|---|
|
Connexion unique |
Accès aux ressources d'entreprise sécurisées et aux services basés sur une identité unique avec une connexion unique pour l'accès Web |
Services d'identité |
|
Messagerie Calendrier |
Messagerie électronique assurant la communication entre les employés et le monde extérieur Dispositions électroniques des employés concernant le calendrier et les réunions |
Services de communication et de collaboration |
|
Accès au portail |
Points d'accès Web uniques et personnalisés aux services de communication, tels que la messagerie électronique, le calendrier et les pages Web internes |
Services de portail |
En outre, toute entreprise doit faire face à des exigences de performances, de disponibilité, de sécurité réseau et d'évolutivité du système logiciel qui fournit ces services.
Architecture logique de l'exemple de scénario
La figure suivante présente une architecture logique pour la fourniture de services de portail, de communication et d'identité identifiés dans le Tableau 2–4 à l'aide de composants Java ES. L'architecture traite les configurations logiques spécifiques de Messaging Server comme composants séparés du fait des services distincts fournis par chacun d'entre eux.
Figure 2–6 Architecture logique d'un scénario de communication d'entreprise
Les composants placés dans une dimension horizontale représentent les niveaux logiques standard et ceux placés dans une dimension verticale représentent les niveaux de services d'infrastructure. Les interactions entre les composants dépendent de leurs fonctions en tant que services d'infrastructure distribués (interactions entre les niveaux de services d'infrastructure) ou de leurs rôles au sein d'une architecture d'application à plusieurs niveaux (interactions au sein des niveaux logiques et entre ceux-ci).
Dans cette architecture, Access Manager, en accédant aux informations utilisateur stockées dans Directory Server, régit l'autorisation et l'authentification de connexion unique pour Portal Server et les autre composants Web du niveau présentation. Les composants de Messaging Server incluent une mémoire de (Messaging Server -STR) au niveau données, l'envoi et la réception des composants au niveau services d'entreprise et un composant d'accès HTTP et Communications Express au niveau présentation.
L'architecture logique présente également les dépendances de services d'infrastructure entre les divers composants Java ES. Portal Server, par exemple, dépend de Communications Express pour ses canaux de messagerie et de calendrier et d'Access Manager pour les services d'authentification et d'autorisation. Ces composants dépendent, à leur tour, de Directory Server en ce qui concerne les informations utilisateur et les données de configuration. Certains composants nécessitent des services de conteneur Web fournis par Web Server.
Pour plus d'informations sur la conception logique d'une solution Java ES, reportez-vous au Sun Java Enterprise System Deployment Planning Guide.
Architecture de déploiement de l'exemple de scénario
Du fait du passage de l'architecture logique à une architecture de déploiement, les exigences de qualité de service deviennent essentielles. Par exemple, les pare-feux et les sous-éseaux protégés peuvent être utilisés pour créer une barrière de sécurité pour les données d'arrière-plan. Les exigences de disponibilité et d'évolutivité peuvent être satisfaites pour la plupart des composants en les déployant sur plusieurs ordinateurs et en utilisant des équilibreurs de charge pour distribuer les requêtes parmi les composants répliqués.
Toutefois, lorsque des exigences de disponibilité plus contraignantes s'appliquent et lorsqu'une grande quantité de stockage sur disque est impliquée, d'autres solutions de disponibilité sont plus appropriées. Par exemple, Sun Cluster peut être utilisé pour le stockage de Messaging Server et la réplication multimaître peut être utilisée pour Directory Server.
Pour plus d'informations sur la conception du déploiement d'une solution Java ES, reportez-vous au Sun Java Enterprise System Deployment Planning Guide .
Termes clés de ce chapitre
Cette section explique les principaux termes clés utilisés dans ce chapitre, en insistant sur la clarification des relations entre ces termes et sur leur mode d'utilisation dans le contexte Java ES.
- application component (composant d'application)
-
composant logiciel personnalisé exécutant une fonction de calcul particulière, fournissant ainsi des services d'entreprise aux utilisateurs finals ou à d'autres composants d'application. Un composant d'application se conforme en règle générale à un modèle de composant distribué (tel que CORBA et la plate-forme J2EE). Ces composants, qu'ils soient seuls ou associés, peuvent être encapsulés sous la forme de services Web.
- architecture
-
Conception montrant les blocs constitutifs physiques et logiques d'une application distribuée (ou d'un autre système logiciel) et leurs relations les uns par rapport aux autres. Dans le cas d'une distributed enterprise application (application d'entreprise distribuée), la conception architecturale inclut généralement à la fois l'logical architecture (architecture logique) de l'application et l'deployment architecture (architecture de déploiement).
- business service (service d'entreprise)
-
application component (composant d'application) ou assemblage de composants effectuant une logique d'entreprise pour le compte de clients multiples (et qui est donc par conséquent un processus à unités d'exécution multiples). Un service d'entreprise peut également être un assemblage de composants encapsulés sous la forme d'un web service (service Web), ou d'un serveur autonome.
- client
-
Logiciel demandant des services logiciels. Un client peut être un service qui requiert un autre service ou un composant de l'interface graphique auquel accède l'utilisateur final.
- deployment architecture (architecture de déploiement)
-
Conception de haut niveau décrivant le mappage d'une logical architecture (architecture logique) et d'un environnement informatique physique. L'environnement physique inclut les ordinateurs d'un environnement intranet ou Internet, les liaisons réseau entre ceux-ci et tout autre périphérique physique requis pour prendre en charge les logiciels.
- logical architecture (architecture logique)
-
Conception décrivant les blocs constitutifs d'une application distribuée et les relations (ou interfaces) entre ces blocs. L'architecture logique comprend aussi bien les composants d'application distribués que les services d'infrastructure requis pour leur prise en charge.
- serveur
-
Processus logiciel à unités d'exécution multiples (différent d'un serveur matériel) fournissant un service distribué ou un ensemble cohérent de services pour des clients accédant au service par le biais d'une interface externe.
- web service (service Web)
-
Service conforme aux protocoles Internet standard en matière d'accessibilité, d'encapsulation de services et de détection. Les normes incluent le protocole de messagerie SOAP (Simple Object Access Protocol), la définition d'interface WSDL (Web Service definition Language) et la norme de registre UDDI (Universal Discovery, Description and Integration).
- © 2010, Oracle Corporation and/or its affiliates