Présentation technique de Sun Java Enterprise System 5

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 architecture logique et une 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 :

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

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

Schéma présentant le cadre tridimensionnel doté de niveaux logiques, de niveaux de service d'infrastructure et de critères de qualité de service.

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

Diagramme représentant les niveaux d'infrastructure des services distribués allant des services de plate-forme du système d'exploitation de niveau inférieur aux services d'intégration de niveau supérieur.

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 :

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

Diagramme présentant le positionnement des composants de service du système Java ES par rapport aux divers niveaux des services d'infrastructure distribués.


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

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 et Instant Messaging [Les composants Calendar Server, Messaging Server et Instant Messaging sont disponibles dans Sun Java Communications Suite.]

Aucune 

Access Manager 

Application Server ou Web Server 

Directory Server 

Portal Server 

Si configuré pour une connexion unique : Calendar Server, Messaging Server et 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 

Access Manager 

Calendar Server 

Messaging Server  

Instant Messaging 

Service Registry 

Java DB 

Composants basés sur Application Server 

Java DB 

Aucune 

Service Registry 

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

Diagramme représentant quatre niveaux logiques, de gauche à droite : niveau client, niveau présentation, niveau service d'entreprise et niveau donné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.

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 :

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

Diagramme présentant les composants de Messaging Server distribués sur les quatre niveaux logiques.


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 

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 ne doit pas entraîner 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. 

Entretien

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 :

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 

Availability 

Monitoring Console 

Entretien 

Portal Server Secure Remote Access

Sécurité 

Évolutivité 

Sun Cluster 

Availability 

Évolutivité 

Sun Cluster Geographic Edition 

Availability 

Évolutivité 

Web Proxy Server 

Sécurité 

Performance 

Évolutivité 

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 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

Diagramme présentant l'architecture logique de l'exemple de 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.

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 application d'entreprise distribuée, la conception architecturale inclut généralement à la fois l'architecture logique de l'application et l'architecture de déploiement.

service d'entreprise

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 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.

architecture de déploiement

Conception de haut niveau décrivant le mappage d'une 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.

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.

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).