L’optimisationdu patrimoine applicatifdans un environnement SOALivre BlancEt l’Archange Gabriel apparut au Directeur SI et...
INTRODUCTIONDans une architecture orientée services (SOA), chaque élément du Système d’Informationdoit fournir aux autres ...
Mais la plupart du temps, ces programmes de réécritures massifs ne sont pas possibles                                  (au...
Les transactions préparent et délivrent les messages (output) que les services MFS/BMS se chargent de transformer en flux ...
SOA Fastrack gère aussi bien les transactions conversationnelles que non conversa-                                  tionne...
Avec SOA Fastrack, on crée un robot (un Service Flow) qui saute les étapes 1 et 2(affichage MAIN MENU et CUSTOMER MENU), c...
des services web utilisables en mode SOAP (composer sans utiliser SOAP peut aug-                                    menter...
SCORT                                     BP 104                                     1 place du Moutier                   ...
Prochain SlideShare
Chargement dans…5
×

L’optimisation du patrimoine applicatif dans un environnement SOA

736 vues

Publié le

Dans 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. Comment migrer vers une architecture SOA dans les délais impartis et avec des budgets serrés ? Ce livre blanc se propose d'y répondre.

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
736
Sur SlideShare
0
Issues des intégrations
0
Intégrations
54
Actions
Partages
0
Téléchargements
13
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

L’optimisation du patrimoine applicatif dans un environnement SOA

  1. 1. L’optimisationdu patrimoine applicatifdans un environnement SOALivre BlancEt 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.5Le 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.4Et 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 Extending the Mainframe to the Net
  2. 2. INTRODUCTIONDans une architecture orientée services (SOA), chaque élément du Système d’Informationdoit fournir aux autres composantes du SI, ses propres services, en les composant à partirde 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éductiondes 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 denouveaux 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 etsera 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, lesentreprises peuvent en espérer d’excellents retours sur investissement.En conséquence, le modèle SOA basé sur ce développement d’applications compositesoffre un intérêt économique indéniable pour les entreprises qui choisiront cette voie et quiréutiliseront un nombre croissant de services. »Un consensus semble bien s’établir chez les analystes autour de la réutilisationcroissante du patrimoine applicatif, jugée comme élément déterminant pour garantir unbon retour sur investissement (ROI) d’une architecture SOA.En présence de Systèmes d’Information comprenant des milliers de programmesCOBOL et utilisant, pour la plupart, des transactions IBM CICS et/ou IMS, il devientprimordial de pouvoir reprendre ces vastes patrimoines dans des architectures SOA.Pour répondre aux injonctions de l’Archange Gabriel, vous devez rapidement migrervers une architecture SOA ; mais comment y parvenir dans les délais impartis et avec desbudgets 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 efficaceset faciles à exploiter.SOA natif et SOA par réutilisationDe nouvelles transactions Mainframe peuvent être développées comme d’authentiquesservices complets et être accessibles avec les protocoles IBM standard (MQ Series, IMSConnect et CICS/ECI). Ces transactions en « SOA natif » sont par nature SOA Ready1. 02 Mainframe et SOAQuant aux transactions écrans existantes, elles doivent être réécrites pour devenir des Copyright© Décembre 2007 SCORTservices 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 envisageablesi les gains espérés sont supérieurs aux coûts prévus et si les délais sont respectés. Unefois 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 » desapplications/transactions Mainframe.1 D e 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.
  3. 3. 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’écran Pour 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égique Les 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. 03 Bien que chaque étape puisse faire appel à l’une ou l’autre de ces fonctions, l’appro- Mainframe et SOACopyright© Décembre 2007 SCORT che la plus fréquente consiste à suivre le schéma suivant : 1. a (ou les deux) première(s) étapes fait (font) seulement appel à de la navigation L pour guider l’utilisateur avec des menus. 2. uis les quelques étapes suivantes rassemblent les données (et vérifient leur P cohérence et les enregistrent temporairement). 3. a dernière étape accomplit le traitement logique (avec validation finale) et actualise L 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 L e 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 P uisque 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.
  4. 4. 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é, lesservices MFS ou BMS se chargent des flux terminaux entrants et envoient un messaged’entrée à la transaction.Si l’on privilégie cette méthode d’échange de flux de messages avec les transactionsexistantes (en contournant ainsi les flux entre les terminaux), il devient donc possiblede générer un flux de service qui :• gnore toute étape de type 1 (suppression de la navigation par menus, pour aller I directement à la première étape « utile »).• xécute chaque étape, lui générant le message entrant attendu, l’appelant et décodant E son message sortant.• assemble et teste les résultats de chaque étape, accumule les données à produire R 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 ») ettrès faciles à exploiter. Cette méthode constitue donc l’approche stratégique idéalepour 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èrentpas 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. 04Tout d’abord, SCORT SOA Fastrack analyse tous les formats FMT des transactions IMS Mainframe et SOA Copyright© Décembre 2007 SCORTpour ensuite créer les composants nécessaires d’encodage des messages à générer pourles 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 lesmessages 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 transactionsutiles(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 outilgraphique permet de contrôler et de corriger les derniers détails tels que les boucles etles branches en cas d’erreur).Bien qu’aucun flux de présentation ne soit réellement utilisé, il est possible à chaqueinstant de ces phases de création ou de test/débuggage d’afficher un « espace virtuelde 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.
  5. 5. 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 Exemple Considé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 CUSTOMER MENU : type 01 to Create a customer 05 Mainframe et SOACopyright© Décembre 2007 SCORT ENTER DATA CONFIRM (F7) CREATED BACK TO MAIN (F3)
  6. 6. 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 aumessage attendu par la transaction CSTMENU (avec choix = 01), reçoit et décodele MOD correspondant (création), enchaîne par le MID associé avec les données duclient à 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 SOAReady. Les Services Flow peuvent contenir des boucles, des branches, en tant que debesoin. Le point essentiel est que le « métier » du Mainframe est réutilisé tel quel (nimodifié, 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èrentpas directement la fonction présentation mais la délèguent plutôt à leur composantBMS.Les transactions CICS exécutent un message entrant (« RECEIVE MAP ») et envoientune requête « SEND MAP » avec un message de sortie, leurs formats étant décritsdans les définitions MAP.Tout d’abord, SOA Fastrack analyse tous les BMS pour ensuite créer les composantsnécessaires d’encodage des messages à générer pour les transactions (selon laprocé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 messages7avec 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 à VTAMni au protocole TN3270.Le designer SOA Fastrack permet ensuite de « jouer » les transactions utiles (définiesdans les étapes 2 et 3 ci-dessus) et d’enregistrer les navigations. Ensuite le flux deservice est généré à partir des navigations enregistrées (un graphique permet decontrôler et de corriger les derniers détails tels que les boucles et les branches en casd’erreur). 06 Mainframe et SOA Copyright© Décembre 2007 SCORTBien qu’aucun flux de présentation ne soit réellement utilisé, il est possible à chaqueinstant de ces phases de création ou de test/débuggage d’afficher un « espace virtuelde 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’utilisentpas de MAP’s (Send/Receive).L’intégration des Services crées par SOA Fastrack dansl’architecture de l’entrepriseLes services créés par SOA Fastrack peuvent être de plusieurs types9 :• n simple composant Java Bean pouvant servir par la suite à composer et à créer U7 A ppelé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 L orsqu’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#.
  7. 7. des services web utilisables en mode SOAP (composer sans utiliser SOAP peut aug- menter considérablement les niveaux de performances). • es contrôles Workshop pour les utilisateurs de BEA WebLogic ou AquaLogic, qui D peuvent être affichés intégralement dans la palette WorkShop. • es services intégrés dans les connecteurs de type EAI/ESB. D • es Web services compatibles SOAP. D • es composants C# nativement intégrés dans l’architecture .NET au cas où D celle-ci est utilisée. Conclusion Avec 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. 07 Mainframe et SOACopyright© Décembre 2007 SCORT
  8. 8. SCORT BP 104 1 place du Moutier 92153 Suresnes Cedex France Telephone / Phone +33 (0) 1 4138 3500 Telecopie / Fax +33 (0) 1 4144 1144 E-mail info@scort.com Internet www.scort.comExtending the Mainframe to the Net

×