WP101xxx - Why WebSphere Application Server for z/OS IBM System z Software WP101xxx - Why WebSphere Application Server for z/OS Mehrwert von WebSphere Application Server auf IBM System z Andreas Gröschl IT Specialist for WebSphere on z/OS groeschl@de.ibm.com

WP101xxx - Why WebSphere Application Server for z/OS WebSphere Application Server (WAS) ist auf vielen Plattformen verfügbar IBM System x Application Server Windows Linux IBM Power Systems (System p and System i) IBM i IBM AIX IBM System z Mainframe z/OS Other Solaris Open Standard Interfaces and Java Specifications Platform-specific exploitation below the open standards Understanding that WAS is based on open standards is very important because it helps understand how “WAS is WAS” yet also have platform exploitation. That’s possible because the open standards represent application interfaces. That’s where the commonality takes place. But the implementation of the function below the interfaces is handled in some places on a platform- specific basis. Most of the code is common … but a small bit is platform specific, and that all takes place under the open standard specification line. 95%+ gemeinsamer Code Der Rest ist plattformspezifischer Code.

WP101xxx - Why WebSphere Application Server for z/OS Welche Produkte basieren auf WebSphere Application Server für z/OS? Business Fabric Process Server ESB WSRR Portal WebSphere Application Server for z/OS Integration WLM Platform Operating System (z/OS) RRS RACF XCF Hardware Architecture

WP101xxx - Why WebSphere Application Server for z/OS Unterscheidet sich Java auf dem Mainframe? Gibt es etwas zu beachten beim Designen und Schreiben von Java code, der auf WebSphere z/OS laufen soll? Antwort: No! Java ist Java. Der Vorteil eines Applikations- servers basierend auf offenen Standards ist die Reduktion der Plattformabhänigkeiten

WP101xxx - Why WebSphere Application Server for z/OS Welche Admin Console ist welche? z/OS In anderen Worten – Das gleiche “Look and Feel“. Distributed

WP101xxx - Why WebSphere Application Server for z/OS Wsadmin Skripting auf z/OS vs. distributed WZADMIN @ SC55:/WebSphereEd/wzcell/dmgr/DeploymentManager/profiles/default/bin>./wsadmin.sh –port 7010 –user wzadmin –password xyz –lang jython WASX7209I: Connected to process "dmgr" on node wzdmnode using SOAP connector; The type of process is: DeploymentManager WASX7031I: For help, enter: "print Help.help()" wsadmin>AdminControl.completeObjectName("type=DeploymentManager,*") 'WebSphere:name=DeploymentManager,process=dmgr,platform=common,node=wzdmnode,diagnosticProvid er=true,version=6.1.0.12,type=DeploymentManager,mbeanIdentifier=DeploymentManager,cell=wzcell,spec=1. 0' C:\zProducts\was61\AppServer\profiles\Dmgr01\bin>wsadmin -lang jython WASX7209I: Connected to process "dmgr" on node Dmgr01 using SOAP connector; The type of process is: DeploymentManager WASX7031I: For help, enter: "print Help.help()" wsadmin>AdminControl.completeObjectName("type=DeploymentManager,*") 'WebSphere:name=DeploymentManager,process=dmgr,platform=common,node=Dmgr01,diagnosticProvide r=true,version=6.1.0.9,type=DeploymentManager,mbeanIdentifier=DeploymentManager,cell=Dmgr01,spec= 1.0'

WP101xxx - Why WebSphere Application Server for z/OS Mehrwerte von WebSphere auf z/OS Reduktion des CPU Verbrauches durch: Finanzielle Attraktivität durch Offload der Java-Workload auf zAAPs und zNALC Konditionen Qualitity of Services durch WAS auf z/OS: Cross-Memory Kommunikation mit DB2 statt über das vergleichsweise rechenintensive TCP/IP Protokoll Nutzung von Cross-Memory Kommunikaiton mit CICS und IMS statt IP-basierender Lösungen. Intelligente Caching-Mechanismen auf z/OS mit FRCA Komplette Integration ins Betriebssystem z/OS Workload Manager (WLM), RACF Security und Tranaktionalität durch RRS Intelligente Priorisierung der Workload Konsolidierung der WAS Workload auf z/OS durch dynamische Ressourcenverwaltung Bessere Verfügbarkeit durch die z10 Hardware und den WAS z/OS spezifischen Mini-Cluster (Multi-JVM Konstrukt)

System z, z/OS, Linux, und WebSphere Application Server WP101xxx - Why WebSphere Application Server for z/OS System z, z/OS, Linux, und WebSphere Application Server Auf der System z Hardware gibt es zwei unterschiedliche Ausprägungen vom WebSphere Application Server – WAS für Linux und WAS für z/OS WebSphere Application Server für Linux Linux for System z als eigene LPAR Möglich, aber nicht weit verbreitet. Die Lösung für Kunden, bei denen kein z/VM Skill vorhanden ist. Linux for System z als zVM Gast Sehr weit verbeitet. Diese Variante bietet exzellente Virtualisierung mit zVM) and Linux und läuft auf dem IFL. z/OS als zVM Gast Ein weiteres Beispiel für die Fähigkeiten der Virtualisierung durch zVM. WAS z/OS wird hier typischerweise in einer Entwicklungs- oder Test-Umgebung betrieben. z/OS in einer non-Sysplex Umgebung WAS läuft direkt auf z/OS ohne zVM Virtualisierung. Eine Umgebung ohne Syplex wird typischerweiser nur in Test- oder kleinen Produktionsumgebungen verwendet. z/OS in einer Parallel Sysplex Umgebung Das ist die Implementierung mit den besten Quality of Services. Hier haben wir die hohe Verfügbarkeit, Skalierbarkeit und den maximalen Nutzen an Plattform Spezifika. WebSphere Application Server für z/OS Linux for System z z/OS Guest 1 IFL Guest 2 zOS zOS zVM 3 4 Parallel Sysplex IFL 5 System z Hardware Logically Partitioned LPAR or CEC Coupling Facility Here we’re providing a kind of schematic diagram of how WebSphere Application Server is capable of running on the System z hardware. The System z hardware has three operating systems that can run on it, and this chart is designed to try to clear up the options. The chart’s text provides the information intended. Our focus in this presentation will really be on numbered blocks 4 and 5, as those are the z/OS options where platform exploitation is the most apparent. Note: Numbered block 3 also has z/OS exploitation going on, but for the purposes of this presentation we’ll assume 3 is the same as 4 and 5. Running z/OS as a guest under zVM makes a wonderful test/development environment. Not as common for production environments. We will briefly talk about Linux for System z as a positioning of that option against z/OS. But in general this presentation is about WAS on z/OS. WebSphere z/OS Design und Implementierung nutzt die Sysplex Fähigkeiten aus.

WP101xxx - Why WebSphere Application Server for z/OS Die Konsolidierung einer Multi-Tier Architektur vorher nachher Networked Web Serving 1st Tier 2nd Tier 3rd Tier Client 1st Tier Data Power WAS zAAP Integrated z/OS Application & Database Servicing Client 2nd Tier App Server IFL Linux Integrated Application & Database Server IMS CICS DB2 z/OS Database Server Client z/OS App Server Client Standard CP Multiple Data Copies Single Data View Potentielle Vorteile von Konsolidierung von Anwendungen und Daten Security Fewer points of intrusion Resilience Fewer Points of Failure Performance Avoid Network Latency Operations Fewer parts to manage Environmentals Less Hardware Utilization Efficient use of resources Scalability Batch and Transaction Processing Auditability Consistent identity Simplification Problem Determination/diagnosis Transaction Integrity Automatic recovery/rollback

Der Vorteil der Datennähe: Ein PoC aus der Transport-Industrie Unit 5a - zDiff Functionality WP101xxx - Why WebSphere Application Server for z/OS Der Vorteil der Datennähe: Ein PoC aus der Transport-Industrie Präsentations- logik Präsentations- logik Geschäfts- logik Distributed Durchschnittliche CPU-Zeit pro trx (ms)‏ Datenvolumen pro Transaktion (KB)‏ 11.73 54.4 Durchschnittliche CPU-Zeit pro trx (ms)‏ Datenvolumen pro Tranaktion (KB)‏ 2.64 0.5 Geschäfts- logik Daten- logik Daten- logik DB2 Der Effect der Verlagerung von Geschäftslogik zu den Daten auf z/OS: Die durchschnittliche CPU-Zeit pro EJB Transaktion wurde um 77% reduziert. Das transferierte Datenvolumen pro EJB Transaktion wurde um 99% reduziert. Quelle: http://www.ibm.com/support/techdocs, Optimizing WebSphere Performance on DB2, WP100558 Unit 5a - 10

WP101xxx - Why WebSphere Application Server for z/OS Ergebnis eines WebSphere z/OS Co-location Benchmarks Wenn die Daten für Ihre bestehenden Java Enterprise Anwendungen bereits auf DB2 z/OS liegen, macht es aus technischer und finanzieller Sicht Sinn auch WAS z/OS in der gleichen LPAR zu betreiben. In diesem offiziellen Benchmark konnte der Durchsatz dadurch um 62% gesteigert werden. Ermöglicht wird dieser hohe Durchsatz auf einer z/OS LPAR durch lokale Cross-Memory Kommunikation (JDBC Type 2) vom WAS z/OS mit dem DB2 z/OS . Ein Overhead durch Netzwerkprotokolle entsteht auf der gleichen LPAR nicht und reduziert damit auch den CPU-Verbrauch insgesamt. unterschiedliche Maschinen unterschiedliche LPARs gleiche LPAR WAS V6.1 JDBC Type 4 Linux DB2 V8.1 DDF z/OS 4 CPUs (32% busy) (98% busy) z Series Server : z9-EC, 8 x 1.7 GHz, 64 GB RAM DB2 V8.1 DDF z/OS 8 CPUs im shared pool (91% busy) z Series Server : z9-EC, 8 x 1.7 GHz, 64 GB RAM WAS V6.1 JDBC Type 4 DB2 V8.1 z/OS 8 CPUs (91% busy) z Series Server : z9-EC, 8 x 1.7 GHz, 64 GB RAM WAS V6.1 JDBC Type 2 150 Transaktionen pro Sekunde 160 Transaktionen pro Sekunde 243 Transaktionen pro Sekunde + 62% Quelle: WebSphere z/OS – The Value of Co-Location Benchmark http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101476

Die Nutzung von lokalen Cross-Memory Konnektoren WP101xxx - Why WebSphere Application Server for z/OS Die Nutzung von lokalen Cross-Memory Konnektoren Immer wenn WebSphere und weitere Zielsysteme wie DB2, CICS und MQ auf einer LPAR liegen, kann von lokalen Konnektoren profitiert werden. Datenzugriff: LPAR DB2 LPAR memory JDBC Type 2 Vorteile: Cross-Memory Geschwindigkeit Übertragung des Security Kontextes an andere z/OS Subsysteme Transaktionalität gewährleistet durch RRS im z/OS – ohne zusätzlichen Protokolle wie XA Vermeiderung der Serialisierung von Parametern Vermeidung von SSL Overhead CR SR AppServer CTG Local CICS Bindings MQ Lokale Kommunikation: Used for IIOP flows between servers on the same LPAR. LPAR CR SR AppServer Vorteile: Die lokale X-memory Kommunikation benutzt keinen TCP/IP Stack Vermeidung von SSL Overhead Sehr schnell, sehr sicher Eine Erweiterung: Die neuen Optimized Local Adapters (WOLA) … Cross Memory COMM CR SR AppServer

WP101xxx - Why WebSphere Application Server for z/OS Bessere Verfügbarkeit durch einen eingebauten Mini-Cluster Verfügbarkeit und Skalierbarkeit - Ein logischer Application Server kann unter z/OS schon als Mini-Cluster aus mehreren JVMs bestehen, die je nach Last dynamisch gestartet werden können. Definition von Service Level Agreements in Form von WLM Zielen ist möglich. Zum Beispiel können je nach Kundenstatus mehr Ressourcen zugeordnet werden. AppServer (WAS z/OS) Verfügbarkeit: Bereits ein logischer Application Server kann aus mehreren Java Virtual Machines (JVM) bestehen. Skalierbarkeit: Abhängig von der Auslastung kann der WLM automatisch zusätzliche JVMs starten. Quality of Services: Die Workload kann durch den WLM priorisiert werden. SLA können definiert werden. 90% Requests in 0.2 Sekunden Servant Region JVM App App Request Gold Kunde Control Region WLM Queues JVM Request Silber Kunde Servant Region JVM App 90% Requests in 1 Sekunde

Intelligente Priorisierung von unterschiedlichster Workload auf z/OS WP101xxx - Why WebSphere Application Server for z/OS Intelligente Priorisierung von unterschiedlichster Workload auf z/OS Klassifizierung und Prioriserung von einzelnen Transaktionen durch den z/OS Workload Manager (WLM) möglich. Niedrigere Priorität o. unklassifiziert Hohe Priorität _____ WLM Hohe Priorität Controller Region Servant Region Der JVM werden mehr System Ressourcen zugewiesen Einkommende Requests HTTP / HTTPS IIOP MDB 2 1 JVM 4 Pull 3 Application(s) 5 Niedrigere Priorität Servant Region Dieser JVM werden weniger System Ressourcen zugewiesbade n Pull JVM Application(s) Hiermit können Anwendungen mit unterschiedlichsten SLA Anforderungen parallel betrieben werden. Der WLM versucht durch Zuweisung von zusätzlichen Ressourcen diese SLA's mit allen zur Verfügung stehenden Mitteln zu erfüllen und wird daran gemessen.

FRCA - Fast Response Cache Accelerator WP101xxx - Why WebSphere Application Server for z/OS FRCA - Fast Response Cache Accelerator FRCA ist ein sehr effizienter Cache, der vom TCP/IP Stack im z/OS zur Verfügung gestellt wird. z/OS Operating System User System or Program Nutzung des FRCA Exits Wichtige Punkte: FRCA selbst ist nicht z/OS spezifisch … FRCA gibt es auch auf anderen Plattformen. FRCA ist ein sehr effizienter low-level Cache, der die CPU Verbauch reduzieren kann. Er ist ein wirklich sehr effizienter Cache  Der Nutzen von FRCA ist sehr anwendungsabhängig. Je größer der statische Inhalt oder der cache-fähige dynamische Inhalt, desto größer ist der Mehrwert. FRCA API TCP Stack FRCA Funktionalität In memory cache (Data Space) Physischer Adapter FRCA (pronounced “Fricka”) is a caching mechanism of the TCP stack on z/OS that works at a very low level in the stack, which means it’s very fast and very efficient. There is a FRCA interface that higher-level programs can use if they wish. The FRCA function itself caches the objects into memory, so storing and fetching is very fast as well, involving no databases or I/O. The important points are worth noting: FRCA itself is not new … it’s been around for a while. What’s new is WebSphere’s exploitation of it. We’ll see how it does that in a bit. FRCA is not a z/OS exclusive. It exists on other platforms as well. So when discussing FRCA we have to be careful not to suggest it’s a z/OS exclusive. What is exclusive is how WebSphere z/OS exploits FRCA without requiring an HTTP server. We’ll see that in a bit. For some program or system to use FRCA, it must intentionally write to it. In other words, it must make use of the FRCA API. The older Domino Go Webserver did just that. The new Apache-based z/OS webserver does not. And before V7, WebSphere itself did not. FRCA is remarkably efficient … benchmark studies have shown it is a very scaleable solution, and improves overall CPU usage considerably. But we have to be careful … some applications do not lend themselves to caching because their content is too dynamic. For an application to make good use of something like FRCA, it must have static content and some portion of cache-eligible dynamic content. We’ll talk about that later. Network Benutzer

WP101xxx - Why WebSphere Application Server for z/OS Der Mehrwert von zAAP Prozessoren Java-Workload kann auf den zAAP Prozessoren ausgelagert werden. Da für die auf dem zAAP keine Software Lizenzen benötigt werden, ist der zAAP für New Workload finanziell sehr attraktiv. Der Vorteil eines zAAPs: zAAP Prozessoren haben wesentlich geringe Anschaffungskosten gegenüber traditionellen Prozessoren (CPs) Der Offload von Java-Workload auf den zAAP erlaubt es traditionelle Workload parallel auf den CPs zu betreiben ohne finanzielle Auswirkung. Für die Java-Workload, die auf dem zAAP läuft müssen keine Software Lizenzen gezahlt werden. ohne zAAPs mit zAAPs CR SR AppServer CR SR AppServer = Non-Java = Java Work: General Processor zAAP Processor General Processor Die komplette Workload wird vom CP abgearbeitet Non-Java Workload läuft auf dem CP, Java- Workload dagegen auf dem zAAP Abhängig von den Anwendungen können bis zu 90% der WebSphere Workload auf dem zAAP ausgelagert werden.

WP101xxx - Why WebSphere Application Server for z/OS Unit 5a - zDiff Functionality Plattformvergleich im Versicherungsumfeld – WAS distributed vs. WAS z/OS – Eine Anwendung basierend auf Innovas HI Voraussichtlicher z10 CPU-Bedarf – Projektion und Vergleich  Projektion der Testergebnisse auf die z10 (fester Faktor)  Gleicher Durchsatz und Antwortzeit wie bei System p (hochgerechnet)  Maximalwerte der Testdurchläufe  Vergleichbarkeit mit System p ist gewährleistet Realbedarf System z bei gleichem Durchsatz und Antwortzeit wie System p Summe CP zAAP zIIP KVNeu zWAS 2.63 0.62 1.63 0.39 KVNeu WAS System p 0.88 0.51 0.00 0.37 (DB2 Hostanteil)‏ Vergleich zu System p (Kaufmännische Betrachtung) Summe CP zAAP zIIP KVNeu zWAS 1.75 0.11 1.63 0.02 KVNeu dWAS 3.0 (Auslastung zu 70%) zWAS benötigt 42% weniger CPU Ressourcen Unit 5a - 17

WP101xxx - Why WebSphere Application Server for z/OS TCO Studie von einem großen IT-Dienstleister im Finanzsektor in Deutschland über WebSphere Application Server auf z/OS Kosten für das erste Jahr Kosten für Jahre 2-4

Startpunkt – Wiederbenutzung von bestehenden WAS EJB Assets WP101xxx - Why WebSphere Application Server for z/OS Startpunkt – Wiederbenutzung von bestehenden WAS EJB Assets Mehr und mehr Kunden suchen eine Möglichkeit WAS z/OS EJB Assets aus bestehenden Batch Programmen oder aus anderen Subystemen wie CICS aufzurufen Mehr und mehr Geschäftslogik wird in Form von EJBs implementiert WebSphere z/OS EJB Assets Batch Programs CICS Viele bestehende Lösungen sind designed worden, um aus dem WAS heraus (Outbound) andere Subsysteme aufzurufen. Es gibt andere Lösungen für Verbindungen in den WebSphere herein (Inbound) zum Beispiel Webservices, aber keine erreicht vergleichbare Durchsatzraten wie WOLA. Generally speaking, when people think of WAS they think of the applications inside of WAS being users of data and services outside of WAS. But that’s changing. More and more we find that people have a desire to leverage EJB assets inside of WAS as part of a broader service architecture. It makes sense -- WAS is a powerful Java EE runtime environment; WAS provides a wide range of key services such as security, transaction and container services. EJBs written to leverage the power of the WAS platform can in turn be leveraged by things outside of WAS. The issue is access the EJBs inside of WAS. There are solutions. Please don’t misunderstand. And they are often very good technologies. WOLA was created to address the specific need to access WAS z/OS EJBs in a highly efficient and high throughput manner. So inbound to WAS z/OS the original intent. But the developers did not wish to create a partial solution, so they made WOLA bi-directional … both inbound to WAS z/OS and outbound from WAS z/OS. WOLA is not a brand new technology. It’s actually an extension of an existing WAS z/OS communication mechanism called “Local Comm.” WOLA wurde entwickelt, um eine eine hochskalierbare, transaktionale Inbound Lösung zur Verfügung zu stellen Um das Bild zu komplementieren, wurde WOLA als bi-direktionale Lösung designed. 19

WebSphere Optimized Local Adapters – Was ist es? WP101xxx - Why WebSphere Application Server for z/OS WebSphere Optimized Local Adapters – Was ist es? eine hoch skallierbare transaktionale Kommunikationslösung neue cross-memory Kommunikationsstruktur für WAS V7 und neuer, Erweiterung des internen WAS “Local Comm” im Mai 2009 in WAS 7.0.0.4 eingeführt, erweitert mit WAS 7.0.0.12 LPAR CR SR DMGR CICS Assembler/Cobol/PLI/C or C++ WOLA Daemon Shared Space z/OS Batch Assembler/Cobol/PLI/C or C++ WOLA CR SR AppServer UNIX Systems Services Assembler/Cobol/PLI/C or C++ WOLA Cross memory “Local Comm” AppServer SR Airline Control System Assembler/Cobol/PLI/C or C++ WOLA CR Neu in 7.0.0.12! IMS Assembler/Cobol/PLI/C or C++ WOLA bi-direktionale Pfade! Diese Erweiterung ist realisiert durch ein neues Set von Modulen, die die API für Programme in externen Adressräumen zur Verfügung stellen, mit der diese mit WAS mittels des Deamon shared space Mechnismus kommunizieren können.

Die Basis-Technologie für WOLA “Local Comm” WP101xxx - Why WebSphere Application Server for z/OS Die Basis-Technologie für WOLA “Local Comm” “Local Comm” ist eine intelligente Cross-Memory Lösung, die bisher für die Kommunikation zwischen einzelnen Server innerhalb einer Zelle und LPAR verwendet worden ist. LPAR CR SR AppServer Daemon Shared Space Data Buffers Server Storage Above the bar owned by Daemon CR SR DMGR Daemon Shared Space CR SR AppServer Cross memory “Local Comm” CR SR AppServer “Local Comm” is a feature of WAS z/OS whereby communications between servers in the same cell on the same LPAR (that’s key, as you’ll soon see) are optimized by avoiding the TCP stack and the network altogether. After all, why bother incurring the overhead of that when the source and target are in the same operating system instance? Local Comm is based on a memory-to-memory transfer. Data buffers are transferred to a portion of memory “above the bar” (above the 2GB boundary), then transferred to the target server. That’s a direct memory-to-memory transfer with no serialization, no invocation of the TCP code path, no need to encrypt. It’s very, very efficient. The key to this is a pool of above-the-bar memory that’s owned by the Daemon server instance for the cell on that LPAR. The above-the-bar memory is not strictly speaking “in the Daemon address space,” it’s simply owned by the Daemon. In the picture above, the right-half of the chart shows a representation of this. We’re showing a block of memory in the Daemon, and what that’s meant to represent is the pool of above-the-bar memory owned by the Daemon for that cell on that LPAR. When one server wishes to communicate with another in the cell, the data buffers are transferred cross-memory. That is “Local Comm.” Going node-to-node can use Local Comm provided the two nodes are in the same cell and on the same z/OS operating system instance. Cross-LPAR is another thing altogether. There TCP does get involved. But depending on how the Sysplex is configured, that TCP communication can be optimized. So it’s still very efficient, but it’s not “Local Comm” when going LPAR-to-LPAR within a cell on a Parallel Sysplex. Now we’re ready to introduce WOLA. WAS benutzt Local Comm für die interne Kommuniktaion … zum Beispiel bei IIOP Verbindungen zwischen Servlet und EJB in unterschiedlichen Servern. Kein TCP, kein SSL … sehr effizient. 21

Ein High-Level Überblick der WOLA Implementierung WP101xxx - Why WebSphere Application Server for z/OS Ein High-Level Überblick der WOLA Implementierung Der Daemon verwaltet den gemeinsamen above-the-bar Storage, in dem die WOLA Registierungen erfolgen und die Daten ausgetauscht werden Shared Space Daemon WebSphere z/OS Cell auf einer LPAR STEPLIB DD DSN=hlq.WOLA.LOADLIB AppServer External WOLA APIs External Address Space Assembler/Cobol/PLI/C or C++ Local Comm JCA EJBs Externe Address Spaces benutzen die WOLA Module, um sich beim Daemon anzumelden und Local Comm zu verwenden. Ein zur Verfügung gestellter JCA adapter stellt die Java outbound Schnittstelle zur Verfügung. Für die inbound Kommunikation benötigt das EJB keinen WOLA JCA Adapter. Here’s a very high-level schematic picture of this. We’ve already introduced the notion of “Local Comm” and the above-the-bar shared space owned by the Daemon. We’ve pointed out that while the shared space is not physically in the Daemon’s address space, it is owned by the Daemon. So we represent it as “in the Daemon” just for purposes of simplicity. WOLA supplies a set of modules that provide the APIs and facilities to connect to the extension of the Local Comm architecture. An external address space (batch program, CICS region, USS process) needs to have access to those modules (example, STEPLIB for batch) and it’s able to make the connection. On the WAS side there’s a new Java Connector Architecture (JCA) resource adapter supplied that provides the way EJBs access WOLA. That JCA adapter installs like any other JCA adapter. We’ll discuss the programming implications of this (at a high level) later in this presentation. The yellow box summarizes the key point -- WOLA is a set of APIs that externalizes the Local Comm cross-memory mechanism so programs outside of WAS can participate. Die WOLA Implementierung wird durch APIs realisiert, die die Local Comm Funktion zur Verfügung stellen. 22

Die WOLA Schnittstelle … mit Batch, CICS, IMS WP101xxx - Why WebSphere Application Server for z/OS Die WOLA Schnittstelle … mit Batch, CICS, IMS EJBs initiieren einen Aufruf nach WOLA mittels eines vorhandenen JCA-Adapters. Verschiedene WOLA spezifische Methoden ermöglichen Service-Aufrufe WebSphere Umgebung EJBs, die Ziel von WAS-inbound Aufrufen sind, implementieren die WOLA-eigenen Execute() und ExecuteHome() Klassen. Enterprise Java Bean (oder Servlet) Enterprise Java Bean Aufrufe nach CICS werden über die WOLA- eigenen BBO$/BBO# tasks und Transaktionen vermittelt. Das Ziel-Programm in CICS bleibt unverändert, falls es über COMMAREA oder Channel/Container aufgerufen werden kann. Ein Batch-Programm, das einen WAS aufrufen möchte, muss die WOLA APIs nutzen. WOLA JCA Adapter WOLA Execute() ExecuteHome() Batch Umgebung CICS Umgebung CICS Program Batch Programm WOLA Module/APIs WOLA BBO$/BBO# Ein CICS Programm, das einen outbound call initiieren will, muss die WOLA APIs nutzen WOLA CICS Program WOLA Modules/APIs IMS Dependent regions WOLA IMS ESAF WOLA OTMA BMP/MPP/ IFP Eine WAS Anwendung kann eine existierende IMS Transaktion mittels WOLA über OTMA ohne Änderungen aufrufen. Die verfügbaren WOLA Module/Klassen: STEPLIB, DFHRPL, DFSESL, ola.rar and ola_apis.jar Batch CICS WAS Development Tool IMS

WOLA FIS 7.0.0.12 – IMS Support - Basics WP101xxx - Why WebSphere Application Server for z/OS WOLA FIS 7.0.0.12 – IMS Support - Basics WOLA OTMA support Eine WAS Anwendung kann eine IMS Transaktion mittels WOLA über OTMA ohne Änderungen aufrufen IMS WOLA APIs support die APIs erlauben es IMS Anwendungen in den folgenden IMS dependent regions, die WOLA APIs bidirektional zu nutzen, wenn beide auf dem gleichen z/OS System liegen Message Processing Programs (MPPs) IMS Fast path Programs (IFPs) Batch Message Programs (BMPs) Batch DL/I apps Basierend auf dem External Subsystem Attach Facility (ESAF) ‘WOLA’ subsystem – mit allen notwendigen EXITs (neue BBOAI- Module) WOLA APIs wurden erweitert, um zu erkennen, wann sie unter IMS laufen, um dann Requests an das WOLA Call ESAF exit zu leiten – und dann an WAS. Vorbereitungen für global transactions support

Relativer Vergleich von WOLA und IMS Connect WP101xxx - Why WebSphere Application Server for z/OS Relativer Vergleich von WOLA und IMS Connect relative Vorteile für… WOLA IMS-C Bi-direktional und in der Lage, vorhandene IMS Transaktionen ohne Änderungen aufzurufen Teil von WebSphere Application Server für z/OS WOLA II mit WAS z/OS 7.0.0.12 ausgeliefert, IMS als separate FMID die mit IMS ausgeliefert wird In der Lage, lokal oder remote IMS aufzurufen WOLA ist ausschließlich lokal nutzbar, IMS Connect unterstützt sowohl local mode als auch TCP-basierten Zugriff Propagation/Zuweisung von User Identity von IMS nach WAS WOLA kann User Credentials auf basis von thread-level ID in den WAS EJB container propagieren und zuweisen. Multi-segment messages WOLA über IMS OTMA unterstützt noch keine multi-segment messages. Coming soon. Global Transactions WAS nach IMS WOLA unterstützt dies noch nicht. Global Transactions IMS nach WAS Weder IMS ICAL callout noch WOLA unterstützen dies bisher. WOLA ist eine ergänzende Technologie zu IMS Connect. Beide werden weiterhin ihre Berechtigung in einer Unternehmensarchitektur haben.

Ein einfaches Use-Case Szenario WP101xxx - Why WebSphere Application Server for z/OS Ein einfaches Use-Case Szenario LPAR Eine Flat Record Datei dient als Input für das Batch Programm WAS 7.0.0.4 WOLA modules werden über die STEPLIB im Batch JCL eingebunden Das Batch Program nutzt WOLA APIs, um auf WAS zuzugreifen und das EJB aufzurufen EJB startet Transaktionen in CICS, IMS mit Two- Phase Commit (2PC) mit WAS Connector Architektur Daemon Flat record file Shared Space Cell 1 4 CICS 3 AppServer Batch Program SR CR IMS Local Comm 2 WOLA Modules RRS Let’s take a look at a very simple use case. Doing this helps us picture how this is used. The essential point here is that an existing EJB represents a business resource that’s already taking advantage of the WAS z/OS platform. Accessing that EJB from outside of WAS can be done with other technologies. But using WOLA provides a very efficient, very high-speed transfer mechanism. Dieses Bild illustriert ein einfaches Use-Case Szenario: Ein Batch Programm nutzt eine bestehende EJB, um Daten in anderen Subsysteme zu aktualisieren 26

Ein Performance-Vergleich zwischen WOLA und Web Services WP101xxx - Why WebSphere Application Server for z/OS Ein Performance-Vergleich zwischen WOLA und Web Services Ein aktueller Benchmark vergleicht ein Web Services Aufruf vom WAS ins CICS mit einer WOLA Implementierung per X-Memory. LPAR CICS Transaction Server Program WebSphere Application Server EJB SOAP/HTTP SOAP/HTTP The first comparison test is an inbound to WAS from CICS using web services. Please read the notes … this test was done to establish a framework for performance comparisons. It was not intended to represent “real life” or make any suggestions about the merits of web services. 27

Relativer Durchsatz für eine 100 Byte große Nachricht WP101xxx - Why WebSphere Application Server for z/OS Relativer Durchsatz für eine 100 Byte große Nachricht Ein Vergleich des relativen Durchsatzes basierend auf dem Austausch einer 100 Byte großen Nachricht: Relativer Durchsatz Basiererend auf den CPU and Speicher Ressourcen des Benchmark Systems WOLA Relativer Durchsatz … im Verhältnis zur Web Services Baseline WOLA hatte einen 6X höheren Durchsatz Web Services Normalisierter Durchsatz von “100” Here’s the first test … inbound to WAS from CICS using web services with a message size of 100 bytes. The application in WAS is a simple echo application. The web services run was able to achieve some level of throughput based on the specifics of the server. Whatever the absolute number is doesn’t really matter because our test is focused on relative comparisons. So the web services data was “normalized” to a value of 100 and the WOLA throughput number adjusted proportionally. We see the result. Using the exact same server platform, WOLA was able to achieve six times the throughput. How is that possible? Go back to our earlier pictures about Local Comm and cross-memory transfer. With WOLA there’s no network, no TCP stack invocation, no XML parsing, etc. Does this mean WOLA replaces web services? Absolutely not … web services plays an important role in a service oriented architecture. But does this mean that there may be cases where WOLA makes sense given the application requirements? Yes. That is the message we are trying to send. Wieso? Kein Netzwerk, kein XML Erstellung, kein XML Parsing, etc. Small Messages (100 bytes) Performance measurements are dependent on many factors. Results vary. No guarantee of performance is implied by this chart 28

Neues Redpaper über WOLA WP101xxx - Why WebSphere Application Server for z/OS Neues Redpaper über WOLA

WP101xxx - Why WebSphere Application Server for z/OS