Scénarios d'utilisation des adaptateurs locaux optimisés pour Liberty pour z/OS

Les scénarios expliquent comment les adaptateurs locaux optimisés et les services d'appels des API natives de support peuvent bénéficier de l'architecture d'entreprise et du développement d'applications sur la plateforme z/OS.

WebSphere Optimized Local Adapters (WOLA) fournit des applications métier et middleware existantes en langage natif dans des environnements tels que z/OS Batch, CICS (Customer Information Control System) et USS (services système UNIX) comme alternative pour appeler des applications Java™ implémentées en tant qu'applications Enterprise JavaBeans (EJB) dans Liberty. Lorsque vous utilisez des adaptateurs locaux optimisés, vous pouvez aussi effectuer des appels depuis des applications Liberty vers un programme serveur externe qui s'exécute localement ou sur la même partition logique avec Java EE Connect Architecture (JCA) version 1.5.

Dans le scénario de prise en charge CICS pour l'utilisation de services Web client et serveur, les adaptateurs locaux optimisés peuvent améliorer les performances. Les applications de back end ciblées peuvent appeler une logique métier qui se trouve ailleurs plus facilement lorsqu'elles utilisent les adaptateurs locaux optimisés à la place de la technologie de messagerie SOAP et XML.

Les scénarios hypothétiques ci-après montrent comment les adaptateurs locaux optimisés sont utiles pour atteindre divers objectifs métier.

Scénario : Société de services financiers

Une société qui propose des services financiers utilisant le système IBM® z/OS exploite des applications de gestion sous z/OS Batch. Elle envisage l'achat d'une application de traitement financier qui permettrait d'établir des rapports de transactions boursières en temps réel à destination des places boursières. La possibilité de générer ce type de rapport en temps réel pourrait en effet augmenter sensiblement les revenus de la société.

L'application qui génère des rapports en temps réel est une application Java Enterprise Edition (Java EE) sur un serveur Liberty qui s'exécute sous Windows 8. Elle comprend un ensemble de beans enterprise et d'interfaces de services Web associées qui peuvent être appelés pour divers types d'interaction.

Un scénario de test est développé et implémenté pour appeler l'application Java EE depuis un programme Cobol de traitement par lots. La société financière décide d'aller plus loin et de procéder à des tests plus avancés. Ces tests montrent que, quand ce mécanisme est exploité par plus de 50 à 100 requêtes par seconde, il commence à ralentir au point que les temps de réponse ne satisfont plus les exigences du client. Cette voie est abandonnée en attendant de trouver une approche plus performante pour échanger les informations en temps réel entre l'application métier de traitement par lots et la nouvelle application du fournisseur.

Les adaptateurs locaux optimisés peuvent fournir à ce client de traitement par lots une option permettant de déployer Liberty pour z/OS et de mettre à jour l'application par lots en vue de l'utilisation de l'API Invoke ou Send Request des adaptateurs locaux optimisés. Ces API permettent d'appeler des applications EJB qui sont déployées sur un serveur Liberty local, qui appelle la logique métier pour le service Web.

Scénario : Compagnie d'assurance

Une compagnie d'assurance utilisant un système IBM z/OS exploite une application de gestion sous CICS. Elle souhaite offrir à ses clients la possibilité d'obtenir et de modifier en temps réel les données de leurs contrats d'assurance. Ces informations doivent être collectées de différentes manières et à partir de plusieurs endroits, notamment :
  • Auprès de DB2
  • En appelant un programme dans CICS
  • En démarrant un service Web afin de communiquer avec un service distant fourni par une autre compagnie

La compagnie d'assurance décide d'utiliser une application Java pour plusieurs raisons, mais surtout parce que son équipe de développement maîtrise particulièrement la programmation en langage Java. Quand la nouvelle application arrive en phase de test, le client constate que les temps de réponse pour obtenir les informations sont très longs. Ce long temps de réponse vient du fait que le serveur Liberty s'exécute sur un serveur distribué et qu'un temps d'attente important est induit par les communications à distance avec DB2 pendant les appels CICS via des services Web et des messages SOAP.

Pour corriger ce problème, le client déploie plusieurs serveurs Liberty dans la même configuration afin de réduire le nombre de demandes par seconde sur chacun des serveurs et de répartir les requêtes entre différents chemins de réseau.

L'utilisation des adaptateurs locaux optimisés fournit une alternative au déploiement de plusieurs serveurs. Le client pourrait installer l'application sur un serveur Liberty sous z/OS, plus proche des environnements DB2 et CICS. L'utilisation des API des adaptateurs locaux optimisés pour les appels vers CICS depuis le serveur Liberty procure un bénéfice réel par rapport à l'utilisation des services Web et de SOAP. Le regroupement sur des plateformes z/OS réduit la nécessité d'installer d'autres serveurs distribués qui requièrent plus d'espace, d'énergie et de ressources pour fonctionner. Dans ce scénario, dans la mesure où l'emplacement des données et des applications est le facteur majeur, augmenter la taille du serveur distant ne résout pas forcément le problème.

Migration de la logique métier vers Liberty pour z/OS

Une société utilise depuis des années une logique applicative développée en Cobol et exécutée dans CICS. Elle souhaite migrer certaines de ces applications vers Liberty afin de bénéficier des technologies Java et Java EE et d'utiliser d'autres capacités dans la pile WebSphere.

La taille de l'une des applications est trop élevée pour que celle-ci puisse être migrée en une fois et la société décide de déplacer progressivement des parties de l'application sur un serveur Liberty. La qualité des services de transaction et de sécurité de CICS doit être conservée pendant la migration et l'impact sur les performances de la migration doit être réduit au minimum. Les adaptateurs locaux optimisés permettront de migrer des parties de l'application vers Liberty et de les encapsuler chacune dans un bean session sans état. La logique d'application Cobol peut être modifiée pour utiliser un adaptateur local optimisé afin d'appeler les beans session sans état. Ces appels au serveur Liberty s'exécutent dans les mêmes contextes de sécurité et de transaction que ceux qui sont utilisés par les programmes Cobol dans la région CICS. Les performances sont considérablement améliorées dans ce cas, comparé à des appels similaires avec un service Web. Le client peut continuer à transférer des parties de son application vers le serveur Liberty jusqu'à ce que la migration soit complète.


Icône indiquant le type de rubrique Rubrique de concept

Nom du fichier : cwlp_dat_usagescenarios.html