On en parle peu et pourtant, ils sont toujours là. Le Gartner Group estime que les programmes Cobol représentent 75 % des applications d’entreprise dans le monde, soit entre 180 et 200 milliards de lignes de code. Ils
constitueraient même 15 % des nouvelles applications développées en 2005.Plusieurs éditeurs ont trouvé des solutions pour sortir ces applications de leur isolement. Les outils disponibles permettent de les relier à des systèmes plus modernes comme des serveurs Unix, des intranets ou de les faire fonctionner
sur des plates-formes moins coûteuses, à base de processeurs x86.
Placer le mainframe sur le web
Les premières solutions de Web-to-Host ont fait éclater le couple terminal passif-mainframe en offrant l’accès à de la logique Cobol depuis un PC client équipé d’applications bureautiques. Cette première génération
d’outils
Web-to-Host, proposée par Scort, Seagull ou Attachmate, intercepte à la volée les flux de données CICS ou 5250 et en interprète les données pour les insérer dans des écrans remodelés.
Les utilisateurs disposent ainsi d’interfaces beaucoup plus faciles à exploiter.Point faible de cette technologie, l’interprétation à la volée ralentit considérablement les débits d’informations. La mise en place d’un serveur intermédiaire entre le mainframe et les postes clients a, depuis,
accéléré le système. Fondée sur un serveur d’applications J2EE, cette brique intermédiaire reçoit les données du mainframe, les insère dans un fichier XML avant de les mettre en forme dans des pages HTML, JSP ou ASP, développées une fois pour
toutes lors de la mise en place de la solution. Les transferts d’informations sont rapides, et le flux XML provenant du serveur J2EE peut également être transmis aux systèmes des partenaires de l’entreprise.Autre avantage, la mécanique applicative du serveur intermédiaire cache aux développeurs Cobol la complexité d’un système Java. Le serveur intermédiaire peut aussi être appelé sous la forme d’un service web. Ces systèmes
se révèlent cependant difficiles à faire évoluer. Un changement dans l’application Cobol demande de modifier les composants mis en ?”uvre sur le serveur intermédiaire et les fichiers XML quand ils existent.
Fabriquer des applications objet
Autre alternative, certains éditeurs proposent des approches plus complexes permettant d’exécuter les programmes Cobol sur des machines moins coûteuses que les mainframes. MicroFocus propose ainsi un compilateur pour exécuter du
Cobol avec Unix ou Windows.Cet outil apporte une couche d’abstraction masquant aux développeurs les particularités de ces OS. ‘ Plusieurs éditeurs développent leurs logiciels en Cobol et les compilent sur toutes les plates-formes.
C’est le cas de Fidelity avec HR-Access ou du module de ressources humaines de PeopleSoft ‘, précise Patrick Rataud, directeur des opérations de MicroFocus France.Dernière possibilité proposée, le Cobol Objet. Ici, la programmation procédurale est remplacée par la logique objet. Les applications vieillissantes s’intègrent plus facilement aux plus récentes. Un composant Cobol peut ainsi
être inséré dans un EJB et être présenté comme un service Web.Cette approche laisse cependant sceptique Michel Koutchouk, PDG de la SSII Infotel : ‘ Ce n’est qu’une ouverture, Cobol est fait pour traiter des données. L’objet a d’autres intérêts,
comme la réutilisation des composants ou le développement Web. ‘ Pourtant, Microsoft ne s’y est pas trompé. Le Cobol (Fujitsu et MicroFocus) fait partie des langages de programmation de la plate-forme .NET.Les programmeurs Cobol créent avec lui des applications fonctionnant nativement sur les serveurs Windows 2000 et 2003, que l’éditeur de Seattle veut implanter dans les grands comptes. Les vieux jours du Cobol sont donc
assurés.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
