Retour à Page de Démarrage du SiteTRANSFORMATION D’APPLICATIONS COBOL EN APPLICATIONS FONCTIONNEMENT EN ENVIRONNEMENT OUVERT OU SOUS .NET de MICROSOFT.
Plusieurs Entreprises possèdent des applications développés en langage COBOL sur un système
propriétaire (VAX ou Alpha sous
OpenVMS, Système IBM 390 sous MVS et COBOL CICS, DPS6 DPS7 ou DPS8 sous IDS/TDS,
HP3000 sous UPX, etc…).
Pour ces
entreprises se pose la question du portage de
leurs application vers des plates-formes plus ouvertes ou avec un
interface utilisateur plus convivial. De même
se pose souvent la question
d’ouvrir l’application au monde WEB sans remettre en cause d’une manière
fondamentale la logique de son fonctionnement.
ISSI préconise
d’amener ou d’aider à mettre en œuvre une autre solution que celle d’une
réécriture totale du code sous JAVA,
VB, ou C# .
En effet la société
FUJITSU Software Corporation filiale
américaine à 100 pour cent de FUJITSU No 1 de l’Electronique Japonaise a
développé tout un ensemble de produits qui permettent une migration facile de
vos applications COBOL sur les plate formes Windows standard (en mode
Client/Serveur), Windows sous .NET, et
ou Linux.
ISSI utilise ces produits
depuis plusieurs années, et a réalisé
plusieurs portages. Aussi nous sommes à
même de les mettre en œuvre ou d’aider un client final à les mettre en
œuvre.
Nous pensons en
effet que les applications COBOL (du
fait de la clarté syntaxique inhérente au langage ) sont particulièrement
portables, fiables, structurellement
orientés gestion, et faciles à maintenir. Etudier leur portage sans changer de
langage avant de se lancer aveuglément dans une réécriture complète du code, peut
s’avérer une meilleure solution .
Nous expliquons ci-dessous les méthodologies
utilisées ainsi que les diverses possibilités et services que nous pouvons
proposer dans cette optique.
| Retour à Page de Démarrage du Site |
D’une manière générale une application informatique standard
développée sous COBOL comporte deux unités
de programmes :
Programmes dits transactionnels . Ils s’occupent de la gestion du dialogue opérateur, comportent des provisions pour être multi-utilisateurs, et, en général, mettent à jour des fichiers ISAM ou tables de mouvements d’une base de données.
Programmes dits Batch (ou de traitement par Lot) : Ces programmes, sont soit lancés automatiquement sur base journalière, hebdomadaire, mensuelle ou annuelle (traitements dits journaliers, mensuels, etc…), soit aussi lancés par un programme transactionnel.
Les programmes dits transactionnels font souvent des appels à des primitives d’un système transactionnel (tel CICS,) Les Ecrans de Gestion qui permettent la saisie des données sont souvent écrits avec un gestionnaire d’écran qui peut être un sous système du système transactionnel (BMS,FMS, FORMS, etc…). Le programme transactionnel COBOL se présente alors avec des appels au gestionnaire d’écran, le résultat de ces appels étant le remplissage de données à partir des écrans de saisie qui se succèdent. Les données étant alimentées, la logique de validation et de traitement des données est alors quasiment indépendante du dialogue opérateur.
| Retour à Page de Démarrage du Site |
Le nombre de possibilités de portage étant particulièrement
important nous ne pouvons ici les exposer toutes, et le type de portage optimal
ne peut être décidé qu’au cas par cas. Toutefois à titre indicatif nos donnons
plusieurs types de portage possibles.
3.1) Le portage est sur une plate-forme WINDOWS classique . L’application de départ ne fait pas appel à une base de données, elle utilise des fichiers ISAM , et le nombre d’utilisateurs de l’application est limité.(disons 20 utilisateurs maxi). Les utilisateurs partageant les données se trouvent au sein d’un même établissement. On désire avoir des possibilités d’extension type Internet, ou Intranet limités, pour permettre quelques consultations externes.
Pour un tel cas le portage est relativement immédiat.
Globalement tous les programmes BATCH serons conservés tel que (avec
éventuellement des modifications mineures au niveau de l’environnement) .
Les programmes Transactionnels seront repris. La logique de ces programmes sera
globalement conservée, des améliorations pourront être amenés (introduction de
contrôles Windows, tels listes ou tables
déroulantes, boutons poussoirs, pavés de sélection, etc…). Les temps et
l’effort de portages seront limités. Notre expérience nous amène à considérer
un temps de portage de 0,2 à 1 journée en ce qui concerne les programmes BATCH,
et de 0,5 à plusieurs journées (suivant les cas) en ce qui concerne les programmes transactionnels.
3.2) Même cas que précédemment mais soit le nombre d’utilisateur est élevé (plus de 20), soit, plusieurs utilisateurs veulent travailler en accès distant, soit l’appel aux données se fait via une base de données. Dans ce cas, soit toute la logique ISAM s’i y en a est à reprendre pour être transformée en des appels à un gestionnaire de base de données type ORACLE, (la logique appel aux bases de données est conservée). Soit, l’application doit être portée en mode Cient /Serveur sous Intranet ou Internet. Dans ce second cas les écrans sont en fait des pages HTML envoyés par le serveur (pages générés par un éditeur HTML type Visual Interdev ,HomeSite, etc…).
3.2.1) Cas où la logique ISAM de l’application originelle n’est
pas conservée (transformée en appels SQL).
Dans ce cas une transformation des appels ISAM en des appels SGBDR ainsi que la reprise en partie de la logique des programmes BATCH s’impose. La transformation des programmes transactionnels représentant un effort du même type que celui défini en 2.1.
3.2.2) Conservation de la logique ISAM :
Dans ce cas (transformation en mode Client/Serveur type intranet en consevant la logique ISAM s’il y en a), les programmes BATCH sont pratiquement conservés dans leur intégralité. Les programmes transactionnels sont à reprendre en grande partie pour les séparer en une partie de logique applicative, en relation via CGI, ou des appels IAS ou NAS avec la couche serveur IIS (Internet Application Server de Microsoft), ou NAS (Network Application Server de Netscape), et une partie dialogue opérateur . Les écrans développés deviennent des pages HTML ou ASP générés via un générateur ou éditeur HTML tel HomeSite ou Visual Interdev.
3.2.3) Enfin il existe toujours la possibilité de travailler en
faisant appel aux couches logicielles WTS (Windows Terminal Server) serveur
nécessairement du type Windows 2000 Server, ou Windows NT Server. Ces solutions dites de client léger sont très performantes.
pourvu que la puissance du serveur soit en rapport avec le nombre de clients connectés en simultanée.
Avec une solution client léger la charge du portage est du même ordre que défini en 3.1 ci-dessus.
3.3) Même cas que précédemment mais on désire faire appel à la technologie .NET :
Nous pensons que cette solution bien que plus onéreuse peu être à long terme la plus optimale. Ceci est particulièrement le cas si on désire une ouverture importante de son application propriétaire au monde WEB. Désir de voir ses clients consulter leur compte, voir les derniers règlements qu’ils ont reçus, ouverture vers des interrogations à partir de mobiles, etc…
La technologie .NET est le résultat d’un désir d’uniformisation et d’ouverture affiché de Microsoft. L’avantage d’une application développée sur plate-forme .NET (Visual Studio for .NET) est qu’elle peut en natif faire appel à tous les composants contenus par cette nouvelle plate-forme (Composants ADO, XML, SOAP, WebForms, WinForms, WSDL, etc…). Ces composants sont les mêmes quel que soit le langage de développement, d’où une interopérabilité sans précédent dans le monde du développement sur plates-formes Microsoft.
Le portage d’une application standard COBOL sur cette nouvelle plate-forme est une garantie d’évolutivité d’interopérabilité et de pérennité de celle-ci.
Comme l’indique le rapport HURTWITZ que vous pouvez consulter sur www.netcobol.com :
La conservation du patrimoine technologique et administratif est souvent capital pour une entreprise.
La majorité des sociétés pensent que l’ouverture de leur applications mainframe développés sous COBOL au monde Web est une nécessité.
Le choix de .NET comme plate-forme de développement d’un portage est plébiscité par la majorité des sociétés interrogés.
Pour un tel portage, là aussi tous les programme BATCH sont conservés en grande partie (la nécessité d’ouverture, implique une reprise des programmes afin de les présenter comme étant des méthodes propres à l’objet application batch). Les programmes interactifs sont réécrits, mais, la logique programmatique (vérification d’existence d’articles, logiques de validations, etc.…) est conservée. Ces nouveaux programmes interactifs font alors appel aux composants MS WINFORMS, (s’il s’agit d’une interface locale de Microsoft pour la plate-fome .NET a développer) ou WEBFORMS (s’il s’agit d’une interface destinée à être déployée sur le WEB) de Visual Studio for .NET. Le coût du portage est cependant plus important que dans les cas 3.1, 3.2 décrits ci-dessus, mais l’avantage est une plus grande ouverture : possibilités de faire des appels XML ou SOAP en natif et une interopérabilité native avec les autres langages de développement (qui peuvent faire appel aux composants COBOL constituant la logique applicative développée).
| Retour à Page de Démarrage du Site |
4) Comment envisager la collaboration entre ISSI et votre entreprise :
Quel que soient les scénarii envisagés, ISSI pourra si le client le désire intéresser les équipes de celui-ci au développement applicatif . De plus en général il sera nécessaire de faire un audit préliminaire à la définition de la stratégie de portage. Nous donnons à titre d’exemple plusieurs scénarii envisageables.
4.1) Il s’agit d’une application moyenne à usage départemental.
La transformation ne fait pas appel aux technologies .Net, et le nombre de programmes à transformer est moyennement important (40 à 80 unités de programmes) . La logique programmatique est peu ou pas transformée. Les ouvertures vers Intranet/Internet de la nouvelle application sont limités.
Dans un tel cas ISSI pourrait sous certaines conditions réaliser la transformation, sur une base totalement ou partiellement forfaitaire. Le projet pilote pourrait alors donner lieu à une formation des équipes du client sur les nouvelles technologies de NetCobol (mais pas NetCobol pour .NET)
4.2) Il s’agit d’une application plus importante.
Des extensions WEB sont désirés par l’utilisateur (appel ou pas aux technologies .NET) .
Là aussi suivant l’importance du projet le portage pourrait en partie se faire sur base forfaitaire.
4.3) Il s’agit d’une application importante (plusieurs centaines d’unité de traitement).
Nous pensons que dans un tel cas et afin de voir rapidement toutes les possibilités offertes par ces nouvelles technologies, le développement serait à décomposer en unités distinctes . Des produits de portages de masse tels WINKICKS pour un applications utilisant des appels standard COBOL.CICS, ou SWEET3000 pour des applications développés sur HP3000, sont disponibles, elles permettent de porter sans grand changement d’apparence votre programme sur une plateforme NETCOBOL (mais pas NETCOBOL for .NET) par la suite les ajouts et améliorations sont possibles à partir des produits de développement standard de NETCOBOL (ajout d’appels à IIS, développements de services WEB). Dans une seconde phase un portage sur plate-forme .NET est envisageable.