Moniteur transactionnel - Définition

Introduction

En informatique, un moniteur transactionnel (ou "TP monitor" pour "Transaction Processing Monitor") est un système transactionnel de partage des ressources machine (mémoire, base de données, etc.). Les éléments gérés par le moniteur transactionnel sont des transactions dont le champ d'application varie suivant les produits.

Le moniteur transactionnel gère les ressources et s'appuie sur des gestionnaires de transactions externes (comme un moteur de base de données, par exemple, ou un système de queues transactionnelles). Il ne gère pas directement les transactions elles-mêmes mais les coordonne.

Description

Un moniteur transactionnel est un élément logiciel, faisant partie du "middleware", prenant en charge la planification de l'exécution des transactions et leur synchronisation afin de consommer le moins de ressources possible sur un système informatique. En cela, le moniteur transactionnel n'est pas un moteur de gestion des transactions, mais plus un "scheduler" (ordonnanceur) plus ou moins sophistiqué ayant pour objet de partager des ressources limitées entre un grand nombre d'utilisateurs simultanés, tout en ne dégradant pas le temps de réponse de l'application informatique.

Historiquement, le besoin de moniteur transactionnel vient du fait que les premières machines (mainframe) possédaient très peu de ressources et que les applications devant être déployées sur ces machines devaient servir un très grand nombre d'utilisateurs (compagnies aériennes, banques, assurances, etc.). Les éditeurs de l'époque, et principalement les ingénieurs d'IBM, développèrent des systèmes très performants pour arriver à concilier ce besoin transactionnel très élevé avec des ressources machine très limitées (TPF puis IMS et CICS notamment).

Rationale du moniteur transactionnel

Une application informatique transactionnelle est la plupart du temps conçue pour répondre à un nombre important d'utilisateurs (clients) travaillant de manière simultanée sur une même machine. Cette application, dans le cadre de ses tâches, se doit d'accéder à un certain nombre de ressources situées soit sur la machine même hébergeant l'application, soit sur d'autres machines du même réseau.

Lorsqu'une application informatique est conçue, deux grands types de modèles peuvent s'appliquer.

Modèle applicatif des ressources réservées

Le premier modèle vise à réserver des ressources pour chaque utilisateur et à dimensionner la machine en multipliant les ressources allouées pour chaque utilisateur par le nombre d'utilisateurs. Cette technique possède trois inconvénients majeurs :

• lorsque l'utilisateur ne travaille pas, les ressources sont réservées pour rien et elles sont inexploitables pour d'autres applications ;
• il n'est pas toujours possible de compter les utilisateur pour leur réserver des ressources, notamment dans le cadre des applications de grande envergure ou des applications connectées au web ;
• cette façon de concevoir des applications engendre des achats matériels et logiciels de coûts prohibitifs et souvent disproportionnés par rapport à l'application (voir exemple).

Ce modèle est souvent réservé pour des applications de petite et moyenne taille. On trouve les applications en architecture deux tiers dans ce modèle.

Modèle applicatif des ressources partagées

Le concept du moniteur transactionnel vient du constat qu'une application ne peut répondre à chaque demande d'un client au moment exact où ce dernier soumet sa demande pour les trois raisons expliquées ci-dessus. Si une application répond de manière immédiate à chaque demande du client, elle met en péril le système sur lequel elle tourne dans la mesure où tous les clients peuvent potentiellement demander des transactions au même exact moment et donc saturer les ressources de la machine.

Le moniteur transactionnel va donc gérer un nombre dit maximum de transactions pouvant être exécutées en parallèle. C'est ce nombre (et non le nombre des utilisateurs) qui dimensionnera les caractéristiques de la machine. Entre chaque transaction, le moniteur transactionnel ne garde aucune mémoire de la transaction utilisateur qui vient de s'achever, si bien que chaque utilisateur ne coûte rien au système dès lors que ce dernier a achevé sa transaction.

Comparaison des deux modèles

Considérons un système R de ressources réservées. Nous dirons pour simplifier qu'une transaction T moyenne sur ce système consomme X ressources du système durant le temps de la transaction T. Si nous voulons que 4 000 utilisateurs travaillent sur ce système, nous dimensionnerons la machine à (4000.X) en termes de ressources système.

Considérons désormais un système équipé d'un moniteur transactionnel M. Nous imposerons les mêmes contraintes sur les 4000 utilisateurs voulant exécuter des transactions T consommant X à chaque fois. Nous estimerons que le temps moyen de la transaction sera de 1s et prendrons l'hypothèse que chaque utilisateur fera en moyenne 1 transaction T toutes les 15 secondes. Nous aurons donc un trafic moyen de 4000/15 = 267 transactions par seconde, soit une machine devant être dimensionnée à (267.X) en termes de ressources système, soit 15 fois moins que dans le modèle précédent.

Inconvénients du moniteur transactionnel

L'utilisation d'un moniteur transactionnel est un élément des plus structurant de la conception d'une application informatique. Ainsi, on ne peut pas porter facilement n'importe quelle application sur un moniteur transactionnel (la plupart du temps, ces portages sont même impossibles et nécessitent une réécriture de l'application). De plus, la programmation dans un moniteur transactionnel impose un certain nombre de contraintes de conception et de contraintes techniques, ce qui rend la programmation parfois plus complexe.

Cependant, une application transactionnelle lourde ne saurait être implémentée sans une gestion fine du partage des ressources pour des raisons de fiabilité opérationnelle de l'application et d'économie de ressources machine.