OLA-Einsatzszenarien für Liberty for z/OS

Realistische Szenarien veranschaulichen, wie die Unternehmensarchitektur und die Anwendungsentwicklung auf der z/OS-Plattform von optimierten lokalen Adaptern und unterstützenden aufrufbaren Services der nativen API profitieren können.

WebSphere Optimized Local Adapters (WOLA, optimierte lokale WebSphere-Adapter) bieten vorhandenen, in nativen Sprachen geschriebenen Geschäfts- und Middlewareanwendungen in z/OS Batch-, CICS- (Customer Information Control System) und UNIX System Services-Umgebungen eine alternative Möglichkeit für den Aufruf von Java™-Anwendungen, die als EJB-Anwendungen (Enterprise JavaBeans) in Liberty implementiert sind. Wenn Sie optimierte lokale Adapter verwenden, können Sie auch Aufrufe von Liberty-Anwendungen an ein externes Serverprogramm absetzen, das lokal oder in derselben logischen Partition ausgeführt wird, in der Java EE Connect Architecture (JCA) Version 1.5 verwendet wird.

Ein Szenario, in dem optimierte lokale Adapter zu einer höheren Leistung führen, ist die CICS-Unterstützung für die Verwendung von Server- und Client-Web-Services. Durch Einsatz von optimierten lokalen Adaptern (OLA) anstelle von XML und der SOAP-Messaging-Technologie können die Back-End-Zielanwendungen effizienter auf Geschäftslogik zugreifen, die sich anderswo befindet.

Die folgenden hypothetischen realistischen Szenarien beschreiben, wie optimierte lokale Adapter eingesetzt werden können, um verschiedene Geschäftsziele zu erreichen.

Szenario für ein Finanzdienstleistungsunternehmen

Ein IBM® z/OS-Finanzdienstleistungskunde, der Geschäftsanwendungen unter z/OS Batch ausführt, muss über den Erwerb einer Finanzverarbeitungsanwendung entscheiden, die neue Unterstützung für die Echtzeitberichterstellung zum Aktienhandel an die Börse liefert. Die Möglichkeit, diese Art der Berichterstattung in Echtzeit zu realisieren, kann zu einer Umsatzsteigerung beim Kunden führen.

Die Anwendung für Echtzeitberichterstellung ist eine Java EE-Anwendung (Java Enterprise Edition) auf einem Liberty-Server, der unter Windows 8 ausgeführt wird. Die Anwendung stellt eine Reihe von Enterprise-Beans und die zugehörigen Web-Service-Schnittstellen zur Verfügung, die für verschiedene Arten der Interaktionen aufgerufen werden können.

Ein Testszenario wird entwickelt und erfolgreich implementiert, in dem die Java EE-Anwendung von einem Batch-COBOL-Programm aufgerufen wird. Aus diesem Grund entscheidet sich der Kunde, fortzufahren und strengere Tests durchzuführen. Die weiteren Tests zeigen, dass dieser Mechanismus bei einem Anstieg der Anforderungen auf über 50 - 100 Anforderungen pro Sekunde langsamer wird bis zu einem Punkt, an dem die Antwortzeiten den Kundenanforderungen nicht mehr genügen. Der Prozess wird abgebrochen, bis eine realistischere Lösung verfügbar ist, um Informationen zwischen der Batchgeschäftsanwendung und der neuen Anbieteranwendung in Echtzeit auszutauschen.

Die optimierten lokalen Adapter (OLA) können diesem Batch-Kunden ermöglichen, Liberty for z/OS zu implementieren und die Batchanwendung so zu aktualisieren, dass sie die OLA-API zum Aufrufen oder die OLA-API zum Senden von Anforderungen implementiert. Diese APIs bieten eine Möglichkeit zum Aufrufen von EJB-Anwendungen, die in einem lokalen Liberty-Server implementiert sind und die wiederum die Geschäftslogik für den Web-Service aufrufen.

Szenario für ein Versicherungsunternehmen

Ein IBM z/OS-Versicherungsunternehmenskunde, der eine Geschäftsanwendung unter CICS verwendet, möchte seinen Kunden die Möglichkeit bieten, Richtlinieninformationen in Echtzeit abzurufen und zu aktualisieren. Diese Informationen müssen auf verschiedene Arten und aus verschiedenen Bereichen zusammengestellt werden:
  • Informationen, die direkt von DB2 zusammenstellt werden
  • Informationen, die durch Aufruf eines Programms in CICS zusammengestellt werden
  • Informationen, die zusammengestellt werden, indem ein Web-Service gestartet wird, der mit einem von einem anderen Unternehmen bereitgestellten fernen Service kommuniziert

Der Kunde entscheidet sich aus mehreren Gründen, hauptsächlich aber aufgrund von Programmierkenntnissen in Java, für die Verwendung einer Java-Anwendung. Beim Testen der neuen Anwendung bemerkt der Kunde lange Antwortzeiten beim Abrufen von Informationen. Die langen Antwortzeiten sind die Folge davon, dass der Liberty-Server auf einem verteilten Server ausgeführt wird und aufgrund der fernen Kommunikation mit DB2 während des Aufrufs von CICS über Web-Services und SOAP-Nachrichten Latenzzeiten auftreten.

Um das Problem zu beheben, implementiert der Kunde mehrere Liberty-Server in derselben Konfiguration, um die Anzahl der Anforderungen pro Sekunde auf jedem Server zu reduzieren und die Anforderungen über separate Netzpfade zu verteilen.

Die Verwendung optimierter lokaler Adapter bietet dem Kunden eine Alternative zur Implementierung mehrerer Server. Der Kunde könnte die Anwendung auf einem Liberty-Server unter z/OS näher an den DB2- und CICS-Umgebungen installieren. Werden für die CICS-Aufrufe vom Liberty-Server OLA-APIs verwendet, führt dies zu einer erheblichen Verbesserung gegenüber der Verwendung der Web-Services- und SOAP-Lösung. Die Konsolidierung auf z/OS-Plattformen verringert den Bedarf an weiteren verteilten Servern, die Platz, Strom und Ressourcen für ihren Betrieb verbrauchen. Weil in diesem Szenario die Position der Daten und Anwendungen ein entscheidender Faktor ist, führt eine Erhöhung der Größe des fernen Servers und damit verbunden die größtmögliche Leistungsfähigkeit nicht unbedingt zur Lösung des Problems.

Geschäftslogik in Liberty for z/OS migrieren

Ein Kunde verwendet seit Jahren COBOL-Anwendungslogik, die in CICS ausgeführt wird. Er möchte einige dieser Anwendungen in Liberty migrieren, um die Vorteile der Java- und und Java EE-Technologie und die zusätzliche Funktionalität des WebSphere-Stack zu nutzen.

Eine der Anwendungen ist so groß, dass sie nicht in einem Stück migriert werden kann, daher soll sie sukzessive auf einen Liberty-Server umgestellt werden. Während der Migration müssen die Transaktions- und Sicherheitsservicequalitäten, die von CICS bereitgestellt werden, aufrechterhalten und die Leistungseinbußen minimal gehalten werden. Mit optimierten lokalen Adaptern können Teile der Anwendung in Liberty migriert und in eine Stateless-Session-Bean gepackt werden. Die COBOL-Anwendungslogik kann so modifiziert werden, dass sie die optimierten lokalen Adapter zum Aufrufen der Stateless Session-Beans verwendet. Diese Aufrufe an den Liberty-Server werden unter denselben Transaktions- und Sicherheitskontexten ausgeführt, die das COBOL-Programm in der CICS-Region verwendet. Im Vergleich zu ähnlichen Aufrufen über einen Web-Service wird eine signifikante Leistungssteigerung erzielt. Der Kunde kann fortfahren, Teile der Anwendung auf den Liberty-Server zu verlagern, bis die Anwendung vollständig migriert ist.


Symbol das den Typ des Artikels anzeigt. Konzeptartikel

Dateiname: cwlp_dat_usagescenarios.html