[z/OS]

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

Les adaptateurs locaux optimisés et les services d'appels d'API natives qui les prennent en charge constituent une alternative pour le développement d'applications et d'architectures d'entreprise sur la plateforme z/OS.

Pour les applications métier et les middleware écrits dans des langages natifs tels que Cobol, PL/I, C/C+ ou assembleur de haut niveau et exécutés dans des environnements comme z/OS batch, CICS, IMS et USS (UNIX System Services), l'utilisation des adaptateurs locaux optimisés constitue une alternative pour appeler des applications Java™ implémentées comme des Enterprise JavaBeans (EJB) dans WebSphere Application Server for z/OS.

La prise en charge des adaptateurs locaux optimisés permet aussi d'appeler à partir d'applications WebSphere Application Server un programme serveur externe exécuté localement ou sur la même partition logique (LPAR) à l'aide du modèle de programmation JCA (Java EE Connect Architecture) version 1.5. Les programmes serveur cible peuvent être des middleware ou des applications métier développées en Cobol, PL/I, C/C+ ou en assembleur de haut niveau.

Les adaptateurs locaux optimisés permettent notamment d'augmenter les performances quand vous utilisez CICS ou IMS pour prendre en charge des services Web avec serveur et client. Les applications d'arrière-plan cible peuvent appeler une logique applicative distante de manière plus efficace en utilisant des adaptateurs locaux optimisés plutôt qu'une technologie de message SOAP ou XML. Les services Web ne sont qu'un exemple dans lequel l'utilisation des adaptateurs locaux optimisés permet d'améliorer l'efficacité. Les exemples de scénario qui suivent décrivent comment les adaptateurs locaux optimisés peuvent s'avérer utiles dans une variété de situations.

Scénario : Société de services financiers

Une société de services financiers utilisant le système IBM® z/OS exploite des applications de gestion sous CICS. 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 les rapports en temps réel est basée sur Java Enterprise Edition (Java EE). Elle est déployée dans WebSphere Application Server sur une plateforme Windows XP. L'application comprend un ensemble de beans enterprise et les interfaces de service Web associées qui peuvent être appelées pour divers types d'interactions.

Un scénario de test a été développé et implémenté pour appeler l'application Java EE à partir d'un programme CICS en Cobol. 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 information en temps réel entre l'application métier CICS et la nouvelle application.

Avec les adaptateurs locaux optimisés, la société propriétaire de cette application métier CICS a l'opportunité de déployer WebSphere Application Server for z/OS et de mettre à jour l'application CICS afin qu'elle utilise les API Invoke ou Send Request des adaptateurs locaux optimisés. Ces API permettent d'appeler les applications EJB déployées dans une instance locale d'un serveur WebSphere Application Server for z/OS qui appellera à son tour la logique applicative du service Web demandé.

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 :
  • Informations recueillies directement auprès de DB2
  • Informations collectées en appelant un programme dans CICS
  • Informations collectées en démarrant un service Web pour communiquer avec un service à distance fourni par une autre entreprise

La compagnie d'assurance décide d'utiliser une application Java pour plusieurs raisons, mais surtout, parce que son équipe 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 WebSphere Application Server s'exécute sur un serveur réparti 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 WebSphere Application Server dans la même configuration afin de réduire le nombre de requêtes 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 WebSphere Application Server for z/OS, puis installer sa nouvelle application sur un serveur z/OS, plus près des environnements DB2 et CICS. Pour les appels à CICS depuis WebSphere Application Server, l'utilisation des API des adaptateurs locaux optimisés procure un bénéfice réel comparé à l'utilisation des services Web et de SOAP. Un regroupement de ce type sur des plateformes z/OS réduirait la nécessité d'installer d'autres serveurs répartis qui demanderaient 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ésoudra pas forcément le problème.

Migration de la logique applicative vers WebSphere Application Server for 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 faire migrer certaines de ces applications vers WebSphere Application Server pour bénéficier des technologies Java et Java EE et exploiter d'autres fonctionnalités de la pile WebSphere.

L'une des ces applications est trop volumineuse pour migrer d'un seul bloc et le client voudrait la transférer graduellement, par portions, dans WebSphere Application Server. La qualité des services de transaction et de sécurité de CICS doit être conservée pendant la transition et l'impact sur les performances doit être réduit au minimum. Les adaptateurs locaux optimisés permettront de faire migrer des portions de l'application vers WebSphere Application Server et de les encapsuler chacune dans un bean session sans état. La logique applicative en Cobol peut être modifiée pour utiliser un adaptateur local optimisé afin d'appeler les beans session sans état. Ces appels à WebSphere Application Server s'exécutent dans les mêmes contextes de sécurité et de transaction que les programmes en Cobol exécutés dans la région CICS. Le gain de performances est significatif comparativement aux appels du même type exécutés avec un service Web. Le client pourra continuer à transférer son application par portions vers WebSphere Application Server jusqu'à ce que la migration soit complète.


Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cdat_usagescenarios
Nom du fichier : cdat_usagescenarios.html