Was ändert sich im Vergleich zu Version 1.0? Architektur HORIZON 1.1 Was ändert sich im Vergleich zu Version 1.0? Pascal Meyer / Karlheinz Hartkorn, FIDUCIA IT AG AEW6TA | JBFOne 2008

Ziel dieses Vortrags Darstellung der Weiterentwicklung der HORIZON-Architektur in diesem Vortrag soll das Delta zwischen der Architektur Version 1.0 zu Version 1.1 und die Motivation dazu vermittelt werden

Agenda Motivation für die Veränderungen Architektur-Entscheidungen Die DB2-Infrastruktur

Agenda Motivation für die Veränderungen Architektur-Entscheidungen Die DB2-Infrastruktur

Motivation der Veränderungen die neue Strategie „agree plus“ neue fachliche Strukturierung des agree-Kernsystems getrieben von Anforderungen des Marktes die Strategie HORIZON Systemerneuerung auf neuer Infrastruktur Reduzierung der Plattformabhängigkeiten Mehrhersteller-Politik die Erfahrung im Betrieb setzt eine Fortschreibung der HORIZON Architektur voraus im Bereich der Koexistenz wird unterschieden zwischen sehr koexistenzintensiven Komponenten und Komponenten ohne hohe Koexistenz-Anforderungen für die koexistenzintensiven Komponenten wird DB2 als RDBMS und für die Komponenten ohne hohe Koexistenz-Anforderungen wird Oracle verwendet

Neue fachliche Strukturierung des Systems agree Basis HORIZON Infrastruktur TWS Cronacle CPS PPLEX agree 1 1 2 4 5 J agree 2 8 9 A 7 D agree 3 L Q S T Z agree 7 E H I K N NIB 8 Netz PPS KBS Schnittstellen KBS Oracle JBF-Portale z/OS-Plattform / IMS-Transaktionen Open System Plattform

Datenspeicherung in Oracle? agree Basis HORIZON Infrastruktur TWS Cronacle CPS PPLEX agree 1 1 2 4 5 J agree 2 8 9 A 7 D agree 3 L Q S T Z agree 7 E H I K N NIB 8 Netz PPS KBS Daten-Schnittstellen Funktions-Schnittstellen Oracle JBF-Portale z/OS-Plattform / IMS-Transaktionen Open System Plattform

Anforderungen aus der Koexistenz Funktions-Schnittstellen eine Funktion auf der anderen Plattform muss über Messaging gerufen werden es wird vom synchronen ins asynchrone Verarbeitungsmodell gewechselt (Neartime) im Batch muss der Folgeschritt auf der anderen Plattform mit plattformübergreifenden JOB-Ketten angesteuert werden Daten-Schnittstellen IMS-Transaktionen greifen transaktional auf Oracle-Tabellen zu Batch-Anwendungen greifen transaktional auf Oracle-Tabellen zu plattformübergreifende Datenaustausch mit Hilfe der LOB-Tabelle

Lösung für die Datenschnittstellen GPLEX PPLEX Koexistenz agreeB agreeF agree H agree I agree 1 agree 2 agree 3 agree 7 G V 3 6 F O B C TWS 1 2 8 9 L Q E H TWS W P M Y X R U 4 5 A 7 S T I K J D Z N DB2B DB2F DB2H DB2I DB21 DB22 DB23 DB27 NIB E DB2 A DWH-DB2 C JDBC-DB2 D Endkunde Bankanw. NIB 8 DB2 9 DWH-DB2 G JDBC-DB2 L Endkunde Bankanw. Cronacle Cronacle CPS PPS Oracle Oracle JBF-Portale JBF-Portale

Die HORIZON Architektur Version 1.1 Batch-Scheduler KNP agree Basis TWS JBF-Portal n JBF-Portal 2 JBF-Portal 1 Queueing-System Queueing-System PPS n PPS 2 PPS 1 CPS RDBMS RDBMS = Kommunikationsbeziehung = Control-Flow = Batch-/Stapelverarbeitung

Agenda Motivation für die Veränderungen Architektur-Entscheidungen Die DB2-Infrastruktur

Architektur-Entscheidungen (1/2) die HORIZON-Architektur unterscheidet zwei Gruppen von Datenbank-Beständen fachliche Daten technische Daten die fachlichen Daten sind mandantenbezogene Daten und andere fachliche Daten, die für die fachliche Verarbeitung gebraucht werde z.B. Bankleitzahlentabelle, Marktdaten, … die technischen Daten sind für die Steuerung und den Betrieb der HORIZON-Umgebung notwendig Sie werden unterschieden in zentrale Tabellen, die nur in einer zentralen Datenbank der Horizen-Umgebung gehalten werden können, z.B. Steuertabellen, LOB-Tabelle, …und andere technische Tabellen, die zusammen mit fachlichen Tabellen in einer Unit of Work verarbeitet werden müssen (z.B. Restart-Tabelle, GRID-Tabellen, … ); diese sind in jedem RDBMS, in dem fachliche Daten gehalten werden, vorhanden

Architektur-Entscheidungen (2/2) zentrale Tabellen werden in der Oracle-Datenbank gehalten da in jedem Plex je eine Oracle-DB betrieben wird, gibt es nach wie vor zwei HORIZONumgebungen („G“ und „P“) für die fachliche Datenhaltung werden die integrierten DB2-Systeme verwendet die Festlegung, welches DB-System verwendet wird, wird auf Ebene der Komponente getroffen bei der Datenhaltung im DB2 wird WebsphereMQ als Queueing-System verwendet bei der Datenhaltung in Oracle wird AQ als Queueing-System verwendet

Agenda Motivation für die Veränderungen Architektur-Entscheidungen Die DB2-Infrastruktur

Subsystemarchitektur HORIZON 1.1 SUN z10 zOS Agree n solaris zOS Agree1 AM4I IMS MGW OCI AMI IMS IMS TM Oracle IMS TM MQ Series MQ Series Horizon AQ OTMA DB2 OTMA DB2 IMS-Connect UDF IMS-Connect Horizon UDF … JDBC HORIZON 1.1 Portale

Übersicht Lösungsvarianten Die vorhandenen DB2-Systeme aus den Kernsystem-blöcken werden für JDBC-Workload enabled und mitverwendet Ein vorhandenes oder neu aufzubauendes zentrales DB2- System wird verwendet Die Oracle RACs werden auf Basis der Variante 1 angeglichen und die vorh. JDBC-Systeme in die Kern-systeme integriert out-of-Scope in HORIZON 1.1 mögliche langfristige Perspektive

Verwendung der DB2-Systeme aus den Kernsystemblöcken Einfache Integration des neuen Workloads Keine Anpassungen an agreeBasis erforderlich. Dadurch Komplexität, Risiko, Aufwände begrenzt lokale Zugriffe für Koexistenzphase optimal Wenig Anpassungen bei der DB2 Gestaltung Skalierbarkeit durch weitere DB2 Member gegeben Kernsystem 1 Kernsystem 2 Kernsystem n IMS IMS IMS IMS TM IMS TM IMS TM ... MQ ... MQ MQ DB2 DB2 DB2 zentrales JDBC DB2 zentraler Oracle RAC DB2 ORA HORIZON 1.1 Portale

Erweiterte Bedeutung der SteuerAPI / Steuertabellen Heimat der Daten abhängig vom Komponententyp (Oracle oder DB2) Customer-ID (welches Oracle, welches DB2) Das Datenhaltungssystem einer Komponente wird bei deren Entstehung festgelegt Erweiterte Ansteuerung der Datenbank Bei Oracle heute Plex gebunden (Stand Heute) Bei DB2 Subsystem gebunden (abhängig von Customer ID) Im Code muss hierfür keine Logik implementiert werden Die SteuerAPI übernimmt diese Ermittlungs-aufgabe: „Gib mir Connection für (Komponente, Cust-ID)“ Die Steuertabellen Zentrale Stelle Alle Topologie Informationen sind hier hinterlegt

Subsystemarchitektur HORIZON 1.1 (Beispiel Pplex) SUN z10 zOS Agree n solaris zOS Agree1 AM4I IMS MGW OCI AMI IMS IMS TM Oracle IMS TM MQ Series ORAP MQ Series Horizon AQ OTMA DB2 OTMA DB21 DB2 IMS-Connect UDF IMS-Connect Horizon UDF … JDBC HORIZON 1.1 Portale

HORIZON 1.1: Performance DB2 / MQ / IMS HORIZON Anwendungen Zugriff auf dezentraler Sicht gegen DB2 z/OS vergleichbar mit Zugriff auf Oracle oder DB2 LUW JDBC Zugriffe sind Workload balanced (Verwendung der am wenigsten ausgelasteten Instanz)  bringt auch bei Pooling Vorteile (Treiber Spezifika) Zugriff auf MQ mit Zugriff auf AQ vergleichbar agree Basis IMS zugriffe auf DB2 bleiben „lokal“: keine Latenzzeiten wegen Netz

HORIZON 1.1 Skalierbarkeit DB2 (Beispiel an Subsystem 1) HQS: agree1 CF MVS1 MVS2 IMS1 IMS-Connect IMS DBs IMB1 IMS-Connect AMI OTMA OTMA AMI MQ01 MQB1 UDF DB21 DBx1 DB11 UDF JDBC HORIZON 1.1 Portale

HORIZON 1.1: Verfügbarkeit DB2 / MQ / IMS Verlust eines DB2-Members (inkl. Zugang zu / Träger von) Nur die aktive Session an diesem Member brechen ab Neue eingehende Sessions werden von anderen Member bedient Verlust eines Subsystems: nicht möglich Verlust eines MQ-Managers: Nur aktive Nutzer an dem Manager brechen ab Neue eingehende Messages werden von anderen Manager bedient

HORIZON 1.1 Skalierbarkeit DB2: Alternativen HQS: agree1 CF ADA BAS1 MVS1 MVS2 ADA BASB1 IMS1 IMB1 IMS-Connect IMS DBs IMS-Connect AMI OTMA OTMA AMI MQ01 MQB1 DB41 MVSx MQ41 UDF DB21 DB2 DBs DB11 UDF DB31 JDBC HORIZON 1.1 Portale

HORIZON 1.1: Skalierung DB2 / MQ Erweiterung der Anzahl Member möglich Innerhalb vorhandener LPARs In zusätzlichen LPARS in Verbindung mit Erweiterung der Anzahl MQ-Manager Shared Queues

Zusammenfassung Die Lösung erfüllt die SL- Anforderungen aus IMS Sicht HORIZON 1.1 wird mit den vorhandenen DB2 Umgebungen begonnen Skalierungsvarianten werden erst bei Bedarf angewendet

Fragen? – Diskussion? Karlheinz Hartkorn Pascal Meyer Anwendungsentwicklung Technische Architektur karlheinz.hartkorn@fiducia.de 0721 / 4004 – 14 59 Pascal Meyer pascal.meyer@fiducia.de 0721 / 4004 – 28 34

Ihr IT-Partner Vielen Dank