© 2010 IBM Corporation
IBM System z Software
Mehrwert von WebSphere Application Server auf IBM System z
Andreas Gröschl IT Specialist for WebSphere on z/OS
© 2010 IBM Corporation2
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)
Application Server
IBM i IBM AIX Linux
IBM System z Mainframe
Application Server
z/OS Linux
Other
Application Server
Solaris
Open Standard Interfaces and Java Specifications
Platform-specific exploitation below the open standards
95%+ gemeinsamer Code
Der Rest ist plattformspezifischer Code.
© 2010 IBM Corporation
Hardware Architecture
WebSphere Application Server for z/OS
Platform Operating System (z/OS)
Integration
Business Fabric
WSRR PortalESB
Process Server
WLM RRS RACF XCF
Welche Produkte basieren auf WebSphere Application Server für z/OS?
© 2010 IBM Corporation4
Gibt es etwas zu beachten beim Designen und Schreiben von Java code, der auf WebSphere z/OS laufen soll?
Antwort:
No!No!Java ist Java.
Der Vorteil eines Applikations-servers basierend auf offenen
Standards ist die Reduktion der Plattformabhänigkeiten
Unterscheidet sich Java auf dem Mainframe?
© 2010 IBM Corporation
z/OS
Distributed
In anderen Worten – Das gleiche “Look and Feel“.
Welche Admin Console ist welche?
© 2010 IBM Corporation
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,diagnosticProvider=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,diagnosticProvider=true,version=6.1.0.9,type=DeploymentManager,mbeanIdentifier=DeploymentManager,cell=Dmgr01,spec=1.0'
Wsadmin Skripting auf z/OS vs. distributed
© 2010 IBM Corporation7
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:
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)
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
Mehrwerte von WebSphere auf z/OS
© 2010 IBM Corporation8
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
zVM
IFL
Linux for System z
System z HardwareLogically Partitioned
zOS
z/OSGuest
WebSphere Application Server
für Linux
WebSphere Application Serverfür z/OS
GuestIFLzOS
Coupling Facility
LPAR or CEC
Parallel Sysplex
1
2
3 4
5
Linux for System z als eigene LPARMö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 GastSehr weit verbeitet. Diese Variante bietet exzellente Virtualisierung mit zVM) and Linux und läuft auf dem IFL.
z/OS als zVM GastEin 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 UmgebungWAS 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 UmgebungDas 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 z/OS Design und Implementierung nutzt die Sysplex Fähigkeiten aus.
© 2010 IBM Corporation9
Security Fewer points of intrusionResilience Fewer Points of FailurePerformance Avoid Network LatencyOperations Fewer parts to manage Environmentals Less Hardware
Utilization Efficient use of resourcesScalability Batch and Transaction ProcessingAuditability Consistent identity Simplification Problem Determination/diagnosisTransaction Integrity Automatic recovery/rollback
Client
Client
Client
1st Tier 2nd Tier 3rd Tier
AppServer
AppServer
z/OSDatabase
Server
Networked Web ServingNetworked Web Servingvorher
Multiple Data Copies
Potentielle Vorteile von Konsolidierung von Anwendungen und Daten
Client
Client
Client
1st Tier
2nd Tier
IMSCICS
DB2
Standard CP
nachher
Integrated z/OS Application & Database Servicing
z/OS
DataPower
WAS
zAAP IFL
Linux
Integrated Application & Database Server
Single Data View
Die Konsolidierung einer Multi-Tier Architektur
© 2010 IBM Corporation10
Präsentations-logik
Geschäfts-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% reduziertum 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
Der Vorteil der Datennähe: Ein PoC aus der Transport-Industrie
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
Präsentations-logik
Geschäfts-logik
Daten-logik
Distributed
© 2010 IBM Corporation
WAS V6.1
JDBC Type 4
Linux
DB2 V8.1
DD
F
z/OS
4 CPUs(32% busy)
4 CPUs (98% busy)
z Series Server : z9-EC, 8 x 1.7 GHz, 64 GB RAM
DB2 V8.1
DD
F
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
z/OS
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
unterschiedliche Maschinen unterschiedliche LPARs gleiche LPAR
150Transaktionen pro Sekunde
160Transaktionen pro Sekunde
243Transaktionen pro Sekunde
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.
Quelle: WebSphere z/OS – The Value of Co-Location Benchmark
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101476
+ 62%
Ergebnis eines WebSphere z/OS Co-location Benchmarks
© 2010 IBM Corporation12
LPAR
Die Nutzung von lokalen Cross-Memory KonnektorenImmer wenn WebSphere und weitere Zielsysteme wie DB2, CICS und MQ auf einer LPAR liegen, kann von lokalen Konnektoren profitiert werden. Datenzugriff:
CR SR
AppServer
DB2JDBC Type 2
CICSCTG Local
MQBindings
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 OverheadLokale Kommunikation:Used for IIOP flows between servers on the same LPAR.
Vorteile:
• Die lokale X-memory Kommunikation benutzt keinen TCP/IP Stack
• Vermeidung von SSL Overhead
• Sehr schnell, sehr sicher
LPARLPAR memory
CR SR
AppServer
CR SR
AppServer
Cross Memory COMM
Eine Erweiterung: Die neuen
Optimized Local Adapters (WOLA)…
© 2010 IBM Corporation13
AppServer (WAS z/OS)
Servant Region
JVM
App App
WLM Queues
Servant Region
JVM
App App
90% Requests in 0.2 Sekunden
90% Requests in 1 Sekunde
Control Region
JVM
Request Gold Kunde
Request Silber Kunde
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.
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.
Bessere Verfügbarkeit durch einen eingebauten Mini-Cluster
© 2010 IBM Corporation14
Intelligente Priorisierung von unterschiedlichster Workload auf z/OS
Klassifizierung und Prioriserung von einzelnen Transaktionen durch den z/OS Workload Manager (WLM) möglich.
Controller Region Servant Region
JVM
Application(s)
Servant Region
JVM
Application(s)
_____
_____
_____
_____
_____
_____
_____
WLM
Einkommende Requests
• HTTP / HTTPS• IIOP• MDB
21
3
Pull
Pull
4
Niedrigere Priorität o. unklassifiziert
Hohe Priorität
Hohe Priorität
Niedrigere Priorität
Der JVM werden mehr System Ressourcen zugewiesen
Dieser JVM werden weniger System Ressourcen zugewiesbaden
5
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.
© 2010 IBM Corporation15
FRCA - Fast Response Cache Accelerator
FRCA ist ein sehr effizienter Cache, der vom TCP/IP Stack im z/OS zur Verfügung gestellt wird.
FRCA Funktionalität
FRCA API
TCP Stack
Physischer Adapter
In memory cache
(Data Space)
z/OS Operating System
Network
User System or Program
Benutzer
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.
Nutzung des FRCA
Exits
© 2010 IBM Corporation16
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.
CR SR
AppServer
General Processor
ohne zAAPs
CR SR
AppServer
mit zAAPs
General Processor
zAAP Processor
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.
Die komplette Workload wird vom CP
abgearbeitet
Non-Java Workload läuft auf dem CP, Java-Workload dagegen auf
dem zAAP
= Non-Java = Java
Work:
Abhängig von den Anwendungen können bis zu 90% der WebSphere Workload auf dem zAAP ausgelagert werden.
Der Mehrwert von zAAP Prozessoren
© 2010 IBM Corporation
Voraussichtlicher z10 CPU-Bedarf – Projektion und Vergleich
Projektion der Testergebnisse auf die z10 (fester Faktor)
Summe CP zAAP zIIP
KVNeu zWAS 2.63 0.62 1.63 0.39
Summe CP zAAP zIIP
KVNeu zWAS 1.75 0.11 1.63 0.02
KVNeu dWAS 3.0 (Auslastung zu 70%)
Vergleich zu System p (Kaufmännische Betrachtung)
Realbedarf System z bei gleichem Durchsatz und Antwortzeit wie System p
KVNeu WAS System p 0.88 0.51 0.00 0.37(DB2 Hostanteil)
Gleicher Durchsatz und Antwortzeit wie bei System p (hochgerechnet)
Maximalwerte der Testdurchläufe
Vergleichbarkeit mit System p ist gewährleistet
zWAS benötigt 42% weniger CPU Ressourcen
Plattformvergleich im Versicherungsumfeld – WAS distributed vs. WAS z/OS – Eine Anwendung basierend auf Innovas HI
© 2010 IBM Corporation18
Kosten für das erste Jahr Kosten für Jahre 2-4
TCO Studie von einem großen IT-Dienstleister im Finanzsektor in Deutschland über WebSphere Application Server auf z/OS
© 2010 IBM Corporation19
Startpunkt – Wiederbenutzung von bestehenden WAS EJB AssetsMehr und mehr Kunden suchen eine Möglichkeit WAS z/OS EJB Assets aus bestehenden Batch Programmen oder aus anderen Subystemen wie CICS aufzurufen
WebSphere z/OS
EJB Assets
Batch Programs
CICS
Mehr und mehr Geschäftslogik wird in Form von EJBs
implementiert
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.
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.
© 2010 IBM Corporation
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
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.
CR SR
AppServer
CR SR
DMGRDaemon
Shared Space
WOLACICSAssembler/Cobol/PLI/C or C++
z/OS BatchAssembler/Cobol/PLI/C or C++
UNIX Systems ServicesAssembler/Cobol/PLI/C or C++
Airline Control SystemAssembler/Cobol/PLI/C or C++
WOLA
WOLA
WOLA
bi-direktionale Pfade!
Cross memory “Local Comm”
CR SR
AppServer
IMSAssembler/Cobol/PLI/C or C++
WOLA
Neu in 7.0.0.12!
LPAR
© 2010 IBM Corporation21
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.
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.
CR SR
DMGRDaemon
Shared Space
CR SR
AppServer
CR SR
AppServer
Cross memory “Local Comm”
LPAR
CR SR
AppServer
CR SR
AppServer
Daemon
CR
Shared Space
Data Buffers
Data Buffers
Server Storage
Server Storage
Data Buffers
Above the bar owned by Daemon
© 2010 IBM Corporation22
Ein High-Level Überblick der WOLA Implementierung
Local CommExternal Address SpaceAssembler/Cobol/PLI/C or C++
WebSphere z/OS Cell auf einer LPAR
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.
STEPLIB DD DSN=hlq.WOLA.LOADLIB
Die WOLA Implementierung wird durch APIs realisiert, die die Local Comm Funktion zur Verfügung stellen.
Shared Space
Daemon
AppServer
EJBsJCA
External
WOLA APIs
Der Daemon verwaltet den gemeinsamen above-the-bar Storage, in dem die WOLA Registierungen erfolgen und die Daten
ausgetauscht werden
© 2010 IBM Corporation23
Die WOLA Schnittstelle … mit Batch, CICS, IMS
Enterprise Java Bean(oder Servlet)
Enterprise Java Bean
WOLA Execute()ExecuteHome()
WOLA JCA Adapter
WOLA
CICS Program
CICS Program
WOLA BBO$/BBO#
WOLA Modules/APIs
Batch Programm
WOLA Module/APIs
WebSphere Umgebung
CICS UmgebungBatch Umgebung
EJBs initiieren einen Aufruf nach WOLA mittels eines vorhandenen
JCA-Adapters. Verschiedene WOLA spezifische Methoden ermöglichen
Service-Aufrufe
EJBs, die Ziel von WAS-inbound Aufrufen sind, implementieren die WOLA-eigenen Execute() und ExecuteHome() Klassen.
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 CICS Programm, das einen outbound call initiieren will, muss die WOLA APIs nutzen
Ein Batch-Programm, das einen WAS aufrufen möchte, muss die
WOLA APIs nutzen.
Die verfügbaren WOLA Module/Klassen: STEPLIB, DFHRPL, DFSESL, ola.rar and ola_apis.jar Batch CICS WAS Development ToolIMS
BMP/MPP/ IFP
WOLA IMS
ESAF
IMS Dependent regionsWOLAOTMA
Eine WAS Anwendung kann eine existierende IMS Transaktion mittels WOLA über OTMA ohne Änderungen aufrufen.
© 2010 IBM Corporation24
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
© 2010 IBM Corporation25
relative Vorteile für…
WOLA IMS-C
Teil von WebSphere Application Server für z/OSWOLA 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 aufzurufenWOLA 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 WASWOLA kann User Credentials auf basis von thread-level ID in den WAS EJB container propagieren und zuweisen.
Bi-direktional und in der Lage, vorhandene IMS Transaktionen ohne Änderungen aufzurufen
Multi-segment messages WOLA über IMS OTMA unterstützt noch keine multi-segment messages. Coming soon.
WOLA ist eine ergänzende Technologie zu IMS Connect. Beide werden weiterhin ihre Berechtigung in einer Unternehmensarchitektur haben.
Global Transactions WAS nach IMS WOLA unterstützt dies noch nicht.
Global Transactions IMS nach WASWeder IMS ICAL callout noch WOLA unterstützen dies bisher.
Relativer Vergleich von WOLA und IMS Connect
© 2010 IBM Corporation26
Ein einfaches Use-Case Szenario
1. Eine Flat Record Datei dient als Input für das Batch Programm
2. WAS 7.0.0.4 WOLA modules werden über die STEPLIB im Batch JCL eingebunden
3. Das Batch Program nutzt WOLA APIs, um auf WAS zuzugreifen und das EJB aufzurufen
4. EJB startet Transaktionen in CICS, IMS mit Two-Phase Commit (2PC) mit WAS Connector Architektur
Daemon
Shared Space
CR SR
AppServerCICS
IMS
RRS
Flat record file
Batch Program
LPAR
Cell
14
WOLA Modules
2
3
Dieses Bild illustriert ein einfaches Use-Case Szenario: Ein Batch Programm nutzt eine bestehende EJB, um Daten in anderen Subsysteme zu
aktualisieren
Local Comm
© 2010 IBM Corporation27
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.
CICS Transaction Server
Program
WebSphere Application
Server
EJB
LPAR
SOAP/HTTP
SOAP/HTTP
© 2010 IBM Corporation28
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:
Small Messages(100 bytes)
Relativer DurchsatzBasiererend auf den CPU and Speicher Ressourcen des Benchmark Systems
Web ServicesNormalisierter Durchsatz von
“100”
WOLARelativer Durchsatz … im Verhältnis zur Web
Services Baseline
WOLA hatte einen 6X höheren Durchsatz
Wieso? Kein Netzwerk, kein XML Erstellung, kein XML Parsing, etc.
Performance measurements are dependent on many factors. Results vary. No guarantee of performance is implied by this chart
© 2010 IBM Corporation29
Neues Redpaper über WOLA
© 2010 IBM Corporation30