L’optimisationdu patrimoine applicatifdans un environnement SOA

Livre Blanc

Extending the Mainframe to the Net

Et l’Archange Gabriel apparut au Directeur SI et lui dit :« Votre système d’information devra passer au SOA. »Evangile selon Saint Gartner, Verset 12.5

Le jour suivant, Gabriel rendit à nouveau visite au Directeur SI et lui dit :« Mais vous avez six mois pour réussir. »Evangile selon Saint MOA, Verset 13.4

Et l’Archange Gabriel ajouta :« Bien sûr le budget est limité, mais ce n’est pas un problème puisque vous réutiliserez 90% des applications existantes. »Evangile selon Saint Directeur Financier, Verset 6.2

02Mainframe et SOACopyright© Décembre 2007 SCORT

INTRODUCTIONDans une architecture orientée services (SOA), chaque élément du Système d’Information doit fournir aux autres composantes du SI, ses propres services, en les composant à partir de la réutilisation de services existants plutôt qu’en développant de nouvelles applications, et permettre en cela de répondre aux nouvelles exigences métier.

Ainsi que le souligne le cabinet ZapThink :

« Les architectures SOA sont bénéfiques dans quatre grands domaines : une réduction des coûts d’intégration, une réutilisation optimale des applications existantes, une plus grande souplesse opérationnelle et une meilleure gestion du risque. »….« L’un des principaux avantages des architectures SOA est de pouvoir créer de nouveaux processus métier en composant des applications à partir des services exis-tants. En d’autres termes, la réutilisation de ces services va vite devenir incontournable et sera nettement préférable à l’intégration d’applications. En créant de nouveaux services, réutilisables à leur tour dans le développement de nouvelles applications composites, les entreprises peuvent en espérer d’excellents retours sur investissement.En conséquence, le modèle SOA basé sur ce développement d’applications composites offre un intérêt économique indéniable pour les entreprises qui choisiront cette voie et qui réutiliseront un nombre croissant de services. »

Un consensus semble bien s’établir chez les analystes autour de la réutilisation croissante du patrimoine applicatif, jugée comme élément déterminant pour garantir un bon retour sur investissement (ROI) d’une architecture SOA.

En présence de Systèmes d’Information comprenant des milliers de programmes COBOL et utilisant, pour la plupart, des transactions IBM CICS et/ou IMS, il devient primordial de pouvoir reprendre ces vastes patrimoines dans des architectures SOA.

Pour répondre aux injonctions de l’Archange Gabriel, vous devez rapidement migrer vers une architecture SOA ; mais comment y parvenir dans les délais impartis et avec des budgets serrés si vous ne pouvez pas vous appuyer sur vos applications existantes ?

Ce document se propose d’y apporter des réponses en expliquant comment de nou-veaux services SOA basés sur les transactions existantes seront parfaitement efficaces et faciles à exploiter.

SOA natif et SOA par réutilisationDe nouvelles transactions Mainframe peuvent être développées comme d’authentiques services complets et être accessibles avec les protocoles IBM standard (MQ Series, IMS Connect et CICS/ECI). Ces transactions en « SOA natif » sont par nature SOA Ready1.

Quant aux transactions écrans existantes, elles doivent être réécrites pour devenir des services consultables soit à partir d’autres transactions sur le Mainframe lui-même, soit à partir d’autres composants du Système d’Information.

Il peut arriver que ce lourd programme de réécriture demeure une solution envisageable si les gains espérés sont supérieurs aux coûts prévus et si les délais sont respectés. Une fois réécrites, ces transactions seront aussi considérées comme SOA Ready.

Qu’elles soient initialement développées en tant que services ou réécrites ultérieu-rement, les transactions « servicées » représentent la partie « SOA natif » des applications/transactions Mainframe.

1 De telles transactions « servicées » seront ensuite publiées en tant que services dans un environnement ouvert avec des outils comme IBM RAD ou SCORT Data Mapper.

03Mainframe et SOA

Copyright© Décembre 2007 SCORT

Mais la plupart du temps, ces programmes de réécritures massifs ne sont pas possibles (au moins à court/moyen terme), pour des raisons de coût, de délais ou de risque.

Si la solution de réécriture n’est pas retenue, quelles sont les alternatives d’une stratégie viable d’une SOA par réutilisation ?

SOA par réutilisation : accès par l’écranPour transformer des transactions écrans en services, une méthode connue consiste à créer un robot (Java) qui se comporte comme un utilisateur 3270 (il se connecte au Mainframe en utilisant le protocole TN3270).

Le robot navigue parmi les écrans, envoie à chaque écran sollicité les valeurs requises (paramètres de service), puis en extrait des données et les rassemble pour finalement les restituer en tant que résultats du service.

Parfois dénommée « screen scrapping » (balayage des écrans pour en extraire les données), cette technique s’est révélée intéressante dans certains contextes particu-liers et limités, mais ne peut pas être considérée comme une approche stratégique pour la réutilisation massive d’applications : elle souffre en effet de multiples contraintes comme une trop grande dépendance sur les détails de la présentation des écrans2, ou encore d’un manque de performances3 et d’une difficile gestion de la maintenance4.

L’encapsulation de flux d’écrans5 peut donc difficilement constituer une stratégie à long terme dans une approche SOA par réutilisation.

SOA par réutilisation : l’approche stratégiqueLes transactions existantes se composent en fait de trois éléments :

• Une fonction logique métier,• Une fonction navigation,• Une fonction présentation.

Un processus donné (par exemple actualiser une déclaration, créer un nouveau contrat, rentrer un nouveau client) se décompose en plusieurs étapes ; chaque étape peut soit rassembler/afficher des informations, soit mettre en œuvre un traitement logique.

Bien que chaque étape puisse faire appel à l’une ou l’autre de ces fonctions, l’appro-che la plus fréquente consiste à suivre le schéma suivant :

1. La (ou les deux) première(s) étapes fait (font) seulement appel à de la navigation pour guider l’utilisateur avec des menus.

2. Puis les quelques étapes suivantes rassemblent les données (et vérifient leur cohérence et les enregistrent temporairement).

3. La dernière étape accomplit le traitement logique (avec validation finale) et actualise les nombreuses et complexes tables SQL (ou DL1).

Pour chaque étape, la fonction présentation n’est pas directement réalisée par le code transactionnel, mais plutôt effectuée par le moniteur transactionnel :

• Pour IMS, par le service MFS • Pour CICS, par le service BMS.

2 Tels que l’emplacement des données sur l’écran, les attributs.3 Le Mainframe et la plate-forme Java passent un temps considérable à coder/décoder les flux entre terminaux.

De plus, dans certains cas, le robot reste inactif en attendant que l’écran soit totalement rempli. Le protocole utilisé (TN3270) est un protocole d’affichage pour le terminal, et non un protocole d’échange de données.

4 Puisque le robot s’appuie sur des détails de présentation, une intervention de maintenance est nécessaire chaque fois qu’un de ces détails est modifié, alors qu’il ne devrait intervenir seulement lors d’un changement impliquant une logique métier.

5 Même si des produits tels que SCORT Enterprise Studio et SCORT Mainframe Integrator permettent de créer de tels robots Java avec des temps de traitement efficaces.

04Mainframe et SOACopyright© Décembre 2007 SCORT

Les transactions préparent et délivrent les messages (output) que les services MFS/BMS se chargent de transformer en flux terminal, tandis que, dans le sens opposé, les services MFS ou BMS se chargent des flux terminaux entrants et envoient un message d’entrée à la transaction.

Si l’on privilégie cette méthode d’échange de flux de messages avec les transactions existantes (en contournant ainsi les flux entre les terminaux), il devient donc possible de générer un flux de service qui :

• Ignore toute étape de type 1 (suppression de la navigation par menus, pour aller directement à la première étape « utile »).

• Exécute chaque étape, lui générant le message entrant attendu, l’appelant et décodant son message sortant.

• Rassemble et teste les résultats de chaque étape, accumule les données à produire en retour du service et enchaîne sur l’étape ultérieure.

Cette approche permet de mettre en œuvre un service qui :

• Réutilise tous les composants utiles (logiques métier et validation des données),• Ignore/Contourne les étapes inutiles,• Echange seulement des messages (en éliminant les flux entre terminaux).

Il en résulte des services très performants (similaires à des services « SOA natif ») et très faciles à exploiter. Cette méthode constitue donc l’approche stratégique idéale pour les architectures SOA par réutilisation.

SCORT SOA Fastrack propose une gamme complète d’outils (conception et exécution) pour mettre en place de tels services aussi bien pour les transactions IMS que CICS.

SCORT SOA Fastrack pour IMSSCORT SOA Fastrack/IMS Edition repose sur le fait que les transactions IMS ne gèrent pas directement la fonction présentation mais la délèguent plutôt à leur composant MFS.

Les transactions IMS reçoivent un message entrant et envoient un message de sortie, leurs formats étant déterminés respectivement par les descriptions MID et MOD des défi-nitions de format.

Tout d’abord, SCORT SOA Fastrack analyse tous les formats FMT des transactions IMS pour ensuite créer les composants nécessaires d’encodage des messages à générer pour les transactions (selon la définition MID) et de décodage des messages selon leurs défi-nitions MOD.

SCORT SOA Fastrack se connecte à IMS via IMS Connect ou MQ Series et échange les messages avec les transactions existantes via IMS Connect/OTMA ou MQ Series/OTMA.

Il ne fait appel à aucun flux d’écrans, ni à VTAM, ni au protocole TN3270.

Le designer SCORT SOA Fastrack permet ensuite de « jouer » les transactions utiles(définies dans les étapes 2 et 3 ci-dessus) et d’enregistrer les navigations. Ensuite le flux de service est généré à partir des navigations enregistrées (un outil graphique permet de contrôler et de corriger les derniers détails tels que les boucles et les branches en cas d’erreur).

Bien qu’aucun flux de présentation ne soit réellement utilisé, il est possible à chaque instant de ces phases de création ou de test/débuggage d’afficher un « espace virtuel de présentation » afin de bien comprendre ce qui est effectué6.

6 L’espace de présentation est reconstruit par SOA Fastrack à partir des informations extraites (DFLD’s) après que les formats aient été décomposés.

05Mainframe et SOA

Copyright© Décembre 2007 SCORT

SOA Fastrack gère aussi bien les transactions conversationnelles que non conversa-tionnelles de manière totalement transparente pour l’utilisateur.

En outre, l’exécution d’un service par SOA Fastrack pour IMS génère un gain de CPU Mainframe de 15 à 20% comparé aux méthodes traditionnelles utilisant les transac-tions écrans.

Lorsqu’il est déployé dans un serveur WebSphere (WAS ou WPS) SOA Fastrack utilise le « Resource Adapter » fourni par WebSphere (IMS TM RA). Si vous déployez WAS sur le Mainframe, vos services auront la qualité de service/robustesse intrinsèque à la plate-forme z/OS, les performances de communication avec IMS liés aux Hypersocket et/ou liens XCF, la performance d’exécution et les facilités/coûts réduits de fabrication liés à SOA Fastrack.

Un petit ExempleConsidérons une application (IMS)qui gère une base clients.

Les opérations sur la base clients sont (classiquement) :LIST, CREATE, UPDATE, DELETE, FIND.

Voici le déroulement de la création d’un client :

MAIN MENU : select 01 for CUSTOMER MENU

ENTER DATA

CREATED

CUSTOMER MENU : type 01 to Create a customer

CONFIRM (F7)

BACK TO MAIN (F3)

06Mainframe et SOACopyright© Décembre 2007 SCORT

Avec SOA Fastrack, on crée un robot (un Service Flow) qui saute les étapes 1 et 2 (affichage MAIN MENU et CUSTOMER MENU), construit un MID correspondant au message attendu par la transaction CSTMENU (avec choix = 01), reçoit et décode le MOD correspondant (création), enchaîne par le MID associé avec les données du client à créer et termine l’opération par un MID avec une clé PF7 (la dernière étape est également éliminée). Les messages sont échangés via IMS Connect et les transac-tions Mainframe ne « voient aucune différence » avec des messages qui auraient été construits par le composant MFS à partir de flux terminaux.

Pour cette application, on va ainsi créer des Services Flow pour les opérations CREATE, LIST, UPDATE, LIST, faisant ainsi de l’application « écrans » une application SOA Ready. Les Services Flow peuvent contenir des boucles, des branches, en tant que de besoin. Le point essentiel est que le « métier » du Mainframe est réutilisé tel quel (ni modifié, ni dupliqué dans l’application Java).

SCORT SOA Fastrack pour CICSSCORT SOA Fastrack/CICS Edition repose sur le fait que les transactions CICS ne gèrent pas directement la fonction présentation mais la délèguent plutôt à leur composant BMS.

Les transactions CICS exécutent un message entrant (« RECEIVE MAP ») et envoient une requête « SEND MAP » avec un message de sortie, leurs formats étant décrits dans les définitions MAP.

Tout d’abord, SOA Fastrack analyse tous les BMS pour ensuite créer les composants nécessaires d’encodage des messages à générer pour les transactions (selon la procédure MAP) et décoder les messages selon leurs définitions de sortie MAP.

SOA Fastrack se connecte à CICS via CTG ou MQ Series et échange les messages7

avec les transactions existantes via un programme CICS : la passerelle DFHL3270 (aussi référencée comme Link3270). Il ne fait appel à aucun flux d’écrans, ni à VTAM ni au protocole TN3270.

Le designer SOA Fastrack permet ensuite de « jouer » les transactions utiles (définies dans les étapes 2 et 3 ci-dessus) et d’enregistrer les navigations. Ensuite le flux de service est généré à partir des navigations enregistrées (un graphique permet de contrôler et de corriger les derniers détails tels que les boucles et les branches en cas d’erreur).

Bien qu’aucun flux de présentation ne soit réellement utilisé, il est possible à chaque instant de ces phases de création ou de test/débuggage d’afficher un « espace virtuel de présentation » afin de bien comprendre ce qui est effectué8.

SOA Fastrack gère aussi bien les transactions conversationnelles que non conversa-tionnelles de manière totalement transparente pour l’utilisateur.

Enfin, SCORT SOA Fastrack peut également interfacer des transactions qui n’utilisent pas de MAP’s (Send/Receive).

L’intégration des Services crées par SOA Fastrack dans l’architecture de l’entreprise Les services créés par SOA Fastrack peuvent être de plusieurs types9 :

• Un simple composant Java Bean pouvant servir par la suite à composer et à créer

7 Appelés respectivement « input and output vectors ».8 L’espace de présentation est reconstruit par SOA Fastrack à partir des informations extraites (DFLD’s pour

IMS, MAP’s pour CICS) après que les formats ont été décomposés.9 Lorsqu’ils sont intégrés comme composants Java, les composants SOA Fastrack générés ainsi que le

run time associé sont 100% Java. De même, lorsqu’ils sont intégrés dans un environnement .NET, les composants Fastrack générés ainsi que le run time associé sont 100% C#.

07Mainframe et SOA

Copyright© Décembre 2007 SCORT

des services web utilisables en mode SOAP (composer sans utiliser SOAP peut aug-menter considérablement les niveaux de performances).

• Des contrôles Workshop pour les utilisateurs de BEA WebLogic ou AquaLogic, qui peuvent être affichés intégralement dans la palette WorkShop.

• Des services intégrés dans les connecteurs de type EAI/ESB.• Des Web services compatibles SOAP.• Des composants C# nativement intégrés dans l’architecture .NET au cas où

celle-ci est utilisée.

ConclusionAvec SOA Fastrack, publier une application comme un ensemble de services est simple et rapide, et ne nécessite aucune modification de l’application Mainframe.

C’est le moyen de transformer une application complète, dont une partie seulement doit être réécrite, dans une vue unifiée de services, et d’offrir ainsi d’authentiques « services SOA natifs ».

La conception et l’utilisation sont rapides, car il n’y pas de code à réécrire et les outils permettent la conception et le test des services de manière immédiate.

Les temps d’exécution sont rapides, car seulement des messages sont échangés via IMS Connect / CTG ou MQ Series et les itinéraires de navigation choisis sont les plus courts.

SOA Fastrack représente une solution complète pour une approche stratégique du SOA par réutilisation.

SCORTBP 1041 place du Moutier92153 Suresnes CedexFrance

Telephone / Phone+33 (0) 1 4138 3500Telecopie / Fax+33 (0) 1 4144 1144E-mailinfo@scort.comInternetwww.scort.com

Extending the Mainframe to the Net