Coherence und CNS-Ablösung …

Präsentation zum Thema: "Coherence und CNS-Ablösung …"—  Präsentation transkript:

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

2 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

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

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

5 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

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

7 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

8 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

9 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“

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

11 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

12 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 "?> <service:service xmlns: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(); }

13 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!

14 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

15 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

16 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

17 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 "?> <service:service xmlns:service=……………….. <service:request ………………….. … <service:invalidator service:type=„de.bapagree.abc.service.impl.comp.HastaLaVistaInvalidator“ /> </service:service>

18 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?

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

20 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

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

22 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

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

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

25 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

26 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

27 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

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

29 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

30 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

31 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

32 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

33 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

34 JBFImsConnect - Mengengerüst
Stand Juli 2009: 60 Mio. Transaktionen / Tag Input Messages (IMS1, um Uhr) Max. Messagelänge ca. 2 MB 99% aller Messages < 26 KB 95% aller Messages < 12 KB Output Messages (IMS1, um 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)

35 JBFImsConnect - Protokoll
Req_ : ArraySize: Start: End: Bytes: j *NBS002* À 01Ø è FU119N10DATASTORLTERM RACFUID PASSWORD dcefff ff cefffdffcceceedddecddfff dcccecc4dceeeddc 00210c00c522002c YC8MC N ecfdcff4ffffffff d04000f000f000f abcdef abcdef abcde â àáãåçñÄ éêëèíîïì Ü *  ÀÁÃÅÇÑö øÉÊËÈÍÎÏÌ Øabcdefghi ðýþ jk f abcdef abcdef abcdef abcdef abcdef abcdef012 lmnopqrªºæ Æ µßstuvwxyz ÐÝÞ äABCDEFGHI ô òóõüJKLMNOPQR û ùúÿÖ STUVWXYZ Ô ÒÓÕ aaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbccccccccccccccccddddddddddddddddeeeeeeeeeeeeeeeefffffff abcdef abcdef abcdef abcdef abcdef abcdef Û ÙÚ â àáãåçñÄ éêëèíîïì Ü fffffffff 789abcdef abcdef abcdef abcdef abcdef abcdef a *  ÀÁÃÅÇÑö øÉÊËÈÍÎÏÌ Øabcdefghi ðýþ jklmnopqrªºæ Æ µßstuvwxyz ÐÝÞ aaaaaaaaaaaaaaaabbbbbbbbbbbbbbb bcdef abcdef abcdef abcdef abcdef abcdef abcde äABCDEFGHI ô òóõüJKLMNOPQR û ùúÿÖ STUVWXYZ Ô ÒÓÕ0123 bccccccccccccccccddddddddddddddddeeeeeeeeeeeeeeeeffff0000 f abcdef abcdef abcdef

36 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.

37 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

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

39 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

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

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

42 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

43 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 …

44 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

45 Fragen? – Diskussion? Roman Koutny Alexander Trischler
Anwendungsentwicklung Technische Architektur 089/ Alexander Trischler 0721/

46 Ihr IT-Partner Vielen Dank