IBM, COBOL, CICS
Le monde informatique bancaire a toujours été un
très grand utilisateur de tous les systèmes IBM. Ces
systèmes hôtes représentent un grand investissement qui est
intégré au niveau des processus et des sources de données.
Le challenge des projets SOA est donc aussi d'intégrer l'ensemble des
applications développées sur les systèmes IBM, qui sont
appelés application Mainframes ou System i. Les Web Services vont
permettre de publier les processus métiers bancaires offerts par le
système informatique existant et de les mettre à disposition de
façon standard, peu importe le langage de développement
utilisé.
L'histoire du Mainframe dans les banques est vieille de 50 ans
et est liée au Cobol. C'est un langage de programmation
de troisième génération créé en 1959 et est
l'acronyme de Common Business Oriented Language dont le but est d'être un
langage commun pour la programmation d'applications de gestion. Ce langage
était le plus employé des années 1960 à 1980 et
reste donc très utilisé dans les institutions financières.
En effet, l'immense majorité des plus grandes entreprises du secteur
financier ont encore des Mainframe et leur confient leurs applications et leurs
données les plus critiques. Les révolutions architecturales ont
entre temps eu lieu mais n'ont pas remplacé les Mainframe : elles
se sont superposées à l'existant, les complexifiant et nuisant
à toute évolutivité.
C'est cette situation figée que les entreprises veulent
faire évoluer en s'affranchissant de la dépendance aux
développeurs Cobol et de la complexité à
appréhender le patrimoine applicatif. Le but de l'utilisation de SOA est
donc de rénover les pratiques du développement sur Mainframe. La
solution logicielle que préféreront les banques est la solution
IBM Rational Software du fait de ce lien particulier avec IBM. La modernisation
des architectures est un point essentiel car il y a un trop fort couplage entre
les composants, empêchant la flexibilité des solutions et la
réutilisation du code. Les solutions comme Rational (d'autres existent
sur le marché) vont permettre de transformer les applications
« green screen » (un écran vert servant de client)
en interfaces ou en Web Services, de pouvoir développer des Web Services
à partir de langages comme Cobol ou Java ou à partir
d'application CICS avec le Service Flow Modeler. Le
système CICS (Customer Information Control System) est un système
qui permet d'effectuer des opérations transactionnelles, comme la
consultation ou la mise à jour de bases de données ou de
fichiers, avec une très grande économie de moyens. Service Flow
Modeler est l'outil permettant de construire un flow de services en se basant
sur des Commarea (fichiers Cobol de définition de données) et
applications Terminal CICS (voir annexes).
On peut ainsi exposer des flows de données en tant que
service avec des logiciels rendant possible l'utilisation des technologies
CICS dans une architecture SOA.
On expose ainsi le service CICS par le biais d'une interface
WSDL générée. En détail, on obtient le
schéma suivant où un service consommateur (requester) envoie une
requête au service fournisseur (provider).
Remarque : une application CICS peut aussi être le
service consommateur.
Toute une gamme de logiciels existe pour accompagner la vie
d'un projet SOA et IBM fonctionne beaucoup avec ces entreprises travaillant
dans le monde bancaire. Des logiciels existent et suivent une
méthodologie particulière pour surveiller la qualité et
les tests : cette méthodologie sera évoquée dans la
deuxième partie de ce document. Cet aspect est important car les tests
fonctionnels non intégrés et les tests de performances
différents entre îlots et des processus de fabrication
inconsistants contribuent à fragiliser le processus de
développement et en augmenter les coûts.
Les possibilités de modernisation des Systèmes
d'Information traditionnels sont :
- L'analyse du patrimoine : détection de
l'ensemble des interactions d'une application Cobol/CICS avec le reste du parc
applicatif
- La séparation de la couche de présentation de
traitement métier
- La transformation de ce module de traitement écrit en
cobol, en web service invocable au sein d'une architecture SOA, sans impact sur
le fonctionnement du système d'information.
C'est bien sûr compliqué de réorganiser
les composants applicatifs, de les récrire, ou de les mutualiser dans
des architectures SOA. Des outils permettent de détecter des
interdépendances applicatives pour pouvoir mettre en évidence la
structure complète du programme : quelles sont les transactions
CICS, quels sont les programmes COBOL, ... Cette étape est importante
dans l'optique d'un passage à SOA pour repérer les programmes les
plus utilisés et ainsi récolter des informations stockées
dans un référentiel utilisé par les outils de cartographie
et d'analyse d'impact. Un des objectifs est donc, bien entendu,
d'améliorer les taux de réutilisation des composants. en se
servant des analyses précédemment effectuées. Les outils
existants (comme Rational Developer for System Z d'IBM) permettent ensuite la
suppression de la partie cobol de l'application et la création d'un
service web utilisant la partie métier écrite en Cobol/CICS. Les
possibilités sont énormes et permettent la visualisation
transparente des programmes quelque soit leur origine et leur structure dans
une présentation type station de travail, avec une unité de
navigation et d'outils d'analyse et de débogage pour toutes les sources.
Toutes les combinaisons sont possibles : création depuis le
début d'un service, transformation d'un module métier en cobol en
nouveau service, ...
| 
