Rubriques

Introduction Haut de la page

L'architecture d'exécution d'une application est décrite dans la vue des processus, une vue architecturale décrivant les éléments en concurrence d'accès d'un système. Ces principes et conseils apportent une aide spécifique sur la manière de modéliser la vue des processus pour une application J2EE.

Voir également Concepts : Vue des processus.

Modélisation de la vue des processusHaut  de la page

Les composants J2EE (voir Concepts : Présentation de J2EE : Composants J2EE) sont déployés dans des environnements appelés "conteneurs". Voir Concepts : Présentation de J2EE : Conteneurs J2EE pour une description de chaque type de conteneur défini par J2EE.

Chaque conteneur est un élément en concurrence d'accès et doit apparaître ainsi dans la vue des processus de l'architecture. Une autre type important d'éléments apparaissant généralement dans la vue des processus de haut niveau est constitué par les systèmes externes.

Un diagramme typique de la vue des processus de haut niveau d'une application J2EE est représenté ci-dessous.

Diagramme décrit dans le texte d'accompagnement.

Dans un cas réel, le diagramme comporterait également un middleware orienté message (MOM) spécifique à un fournisseur, ainsi que des systèmes existants et des clients d'application spécifiques. Le conteneur Web et le conteneur EJB sont néanmoins des conteneurs standard qui doivent apparaître dans toutes les vues de processus J2EE.

Notez que ce diagramme ne représente pas la distribution physique de ces systèmes sur des noeuds matériels spécifiques. Cette distribution apparaît dans le modèle de déploiement (voir Principes et conseils : Description de la distribution des applications J2EE).

Cet exemple montre les mécanismes de communication interprocessus utilisés entre les conteneurs. J2EE fournit des mécanismes de communications interprocessus spécifiques :

  • Java Remote Method Invocation (RMI, invocation de méthode distante) pour les communications synchrones entre classes Java
  • RMI-IIOP pour la communication avec les clients CORBA (généralement des applications existantes)
  • HTTP/HTTPS pour la communication avec les clients Web (mais d'autres protocoles peuvent être pris en charge, par exemple en cas d'interaction avec des services Web XML)
  • Java Message Service (JMS) pour la messagerie et les interactions avec les MOM

Dans la définition de la vue des processus, le choix de JMS au lieu de RMI ou de RMI-IIOP constitue une décision importante. Dans cet exemple, le client d'application, le conteneur EJB et un autre système existant utilisent la messagerie pour communiquer. Mais on ne voit pas clairement quels éléments communiquent entre eux. Pour résoudre cette ambiguïté, on peut envisager de supprimer le système MOM du diagramme et d'utiliser JMS comme association entre les éléments communiquant par messagerie.

Autre ambiguïté : on ne voit pas clairement si les EJB communiquent entre eux par messagerie. Cette ambiguïté peut être levée par la représentation d'une association JMS entre le conteneur EJB et lui-même. Le diagramme final devient donc :

Diagramme décrit dans le texte d'accompagnement.

Mais la vue des processus ne se limite pas à des conteneurs et à des processus de haut niveau. Elle prend également en compte la concurrence d'accès entre ces conteneurs et systèmes.

La vue des processus doit identifier et modéliser les types de classes actives suivantes.

  • Unités d'exécution Java
  • Destinations des messages
  • Beans orientés message (parce qu'ils sont appelés de façon asynchrone via les messages). Sur les stéréotypes spécifiques utilisés pour modéliser les beans orientés message, voir Principes et conseils : Identification des Enterprise JavaBeans.
  • Processus supplémentaires relevant de la conception d'ensemble du système, par exemple un processus temporisateur.

Lorsque vous utilisez JMS, vous pouvez soit relier directement producteurs et consommateurs du message, soit modéliser plus précisément la relation par une modélisation du contenu échangé et des files d'attente.

Des diagrammes d'interaction sont utilisés pour représenter la communication synchrone et asynchrone entre éléments de conception. Ils peuvent également être utilisés pour analyser le comportement en concurrence dans les problèmes de performances et de logique. En particulier, l'architecte logiciel peut y rechercher les fréquences trop élevées de messages ou les volumes trop importants de données transférées sur le réseau. Cela peut l'amener à reconcevoir les interfaces ou a réaffecter les éléments de conception entre les unités d'exécution de contrôle, entre serveurs ou entre client et serveur.

Remarquez qu'à l'intérieur d'un conteneur, les unités d'exécution et les processus sont gérés par le conteneur EJB et que les EJB ne peuvent créer ou gérer des unités d'exécution. Bien que les EJB doivent logiquement être considérés comme des classes actives, ils ne sont généralement pas modélisés comme tels, parce que les appels aux beans de session et d'entité sont des appels bloquants synchrones. Sur la vue des processus, un conteneur EJB est généralement représenté avec le seul mécanisme en concurrence d'accès disponible : JMS avec beans orientés message JMS.

Même si les beans de session et d'entité ne sont généralement pas modélisés comme des classes actives, ils posent des problèmes de concurrence d'accès, par exemple lorsqu'un EJB lit la base de données pendant qu'un autre y accède en écriture. Ces problèmes sont traités par des transactions. L'approche par laquelle les transactions sont utilisées doit être documentée dans des principes et conseils spécifiques au projet.

Attribution d'éléments de conception aux classes activesHaut de la page

L'activité : Description de l'architecture d'exécution décrit le besoin d'attribuer des éléments de conception aux processus et aux 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 EJB. Grâce à cette relation simple, il n'est pas nécessaire de modéliser cette attribution.

Mais si votre conception comporte des processus supplémentaires en concurrence d'accès (tels que deux clients d'application différents), il peut être utile de spécifier quel élément de conception s'exécute sur chaque application.

Dans le cas des unités d'exécution Java, des beans orientés message et des contenus d'échanges et files d'attente JMS, le problème est davantage leur intercommunication, de manière à éviter les blocages, l'incohérence des données, etc. Le meilleur moyen d'étudier ce problème est d'examiner des réalisations de cas d'utilisation comportant ces éléments.

Autres possibilités de modélisationHaut de la page

Les diagrammes de haut niveau de la vue des processus et de la vue du déploiement sont souvent combinés en raison de l'affinité entre ces deux vues.

De plus, chaque conteneur J2EE constituant un environnement d'exécution et non seulement un processus, il peut être modélisé comme un "noeud logique" au lieu d'une classe active.



RUP (Rational Unified Process)   2003.06.15