Technologies

Interface COBOL/Java

Publié le : Auteur: Frédéric DEIXONNE 2 commentaires
technologies

De nombreuses applications fonctionnent en mode client-serveur. Ainsi, une application de gestion peut comprendre une partie client qui prend en charge les contrôles de premier niveau et la navigation, une partie serveur qui accède aux données et exécute des traitements situés sur un site central.

Le déroulement d’une application nécessite des échanges d’informations entre ces deux mondes : le client et le serveur. Bien évidemment, chaque monde utilise ses propres langages de programmation. Sur le poste client, on utilisera des langages comme Visual Basic, C++, Java, PHP,.. Sur un serveur central, on utilisera des langages moins récents comme le COBOL. Or, le langage de description des données est typique du langage utilisé. Et les deux modes doivent communiquer et se comprendre.

La plupart du temps, on procédure en deux temps. Une description des données COBOL est extraite du serveur. Puis, cette description est passée dans un utilitaire qui la traduit en une description compréhensible par le client comme une classe Java ou un formulaire XML.

Dans un cycle de développement, toute modification d’un agrégat effectuée sur le serveur central doit être communiquée au client. Et l’on repart dans une boucle : extraction – traduction – installation.

En COBOL, les données sont définies dans une partie réservée appelée DATA DIVISION.

Dans cette DATA DIVISION un agrégat de données ENREG-AR a été défini. Cet agrégat de données regroupe plusieurs données élémentaires. Chaque donnée est accompagnée d’une PICTURE qui précise sa longueur et son type.

Dans cet exemple, CRANN-AR est une donnée alphanumérique de longueur 1 et QUANT-AR est une donnée numérique de longueur 6.

 10  ENREG-AR.
 *                 TOP CREATION/ANNULATION
 *                 -----------------------
 20  CRANN-AR    PIC X(01).
 *                 COMPTE ESPECES
 *                 --------------
 20  CPTES-AR    PIC X(12).
 *                 NUMERO D'ORDRE
 *                 --------------
 20  NOORD-AR    PIC X(12).
 *                 LIBELLE OST
 *                 -----------
 20  LBOST-AR    PIC X(30).
 *                QUANTITE SAISIE
 *                ---------------
 20  QUANT-AR    PIC 9(06).
 *

La conversion donnera une description équivalente en JAVA et compatible avec la description COBOL :

public class EnregAr {
 public char CrannAR;
 public String CptesAR;
 .
 .
 public int QuantAR;
}

La solution la plus propre consiste à partir d’un modèle de ces données. On utilisera un modeleur pour définir des données et des agrégats de données indépendants des langages. Ainsi, à partir d’une définition logique d’un agrégat, il sera possible de générer une description dans le langage cible souhaité.

Conclusion

Le SI de nombreuses entreprises s’est construit au fil du temps par strates successives. Chaque nouvelle strate s’appuyant sur la strate précédente.  Ainsi, la couche Java est venue se superposer à une couche COBOL décrivant les données. Pour ces systèmes anciens ayant évolués par couches successives, une réurbanisation du SI serait nécessaire mais s’agit là d’une autre histoire…

  • Vincent Hanniet

    Approche intéressante, Frédéric. Mais dans la pratique, est-ce que ça marche comme ça ? Existe-t-il des produits sur étagère qui permettent de générer des structures Java à partir d’un COPY COBOL (par exemple) ?

    • Dans la catégorie des outils payants, IBM en fournit plusieurs. Les applicatifs jee et mainframe communiquent par échange (request/response) de blocs de données au format « positionnel indexé », identique aux structures COBOL. Des connecteurs JCA comme la CTG d’ibm (CICS Transaction Gateway) permettent d’appeler de manière unitaire des programmes COBOL, et même de les impliquer dans une transaction JEE globale, aux cotés de JDBC ou JMS…

      IBM fournit des outils pour générer des classes techniques (i.e. des DTO) à partir des descriptions de copy cobol. Ces classes peuvent être sérialisées au format attendu par le programme cobol cible. Et inversement, désérialisées à partir des données retournées par le mainframe.

      Et dans la pratique cela marche vraiment ! C’est utilisé massivement (!) chez de grand comptes …

      A ma connaissance il existe aussi un produit opensource pour générer des pojo : LegStar. http://www.legsem.com/legstar/