Agon Newsletter 03 / 2015.

Zurück

Synchrone Nutzung von Webservices aus COBOL Programmen in IMS-Transaktionen

Der Mainframe z/OS ist längst nicht mehr allein und gemischte Anwendungslandschaften sind bei unseren Kunden die Regel. Für die Kommunikation und den Datenaustausch dezentraler Anwendungen mit dem Mainframe gibt es viele etablierte Lösungen. Überwiegend geht dabei die Initiative von der dezentralen Anwendung aus, die Schnittstellen und Businesslogik auf dem Mainframe nutzen möchte, um Datenbestände zu lesen oder zu pflegen. Was ist aber, wenn ein COBOL-Programm aus einer IMS-Transaktion einen Webservice nutzen möchte und eine synchrone Rückmeldung benötigt?

Unsere Kunden der Branchen Banken/Finanzdienstleister und Touristik/Aviation nutzen auf dem IBM-Mainframe CICS oder IMS-DC als Transaktionsmanager. Während im CICS-Umfeld bereits eine Reihe unterschiedlicher Architekturlösungen standardisiert sind, um auf die „Außenwelt" zuzugreifen, ist dies bei IMS-DC bisher nicht der Fall.

In den genannten Branchen ist der IBM-Mainframe weiterhin von großer Bedeutung um insbesondere geschäftskritische Datenbestände und Anwendungen mit hohem Transaktionsvolumen zu betreiben. Auch in diesen Branchen nimmt die Zahl dezentraler Anwendungen und Bestände stetig zu und damit die Notwendigkeit, aus Mainframe-Routinen direkt und synchron auf diese zuzugreifen.

Konkret hat sich beispielsweise eine Universalbank entschieden, einen aggregierten Konsolidierungsbestand aus mehreren Personensystemen auf einem Unix-Server in einer Oracle-Datenbank bereitzustellen, da die überwiegende Zahl der Nutzer selbst dezentrale Systeme sind. Es gibt aber auch Mainframe-Anwendungen, die – beispielsweise zur Personensuche – auf diesen Bestand zugreifen sollen. Die Funktionen zur Personensuche werden als Webservice zur Verfügung gestellt.

Da IMS-DC Out-of-the-Box nicht in der Lage ist mit Webservices zu kommunizieren, wird hierfür eine Middleware benötigt. Unser Kunde nutzt als Standard normalerweise MQ Series – mit gewissen Einschränkungen. Auf Initiative der Gruppe Systemarchitektur wurde jetzt IBM's WebSphere Optimized Local Adapters (WOLA) für eine Prototypisierung ausgewählt. WOLA ist eine funktionale Komponente von IBM's WebSphere Application Server for z/OS, d.h. das Vorhandensein eines WebSphere-Application-Servers auf dem Mainframe ist Voraussetzung für diese Lösung. Bei unserem Kunden war dies der Fall.

WOLA bietet zahlreiche Kommunikationsmöglichkeiten undkann aus IMS-DC Sicht für eingehende (outbound) und ausgehende (inbound) Nachrichten eingesetzt werden. Je nach Use-Case kann die Verarbeitung synchron oder asynchron erfolgen. Ein Two-phase commit transaction processing ist – zumindest eingeschränkt – möglich.

Der Anwendungsfall für unseren Proof-of-Concept war der Aufruf eines Webservice aus einem COBOL-Modul mit dem Inbound-Request, um Daten zu einer Personenkennung aus dem Oracle-Bestand zu lesen und die Antwort an das COBOL-Modul zurückzuliefern, so dass dieses anschließend mit den gelesenen Informationen innerhalb derselben Transaktion weiterarbeiten kann. Dieser einfache Use-Case wurde mit synchroner Verarbeitung umgesetzt. Wir haben unseren Kunden bei der Implementierung des COBOL-Moduls und bei der Testdurchführung unterstützt.

 

Abb. 1 Kundenbeispiel

Neben der technischen Machbarkeit war insbesondere der Nachweis zu erbringen, dass die Lösung auch den Performanceanforderungen des Kunden genügt. Im Rahmen der Testläufe wurden daher Performancemessungen mittels Traces aufgesetzt, um – End-to-End - die auf die verschiedenen Etappen entfallenden Anteile der Gesamtlaufzeit des Zugriffs ermitteln zu können. Um repräsentative Ergebnisse zu erzielen, wurde der Webservice in einer Schleife mehrfach wiederholt aufgerufen und durchschnittliche Laufzeiten ermittelt. Die auf Datenbankzugriffe innerhalb des Webservice entfallende Zugriffszeit war dabei nicht relevant, so dass beispielsweise Caching-Effekte nicht berücksichtigt werden mussten.

Das COBOL-Programm übergibt seine Requests der WOLA API im IMS. WOLA leitet diese weiter an eine EJB auf dem WAS z/OS. Bis dorthin liegt die Laufzeit noch bei unter 0,4 ms und ist damit deutlich schneller als MQ Series (weiterer Vorteil von WOLA gegenüber MQ Series: es fallen weder Administrationsaktivitäten, noch Ressourcenverbrauch für eine eigene Queue an). Jetzt wird aus der EJB der Webservice auf einem Application Server gerufen, in unserem Fall nicht auf demselben WebSphere z/OS sondern einem anderen auf Basis von Solaris. Das bedeutet, dass die weitere Laufzeit stark von der Netzverbindung zwischen diesen Servern abhängt. Auf diese Strecke entfiel dann auch der größte Anteil der Messungen mit durchschnittlich etwa 100 ms. Der Webservice selbst hat noch einmal etwa 100 ms verbraucht, um die Eingabe zu verarbeiten, in der Oracle-Datenbank zu lesen und die Antwort zurückzugeben. In Summe betrug die Gesamtlaufzeit einer Nachricht, ausgehend vom COBOL-Programm und zurück, durchschnittlich ca. 200 ms. Die Verweilzeiten in WOLA und in der EJB können bezogen auf die Gesamtlaufzeit fast vernachlässigt werden.

Fazit: Die technische Machbarkeit wurde im Rahmen des Proof-of-Concept nachgewiesen. Die Umsetzung war wenig kompliziert und klappte relativ reibungslos. Die Laufzeit liegt deutlich über der einer durchschnittlichen IMS-Transaktion für einen vergleichbaren Zugriff innerhalb des Mainframe. Dies ist im Wesentlichen der Laufzeit in der Netzverbindung zwischen dem WAS z/OS und dem Solaris Application Server geschuldet und liegt nicht an WOLA, da die Middleware selbst kaum nennenswert Zeit verbraucht.

Für einen einfachen Use-Case mit einzelnen Requests an den dezentralen Bestand ist diese Lösung tragfähig und ausreichend performant. Bei komplizierteren Anwendungsfällen bietet die asynchrone Verarbeitung in WOLA vielversprechende Ansätze, sofern der Use-Case in parallelisierungsfähige Einzel-Requests aufgeteilt werden kann. Für eine Massendatenverarbeitung auf dem Mainframe mit millionenfachen, nicht parallelisierungsfähigen Zugriffen auf einen Webservice eines Application-Servers außerhalb des z/OS ist die Lösung in dieser Umgebung eher schlecht bzw. nicht geeignet und wäre auch mit einer anderen Middleware, die dieselbe Netzverbindung nutzen muss, nicht zu verbessern.

Stefan Ludwig, Consultant der Agon Solutions