Introduction
L'architecture d'exécution d'une application est décrite dans la vue de processus, une vue d'architecture qui décrit
les éléments concurrents d'un système. Ces instructions offrent des conseils spécifiques sur la modélisation de la vue
de processus d'une application J2EE.
Voir aussi Concept : Vue de processus.
Modélisation de la vue de processus
Les composants J2EE (reportez-vous à Concept : Présentation de la plateforme J2EE : Conteneurs J2EE) sont déployés dans
des environnements appelés Conteneurs. Reportez-vous à Concept : Présentation de la plateforme J2EE : Conteneurs J2EE pour obtenir une
description de chaque type de conteneurs défini par J2EE.
Chaque conteneur est un élément concurrent, et doit donc apparaître dans la vue de processus de l'architecture.
D'autres éléments concurrents apparaissent généralement dans la vue de processus de haut niveau ; ce sont les systèmes
externes.
Le diagramme suivant est caractéristique d'une vue de processus de haut niveau pour une application J2EE.
Dans un exemple réel, cette représentation comporterait un logiciel intermédiaire Message Oriented Middleware (MOM)
spécifique au fournisseur, ainsi que des systèmes en vigueur et clients d'application spécifiques. Cependant, les
conteneurs Web et d'EJB sont des conteneurs standard qui doivent apparaître dans toutes les vues de processus J2EE.
Notez que ce diagramme n'illustre pas la répartition physique de ces systèmes sur des noeuds matériels particuliers.
Cette répartition figure dans le modèle de déploiement (reportez-vous à Technique : Description de la répartition des applications J2EE).
Cet exemple montre les mécanismes de communication interprocessus sélectionnés utilisés entre les conteneurs. La
plateforme J2EE offre des mécanismes de communication interprocessus spécifiques. Ces mécanismes sont les suivants :
-
L'invocation Java Remote Method Invocation (RMI) pour la communication synchrone entre les classes Java
-
RMI-IIOP pour l'interopération avec les clients CORBA (généralement des applications existantes)
-
Les protocoles HTTP et HTTPS pour la communication avec les clients Web (bien que d'autres protocoles Web puissent
être pris en charge, par exemple lors d'une interaction avec des services Web XML)
-
Le service Java Message Service (JMS) pour la messagerie et les interactions avec le logiciel intermédiaire Message
Oriented Middleware (MOM)
Lors de la définition de la vue de processus, vous devrez effectuer des choix d'utilisation importants entre trois
mécanismes différents : JMS, RMI et RMI-IIOP. Dans cet exemple, le client d'application, le conteneur d'EJB et un autre
système en vigueur utilisent des messages pour communiquer. Cependant, le lecteur ne comprend pas clairement quels sont
les éléments qui communiquent entre eux. Pour résoudre cette ambiguïté, envisagez de supprimer le système MOM du
diagramme et d'indiquer JMS comme association entre les éléments qui communiquent par messagerie.
Il n'est pas clairement indiqué non plus si les EJB communiquent entre eux par des messages. Pour clarifier la
situation, il suffit d'établir une association JMS, du conteneur d'EJB vers lui-même. Le diagramme final devient alors
le suivant :
Cependant, la vue de processus représente bien plus que des conteneurs et des systèmes de haut niveau. Elle traite
également l'accès concurrent au sein de ces conteneurs et systèmes.
La vue de processus doit identifier et modéliser les types suivants de classes actives.
-
unités d'exécution Java
-
destinations des messages
-
beans gérés par message (car ils sont appelés de manière asynchrone par le biais des messages). Reportez-vous à Technique : Identification des Enterprise JavaBeans pour connaître les
stéréotypes particuliers utilisés dans la modélisation des beans gérés par message.
-
processus supplémentaires faisant partie de la conception de l'ensemble du système. Un processus temporisateur
distinct en est un exemple.
Lorsque vous utilisez JMS, vous pouvez choisir de relier directement les producteurs et les consommateurs de messages
ou de représenter plus précisément les relations en modélisant les sujets et les files d'attente.
Les diagrammes d'interaction permettent d'illustrer les communications de type synchrone et asynchrone entre les
éléments de conception. Ils peuvent également servir à l'analyse du comportement concurrent pour les problèmes de
performances et de logique. En particulier, l'architecte logiciel peut rechercher les envois de messages fréquents ou
les gros volumes de transfert de données sur le réseau. Il peut être amené à reconcevoir les interfaces ou à
réattribuer les éléments de conception entre les unités de contrôle, entre les serveurs, ou entre le client et le
serveur.
Notez que les unités d'exécution et processus d'un conteneur d'EJB sont gérés par ce conteneur (les EJB ne peuvent
créer ou gérer des unités d'exécution). En principe, chaque EJB devrait être considéré comme une classe active.
Cependant, les appels aux beans session et entity étant des appels synchrones bloquants, ces beans ne sont
habituellement pas modélisés comme des classes actives. La vue de processus d'un conteneur d'EJB se limite généralement
au seul mécanisme d'accès concurrent disponible, JMS, et aux beans gérés par messages JMS.
Si les beans session et entity ne sont généralement pas modélisés comme des classes actives, il ne sont pas moins
épargnés par les problèmes d'accès concurrent (par exemple, lorsqu'un EJB lit une base de données tandis qu'un autre
écrit dans cette base). Ces problèmes sont traités à l'aide des transactions. Le mode d'utilisation des transactions
doit être documenté dans les instructions spécifiques au projet.
Attribution des éléments de conception aux classes actives
La Tâche : Décrire l'architecture d'exécution porte sur la nécessité
d'attribuer des éléments de conception à des processus et unités d'exécution. Dans une application J2EE, tous les
composants Web sont attribués au conteneur Web, et tous les EJB au conteneur d'EJB. Cette relation étant simple, il
n'est pas nécessaire de la modéliser.
Cependant, si votre conception comprend des processus concurrents supplémentaires (comme deux clients d'application
différents), il peut être utile de spécifier les éléments de conception exécutés sur chaque application.
Le problème posé par les unités d'exécution Java, les beans gérés par message, ainsi que les sujets et files d'attente
JMS concerne davantage la manière dont ils communiquent entre eux afin d'éviter les blocages, les incohérences entre
les données, etc. Le meilleur moyen d'explorer cette communication est d'examiner les réalisations de cas d'utilisation
qui comprennent ces éléments.
Autres possibilités de modélisation
En raison de l'affinité entre la vue de processus et la vue de déploiement, les diagrammes de haut niveau de ces vues
sont souvent combinés.
De plus, un conteneur J2EE ne représentant pas simplement un processus, mais également un environnement d'exécution, il
peut être modélisé comme "noeud logique" plutôt que comme classe active.
|