Einführung in Smart-AMs und Multiversionierung 2.0. Kommunikation

Transkript

1 Einführung in Smart-AMs und Multiversionierung 2.0 Kommunikation

2 Ziel dieses Vortrags Optimierungspotenzial der derzeitigen Architektur für Zugriffe aus Kanälen verdeutlichen Optimierung durch Architekturänderung, Multiversion 2.0 und SmartAMs Einführung in Multiversion 2.0 Überblick über Designziele und Eigenschaften von SmartAMs Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 2

3 Agenda Kanäle und Portale Überblick über Multiversion 2.0 Regeln für neue Versionen -Implementierung für multiversionierte s Neue Datenklassen Serialisierung Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 3

5 Situation heute IFD ebanking IFD 4711 ebanking IFD 4712 ebanking DB Host Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 5

6 Ziel IFD ebanking IFD 4711 ebanking IFD 4712 ebanking KNP-API 4.1 KNP-API 4.2 KNP-API 4.2 KNP-API 4.3 KNP 4.2 KNP KN 4712 KN DB Host Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 6

7 Zwischenschritt IFD ebanking IFD 4711 ebanking IFD 4712 ebanking KNP-API 4.1 KNP-API 4.2 KNP-API 4.2 KNP-API 4.3 Wie können unterschiedliche Programmstände miteinander kommunizieren? Auch über JVM-Versionen hinweg? KNP 4.2 KNP 4.3 KN... KN... DB Host Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 7

9 Was leistet Multiversionierung? Kommunikation über Programmstände hinweg Rückwärtskompatibilität ist garantiert: Z. B. stellt ein KNP der Version 4.3 bereit: Seine eigenen, neuen s Zusätzlich alle alten s aus 4.2 Damit ist es für ein KSP der Version 4.2 unerheblich, ob das von ihm gerufene KNP die Version 4.2 oder 4.3 hat Vorwärtskompatibilität wird nicht gewährleistet: Auf einem Portal der Version 4.2 gibt es keine s aus 4.3 Das gerufene Portal muss also mindestens die Version des Rufers haben Datenmodelle können kompatibel voneinander abweichen Z. B. kann das 4.3er Modell mehr Attribute und Klassen haben Kommunikation über JVM-Versionen hinweg dank eigener Serialisierung Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 9

10 Was versionieren wir Nur s in basis-modulen Externe Außenschnittstellen: aus service.api wird service.api.v01 (ändert sich praktisch nie) s: aus TueDies wird TueDiesV001 / Kanal bap-vert. frontlet Kanalspezifischer cpi ktkservice cpi bap-vert. service api ktkfrontlet Kanalneutraler api basis-v. service cpi data api basisprodukt Aufruf externer basis-schnittstelle Aufruf interner Schnittstelle api cpi Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 10

11 Unterschiede zu Multiversionierung V Datenklassen gibt es (im Normalfall) nur einmal auch über Versionen hinweg Package ändert sich von service.api auf service.api.v01 Multiversionierte s liegen nun immer in einem asa-modul basis-xxx Im RSA müssen an den s Versionen annotiert werden Datenklassen, s und Fassaden müssen neu durchgeneriert werden Die alten Mapperklassen fallen weg -Implementierungen liegt nun in service.impl.v01 Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 11

13 Wann gibt es eine neue Version? Entscheidend sind die Modelländerungen Bei kompatiblen Modeländerungen gibt es eine neue -Version Bei inkompatiblen Modelländerungen brauchen wir eine neue Version der Außenschnittstelle und für jeden eine neue Version (daher vermeiden!) Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 13

14 Was sind kompatible Modelländerungen? (1) Klassen Kompatibel: Hinzufügen von Attributen/Referenzen/Collections Löschen ist ok, wenn sichergestellt ist, dass in Produktion alle Nutzer das Attribut/Ref/Col nicht mehr verwenden Inkompatibel: Typ-Änderungen von Attributen/Referenzen/Collections Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 14

15 Was sind kompatible Modelländerungen? (2) Enums Kompatibel: Hinzufügen von Ausprägungen ist ok, wenn sie in alten -Versionen nie ausgeliefert werden Löschen von Ausprägungen ist ok, wenn sichergestellt ist, dass in Produktion niemand mehr die Ausprägung verwendet Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 15

17 -Implementierung -Implementierung nun in Package service.impl.v01 Mehrere -Versionen können auf eine Implementierung zeigen Mapper-Implementierungen sind möglich und zu bevorzugen gegenüber Abfragen auf Version Zur Not ist auch eine getrennte Implementierung je nach Version möglich Nutzer V001 Nutzer V002 CM Kompnente service.api.v01 CF SchnittstelleX A v001 A v002 service.impl.v01 A Implem. service.api.v01 service.impl.v01 Nutzer V001 Nutzer V002 CM Kompnente CF SchnittstelleX A v001 A v002 A bisv001 Im. A Implem. Mapper v001 v002 Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 17

19 Warum neue Datenklassen? Multiversionierung erfordert Kommunikation zwischen kompatiblen AM-Versionen: Empfänger hat höhere Version als Sender Sender hat höhere Version als Empfänger Für Request und Response von multiversionierten s dürfen ausschließlich die neuen Datenklassen verwendet werden! Weiteres Designziel: Performance Die klassischen AMs sind für den optimiert, aber Viele Features werden im Server nicht benötigt -spezifische Daten brauchen nicht serialisiert zu werden Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 19

20 SmartAMs - die schlauen AMs SmartApplicationModel Als Ersatz für ApplicationModel SmartList Als Ersatz für AMCollection CompatApplicationModel Erben von SmartApplicationModel und von ApplicationModel (Vorerst) die einzigen Ausprägungen von SmartApplicationModel CompatList Erben von SmartList, AMCollection, java.util.list (Vorerst) die einzigen Ausprägungen von SmartList Alle SmartAMs erben von CompatApplicationModel oder CompatList Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 20

21 SmartAMs Eigenschaften (1) Weitestgehend kompatibel zu den klassischen AMs Nur noch drei Klassen pro SmartAM (Interface, Home, Impl) Kein User Code in generierten Klassen Fest definierte Auswahl von Attributtypen Setter und Getter jeweils mit und ohne Prefix (str, num, flg, ) SmartLists sind typisiert Utilities zum Mappen und Clonen Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 21

22 SmartAMs Eigenschaften (2) Attribute werden intern in Arrays gehalten effizienter Zugriff über Indizes Je ein Array für aktuelle Werte und initiale Werte Unterstützung für genau eine Ebene von Modifications Selbstbeschreibung über statische Meta-Information für Serialisierung, Mapping und Cloning Ermöglichen Kommunikation zwischen Versionen mit kompatiblen Änderungen Effiziente Serialisierung Generierung ausschließlich aus RSA Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 22

23 Kompatibilität von SmartAMs CompatApplicationModel erbt von ApplicationModel syntaktisch stehen alle Methoden von ApplicationModel bereit Implementierung über Delegation Dazu existieren 2 Varianten: Server Das Delegate unterstützt nur die Methoden in Zusammenhang mit Modifications: finishinitialization(), getmodifications(), Alle anderen werden eine UnsupportedOperationException Das Delegate unterstützt alle Methoden, aber: Diejenigen wo in den klassischen AMs User Code aufgerufen wurde, haben eine leere Implementierung (z. B. check-methoden) Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 23

24 SmartAMs erlaubte Attribute SmartApplicationModel SmartApplicationModel SmartList Boolean String EnumValue DT-Typen: DTInteger, DTDecimal, DTDate, DTValutaDate, DTDateTime, DTTime, DTBlob SmartList SmartApplicationModel!!! Keine anderen Typen möglich!!! Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 24

25 Mapping und Cloning von SmartAMs Mapping Attribute des Quellobjekts werden in das Zielobjekt kopiert, falls sie dort definiert sind Quell- und Zielobjekt haben ähnliche Struktur, aber verschiedene Typen Zwei Varianten Cloning Vollständiges Mapping (aktuelle Werte und Initialwerte) Anwendungsfall: Übergang zwischen TOs und DOs Mapping nur der Modifikationen Anwendungsfall: im Data beim Persistieren von Änderungen Zielobjekt wird als Kopie des Quellobjekts erzeugt Quell- und Zielobjekt sind vom selben Typ Zwei Varianten: Vollständiges Cloning Cloning nur der aktuellen Werte (keine Initialwerte) Anwendungsfall: beim Aufruf von Subdialogen Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 25

26 Mapping und Cloning von SmartAMs: Utilities Mapping und Cloning ist eine (fehleranfällige) Fleißarbeit Unterstützung durch generische Utilities mit statischen Methoden SmartMapping Vollständig/nur Modifikationen Zyklische/einfache Strukturen SmartCloning Vollständig/ohne Modifikationen Zyklische/einfache Strukturen Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 26

28 Serialisierung Neue Rahmenbedingungen: Unterschiedliche JDK-Versionen Unterschiedliche JBF-Versionen Unterschiedliche Anwendungsversionen (Request / Response, AMs) Abkehr von der bisher verwendeten Java-Serialisierung! Ziel: Kompatibilität zwischen JBF- und Anwendungsversionen ab 4.2 aufwärts Keine Kompatibilität zwischen 4.2 und 4.1 abwärts Maßnahmen: Definition eines neuen Protokolls auf JBF-Ebene Verwendung einer alternativen Serialisierung: Hessian Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 28

29 Hessian Ein Protokoll und eine Referenzimplementierung zur Serialisierung von Objektgeflechten Quelle: Eigenschaften: Unterstützt ideal die Anforderungen von Multiversionierung Effizient und sehr kompakt Der Preis Für jede Klasse muss ein Serialisierer und ein Deserialisierer existieren Diese müssen sich verstehen Ab 4.2 ist Hessian transparent für die Anwendungen in JBF integriert Requests und Responses für multiversionierte s gehen immer über Hessian Andere gehen nach Möglichkeit über Hessian (abhängig vom Inhalt) Unterstützt werden alle Datentypen, die laut XBF-Dokumentation in Requests und Responses erlaubt sind (Ausnahme: klassische AMs) Einbindung in JBF transparent für die Anwendungen Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 29

30 Fazit/Zusammenfassung Mit 4.2 konnten KSPs und KNPs eingeführt werden Voraussetzung dazu war die Multiversionierung 2.0 Dazu existieren eine umfassende Tool-Unterstützung in Form von RSA-Generatoren Eclipse-Plugin Framework-Unterstützung durch Routing SmartAMs Hessian-Serialisierung Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 30

31 Fragen? Diskussion? Christian Wicke Anwendungsentwicklung Professional s Gert Lormes Anwendungsentwicklung Technische Architektur JBF-Team Christian.Wicke@fiducia.de / Gert.Lormes@fiducia.de / Matthias Kast Anwendungsentwicklung Technische Architektur JBF-Team Matthias.Kast@fiducia.de 0 89 / Einführung in Smart-AMs und Multiversionierung 2.0 Christian Wicke, Gert Lormes, Matthias Kast JBFOne 2010 Seite 31

32 Ihr IT-Partner Vielen Dank