Histoire du Transactionnel


Introduction et Architecture

Au cours des années 60s, est apparu le besoin d'effectuer des traitements informatiques en "temps réel", c'est à dire de faire effectuer un traitement à un enregistrement d'entrée et d'y faire correspondre une modification de la base de données (un ou plusieurs enregistrements dans un ou plusieurs fichiers) et un enregistrement de sortie. Au début, ces traitements n'étaient que partiellement faits en temps réel: par exemple, les systèmes se contentaient de la collecte des enregistrements d'entrée et de leur vérification, la mise à jour proprement dite était faite en "batch" ainsi que les états de sortie.

Le traitement complet en "temps réel" demandait une remise en cause fondamentale de l'architecture du traitement telle que la proposait le langage COBOL par exemple.


La première voie ouverte a été celle du traitement séquentiel des transactions. Une transaction se déroule complètement avant de prendre en compte la précédente. Cette procédure a été popularisée par les ordinateurs individuels (du G-55 aux Micros MS/DOS). Elle a été utilisée par des systèmes plus importants en utilisant l'asynchronisme des entrées et des sorties de télécommunications. Les contraintes que ce transactionnel avait sur le système de base étaient limitées. Mais on a rencontré une limitation importante qui était que le débit du système était limité par la durée (en temps "elapsed") de chaque transaction, alors que la majeure partie du temps était fait de temps d'attente sur la mémoire secondaire.

Les systèmes qualifiables de vrai "transactionnel" ont cherché à réaliser un partage de temps entre deux transactions. On peut les classer en deux catégories:

La première catégorie (multi-serveurs) dérivée des systèmes de traitement différé des données collectées en temps réel a été utilisée d'abord sur des gros systèmes (tels que IBM IMS et GE TPS) présente l'inconvénient d'être non appropriée à un haut débit de transactions de même type et de nécessiter des ressources importantes pour conserver plusieurs serveurs actifs ou dormants. L'augmentation considérable des ressources matériels disponible permettra aux systèmes UNIX d'utiliser cette architecture à la fin des années 80s.

La seconde catégorie (multi-tâches), dont les réalisations incluent GE TDS puis IBM CICS, remettait assez profondément en question l'architecture du système d'exploitation. En pratique, elle a été réalisée sous la forme d'un système développé au dessus et relativement indépendamment du système de base. Ce n'est qu'avec GCOS64 TDS qu'une grande partie des fonctions transactionnelles a été incluse dans le système d'exploitation. L'architecture d'un système TDS inclut les fonctions suivantes:

De plus des problèmes supplémentaires ont dû être résolus progressivement, tels que la garantie de l'intégrité de sortie, le dénouement de l'"interlocking" des tâches, la confidentialité des transactions, la communication entre systèmes transactionnels, l'exécution de programmes "batch" à la demande de transactions…

retour


Les réalisations dans la famille Bull.

GE400.

Le premier système du type TDS introduit chez Bull a été OLBS (On Line Banking System) sur GE-400 réalisé par Bull-General Electric en collaboration avec ACT.

retour


GE600-6000-DPS8.

En parallèle, GE réalisait le système spécial WEYCOS (client Weyerhauser) qui traitait pour la première fois la totalité des problèmes de journaux.

Néanmoins, GE Phoenix marquait sa préférence pour les systèmes multi serveurs TPS et système spécial TPII (client Teamsters) et c'est Honeywell-Bull qui réalisera et exportera à Phoenix le système TDS-6. On notera que la plupart de ces systèmes n'utiliseront qu'une seule base de données IDS. Plus tard, le code TDS6 devra être totalement repris pour s'adapter à GCOS8 (et à supporter le code ASCII e non plus BCD) sous le nom de DMIV-TP puis de TP8. La coexistence de plusieurs "environnements" de programmation sous GCOS8 est responsable de ces variantes.

retour


GCOS64-DPS7

En 1974, débutera la réalisation de TDS-64 qui utilise à fond les fonctions système de segmentation et de multi-tasking ainsi que le système de fichiers standard. Cela lui permettra d'utiliser des bases de données mixtes et multiples et de partager sans trop de difficultés les fichiers avec le monde du batch. Le langage de programmation client utilisé est un dialecte de COBOL avec des extensions et des variantes sémantiques pour s'adapter au nouvel environnement.TDS64 sera réécrit vers 1982 (TDS7) pour améliorer ses limites fonctionnelles et pour introduire le "TDS coopératif". Mais l'architecture générale restera inchangée. NEC réalisera sur une base ACOS4 voisine de GCOS7un système multi-serveurs très voisine de celle d'IBM IMS/VS.

retour


DPS6

Honeywell réalisera quelques systèmes transactionnels sur GCOS6: DM6-TP inspiré du DMIV-TP de GCOS8 sera le produit officiel de Boston, Honeywell UK réalisera un TDS6 plus optimisé aux besoins clients.

retour


DPS4

Sur GCOS4, Honeywell Italia introduira des fonctions transactionnelles du type mono-serveur inspirées de l'IBM38 et de AS/400: journalisation, bases de données partagées.

retour


UNIX

L'arrivée des systèmes UNIX verra le déclin des architectures transactionnelles spécialisées malgré l'introduction sur AIX de CICS6000. Il y a à cela deux raisons: l'abondance des ressources et le retard à l'utilisation du multi-threading sur UNIX. L'utilisation de UNIX (et de Windows/NT) correspond à la remise en cause du modèle terminal-main frame et son remplacement par le modèle client-serveur. La station de travail client est responsable de la conservation du contexte et le serveur n'a plus que la responsabilité applicative de la gestion de la base de données. Cette gestion est en général intégrée dans le code du fournisseur de base données (ex. Oracle, SQL Sevrer de Sysbase-Microsoft). Il reste à donner aux réalisations sur ce modèle les mêmes performances et la rigueur d'organisation des systèmes main frames.


retour

Retour Sommaire Histoire des Systèmes FEB