Article

1 - QUELQUES NOTIONS D’ARCHITECTURE INDISPENSABLES

2 - TRANSACTIONNEL TRADITIONNEL

3 - TRANSACTIONNEL RÉPARTI

4 - MÉCANISMES FONDAMENTAUX D’UN ENVIRONNEMENT TRANSACTIONNEL

5 - ENVIRONNEMENT DE PROGRAMMATION TRANSACTIONNELLE

  • 5.1 - Évolutions de la programmation des transactions
  • 5.2 - Outils d’aide à la programmation des transactions

6 - PERSPECTIVES

Article de référence | Réf : H2708 v1

Programmation et systèmes transactionnels

Auteur(s) : Jacques PRINTZ, Gérard MORGANTI, Jacques WAJNFLASZ

Relu et validé le 16 juin 2016

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

Version en anglais English

Auteur(s)

  • Jacques PRINTZ : Ancien Élève de l’École Centrale des Arts et Manufactures - Professeur T itulaire de la Chaire de Génie Logiciel au Conservatoire National des Arts et Métiers

  • Gérard MORGANTI : Ingénieur CNAM - Directeur Général de la société MOSAIC

  • Jacques WAJNFLASZ : Ancien Élève de l’École Centrale des Arts et Manufactures - Consultant en Sécurité des Systèmes d’information (SRTI System)

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

INTRODUCTION

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.

Émergence du transactionnel en informatique de gestion

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.

Information « en ligne »

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

Informatisation de l’entreprise

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.

Cet article est réservé aux abonnés.
Il vous reste 92% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-h2708


Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(239 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Version en anglais English

Cet article est réservé aux abonnés.
Il vous reste 92% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(239 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - GRAY (J.), REUTER (A.) -   Transaction processing : concepts and techniques.  -  Morgan Kaufman Publishers, 1993.

  • (2) -   The benchmark handbook for database and transaction processing systems.  -  Morgan Kaufman Publishers, 1991.

  • (3) - EPPINGER (J.), MUMMERT (L.), SPECTOR (A.) -   Camelot and Avalon : A distributed transaction facility.  -  Morgan Kaufman Publishers, 1991.

  • (4) - CHRISTIAN (F.) -   Understanding fault tolerant distributed systems.  -  CACM, vol. 34, n× 2, 1991.

  • (5) - GRAY (J.) and alii -   The recovery manager of the system R database manager.  -  ACM Computing Survey, vol. 13, n× 2, 1981.

  • (6) - HAËRDER (T.), REUTER (A.) -   Principles of transaction-oriented database recovery.  -  ACM Computing Survey, vol. 15, n× 4, 1983.

  • ...

1 Offre produits

HAUT DE PAGE

1.1 Transactionnel constructeurs

La plupart des constructeurs d’ordinateurs offrent des systèmes transactionnels (pour une information complète et à jour, il convient de se reporter aux descriptifs des différents produits).

IBM offre plusieurs environnements transactionnels. Le plus ancien est IMS (Information Management System). C’est l’environnement transactionnel de référence pour les très grands systèmes IBM.

CICS (Customer Information Control System), plus récent, est disponible sur toutes les plates-formes IBM : MVS, OS/2, AS/400 et AIX. CICS a été le premier système commercial à offrir un service sûr en architecture distribuée à travers le protocole LU6.2 qui est un standard de fait (appelé également APPC dans l’architecture SAA d’IBM). LU6.2 a servi de modèle à la norme OSI/TP.

BULL offre sur ces systèmes GCOS-7 et GCOS-8 un environnement transactionnel TDS (Transaction Driven System) très performant qui tire parti de l’architecture système sous-jacente.

TANDEM, qui a depuis l’origine axé son offre système sur des caractéristiques « Non-stop », propose un environnement transactionnel TMF (Transaction Monitoring Facility) étroitement associé au système d’exploitation GUARDIAN. TANDEM a été le premier constructeur à intégrer...

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(239 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS