Urbanisation des Systèmes d'Information

Aujourd'hui, j'aimerais bien, histoire de plaisanter un peu, vous racontez ma guerre de 14. C’est une histoire d’il y a 6 ou 7 ans mais elle est néanmoins très instructive. Voyez plutôt.
J'ai eu un jour l'occasion de travailler sur une application informatique en client serveur, dont le nom a été changé ici en « MARECAGE ».
Il faut tout d'abord avoir la patience de lire tranquillement la descente progressive de toutes les couches applicatives de l'utilisateur final jusqu'au fin fond du serveur et vous allez voir ça ne manque pas de piquant. Les technologies datent des années 1990 mais tout de même...

Voici un petit schéma pour aider un peu dans la compréhension.

C'est le système client serveur le plus fou que j'ai jamais vu à ce jour. Voyez plutôt :
- l'utilisateur saisit différents champs dans un formulaire PowerBuilder
- un framework défini dans PowerBuilder (qui en donne la possibilité) annule son comportement par défaut de L4G et ré-implémente le mécanisme de liaison automatique vers le middleware de communication un appel sortant vers une interface COM (prédécesseur Microsoft de .NET pour la communication inter applicative)
- une couche de transcodage COM- CORBA transforme l'appel en un appel de méthode vers la classe d'interface CORBA côté client, générée à partir du fichier IDL
- le serveur à l’écoute des sollicitations TCP-IP détecte une sollicitation CORBA et la transmet à la méthode correspondante dans la classe d'interface CORBA côté serveur
- la classe d'interface CORBA invoque une méthode identique dans une classe dite métier implémentée par le développeur cette fois-ci qui réalise le traitement effectif de la prise en compte de nouvelles valeurs, mais ne l'est pas directement en table (ce serait trop facile)la table et ses diverses colonnes ont été transformées en classe équivalente via le moteur de transformation relationnel-objet HIBERNATE. Le but est louable : faciliter le travail du développeur en lui permettant d'éviter la rédaction d'ordre SQL pour accéder au schéma relationnel. Une classe correspondante à chaque table est générée par le moteur. L'insertion se fait par l’invocation d'une méthode d'insertion, mécanisme qu'utilise la classe dite « métier »

Vous comprenez ?
Attendez, je vais vous la refaire !
Savez-vous que les allemands, quand ils éteignent un incendie ils font un bruit de train ? C’est parce qu’ils se mettent à la queue-leu-leu et se passent les seaux d’eau un par un à leur voisin en disant « bitte schön, danke schön »
Ils prennent le seau : « bitte schön »
Ils donnent le seau au voisin : « danke schön »
Passe à ton voisin.
L’eau met du temps pour arriver sur le lieu de l’incendie. Mais les allemands sont très polis. C’est l’essentiel.
(Eh, c’est une blague, je n’ai rien contre les allemands)

Donc, on reprend :
L'utilisateur saisit dans PowerBuilder (bitte schön) qui passe à COM (danke schön).
COM reçoit de PowerBuilder (bitte schön), et passe à CORBA/Client (danke schön).
CORBA/Server reçoit de CORBA/Client (bitte schön), et passe à la classe métier d’implémentation (danke schön).
La classe métier d’implémentation reçoit de CORBA/Server (bitte schön), et passe à la classe mappée sur la table (danke schön).
La classe mappée sur la table reçoit de la classe métier d’implémentation (bitte schön), et passe au moteur classe relation (danke schön).
Le moteur classe relation reçoit de la classe mappée sur la table (bitte schön), et passe à la table (danke schön).

L’essentiel du temps de machine est consacré à passer au voisin.
Quand on demande une évolution fonctionnelle, il faut reprogrammer un par un les passages au voisin…
J’appelle cela « l’architecture bitte schön, danke schön ».

Je me souviens de l’époque bénie où l’architecture était celle là…

J’ajoute un champ, et le lien est fait tout de suite et tout seul avec la base de données … Mais, bon, il n’y avait pas de couches qui permettaient de rendre chaque tranche indépendante de la précédente (d’ailleurs on s’en fiche parce qu’il faut toutes les reprendre quand on fait évoluer le système). On faisait du logiciel très vite et ca repartait en production très vite…
Les traitements de type batch étaient faits directement en PL/SQL (le langage procédural interne d’Oracle). On accédait directement aux tables. C’était vachement mieux. On avait tout sous la main. On faisait ce qu’on voulait.

À l’époque, « on » nous emm(…)dais pas avec les couches. Il y avait une fonction dans PowerBuilder qui lisait la description de la table puis générait directement un formulaire par défaut. Ca allait vite. On faisait quelques écrans en une après midi.
Pas besoin de faire des « démarches agiles ». Nous, à l’époque on relivrait une évolution en une semaine.
Aujourd’hui, j’ai l’impression qu’on a inventé des tas de «c(…)ries pour vous empêcher de travailler, ou pour mettre 5 personnes là où on n’avais besoin que d’une …

Ah, nostalgie ! C’était mieux avant ! (avec accompagnement de guitare façon Francis Cabrel)
Finalement sur ce coup là je suis resté assez passéiste.
Mais ce n’est pas ma faute si aujourd’hui n’est pas aussi bien qu’autrefois !
À quand, celui qui va nous inventer un vrai AGL vraiment simple, comme les L4G d’avant, qui permettrait au développeur d’en faire le moins possible pour arriver au résultat…
On peut rêver…

À bientôt

Christophe