Brevet FR2787217A1 — publié le 20000616

GENERATION D'INTERFACE PERMETTANT D'ACCEDER A DES SITES CENTRAUX. L'invention concerne le domaine des interfaces de communication entre des systèmes d'exploitation différents. Elle permet de faciliter l'accès à des données auparavant difficilement accessible et d'augmenter la vitesse de traitement des différents composants entrant en jeu dans un système informatique. Les grands systèmes centraux développés avant l'apparition des langages avancés comme Java de Sun possèdent des composants de traitement comme les composants CICS d'IBM, dont l'un des objectifs est l'utilisation ou la réutilisation des briques des systèmes d'informations automatisés mis en place avec des technologies anciennes telles que COBOL, VSAM, DL1 mais toujours valables dans les systèmes d'information d'aujourd'hui. D'autre part les caractéristiques technologiques des systèmes centraux doivent inciter les utilisateurs de ces systèmes à la construction de composants logiciels harmonieusement intégrés aux nouvelles technologies émergeant sur le marché. Les interfaces d'accès aux données vieillissent moins vite que les interfaces utilisateurs. L'utilisateur final recherche toujours l'amélioration sensible des temps de réponse de son applicatif aboutissant à des gains mesurables de la productivité ou de la qualité sur les postes de travail associés aux applications de gestion. Les applications existantes sur les gros sites centraux ne peuvent exécuter simultanément un nombre important de transactions du fait d'un espace mémoire généralement limité. Ceci a donc conduit les concepteurs d'applications du type CICS d'IBM à découper organiquement leurs applications de gestions en petites d. Iau unités d'oeuvre indépendante structurée de la manière suivante: - Acquisition des paramètres de l'unité d'oeuvre. Cette acquisition s'effectue classiquement par l'intermédiaire d'une saisie formatée sur une interface utilisatrice physique ou émulée. Cette saisie est indépendante de tout contexte transactionnel et donc n'occupe aucune ressource mémoire. - Le démarrage de la transaction est matérialisé par l'envoi de l'interface utilisatrice et constitue le démarrage d'une unité d'ouvre transactionnelle chargée d'exécuter une fonction élémentaire de la transaction. - Cette unité d'oeuvre transactionnelle se termine par la transmission du résultat d'exécution au terminal émetteur et le stockage intermédiaire optionnel d'un contexte réutilisable par une autre unité transactionnelle ultérieure. Cette terminaison matérialise le retour du moniteur dans un état stable et les ressources mises à jour sont validées lorsque la terminaison est normale ou invalidées si la transaction se termine de façon anormale. Un programme de site central standard, s'il ne suit pas nécessairement ce schéma, est généralement bâti suivant cette méthodologie de conception de transaction. De ce fait, cette méthode est largement répandue dans les grandes organisations utilisant ce moniteur transactionnel. L'usage répandu de cette généralisation de cette méthode de conception est surtout lié à son caractère optimisant du point de vu de l'utilisation des ressources de traitement. Cette stratégie permet notamment une montée en charge maximale avec une consommation minimale des ressources mémoires. Une structure représentant le cas optimal permettant la plus grande capacité d'évolution consiste 3 2787217 à isoler l'interface de présentation des règles de gestions applicatives. Ceci permet la réutilisation d'une transaction dans une architecture de composant et la prise en compte immédiate d'une évolution de l'interface de présentation. Dans un système d'information, les technologies mises en oeuvre vieillissent de manière inégale. Parmi ces technologies, les interfaces utilisateurs représentent celles dont le vieillissement est le plus rapide. L'isolation de l'interface utilisateur au sein d'une application représente donc un moyen simple et efficace de prolonger la durée de vie, et d'augmenter globalement la pérennité d'un système d'information. Un modèle idéal permet l'intégration d'interfaces de présentations plurielles, mais surtout offre des fondations conceptuelles solides garantissant l'adaptation future de l'application aux nouvelles techniques de présentation de l'information aux utilisateurs. Ce modèle passe par une conception pseudo conversationnelle ("context free") offrant le niveau de performance optimal des composants de traitement du site central et par la séparation des interfaces d'accès de présentation dans des programmes indépendants des programmes implémentant les règles de gestion applicatives propres à chaque organisation. La séparation implique la nécessité de standardiser les mécanismes de communication inter- programmes définissant le passage des paramètres contenant les informations sur la tâche à réaliser ainsi que le résultat de la réalisation à la fin de l'exécution. Le développement des applicatifs est aujourd'hui basé sur les composants logiciels. On peut EiiT 1 m définir assez simplement un composant, fonctionnellement de la manière suivante: un composant est une classe d'objet capable de fournir au monde extérieur, un ensemble fonctionnel de services au travers d'interfaces publiques d'appels utilisées pour communiquer. Il existe aujourd'hui des outils techniques permettant la construction ou la génération de systèmes de composant dans des environnements homogènes. Ces outils permettent aisément de construire de nouveaux composants destinés à être appelés par des applications s'exécutant dans ces environnements. Il est beaucoup plus délicat de définir ou d'adapter techniquement une architecture de composant lorsque les environnements techniques sont existants, hétérogènes et distribués. Les systèmes d'information existant dans les grandes organisations ont été bâtis en utilisant des technologies antérieures aux technologies Internet/Intranet disponibles aujourd'hui. Ces système d'information offrent néanmoins à leurs utilisateurs de bons voire d'excellents niveaux fonctionnels qui interdisent toute reconception même partielle, à court terme, du système existant. Une application présentant ce modèle de conception peut directement générer à l'aide de l'invention une nouvelle interface de présentation Internet/Intranet, coexistant parfaitement avec l'ancienne interface, et offrant ainsi une souplesse d'évolution et d'exploitation. Il est rare qu'une organisation existante ait systématiquement mis en place le modèle de développement idéal, il faut donc généralement prévoir une intégration de cette architecture dans un système existant. L'intégration peut se faire de deux façons: 2787217 - La solution adaptative qui sépare la couche de présentation et le traitement des données. L'isolation de la couche de traitement est la solution qui garantit la plus grande pérennité. Cette solution permet notamment d'isoler complètement la couche de présentation. Cette isolation garantit non seulement la capacité à pouvoir fournir à l'utilisateur rapidement une nouvelle interface de présentation chaque fois que l'évolution technique du marché ou organisationnelle de l'entreprise le demande, mais aussi la capacité à pouvoir supporter simultanément plusieurs interfaces de présentations au sein de l'organisation pour la même application. - La solution extensible: le fonctionnement parallèle de l'existant et des applicatifs Java. Il est souvent nécessaire au sein d'une organisation de préserver l'existant, généralement à cause du renouvellement progressif des postes de travail, qui impose la conservation ou la cohabitation des différentes interfaces de présentation. L'objectif de l'invention est de transformer le site central en serveur de traitement sophistiqué, dans un premier temps sans changer l'existant puis dans un deuxième temps en le structurant en serveur de composants objets. Ceci permet de combiner la puissance de traitement du site central (manipulation de grands volumes d'informations) et la puissance de l'interface utilisatrice des postes clients. L'invention consiste en l'extension de cette architecture afin de permettre à des applications de traitement de pouvoir s'intégrer dans une architecture de composants de type objet s'exécutant dans un contexte Internet/Intranet. Dans une réalisation préférentielle, l'invention s'applique à des applications COBOL CICS d'IBM et la génération de composants Java de Sun. L'invention construit en quatre ou cinq étapes les composants nécessaires à la manipulation de Transactions ou de zones d'échange permettant une liaison rapide entre le site central et le reste de l'architecture informatique: - On récupère les sources, par exemple en langage COBOL (par exemple fichier Clause Copy sous CICS d'IBM), sur le site central ou en local. A l'aide d'un module de communication FTP, on visualise l'arborescence des fichiers du site central et on récupère localement un fichier particulier. De plus, ce module permet de s'adapter au système d'exploitation du site central. Cette opération n'est nécessaire qu'une seule fois. En effet, les sources étant stockées localement, un dictionnaire des fichiers ainsi rapatriés est constitué instantanément. Ce dictionnaire constitue le projet. Le générateur de composants du dispositif mettant en oeuvre l'invention peut travailler avec plusieurs projets en même temps. L'invention précise si le fichier est de type Transaction ou de type Zone d'échange. De plus, il est possible de surcharger le nom (de la Transaction ou de la zone d'échange) qui dans la plupart des cas correspond à la clause 01 d'un fichier COBOL. Dans le cas d'une Transaction, l'invention génère automatiquement un programme source en langage source utilisé au départ, par exemple le COBOL, permettant de surcharger l'appel de celle-ci. Ce fichier est très utile dans le cas o l'on désirerait améliorer la définition actuelle de cette Transaction mais sans bouleverser l'existant. - On configure les paramètres de génération. La configuration du produit permet une indépendance vis à vis du fournisseur de machine virtuelle et des outils de développement. Cette configuration aborde les points suivants: la génération du code, la compilation du code lu1 îm 7 2787217 généré, l'archivage des classes compilées, l'exécution d'une classe particulière, la documentation des classes ainsi générées. La génération étant basée sur un système de "makefile", l'invention peut intégrer très facilement d'autres outils nécessaires à la construction des composants. On construit des composants disponibles pour la production. Cette génération est accompagnée de la compilation des sources générées ainsi que la création d'une documentation technique. Il est alors possible de créer d'une archive constituant le module de livraison des composants nécessaires à la manipulation des Transactions ou des Zones d'échanges du site central. Cette production est indépendante de la phase de génération et compilation des composants unitaires. Ainsi, il est possible de livrer, à partir des mêmes composants unitaires, des archives nommées différemment. Par exemple, la transaction de vérification d'un numéro de sécurité sociale peut être utilisée dans des archives différentes. - On teste immédiatement les composants générés. - Les composants étant générés, la dernière étape consiste à tester et valider l'appel de la transaction ou de la Zone d'échange. En effet, l'invention génère dans chaque composant un module permettant de valider la fonctionnalité et tester les performances. Cette validation peut être locale ou distante. La principale qualité d'une architecture basée sur une technologie de composants, est de permettre d'abord une modularité accrue, mais surtout de fournir la capacité d'exposer des sous-systèmes complexes mis en ouvre par des applications informatiques. Par exemple, une application tableur mettant en oeuvre un système de gestion de grille peut, en implémentant une technologie de composants, exposer au travers d'une interface publique cette fonctionnalité indépendamment de l'usage de l'application tableur. Si l'utilisateur ne souhaite ou ne peut transformer l'application existante, il peut alors décider de développer un nouveau composant selon l'invention qui sera utilisé parallèlement aux anciennes applications existantes. L'inconvénient de cette solution se situe dans la nécessité de modifier simultanément le composant selon l'invention et le programme antérieur en cas d'évolutions les règles de gestion de l'organisation. Il est possible de coupler les composants entre eux afin d'obtenir un composants traitant de manière complète d'un problème fonctionnel. L'invention traite les informations suivantes: - Enchaînements des différents types de transactions en fonction de certains critères (lecture, insertion, modification, suppression, contrôle,....), Enchaînement des différents types de transactions en fonction du contenu des propriétés, - Relation maitre-esclave entre les propriétés des différents types de transactions. L'invention sera mieux comprise grâce à la description détaillée d'une réalisation préférentielle mais non obligatoire suivant des langages largement répandus comme Java de Sun et un environnement bien connu comme CICS d'IBM. Les autres systèmes comme IMS, MQSeries d'IBM, GCOS7 ou GCOS8 de Bull, et les composants ActiveX de Microsoft, Corba, COM/DCOM peuvent tout aussi bien suivre le procédé objet de l'invention. Les types de modèles de transport propriétaire ou ouvert sont supportés par l'invention. Le choix de l'un ou l'autre de ces modèles s'effectue au qu -i lima 9 2787217 moment de l'exécution du composant généré. L'invention peut ainsi mettre directement en oeuvre le mode de connexion dans un réseau quelconque ou utilisant le protocole TCP/IP dans l'environnement choisi seulement, par exemple CICS/MVS d'IBM. Par construction, l'unité de traitement impose aux développeurs l'utilisation de zones de communications inter-programmes destinées à permettre l'échange des données entre les programmes. L'invention s'appuie sur l'existence de ces mécanismes pour mettre en oeuvre une communication entre les composants comme Java Sun et les programmes du type CICS d'IBM. Les deux principaux mécanismes de communications inter- programmes utilisés sont la COMMAREA et les Zones d'échanges. La COMMAREA CICS est une zone de communication CICS largement utilisée pour transférer des données lors des appels inter programmes CICS d'IBM, sa limitation structurelle de taille à 32KO limite son utilisation à des communications de paramètres simples non persistants. Les applications COBOL existantes possèdent une description en langage COBOL de ces zones de communications. L'invention analyse les descriptions COBOL CICS des zones de COMMAREA et génère automatiquement une classe JavaBeans capable de lire ou d'écrire cette zone, en effectuant toutes les conversions de données nécessaires. L'intégralité des composants peut être développée de manière préférentielle à l'aide du langage Java Sun (100% Java Sun) en utilisant la technologie de composant fournis pour cette environnement (JavaBeans). JavaBeans est une architecture technique de T r C l 2787217 développement de composants spécialement conçus par Sun MicroSystems pour le langage Java. Les Zone d'échange CICS sont des zones de communication CICS utilisées pour stocker des information volatiles (stockage mémoire) ou persistantes (stockage VSAM) sans limitations physiques de taille. Cette structure permettant de stocker un nombre variable d'enregistrements (limité au maximum à 32000 occurrences) de taille variable, est utilisée par l'invention pour échanger des données ensemblistes (collections) avec les programmes COBOL. Comme pour la COMMAREA, L'invention analyse les descriptions COBOL des structures de Zone d'échange, et génère à partir de celles-ci, un JavaBeans permettant le transfert des informations de la zone d'échange vers une classe Java, ou l'envoi du contenu d'une zone d'échange stockée dans une classe vers une zone d'échange CICS. Pour la production du JavaBean d'accès à la Zone d'échange, un pilote générique est fourni du côté MVS/CICS. Ce pilote implémente un simple mécanisme de lecture écriture générique de Zone d'échanges CICS qui peut être exécuté sur toutes les plates-formes CICS d'IBM. L'interface 3270 représente l'interface de présentation standard utilisable par une application COBOL CICS. Indépendamment de l'utilité de l'interface utilisateur 3270 dans le contexte de production utilisateur, son utilisation méthodologique dans le cycle de mise au point des applications distribués doit faire partie du cycle de test. Il est nécessaire de conserver un mécanisme de test unitaire des composants pouvant être mis en oeuvre indépendamment de la couche de connexion cliente. Ce mécanisme doit permettre par la lecture d'un écran nu 1 1 M 11i 2787217 3270 ou d'une zone d'échange de valider le comportement unitaire de la transaction en faisant varier la valeur des paramètres reçu. Cette validation doit, dans le cycle de mise au point d'une application basée sur les composants, être un prérequis indispensable au test d'un composant. Dans ce contexte, une Zone d'échange de test représentant un jeu d'essai de composant COBOL CICS peut être fabriquée localement par une application Java Sun et transférée sous CICS en utilisant les fonctionnalités standard de l'invention. L'invention comporte dans une réalisation préférentielle un générateur qui est capable de traiter toutes les versions CICS (MVS, 0S2, AIX, NT). Il analyse les descriptions COBOL des Transactions ou des Zone d'échange et génère des composants JavaBeans. Ces composants JavaBeans contiennent la description de leur pendant COBOL et reposent sur un runtime nécessaire à leur bon fonctionnement. Ce runtime ne contient aucun appel,graphique et peut donc fonctionner sur n'iiporte quel type système d'exploitation possédant une machine virtuelle Java. Le runtime est composé de deux parties distinctes: les composants "core" (minimum) et les composants SQL. Les composants "core" sont nécessaires à la communication entre le site central et l'application cliente. Ils prennent en charge les problèmes réseaux (TCP/IP ou IBM JGate), les problèmes de conversions de types et la manipulation des données. Une fois les composants générés par le procédé objet de l'invention, un driver JDBC permet une manipulation SQL des Transactions et Zone d'échange. Ce driver JDBC, nommé SqlHost, offre une vision relationnelle des composants situés sur le site central. F[Mi M la 12 2787217 Cette technologie permet une utilisation dynamique des composants générés, une standardisation des traitements de données ainsi qu'une facilité d'utilisation dans les outils d'aide au développement. L'invention utilise les modules suivants: un générateur de composants, un Runtime client, un produit JDBC, un driver JDBC et un outil d'interrogation du driver JDBC. Les composants générés peuvent être utilisés dans n'importe quelle application soit en tant que JavaBeans soit en tant que driver JDBC. Dans le cas de JDBC, une Transaction est vue comme une procédure cataloguée et une Zone d'échange comme une table. L'outil de génération peut avantageusement gérer la surcharge des informations en provenance du site central et chaque propriété de la transaction ou de la TS peut subir un contrôle avant manipulation à travers le réseau. Dans le cas de flux de données multiples, il est souvent nécessaire d'appliquer des contrôles sur toutes les informations. Ce contrôle est souvent basé sur un caractère d'unicité ou de validation. Le caractère d'unicité correspond à la notion de primary en SQL. La validation correspond souvent au déclenchement d'une ou plusieurs transactions devant valider ou invalider la donnée. Pour que la réutilisation des composants soit faciliter dans un environnement hétérogène, il est indispensable d'augmenter les informations dites de "métadata". Ces informations complémentaires peuvent porter sur les transactions ou les zones d'échanges ainsi que leurs propriétés. Un composant spécifique permet une centralisation uniformisée des informations dans le mode stockage et le mode visualisation. En effet, il y a souvent une différence entre la donnée stockée et la donnée à afficher. Le format proposé est alors en correspondance avec le type de la propriété. L'invention permet à la fois une prise en charge des traces site central coté client et une prise en charge de tous les composants "site central" de même nature qu'une transaction ou une zone d'échangeú. L'invention joue un râle fédérateur dans le rapprochement du site central dans un environnement informatique hétérogène. Les composants générés par le produit peuvent être utilisés dans les contextes suivants: Directement à partir d'une application (Unix, Windows, AS400, Macintosh,...), - Internet/Intranet, en tant que ActiveX, Applet ou servlet - Dans les outils de développement ou d'analyse (en standard par JDBC et en spécifique en tant que partenariat) - Dans un univers distribué, par le biais de Corba ou DCOM. Ainsi, le même composant peut être utilisé dans des contextes complètement différents mais en respectant toujours la même fonctionnalité. Cette garantie fonctionnelle est impérative dans le contexte d'utilisation d'objets distribués. Les termes UNIX, MACINTOSH, CICS, AS400, IBM, WINDOWS, COBOL, VSAM, DL1, JAVA, JAVABEAN, SUN MICROSYSTEMS, MVS, GCOS7, GCOS8, IMS, BULL, MQSERIES, CORBA, COM/DCOM, ACTIVEX, MICROSOFT, JDBC, JGATE, COMMAREA, JAVABEAN, 0S22, AIT, WINDOWS NT sont des marques déposées. REVENDICATIONS 1 - Procédé de génération de composant créant une interface entre un site central et l'architecture informatique applicative caractérisé en ce qu'il comprend les étapes suivantes: - On récupère les sources à partir du site central; - On configure les paramètres de génération; - On construit des composants disponibles pour la production. Cette génération est accompagnée de la compilation des sources générées ainsi que la création d'une documentation technique. - On teste immédiatement les composants générés et on valide l'appel de la transaction. 2 - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon la revendication 1 caractérisé en ce que la récupération des sources se fait par le biais d'un module de communication du type FTP. 3 - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon la revendication 1 caractérisé en ce que la récupération des fichiers se fait localement. 4 - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon l'une quelconque des revendications précédentes caractérisé en ce qu'on sélectionne un fichier particulier après avoir récupéré les sources. - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon l'une quelconque des revendications précédentes caractérisé en ce que le nom de la transaction est surchargé par le générateur et mémorisé dans un dictionnaire de fichiers. RE - 1 T R 6 - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon l'une quelconque des revendications précédentes caractérisé en ce que la configuration des paramètres de générations comprend au moins les informations suivantes: - les paramètres concernant la compilation du code généré; - les paramètres concernant l'archivage des classes générées - les paramètres concernant la documentation des classes générées. 7 - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon la revendication précédente caractérisé en ce que la configuration des paramètres comprend les informations concernant les composants exécutés. 8 - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon l'une quelconque des revendications 6 ou 7 caractérisé en ce que la génération des composants comprend la création d'une documentation technique et la compilation des sources générées. 9 - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon l'une quelconque des revendications précédentes caractérisé en ce que la génération des composants comporte une étape de création d'une archive comprenant les composants nécessaires à une application particulière. - Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon l'une quelconque des revendications précédentes caractérisé en ce qu'un composant de i u U, y w 16 2787217 validation est généré après le test des différents composants. 11 Procédé de génération d'interface entre un site central et l'architecture informatique applicative selon l'une quelconque des revendications précédentes caractérisé en ce qu'un pilote permettant la communication entre le site central et le poste client. 12 - Interface entre un site central et l'architecture informatique applicative comprenant des composants générés suivant l'une quelconque des revendications précédentes caractérisée en ce qu'elle effectue des interrogations SQL à la norme JDBC. 13 - Application du procédé objet de la revendication 1 à un système CICS d'IBM et générant des composants Java de Sun. 14 - Application du procédé objet de la revendication 1 à un système quelconque parmi les suivants: CICS, IMS et MQSeries d'IBM, GCOS7 et COS 8 de Bull, Unisys; et générant des composants quelconques parmi les suivants: ActiveX et COM/DCOM de Microsoft, JavaBean et Enterprise JavaBean de Sun, CORBA.