Moniteur transactionnel

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.

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

En tant que moniteur, il pilote des systèmes gérant des transactions comme :

• les moteurs de base de données ;
• les systèmes de gestion des queues (souvent utilisées pour des communications asynchrones et/ou sécurisées) ;
• les systèmes de fichiers transactionnels (comme les bases de données séquentielles) ;
• etc.

Il peut aussi gérer les ressources systèmes utilisées par une application informatique :

• la mémoire vive ;
• le temps processeur ;
• plus généralement les ressources système de la machine comme :
  • la mémoire partagée ;
  • les ressources réseau ;
  • les pipe ;
  • les sémaphores ;
  • etc.

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.

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

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.

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.

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.

Un moniteur transactionnel ne doit pas être confondu avec un système gérant les transactions. Dans la plupart des cas, le moniteur transactionnel ne gère pas directement les transactions mais pilote des moteurs transactionnels gérant différents types de transactions (voir par exemple la norme XA utilisée pour synchroniser les différents gestionnaires de transactions).

Par exemple, la responsabilité d'un moniteur dans le cadre d'une transaction peut être de synchroniser en tout ou rien une transaction base de données avec une transaction effectuée sur une queue. C'est cette transaction globale qui est à la charge du moniteur, et pour cela, ce dernier s'appuiera sur un moteur de base de données pour la gestion de la transaction base de données et sur un moteur de gestion des transactions sur les queues pour la seconde partie. Lorsque plusieurs pilotes transactionnels sont invoqués dans la même transaction informatique, se posent les problèmes classiques du commit à deux phases.

Pour illustrer ce pilotage, notamment du moteur transactionnel qui pilote une base de données, on trouve souvent dans les moniteurs transactionnels du marché le concept de pool de connexions à une base données. Le moniteur, dans le cadre de son activité de coordination, gère un ensemble fixe ou variable de connexions à la base de données et impose à chaque transaction d'utiliser une connexion du pool.

Toute création de connexion à la base de données (instructions coûteuses pour l'application) est donc interdite au niveau de la transaction elle-même (et donc au niveau du code applicatif), cette tâche étant réservée au moniteur transactionnel. Ce dernier est aussi chargé de lancer le commit ou le rollback global de la transaction, à la suite d'un code retour normalisé renvoyé par le code applicatif de la transaction. Ainsi, le moniteur se réserve la gestion de certains ordres de pilotage du moteur de base de données en vue de gérer les ressources.

Dans cet exemple, il ne sera pas possible que l'application exécute de manière simultanée plus de transactions qu'il n'y a de connexions dans le pool. Les autres transactions seront mises en queue par le moniteur transactionnel. Certains moniteurs ont la capacité de s'adapter à une croissance subite de la demande pour éviter de mettre à mal les temps de réponse de l'application en plaçant en queue les transactions qui ne peuvent être exécutées.

Le moniteur transactionnel propose, la plupart du temps, une interface de monitoring de production de l'application en temps réel, ainsi que, suivant les cas, des stratégies pour réagir automatiquement à des erreurs de certaines transactions (dump, core) ou des brusques hausses du trafic transactionnel (allocation dynamique de ressources). La plupart des moniteurs sont robustes à des bugs applicatifs et ont une grande fiabilité en production.

D'une manière générale, un moniteur transactionnel est très adapté à la gestion 24/24 7/7 de très nombreux clients faisant beaucoup de transactions en parallèle. Certaines industries ont un besoin crucial de cette brique "middleware" :

• les banques et assurances ;
• les compagnies aériennes et plus généralement toutes les autres compagnies du monde du voyage mettant à disposition des services de réservation en ligne ;
• la grande distribution ;
• les services publics (caisse de retraite, d'assurance maladie, banques régionales, mutuelles, etc.) ;
• etc.

Dans le monde des applications de taille moyenne, la technologie et les principes du moniteur transactionnel ont inspiré la conception des serveurs d'application comme Java EE ou .Net, notamment sur l'axe partage des ressources.

Par contre, certains principes fondamentaux des premiers moniteurs transactionnels ne sont pas respectés par ces nouvelles architectures, par exemple :

• L'échec brutal d'une transaction applicative (dump, core) ne doit pas nuire à la stabilité opérationnelle de l'application. Ceci n'est pas le cas dans le cadre d'une architecture multithread de type Java EE ou .Net.
• Le moniteur transactionnel n'a pas de mémoire du client une fois la transaction terminée. Ceci n'est bien souvent pas le cas dans les architectures de type Java EE ou .Net, le contexte utilisateur subsistant en mémoire vive le temps de la conversation tout entière.

La configuration Apache multi processus est probablement l'une des architecture web les plus proches des concepts des moniteurs transactionnels venant du monde Unix.

Exemples de moniteurs transactionnels :

• IBM TPF : un système d'exploitation fusionné avec un moniteur transactionnel, le plus vieux système transactionnel IBM.
• IBM IMS pour MVS : le plus ancien des moniteurs transactionnels, initialement un scheduleur batch.
• IBM CICS pour MVS : la superstar des moniteurs transactionnels sur plate-forme mainframe, très intégrée avec DB2 et le file system MVS ;
• Bull TDS pour GCOS 7 ;
• Bull TP8 pour GCOS 8 ;
• Top End de NCR pour Unix ;
• Unisys Transaction Interface Package (TIP) ;
• Oracle Tuxedo pour Unix/Windows.

• Rollback (base de données)
• Interblocage
• Commit
• Transaction (base de données)
• Transaction informatique
• Propriétés ACID

• Définition sur journaldunet

• Portail de l’informatique