Instructions: Description de l'architecture d'exécution des applications J2EE
Ces instructions portent sur la modélisation de l'architecture d'exécution d'une application J2EE.
Relations
Description principale

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.

Diagramme décrit dans le texte d'accompagnement.

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 :

Diagramme décrit dans le texte d'accompagnement.

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.