Coherence und CNS-Ablösung … Triton 2 Coherence und CNS-Ablösung … Roman Koutny | Alex Trischler, AEW6TA | JBFOne 2009

Ziel dieses Vortrags Überblick über Coherence und die Integration in JBF Ausblick auf das Caching von Services Information über den aktuellen Stand der CNS-Ablösung JBFQueueing – der erste Kontakt JBFImsConnect – um Anschluss wird gebeten Ausblick Filetransfer

Agenda Coherence Caching von Services CNS-Ablösung JBFQueueing JBFImsConnect Ausblick Filetransfer

Agenda Coherence Caching von Services CNS-Ablösung JBFQueueing JBFImsConnect Ausblick Filetransfer

Coherence Coherence ist ein verteilter Cache, der die zu speichernden Objekte auf beliebig viele JavaVMs verteilen kann Trennung zwischen logischem und physischem Objekt Zugriff erfolgt transparent für die Applikation Für jedes Primärobjekt wird ein Backupobjekt angelegt

Coherence Beendet sich eine VM, werden für die betroffenen Objekte neue Primär- und Backupobjekte erzeugt Lastverteilung! Ausfallsicherheit!

Coherence: Integration in JBF Die „distributedcache“ API ist in JBF Bootstrap-Teil verankert umfasst Jar Files, Konfigurationsfiles und Coherence aktuell ist die Nutzung auf JBF und CBx eingeschränkt app jbf xbf …. … jbf-bootstrap-distributedcache-api JarFile coherence_3.5.1 Jar File WEB-INF lib … fiducia-cache-config.xml tangosol-coherence-override.xml classes

Coherence: Nutzung Wo wird Coherence aktuell im Framework genutzt? CBx Organisationseinheiten Bankinformationen Bedienersuche Ikesa JBF PSF (Property Storage Facility): Property Objekte werden gecached AAF (Authentication and Authorization Facility): Anmeldeinformationen werden gecached; Austausch über Messaging und PSF entfällt ACE (Asynchroneous Coupling Engine): Subscriber werden gecached; Mechanismus über Multicastpakete und Synchronisation mittels http entfällt SessionFailover: Sessiondaten werden in Coherence gehalten; Anmeldesession kann von einem anderen Tomcat übernommen werden

JBF Forschungsthemen Was ist das denn ...? Beispiele für Themen der letzten Jahre Multiversionsfähigkeit von Services ESB Vereinheitlichung des Anmeldeverfahrens Weiterentwicklung DAM Architektur XView für alle JBF/XBF-Anwendungen Überlegung: wie und wo kann Coherence selbst noch genutzt werden? Performanceverbesserung, geringere DB Last und weniger Connections und MIPS Einsparung am Host:  Forschungsthema „Caching von Services“

Agenda Coherence Caching von Services CNS-Ablösung JBFQueueing JBFImsConnect Ausblick Filetransfer

Caching von Services I Was ist damit gemeint? natürlich nicht, dass Service-Klassen im Cache vorgehalten werden … auch nicht, dass Service-Aufrufe in den Cache gestellt werden Die Response-Objekte eines ausgeführten Service-Aufrufs werden in den Cache gelegt! erfolgt derselbe Aufruf erneut, wird das Response Objekt sofort aus dem Cache an den Aufrufer zurückgegeben kein weiterer Overhead mehr im Server notwendig keine weiteren DB-Zugriffe keine weiteren Hostzugriffe eventuell Einsparungen bei Serialisierung /Deserialisierung, wenn Folgeaufrufe wegfallen kein Mapping oder Ähnliches bei der Serviceausführung

Caching von Services II Was braucht man für das „Caching von Services“? einen eindeutigen Key für den Service Aufruf und die Service Response Definition mit Hilfe einer Erweiterung im ServiceDeskriptor <?xml version="1.0" encoding="ISO-8859-1"?> <service:service xmlns:service="http://www.rbg.de/jbf/service/service" service:name="de.bapagree...." ... service:cachable="true" ....> <service:request service:type="de.bapagree...." /> <service:response service:type="de.bapagree...." /> <service:command service:type="de.bapagree...." /> ... </service:service> @CacheContext("CustomerId") public interface DemoRequest extends ServiceRequest { public void setValue(int val); @KeyField("Value") public int getValue(); public void setText(String text); @KeyField("Text") public String getText(); }

Caching von Services III Die Caching-Schnittstelle muss zentral im Framework implementiert werden. Am sinnvollsten im ServiceContainer! Fragestellung: Kann jeder Service gecached werden? Oder ist hier von Fall zu Fall zu unterscheiden? dies hängt vom Service selber ab dies kann nicht vom Framework selbst entschieden werden der Entwickler/das Projekt muss dies entscheiden! Services, die Filtermechanismen verwenden, können nicht auf einfache Art und Weise umgestellt werden, da die Filter-Kennzeichen von Aufruf zu Aufruf unterschiedlich sein können – trotz gleicher Schlüsselwerte im Request Werden bestimmte Felder anhand von Berechtigungen aus der Response herausgefiltert, können diese ebenfalls nicht einfach im Cache abgelegt werden Lösung  Kaskadierte Services Aufgemerkt!

Caching von Services IV Oracle JASS ServiceContainer Aufruf mit Filter-KZ Aufruf ohne Filter-KZ Service Non-cachable Service cachable API Response filtern Filter-KZ Host DB2 IMS Response Response Response Response Response Response Response Coherence

Caching von Services V Erweiterungen für den Betrieb Admin-Konsole, um Cache gezielt bereinigen zu können Blacklist-Mechanismus, um problematische Services zur Laufzeit(!) vom Caching auszunehmen Gruppierung von Services; da ein Service, der Daten ändert, durchaus Response- Objekte im Cache ungültig machen kann. Beim Aufruf dieses Services müssen alle Objekte dieser Gruppe automatisch aus dem Cache entfernt werden. Die Gruppenzugehörigkeit kann ebenfalls im ServiceDeskriptor eingetragen werden Delete Service Update Service Read Service Insert Service Coherence ServiceCache Gruppe ServiceXY ResponseXY read drop

Caching von Services VI Offene Fragen … Wie geht man mit Änderungen im Cache mittels BatchJobs und anderen Programmen um, die nicht den ServiceContainer nutzen? Wie erkennt man, dass sich am Datenbestand etwas geändert hat? Wie lange sollen die Responses im Cache verbleiben?  Lösung mit Hilfe eines „Invalidators“! JASS Fremdsysteme change Oracle Cache Host DB2 IMS BatchJobs change

Caching von Services VII Der Invalidator Zeitliches Invalidieren nach einer bestimmten Verweildauer im Cache zu einer vorgegebenen Uhrzeit zu lesende Daten auf Update Timestamp oder ähnliches überprüfen und dann die Daten im Cache gegebenenfalls verwerfen Implementierung muss vom Service-Ersteller kommen, weil die Update- Mechanismen von Service zu Service unterschiedlich sind Eintrag (Klassenname) erfolgt beispielsweise im ServiceDeskriptor <?xml version="1.0" encoding="ISO-8859-1"?> <service:service xmlns:service=……………….. <service:request ………………….. … <service:invalidator service:type=„de.bapagree.abc.service.impl.comp.HastaLaVistaInvalidator“ /> </service:service>

Caching von Services/Zusammenfassung Again what learned! Caching von Services (Responses) unterscheidet sich wesentlich von der Zwischenspeicherung gelesener Daten Großes Potential – Großes Risiko; Service-Caching gibt es nicht gratis! Qualitätssicherungsverfahren müssen etabliert werden! Administration wird zur Laufzeit notwendig sein! Häufigste/rechenzeitintensivste Services sind zuerst umzustellen; hier ist natürlich der größte Benefit zu erwarten Realisierung 2011?

Agenda Coherence Caching von Services CNS-Ablösung JBFQueueing JBFImsConnect Ausblick Filetransfer

CNS-Ablösung Der CNS (Cross-Network-Server) ist ein in C++ geschriebenes Programmpaket, das als eigene Instanz auf allen JBF-Servern zusätzlich zum Tomcat läuft Das Einsatzgebiet des CNS (Cross-Network-Server) ist schwerpunktmäßig der Datenaustausch zwischen JBF-Server und Host Hierfür werden folgende Dienste angeboten ImsConnect Websphere MQ Filetransfer (AFTx) Die Kommunikation zwischen JBF-Server und CNS erfolgt über RPC Mit BAP 4.0 wurde die Integration der CNS-Dienste in JBF beauftragt, um die Ablösung des CNS zu ermöglichen

Der weite Weg zum Host/Umsteigehaltestelle CNS BAP HTTP JBF-Server TCPIP RPC CNS Host

Was kommt mit BAP 4.0 Websphere MQ für die Nutzung von Websphere MQ aus JBF wird das neue Modul JBFQueueing bereitgestellt ImsConnect Das neue Modul JBFImsConnect dient als Client-Implementierung für den Aufruf von IMS-Transaktionen

Der weite Weg zum Host/Direktverbindung BAP HTTP JBF-Server TCPIP Host

Agenda Coherence Caching von Services CNS-Ablösung JBFQueueing JBFImsConnect Ausblick Filetransfer

JBFQueueing JBFQueueing ist ein neues Modul in JBF. Es dient als API, um aus JBF auf Websphere MQ zuzugreifen Die grundsätzliche Arbeitsweise von JBFQueueing entspricht weitestgehend der API von IBM Zur Vereinfachung der Arbeit und zur Erhöhung des Komforts gibt es noch zusätzliche Fassaden, über die bestimmte Kommunikationsschritte mit bestimmten Defaults einfach abgebildet werden können Die Verbindungen zu den Queue-Managern werden von JBFQueueing im Connection- Pool „geparkt“ und bei Bedarf wiederverwendet Die Konfiguration der Verbindungsdaten für den Connect zu den Queue-Managern sowie die Eigenschaften des Connection-Pools sind in den Steuertabellen im Oracle hinterlegt

Architektur von JBFQueueing Native MQ Java-API AbstractTS.getServiceAccess. processTransaction(MQServiceInputImpl) JBFQueueingHostProcessor Websphere MQ Java API Native (API) Connection- Pool JBFQueueing Connection- Konfig Fassaden (API) Bietet nahezu die volle Funktionalität. Ist zusätzlich um Logging und Connection-Pooling erweitert

Alles wird anders … und die Anwendungen? Der JbfQueueingHostProcessor dient als Glue-Code, um völlig transparent für die Anwendungen mit Websphere MQ direkt vom JBF-Server zu kommunizieren Er tritt nie direkt mit den Anwendungen in Kontakt sondern wird aktiviert durch den klassischen Aufruf: AbstractTS.getServiceAccess.processTransaction(MQServiceInputImpl ) Für die Anwendungen sollte durch die Umstellung lediglich Testaufwand entstehen

Agenda Coherence Caching von Services CNS-Ablösung JBFQueueing JBFImsConnect Ausblick Filetransfer

JBFImsConnect JBFImsConnect ist ein internes JBF-Modul, um aus JBF heraus IMS-Transaktionen aufzurufen. Es löst mit BAP 4.0 ff. die bisherige CNS-Implementierung ab Designziele Transparenz für Anwendungen Performance Einfache Konfiguration Neues Protokoll Trennung von Anwendungsdaten und Protokolldaten Vorrichtungen für Agenturanwendungen Lose Kopplung zum JBF Einsatz in non-JBF Umgebungen möglich Entwicklertests von Transaktionsservices ohne Tomcat

Architektur von JBFImsConnect Server Anwendung, JBF alternativer ConfigProvider JBFImsConnectProcessor DB (controlapi) JBFImsConnect Client JBF Default ConfigProvider TCP/IP Host OTMA Imsconnect Server mit Exit *NBS002* IMS mit FU075U

JBFImsConnect - Performance Persistente Sockets einmal geöffnete Sockets werden nach Möglichkeit wiederverwendet dadurch Vermeidung des Overheads durch Verbindungsauf- und -abbau Verkürzung der Strecke zum Host CNS fällt weg Weglassen von Low Values am Ende der Messages JES Compression Entlastung von Netz und IO aber: zusätzlicher MIPS-Bedarf? In Java IO über NIO Verwendung von Concurrency

Einbindung in die Subsystemarchitektur BAP/JBF,e-Banking,agreeSB,ApplSrv,DB-Srv BAP/JBF,e-Banking,agreeSB,ApplSrv,DB-Srv zentrale Anwendungen RZ Karlsruhe GPLEX PPLEX IMS - Connect IMS - Connect IMS - Connect IMS - Connect IMS - Connect IMS - Connect IMS - Connect IMS - Connect IMS - Connect IMS - Connect agree B G MQ0B agree F agree H agree I NIB E agree 1 agree 2 agree 3 agree 7 NIB 8 3 6 M P F O W X Y B C R U V 1 2 4 5 J 7 8 9 A D L Q S T Z E H I K N MQ0F MQ0H MQ0I MQ0E MQ01 MQ02 MQ03 MQ07 MQ08

JBFImsConnect - Konfiguration Vollständig über Controlapi keine Konfigurationsdateien einheitliche Konfiguration für alle Portale, RZBKs bei Bedarf dynamisch anpassbar JBF00_AGREEBASIS_T00 zur Ermittlung des Subsystems JBF00_IMSCONNECT_T00 Neu, enthält pro Subsystem: Hostname und Port des Imsconnect Servers Userid und Kennwort Parameter zur Poolsteuerung

JBFImsConnect - Mengengerüst Stand Juli 2009: 60 Mio. Transaktionen / Tag Input Messages (IMS1, 14.09.2009 um 10-11 Uhr) Max. Messagelänge ca. 2 MB 99% aller Messages < 26 KB 95% aller Messages < 12 KB Output Messages (IMS1, 14.09.2009 um 10-11 Uhr) Max. Messagelänge ca. 2,1 MB 99% aller Messages < 110 KB 95% aller Messages < 24 KB Aber: mehrere Input/Output Messages pro Transaktion möglich Zahlen wurden in der Implementierung berücksichtigt (Puffergrößen, Low Values, Komprimierung)

JBFImsConnect - Protokoll Req_0000000001 : ArraySize: 1000 Start: 0 End: 657 Bytes: 657 0 - 100 j *NBS002* À 01Ø è FU119N10DATASTORLTERM999 RACFUID PASSWORD 000901005dcefff500000010444444440600ff80000000000500cefffdffcceceedddecddfff00000000dcccecc4dceeeddc 00210c00c522002c000000000000000004000100000000000480641195104131236933594999111010009136494071226694 100 - 200 YC8MC66 88445555 N 4 4 4 ecfdcff4ffffffff0000000000000000000001d04000f000f000f00000000000000001111111111111111222222222222222 838436608844555500000000000000002900015000014001400140123456789abcdef0123456789abcdef0123456789abcde 200 - 300 â àáãåçñÄ éêëèíîïì Ü *  ÀÁÃÅÇÑö øÉÊËÈÍÎÏÌ Øabcdefghi ðýþ jk 2333333333333333344444444444444445555555555555555666666666666666677777777777777778888888888888888999 f0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012 300 - 400 lmnopqrªºæ Æ µßstuvwxyz ÐÝÞ äABCDEFGHI ô òóõüJKLMNOPQR û ùúÿÖ STUVWXYZ Ô ÒÓÕ0123456 9999999999999aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbccccccccccccccccddddddddddddddddeeeeeeeeeeeeeeeefffffff 3456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456 400 - 500 789 Û ÙÚ â àáãåçñÄ éêëèíîïì Ü fffffffff0000000000000000111111111111111122222222222222223333333333333333444444444444444455555555555 789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789a 500 - 600 *  ÀÁÃÅÇÑö øÉÊËÈÍÎÏÌ Øabcdefghi ðýþ jklmnopqrªºæ Æ µßstuvwxyz ÐÝÞ 555556666666666666666777777777777777788888888888888889999999999999999aaaaaaaaaaaaaaaabbbbbbbbbbbbbbb bcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcde 600 - 657 äABCDEFGHI ô òóõüJKLMNOPQR û ùúÿÖ STUVWXYZ Ô ÒÓÕ0123 bccccccccccccccccddddddddddddddddeeeeeeeeeeeeeeeeffff0000 f0123456789abcdef0123456789abcdef0123456789abcdef01230400

Ausschluss von Exoten bei der neuen Kommunikation in Stufe 1 IMSConnect Es gibt noch alte Transaktionen (Baujahr ca. 1980) mit 3stelligen Transaktionscodes. Für diese gibt es in der Kommunikation sowohl auf dezentraler als auch auf zentraler Seite an vielen Stellen Sonderverarbeitung. Eine spezielle Codierung in der Schnittstelle stellt sicher, dass in BAP4.0 nur die Transaktionen, die dem Standard entsprechen, über den neuen IMSConnect-Client abgewickelt werden. Durch einen speziellen Logger, der im Upgrade 4/09 ausgebracht wird, werden alle noch produktiv genutzten Exoten ermittelt. Für BAP4.2 wird dann deren Umstellung auf den agree Standard beauftragt.

Integration der neuen Kommunikation ins Framework (BAP4.0) HostServiceProcessorFactory Entry für alle Transaction-Services (MQ und IMSConnect) - übergibt den Request dem ersten Prozessor der sich „verantwortlich fühlt“ 1 IMSConnectProcessor Neue Prozessoren für IMSConnect und MQ fühlen sich (durch die entsprechende Implementierung) für die Standard-Anwendungsfälle verantwortlich prüfen zusätzlich die Blacklist um evtl. einzelne Anwendungsfälle von der neuen Verarbeitung auszuschließen 2 JBFQueueingHostProcessor isResponsible() Blacklist DB-Table 3 TSFWHostProcessor Bestehende Prozessoren für die Ansteuerung des CNS - bekommen alle Requests, die von den neuen Prozessoren abgewiesen wurden 4 TSFWMQProcessor

Agenda Coherence Caching von Services CNS-Ablösung JBFQueueing JBFImsConnect Ausblick Filetransfer

Filetransfer (AFTx) – Wo stehen wir heute? Für den Filetransfer sind heute zwei Produkte im Einsatz AFTS (Send) Host  Client AFTR (Receive) Client Host Beide Produkte verwenden völlig unterschiedliche Techniken und Kommunikationswege, um die Dateien zwischen den Plattformen zu bewegen AFTS verwendet einen Batchjob-basierten Ansatz, um mittels Connect-Direct (CDI) die Dateien vom Mainframe auf ein NFS-Share zu übertragen AFTR verwendet eine DB2-Table zur Auftragssteuerung und versendet die eigentlichen Daten mittels Websphere MQ zum Mainframe

Überblick AFTS (Send) CDI CDI MF OPC OPC NFS JBF CNS BAP HTTPS 8844 8845 8844 4711 NFS BAP HTTPS JBF CDI CNS Anwendung HC006A FU081U FU275U ZIP CDI MF OPC Anwendung FU081U OPC 3 2 1

Überblick AFTR (Receive) BAP HTTPS JBF MQ-Put DB2-Insert CNS MQ-Queue Status-Tabelle 8844 MF Ini- Datei 8845 MF102M 4711

Ausblick: Filetransfer neu Der neue Filetransfer soll über Datenbank-Lob (Large-Object) realisiert werden Diese Technik soll für beide Richtungen (also Host  Client / Client  Host) in Einsatz kommen In der Datenbank sollen auch alle weiteren benötigten Parameter abgelegt werden

Ausblick: Filetransfer neu (beide Richtungen) Client  Host (ehemals AFTR) Host  Client (ehemals AFTS) 8844 8845 8844 8845 BAP HTTPS LOB-Service Lob-Streaming-API JBF LOB-Tabelle 8844 8845 8844 8845 FU###! Lob-Streaming API FUXXXU MF FU081U …

Zusammenfassung Die ersten Schritte zur Ablösung des CNS sind getan Die Einführung von JBFImsConnect und JBFQueueing mit BAP4.0 stellt einen ersten großen Meilenstein dar Erste Konzepte für die den neuen Filetransfer sind erstellt Jetzt müssen wir uns den Herausforderungen der Details in einem gewachsenen System stellen

Fragen? – Diskussion? Roman Koutny Alexander Trischler Anwendungsentwicklung Technische Architektur Roman.Koutny@fiducia.de 089/9943-3357 Alexander Trischler Alexander.Trischler@fiducia.de 0721/4004-5139

Ihr IT-Partner Vielen Dank