Transactionnel réparti
Programmation et systèmes transactionnels

Le concept de transaction fait partie du patrimoine universel des sociétés humaines dont il est l’un des éléments régulateurs de la fonction d’échange : échange d’un travail contre un salaire, échange d’un bien ou d’un service contre un autre bien ou service, association de deux individus et/ou organisations en vue d’un but inaccessible à chacune des parties prises individuellement.

Une transaction implique toujours trois acteurs :

•  clients et fournisseurs sont les acteurs de l’échange. Ils procèdent selon un protocole explicite connu des deux parties ; ce protocole peut varier selon la nature de l’échange. Le « client » demande un service ou un bien, le « fournisseur » offre le service ou le bien souhaité ;

•  le « juge arbitre », ou observateur neutre, est le garant que la transaction s’est effectuée selon les règles. Il contresigne l’accord des deux parties afin d’en garder une trace officielle accessible par tous.

Il n’est donc pas étonnant de retrouver ce concept au cœur des systèmes d’information dans la mesure où ceux-ci ont comme ambition de modéliser l’activité des individus et/ou des organisations dans le but d’automatiser tout ou partie de la gestion des informations conformément aux objectifs de l’entreprise.

C’est ainsi que, dans une transaction bancaire, par exemple un retrait d’argent, il doit y avoir « simultanément » la remise d’une certaine somme d’argent au client, et débit du compte client de la somme correspondante ; l’opération se fait sous le contrôle du caissier — ce peut être une billetterie automatique — qui s’assure de la solvabilité du client tout en étant le garant de celle de la banque.

C’est ce bloc indivisible qui forme la transaction. Soit les règles qui constituent la transaction ont été respectées, et la transaction est déclarée valide, soit elles n’ont pas été respectées et alors la transaction est invalide, c’est-à-dire qu’il ne s’est rien passé.

La notion de transaction est donc étroitement associée à celle de déontologie et de respect de règles comportementales. Une transaction est un ensemble d’actions cohérentes qui doivent avoir le même sens pour tous les acteurs : c’est donc une notion fondamentalement sémantique.

La notion de programmation transactionnelle apparaît explicitement à la fin des années 60, début des années 70, avec les premiers réseaux de terminaux et les premières bases de données. On passe progressivement d’un monde exclusivement batch à celui du télétraitement interactif. Ce faisant, un certain nombre de problèmes systèmes masqués aux programmeurs dans le mode batch deviennent visibles et incontournables pour les programmeurs d’applications interactives.

Dans une chaîne batch, un seul programme est activé par le moniteur de travaux de la machine. En cas d’incidents, il est donc très facile d’annuler le travail en cours et de relancer le programme sur les données initiales. Cela n’a aucun impact sur les usagers du système informatique qui ne sont pas connectés au système.

Dans une chaîne transactionnelle, la situation est totalement différente. Le même programme, la même transaction peuvent être activés par des dizaines, voire des centaines de terminaux dont chacun devra avoir un contexte d’exécution bien à lui, sans possibilité de contamination de ses voisins. En cas d’incidents, il est bien sûr hors de question d’arrêter tout le système car l’attente aux terminaux deviendrait vite insupportable aux usagers du système. La programmation transactionnelle doit gérer beaucoup plus finement les ressources du système informatique : c’est donc une programmation beaucoup plus complexe, tout en étant beaucoup plus fiable vis-à-vis des incidents qui peuvent survenir comme les conflits d’accès aux ressources communes.

Dans un système d’information, la ressource la plus fondamentale, à laquelle toutes les autres sont subordonnées, est l’information. L’information, généralement stockée dans les bases de données, doit être accessible en permanence, être tenue à jour en temps réel — c’est-à-dire que la différence entre le système et le monde réel soit aussi faible que possible — tout en restant en cohérence avec le reste du système d’information. L’accès à l’information doit être aussi simple que possible tout en préservant les indispensables contraintes de sûreté de fonctionnement : fiabilité, sécurité, intégrité.

Si l’on prend les caractéristiques logiciel préconisées par la norme ISO 9126 : 

•  capacité fonctionnelle ;

•  facilité d’emploi ;

•  fiabilité ;

•  performance/efficacité ;

•  maintenabilité ;

•  portabilité ;

seule la première est véritablement une tâche de programmation à la charge du programmeur, les cinq autres sont à la charge de l’environnement de développement (par exemple avec un générateur d’écrans) et/ou d’exécution. Le programmeur de transactions exprime ce que l’application doit faire, alors que l’environnement d’exécution se charge du comment faire avec toutes les contraintes système que ce partage des tâches implique.

La caractéristique fonctionnelle est la spécification d’une certaine action que le programmeur souhaite faire. Les autres caractéristiques, qualifiées de non fonctionnelles dans la terminologie de la norme ISO 9126, sont propres à l’environnement d’exécution. Si une très haute performance est exigée, c’est le rôle du système de faire en sorte que les caches soient positionnés là où il faut, avec les bons mécanismes d’intégrité, sans que cela n’affecte en rien la facilité de programmation de l’action souhaitée par le programmeur de transaction.

En respectant ce partage des tâches, on met le programmeur en situation de productivité maximale pour des besoins en nouveaux traitements qui lui sont adressés.

Par ailleurs, le fait de considérer les caractéristiques non fonctionnelles comme un besoin général de toutes les fonctions possibles sur le système permet de les regrouper dans un ensemble unique qui, de ce fait, pourra être fiabilisé de façon optimale selon le besoin. Cet ensemble sera sollicité beaucoup plus fréquemment que chacune des fonctions prises individuellement, et il atteindra plus rapidement son palier de maturité.

Les années 80 ont vu l’arrivée en masse des PC, des serveurs de données de communications, des infrastructures de réseaux locaux, etc., à des prix très compétitifs. Cette avalanche a profondément bouleversé le paysage informatique de l’entreprise en donnant un très large accès à des ressources jusqu’alors réservées à quelques services jugés stratégiques (usines, directions générales, directions informatiques).

En conséquence, le programmeur d’application a vu sa vision du système informatique s’élargir considérablement. Dans ce nouvel environnement, différents éléments doivent être contrôlés par le programmeur d’application.

Le bon déroulement du programme transactionnel peut être perturbé par de nombreux aléas survenant dans l’environnement de la transaction. Pour garantir la bonne marche des opérations, l’environnement d’exécution doit établir un contrôle temporaire sur les ressources nécessaires à l’exécution de la transaction.

C’est une notion purement dynamique qui dépend de la nature des ressources utilisées par la transaction. Il est facile d’imaginer que si la gestion de cette « sphère » est laissée au programmeur de l’application, il en résultera une très grande complexité de programmation. Pour conserver à la programmation — essentiellement COBOL, ou L4G — son caractère de simplicité tout en garantissant une meilleure productivité du travail de programmation, cette gestion est entièrement prise en compte par le moniteur transactionnel.

Le but du moniteur transactionnel, par rapport au moniteur batch, est de gérer très finement les ressources nécessaires à l’application transactionnelle. Ce schéma, très incomplet, montre quelques-unes des fonctions de gestion effectuées par le moniteur de transactions. Dès qu’une ressource n’est plus nécessaire, elle est immédiatement remise au pool de façon à ce que d’autres transactions en attente puissent soit démarrer, soit continuer. En cas d’incident et/ou de blocage, le moniteur assure automatiquement toutes les fonctions de reprise.