WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

SOA : Définition, Utilisation dans le monde de la banque et méthodologie de test

( Télécharger le fichier original )
par Cédric MORA
IFIPS - Maison de l'ingénieur - Spécialité informatique 2008
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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, ...

précédent sommaire suivant