Ce sont ainsi l'équivalent de plusieurs années-homme de travail qui sont retournées à la communauté du logiciel libre afin de catalyser pour d'autres le mouvement dont Publicitas a bénéficié en choisissant Linux comme plate-forme stratégique, il y a 5 ans maintenant.
Le but est de poursuivre via la communauté le taux de couverture du Cobol par ces outils afin de les rendre de plus en plus généraux. Cette version est clairement une première livraison (v1.0) : elle sera améliorée par les contributions (tierces) et documentée au fil du retour d'expérience donné par les testeurs externes qui feront fonctionner ces programmes Java sur leurs propres infrastructures. De nouvelles versions sont également à prévoir autour des bibliothèques JLib et NacaRT qui continuent, par leur fonction même, à être utilisées en production par Publicitas et étendues au fil des évolutions de nos systèmes.
La licence retenue est la licence GPL du projet GNU pour l'outil principal de transcodage et sa petite sœur LGPL pour les bibliothèques associées.
Pourquoi ce choix ? Parce que nous souhaitons éviter le détournement de notre travail par des prestataires de services à but lucratif souhaitant utiliser ces programmes pour leur seul bénéfice en le ramenant vers une zone propriétaire.
La GPL place pour ces prestataires sur les outils NACA un bon nombre de contraintes qui imposent le retour vers la communauté Open Source d'un maximum des améliorations faites par des tiers sur le transcodeur et ses bilbiothèques associées. Elle offre, par contre, une grande liberté aux sociétés utilisatrices finales.
La LGPL permet par ailleurs à des éditeurs de logiciels applicatifs de convertir leurs applications via nos outils (NacaTrans), de livrer nos bibliothèques runtime (NacaRT et JLib) en mode source mais de garder les bibliothèques de leur propre application en mode binaire afin de garder leur valeur compétitive dans le secteur industriel de leur application.
Les outils que nous publions aujourd'hui (v1.0) dans le fichier zip
- Doc: un ensemble de documents explicatifs autour de ces outils. Votre retour d'expérience sur leur contenu, leurs déficits nous permettra de les améliorer.
- NacaTrans (licence GPL - approximativement 83 000 lignes de code et 690 classes Java) : le transcodeur. C'est en quelque sorte un compilateur qui analyse d'abord la structure des programmes Cobol initiaux (supposés 100% opérationnels) pour les amener dans une structure XML intermédiaire avant de générer un code Java faisant massivement appel aux classes et fonctions de la bibliothèque de runtime NacaRT. Ce code Java généré a la particularité intentionnelle de ressembler au maximum au code source Cobol initial afin de favoriser la poursuite de la maintenance par les développeurs initiaux. L'exhaustivité de ce compilateur par rapport aux multiples standards du langage Cobol n'est clairement pas garantie, même si NacaTrans compile correctement nos 4 millions de ligne de COBOL. Cependant des tests complémentaires avec du code COBOL applicatif en provenance d'autres sociétés nous laisse croire que le taux de couverture du langage est excellent.
- NacaRT et Jlib (licence LGPL – approximativement 153 000 lignes de code et 890 classes Java) : ce sont les bibliothèques de runtime qui réalisent toutes les fonctions de gestion / fonctionnement d'un système transactionnel classique. Elles émulent tous les verbes d'un moniteur transactionnel comme CICS et réalisent aussi entre autres l'émulation du langage COBOL (par exemple, structure COMMAREA à masques multiples, formats de données COMP-X spécifique à COBOL, etc.)
- NacaRTTest (licence GPL) : une suite de tests nous permettant de valider le fonctionnement correct de nos algorithmes de compilation. Pour toute personne qui installe la suite NACA dans son environnement, c'est la partie à faire fonctionner en priorité car elle tend à garantir une bonne installation de l'ensemble des composants.
Tous ces composants sont livrés avec les fichiers de description de projet au format Eclipse afin de faciliter leur prise en main via des outils standards du monde Java.
Maintenant, la question que vous vous posez sûrement : pourquoi cette démarche ?
- Parce que Publicitas, ayant beaucoup reçu de la communauté Open Source pour le projet NACA, souhaite rendre autant que possible. Avec cette publication, nous pensons livrer une contribution à forte valeur ajoutée et très pointue contribuant activement à notre tour à la dynamique Open Source.
- Parce que nous pensons que nos outils éprouvés à l'aune de notre propre projet de migration puis à celle d'une année complète de fonctionnement opérationnel peuvent être une excellente base pour des projets similaires dans d'autres entreprises souhaitant elles aussi bénéficier de tous les bénéfices de l'Open Source abondamment évoqués dans notre série d'articles sur le sujet.
- Parce que nous souhaitons encore améliorer nos outils qui restent encore abondamment utilisés chez nous : ils gèrent toujours nos 750 000 transactions quotidiennes. Bien sûr , nous souhaitons travailler encore les bibliothèques runtime (Jlib + NacaRT) puisque la version Java de PUB 2000 s'appuie abondamment dessus mais aussi sur le transcodeur NacaRT puisque nos équipes de développement ont fait le choix pour des raisons spécifiques de continuer à maintenir une fraction minoritaire de nos programmes directement en COBOL et de les recompiler au vol en Java. Nous avons développé un greffon Eclipse à cette intention.
Voilà, à vous de jouer : prenez le paquet complet indiqué ci-dessus et mettez-le en place dans votre contexte. Faites-nous part de vos suggestions par vos commentaires sur ce billet.
PS : pour des contacts autour de projets particuliers, vous pouvez nous contacter aussi plus spécifiquement par courriel à cette adresse : naca-contact at publicitas.com
Aller plus loin
- DLFP - Présentation du projet (205 clics)
- DLFP - Le transcodage dans NACA (189 clics)
- Vers le package (source + docs) à télécharger (269 clics)
# faut voir
Posté par volia . Évalué à 4.
Toutefois, toutes les expériences que j'ai eu avec des outils de traduction comme ça m'ont amené à penser qu'ils ne sont utiles que si on a vraiment pas le choix, et c'est rarement la meilleure solution. Le mieux c'est soit de réécrire, et d'en profiter pour repenser les applications (et le besoin ?), soit on garde l'existant.
J'ai souvenir d'un traducteur LISP vers Java... Le code est inmaintenable par la suite.
Et puis, je trouve bizarre l'idée de migrer COBOL vers Java. Une plateforme Unix n'est pas du tout comparable à un Mainframe. On n'y fait pas les choses de la même manière.
S'ils l'ont fait c'est qu'ils en avait besoin j'imagine, ou qu'ils ont cru en avoir besoin, mais ça me laisse perplexe.
Bon, je n'est pas regardé ce projet en particulier, peut-être qu'il est très bien quand même. Il n'y a pas des exemples de code traduit, histoire de se faire une idée ?
[^] # Re: faut voir
Posté par Didier DURAND (site web personnel) . Évalué à 10.
Il faut lire les autres articles que je pointe en entête: nous avons fait ainsi pour aller très vite et économiser chaque année des millions d'euros.
Ces millions d'euros nous permettent maintenant de financer le développement d'une autre version totalement OO et adaptée au nouveaux besoins de notre business
Sans ces économies, cette nouvelle version auraît été très dure à financer....
Concernant les exemple: un peu de patience. Ils vont suivre!...
didier
[^] # Re: faut voir
Posté par djainette . Évalué à 3.
[^] # Re: faut voir
Posté par Didier DURAND (site web personnel) . Évalué à 4.
O peut effectivement s'arrêter en chemin dans la migration et ne migrer que le front-end
Nous avons, dans notre cas, décidé d'aller au bout car il y avait des millions d'euros à économiser chaque année de manière récurrente.
cordialement
didier
# bravo
Posté par karmatronic . Évalué à 4.
moi perso,je connais 2-3 entreprises françaises qui font tourner une grosse appli develloppée en cobol sous AS400,et qui aurait grandement besoin d evoluer vers du linux....!
[^] # Re: bravo
Posté par Didier DURAND (site web personnel) . Évalué à 3.
Merci!
Elles peuvent entrer en contact avec nous si elles veulent de l'aide ou des conseils
cordialement
didier
# Plateforme
Posté par pwet_ . Évalué à 6.
[^] # Re: Plateforme
Posté par Didier DURAND (site web personnel) . Évalué à 5.
Vous apportez-vous même la réponse dans la seconde question: nous ne sommes pas moins fiables mais plus fiables car nous avons pu bâtir une redondance active dans le nouveau système que nous n'avions pas dans l'ancien.
De plus, nous avons pu bâtir un centre de disaster recovery que nous n'avions pas avant à cause des coûts mainframe.
Enfin, les pcs nous ont apporté des possibilités de croissance horizontale (par ajout de machines) et de load-balancing (les programmes "lourds" sur des machines dédiés) que nous n'avions pas avant.
Honnêtement, nous expérimentons depuis 15 mois une meilleure architecture que celle que nous avions avant avec le mainframe (dixit notre resp. d'exploitation qui n'était pourtant pas "chaud" pour linux/serveurs au début.
Si jamais, je suis à votre disposition pour d'autres questions.
cordialement
didier
[^] # Re: Plateforme
Posté par BAud (site web personnel) . Évalué à 5.
- constat d'une perte de compétence et d'un coût élevé pour se la réappropprier, au détriment d'une efficacité à prendre en compte de nouvelles évolutions si j'ai bien compris (réticence à investir sur un système plus forcément très maîtrisé et qui s'est classiquement complexifié au cours du temps ne serait-ce que par la diversité des cas de gestion maîtrisés par un faible nombre d'experts)
- coût non négligeable du système faisant hésiter à s'en séparer mais signant son arrêt de mort dès lors qu'un axe de résorption a réussi à démontrer son efficacité (félicitations pour tes retranscriptions précédentes ayant montré la démarche pour gérer la période transitoire et éviter les régressions tout en accompagnant les évolutions sur la période ; pour moi c'est un très bel exemple de conduite du changement tant du point de vue utilisateurs que du côté organisation des équipes de développement)
- maintien de l'efficacité des mainframes en terme d'exploitation par des procédures de livraisons maîtrisées et prises en compte au titre du projet; je suppose ? Historiquement, c'est le point fort de l'approche mainframe (et le point faible initial des "systèmes ouverts") de prendre en compte l'exploitabilité et la maîtrise des mises à jour dès le début des développements (c'est plus cadré, fruit de l'expérience mainframe qu'il aura fallu 20 ans à récupérer côté systèmes ouverts avec un peu d'ITIL au passage) : clairement entre la gestion des paquets de toute bonne distribution GNU/Linux et les EAR côté Java_EE, c'est tant l'admin système que l'admin applicatif qui sont contents pour la gestion des changements.
Le fourmillement de serveurs est aujourd'hui un peu plus gérable et la virtualisation donne des pistes pour mutualiser sans risque (au prix d'utiliser un marteau piqueur pour enfoncer une punaise mais bon... ça évite au moins l'approvisionnement d'un nième serveur et permet d'utiliser les ressources matérielles au mieux de leur capacité en séparant besoins applicatifs et besoins matériels).
Je suppose que pour l'instant la virtualisation est gardée pour "la prochaine étape" ? (de toute façon des serveurs d'applis ça se mutualise/démutualise facilement quand c'est bien prévu au départ).
[^] # Re: Plateforme
Posté par Didier DURAND (site web personnel) . Évalué à 8.
Pour répondre juste à la partie finale: nous avons essayé de virtualiser même les conflits inter-VM (charge des processeurs) nous ont fait revenir en arrière.
De toute façon, mon expérience est que les coûts essentiels dans les archis serveurs
a) sont dans les RH et pas dans le hard: donc pas de réelle nécéssité d'optimiser les coûts HW au dernier centime (contrairement au mainframe...). Il est souvent plus efficace d'un point de vue financier global de mettre en place un serveur de plus que tenter de les empiler (avec les problèmes précités) dans une architecture virtualisée (VMware, Xen, etc...)
b) dans la gestion des OS (nombre d'images d'OS) que dans les boîtes: on passe beaucoup plus souvent des patches que l'on ne prend le tournevis pour changer qch au hw.
Donc, la virtualisation ne serait (toujours selon mon expérience perso...) qu'une optimisation du 2ème ordre. A admettre que ce soit vraiment une optimisation.
Cordialement
didier
[^] # Re: Plateforme
Posté par ZeroHeure (site web personnel) . Évalué à 1.
très bonnes remarques, je croyais presque être le seul à avoir du bon sens et à recommander d'avoir un bon matériel, simple, facile à gérer, sur lequel on intervient peu, de façon à laisser du temps à ce qui fait tout le charme de notre profession: l'administration de plus en plus chronophage des systèmes.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Plateforme
Posté par pwet_ . Évalué à 2.
[^] # Re: Plateforme
Posté par Didier DURAND (site web personnel) . Évalué à 2.
-un SAN à très haute dispo auquel tous les serveurs du cluster sont accroché
- une redondance horizontale avec des "boîtes" en parallèle (car peu coûteuses) pour pallier les pannes. Ensuite différents dispositifs hw et sw de load-balancing envoient les requêtes vers les serveurs de transaction en "pleine forme".
PS: il semble que le cloud computing (EC2 d'Amazon) et Google avec son million de serveurs vont dans la même direction.
à dispo pour d'autres compléments
didier
[^] # Re: Plateforme
Posté par Yves Agostini (site web personnel) . Évalué à 2.
cf: hadoop ou mogilefs
[^] # Re: Plateforme
Posté par Didier DURAND (site web personnel) . Évalué à 2.
On ne peut pas tout faire en même temps.....
Passer d'un mainframe à des serveurs Linux, c'est déjà un bon pas,non ? Maintenant, on peut construire vers le cloud computing depuis cette base.
cordialement
didier
[^] # Re: Plateforme
Posté par Yves Agostini (site web personnel) . Évalué à 2.
Tant qu'à pinailler, j'ai un peu les même craintes que le premier commentateur que la maintenabilité du code généré. L'extension a l'usage de systèmes de fichiers distribués entraînera la ré-écriture des accès bas niveau et pourrai apporter des surprises.
De plus je ne vous remercie pas pour la mise à disposition de votre code. Je préfère souligner l'intelligence de la démarche :)
En effet, l'utilisation de trans-codage automatique est a priori douteux et pourrait s'apparenter à du bricolage théorique. J'imagine que ce type de bricolage a déjà été réalisé par beaucoup de sociétés.
Heureusement la mise à disposition du code sous licence libre vous permet de pérenniser votre démarche, de la valider et de l'enrichir avec des contributions extérieures. Cela vous a contraint à une démarche qualité sans doute plus contraignante que si elle se limitait à votre société et votre client. C'est une approche pragmatique de l'usage des logiciels libres. Il est alors inutile de vous remerciez, vous et vos clients en seront les premiers bénéficiaires :)
Je vous souhaite plein de fructueuses et enrichissantes collaborations.
Cordialement
1. Club Contre L'Usage Abusif des Buzz Words
[^] # Re: Plateforme
Posté par Didier DURAND (site web personnel) . Évalué à 3.
En fait, nous n'avons plus vraiment besoin du transcodeur: nous travaillons maintenant sur le Java qui est le nouveau source officiel de notre application Pub2000 (Le COBOL est à la poubelle)
Comme vous le soulignez, nous avons fait beaucoup d'efforts pour la lisibilité: j'ai publié un exemple concret sur mon blog perso (en cas de besoin, me contacter)
Enfin, nous ne sommes pas éditeurs d'où la démarche d'open sourcing du code pour restituer ce que nous avons reçu du Libre. Par contre, si qqn veut de notre assistance pour son propre projet, nous sommes dotés d'une expertise toute fraîche et bien réelle. Donc, nous ne sommes pas contre qq mandats d'assistance sur les projets similaires d'autres.
salutations
didier
[^] # Re: Plateforme
Posté par Didier DURAND (site web personnel) . Évalué à 1.
Je citais le cloud computing pour la croissance horizontale et pas le SAN
cordialement
didier
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.