Was ändert sich im Vergleich zu Version 1.0?

Präsentation zum Thema: "Was ändert sich im Vergleich zu Version 1.0?"—  Präsentation transkript:

1 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

2 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

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

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

5 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

6 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

7 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

8 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

9 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

10 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

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

12 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

13 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

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

15 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

16 Ü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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 Fragen? – Diskussion? Karlheinz Hartkorn Pascal Meyer
Anwendungsentwicklung Technische Architektur 0721 / 4004 – 14 59 Pascal Meyer 0721 / 4004 – 28 34

27 Ihr IT-Partner Vielen Dank