Multiversion und kanalneutrale Portale

Präsentation zum Thema: "Multiversion und kanalneutrale Portale"—  Präsentation transkript:

1 Multiversion und kanalneutrale Portale
Markus Haseneder, Klaus Huthmacher; Architektur | JBFOne 2008

2 Ziel dieses Vortrags Verständnis der Problematik der Koexistenz unterschiedlicher Software-Stände von Anwendungssystemen Erläuterung der Begriffe Kanalneutralität Multiversionsunterstützung Aufzeigen von Lösungsalternativen für die Problematik

3 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

4 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

5 Die Strategie agree® plus
Die Strategie agree plus beschreibt die Weiterentwicklung des Banksystems agree in den kommenden fünf Jahren Bankbetriebswirtschaftliche Architektur: Produktstrategie agree® plus / Bebauungsplan agree® plus I Vertriebsbank Produktionsbank Steuerungsbank Weiterentwicklung agree BAP für den Vertrieb Optimierung der Analyse- möglichkeiten Stärkung der elektronischen Vertriebswege konsequenter Abschluss der agree-BAP-Integrationsstrategie bessere Prozesssteuerung und feinere Granularität Ausbau der Reporting-Funktio- nalitäten (MaRisk, GuV-Risiko, …) Kosten-/Produktivitätssteuerung Optimierung von VR-Control (Handling, Praxisorientierung) agree® Basis innovative bankwirtschaftliche Querschnittsfunktionen für Prozessunterstützung, einheitliche Produktgestaltung, Antragsfähigkeit, Agenturfähigkeit u. a. Stand: Verabschiedet von Architektur-Board lt. Frau Eß/Mail vom II Software-Architektur moderne Zielarchitektur mit fachlich geschnittenen Bündeln Service- und Komponenten-Orientierung, Entkopplung von funktionalen Einzel-Domänen Einsatz von Referenz-Architekturen, Tools und Frameworks zur industriellen Software-Produktion HORIZON III Architektur der technischen Infrastruktur Minimierung der Abhängigkeiten von Herstellern und Produkten effizienter, automatisierter und stabiler Betrieb Einsatz von einheitlichen Technologie-Standards und Betriebs-Architekturen

6 agree Zielarchitektur
Fachliche Bündel Kanäle Filiale SB e/mBanking Web aCI Call Center … Prozess & Verbindende Services Konsumkredit Beratung Baufi Produktverkauf Rechenkern Organisation Prozess Mandant Aktivität Dokument Rechte- verwaltung Konto Vertrag Person Produkt Controlling Meldewesen Rechnungs- wesen Zahlungs- verkehr Kasse & Bestände Zugangs- medien ZASt Kredit Beratungs- info Vertriebs- management Rating Bonität Vermögenswert Provision Marktdaten Partner DZ R&V Plattformen FBI

7 aSA – agree Standardarchitektur
Präsentation Integration / Steuerung Fachlogik Datenlogik / Persistenz Geschäfts- Komponente Geschäfts- Komponente Anwendungs- Komponente Kanal-spezifisch Kanal-neutral

8 aSA – agree Standardarchitektur
Datenlogik / Persistenz Fachlogik Integration / Steuerung Präsentation Business- komponenten Anwendungs- komponenten BAP SB eBanking Kern

9 Services Eine Business-Komponente bietet als Außensicht eine oder mehrere Komponentenschnittstellen. Eine Komponentenschnittstelle gruppiert angebotene Services der Komponente nach fachlichen Aspekten. z.B. als Auskunftsschnittstelle mit den Services: Hole Personendaten Hole Einheitenliste Hole Rollen Auskunft Pflege Business-Komponente

10 Services Komponenten-Manager als Fabrik für die Außenschnittstellen einer Komponente Erzeugt eine Servicefassade für jede Komponentenschnittstelle Servicefassade kapselt den Aufruf eines XBF-Service als Methodenaufruf

11 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

12 BAP-Portale BAP-Portale HOST DB BAP 3.0 BAP 3.1 G-Plex BAP 3.2 BAP 3.0
4711 BAP 3.0 BAP 3.1 G-Plex 0815 BAP 3.2 BAP 3.0 1234 BAP 3.1 P-Plex BAP 3.2

13 BAP-Portale BAP-Portale HOST DB BAP 3.0 G-Plex BAP 3.2 G-Plex BAP 3.1
4711 BAP 3.0 G-Plex 0815 BAP 3.2 G-Plex 1234 BAP 3.1 P-Plex

14 eBanking-Portale HOST DB EB-Portal eBanking 2.0 G-Plex BAP 3.2
Browser G-Plex Browser EB-Portal BAP 3.2 eBanking 2.0 P-Plex Browser

15 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

16 Schwierigkeiten am Beispiel eBanking
Kurzbeschreibung des eBankingumfelds und der Softwareabhängigkeiten und Schwierigkeiten: Auf einem aktuellen eBanking System oder Server werden neben dem Framework noch weitere Softwarepakete oder -stacks installiert eBanking, BAP, Kernsystem (SEPA) Es besteht somit eine direkte Anhängigkeit zwischen der eBanking Version und z.B. der eingesetzten oder installierten BAP-Version Aktuell befindet sich für alle Banken nur eine eBanking-Version im Einsatz Somit kann nur eine zugrunde liegende BAP-Version zum Einsatz kommen Mit BAP 3.2 fanden u.a. im Bereich der im eBanking verwendeten CBx-Services eine semantische Schnittstellen- und eine Implementierungsveränderung statt Eine Datenmigration wird zur Verwendung der neuen Schnittstelle vorausgesetzt

17 Schwierigkeiten am Beispiel eBanking
BAP Umfeld BAP V3.2 4711 3.2 (BAP) BAP V3.1 0815 3.1 (BAP) eBanking Umfeld 0815 eBanking V2.1 4711 SEPA V3.22 BAP V3.2 3.2 (BAP)

18 Schwierigkeiten am Beispiel eBanking
Die Betriebsumgebung und -architektur von HORIZON-Komponenten fokussiert sich heute hauptsächlich auf den Betrieb der kanalneutralen Komponenten in den BAP- Portalen Primäre Erweiterung/Weiterentwicklung der BAP-Portale Multiversionsfähigkeit im BAP-Umfeld wird heute über die Organisation der BAP-Portale erreicht Die Kanäle werden in anderen/eigenen Betriebsumgebungen produziert BAP-Portale, eBanking-Portale, agreeSB-Portale HORIZON-Ordnungskriterien im Betrieb jede Bank kann und darf nur auf einem Portal produziert werden (Grid, Dispatcher, etc.) Die Kanäle eBanking und agreeSB wollen Geschäftskomponenten verwenden Wenn ein Kanal Geschäftskomponenten benutzen möchte, müssen diese im jeweiligen Kanal installiert und betrieben werden Bei Geschäftskomponenten, gegeben durch die HORIZON-Architektur, nicht möglich

19 Schwierigkeiten am Beispiel eBanking
Ein Service-Nutzer ist grundsätzlich zur sofortigen Anpassung an neue Service-Versionen oder Geschäftskomponenten-Versionen gezwungen Unabhängig von der Art der Veränderung (z.B. gesetzliche Änderungen, optionale Attribute) Um unterschiedliche Versionen der Geschäftskomponenten (Kernsystem) ansprechen oder nutzen zu können, sind entsprechende Satellitensystem- oder Kanal-Versionen notwendig Für jede Kernsystemversion eine Kanalsystemversion Enge Kopplung zwischen den verschiedenen Kanalsystemen und dem Kernsystem Starke Abhängigkeit zwischen den Anwendungsreleasen von agree SB, eBanking, aCI und den BAP-Releasen Abhängigkeit der Endkunden-Portale zu den BAP-Portalen Keine getrennte Versorgung von Geschäfts- und Anwendungskomponenten möglich

20 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

21 Zielvorstellung Versionsabhängigkeit zwischen Geschäfts- und Anwendungskomponenten auflösen Geschäftskomponenten so betreiben, dass sie von allen Kanälen verwendet werden können Getrennte Versorgung von Geschäfts- und Anwendungskomponenten ermöglichen Flexibilisierung der Betriebslandschaft hinsichtlich Aufbau und Skalierung Reduzierung des Konfigurationsaufwands

22 Zielvorstellung - Lösungsweg
Architektursicht Anwendungs Komponente IMPL 1.0 eBanking V1.0 Geschäfts Komponente IMPL 1.0 SEPA V1.0 1.0 Anwendungs Komponente IMPL 1.1 eBanking V1.1 Geschäfts Komponente IMPL 2.0 SEPA V2.0 2.0

23 Zielvorstellung - Lösungsweg
Architektursicht Geschäfts Komponente IMPL 1.0 SEPA V1.0 Anwendungs Komponente eBanking V1.0 1.0 1.0 Anwendungs Komponente IMPL 1.0 eBanking V1.0 Geschäfts Komponente IMPL 1.0 IMPL 2.0 SEPA V2.0 2.0

24 Zielvorstellung - Lösungsweg
Architektursicht Anwendungs Komponente IMPL 1.0 eBanking V1.0 Geschäfts Komponente IMPL 1.0 SEPA V1.0 1.0 Anwendungs Komponente IMPL 1.0 eBanking V1.0 Geschäfts Komponente IMPL 2.0 SEPA V2.0 2.0

25 Zielvorstellung - Lösungsweg
Deploymentsicht eBanking V1.0 eBanking V1.0 SEPA V1.0 SEPA V2.0

26 Zielvorstellung - Lösungsweg
Deploymentsicht eBanking V1.0 SEPA V1.0 SEPA V2.0

27 Zielvorstellung - Lösungsweg
Deploymentsicht eBanking V1.0 SEPA V1.0 BAP V1.0 eBanking V2.0 SEPA V2.0 BAP V2.0

28 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

29 Erklärung: kanalneutrale Portale, Multiversionskonzept
0815 eBanking V2.1 4711 SEPA V3.22 BAP V3.2 3.2 (BAP)

30 Erklärung: kanalneutrale Portale, Multiversionskonzept
SEPA V3.22 BAP V3.3 3.3 (BAP) 4711 R O U T I N G eBanking V2.2 J B F SEPA V3.22 BAP V3.4 0815 3.4 (BAP)

31 Erklärung: kanalneutrale Portale, Multiversionskonzept Auszug Systemkonzept
eBanking-DMZ am Internet XBF-Schicht FW/Loadbalancer Webserver XBF-Server eBanking-DMZ im P/G-Plex JASS-Schicht FW/Loadbalancer Webserver JASS-Server Neu: Kanalneutrale Schicht FW/Loadbalancer PoolStack I PoolStack II

32 Erklärung: kanalneutrale Portale, Multiversionskonzept Auszug Systemkonzept
Schicht FW/Loadbalancer Stack I BAP 3.3 Stack II BAP 3.4 Webserver I Zone 1 Webserver I Zone 2 Service-Routing für: de.basisagree.* de.cbxagree.* Appserver I Zone 1 Appserver I Zone 2

33 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

34 Multiversion - Motivation / Ausgangssituation
BAP eBanking agree SB aCI / VRS Business Komponente Business Komponente Business Komponente Business Komponente … agree-Kernsystem

35 Multiversionsfähigkeit - Zielvorstellung
Ein Service-Nutzer soll nicht grundsätzlich zur sofortigen Anpassung an neue Service- Versionen gezwungen werden … in bestimmten Fällen ist die Umstellung auf neue Service-Versionen jedoch unumgänglich (z.B. gesetzliche Änderungen) Verschiedene Versionen der Satellitensysteme sollen mit verschiedenen Versionen des Kernsystems zusammenarbeiten können Eine Kopplung der verschiedenen Satellitensysteme über das Kernsystem soll vermieden werden Die Abhängigkeit zwischen Anwendungsreleases von agree SB, eBanking, aCI zu den BAP-Releases soll gelockert werden

36 Multiversionsfähigkeit - Konzept
Die Versionierung bezieht sich auf die Außensicht von Business-Komponenten Eine Business-Komponente bietet als Außensicht eine oder mehrere Komponentenschnittstellen. Eine Komponentenschnittstelle gruppiert angebotene Services der Komponente nach fachlichen Aspekten zum Beispiel als Auskunftsschnittstelle mit den Services: Hole Personendaten Hole Einheitenliste Hole Rollen Auskunft Pflege Business-Komponente

37 Multiversionsfähigkeit - Konzept
Eine neue Version einer Komponentenschnittstelle entsteht dann, wenn sich ein Service dieser Komponentenschnittstelle ändert wenn ein Service an dieser Komponentenschnittstelle hinzukommt oder wegfällt Komponentenschnittstelle als Version 1 Komponentenschnittstelle als Version 2 Komponentenschnittstelle als Version 3 v1 v2 v3 S1 v1 S2 v1 S1 v1 S2 v2 S1 v1 S2 v3 S3 v1 neue Version von Service B neue Version von Service 2 und neuer Service 3 neue Version von Service 2

38 Multiversionsfähigkeit - Konzept
Im Inneren der Komponente sollte immer die aktuelle Service-Version implementiert sein Nach außen werden - neben der aktuellen Version einer Komponentenschnittstelle - auch vorherige Versionen angeboten Komponentenschnittstelle mit aktueller Version 1 Komponentenschnittstelle mit aktueller Version 2 und Vorversion 1 Komponentenschnittstelle mit aktueller Version 3 und Vorversionen 1 und 2 v1 v1 v2 v1 v2 v3 S1 v1 S2 v1 S1 v1 S2 v2 S1 v1 S2 v3 S3 v1 neue Version von Service B neue Version von Service 2 und neuer Service 3 neue Version von Service 2

39 Multiversionsfähigkeit - Implementierung
Versionierung auf Basis des Komponentenmanagers und der Servicefassaden Interfaces des Komponentenmanagers und der Servicefassaden bleiben in der alten Version vorhanden Unterscheidung der Versionen über package-Namen Implementierung der Services ist nur in der aktuellsten Version vorhanden Im Normalfall erfolgt ein (transparentes) Mapping zwischen alten und neuen Daten Falls kein Mapping möglich, werden beide Implementierungen des Service vorgehalten und entsprechend instanziiert Die Service-Implementierung kennt keine Versionen

40 Multiversionsfähigkeit - Implementierung
CF1 V1 S1 Impl V1 Mapping CM V1 Caller V1 CF2 V1 S2 Impl V1 Mapping CF1 V2 S1 Impl V2 CM V2 Caller V2 CF2 V2 S2 Impl V2 CM = Component Manager CF = Component Facade S<x> = Service <x>

41 Multiversion - Implementierung
Unterscheidung der Versionen über den Packagenamen Eine Implementierung in der unversionierten Servicefassade Keine Implementierung in den versionierten Servicefassaden

42 Agenda Einführung, Rahmen und Begriffserklärung
Systemübersicht von BAP und eBanking Schwierigkeiten am Beispiel eBanking Zielvorstellung Erklärung: kanalneutrale Portale, Multiversionskonzept Status / Ausblick

43 Status / Ausblick Konzepte zu Kanalneutralität und Multiversionsunterstützung wurden verprobt Pilotumsetzung ist im Rahmen von BAP 3.5 geplant

44 kanalneutralen Services
Status / Ausblick Bank / Zweigstelle Home Banking SB Geräte Call Center Präsentation Browser Präsentation Präsentation Frontent Präsentation Control Services Control Services Control Services Control Services Mid Tier Business Service Business Service Business Service Business Service Pool von kanalneutralen Services Data Service Data Service Data Service Data Service Backend 44

45 Status / Ausblick Kanalneutrale und Anwendungs-Komponenten werden jeweils auf eigenen Serverpools betrieben. Alle Kanäle rufen die zentralen kanalneutralen Komponenten auf BAP-Serverpool eBanking-Serverpool Requestbasiertes Routing SB-Serverpool RDBMS HORIZON-Serverpool

46 Zusammenfassung Problematik der Koexistenz unterschiedlicher Software-Stände von Anwendungssystemen wurde dargestellt Lösungsmöglichkeiten wurden aufgezeigt Kanalneutrale Services Multiversionsunterstützung bei Services

47 Fragen? – Diskussion? Markus Haseneder Klaus Huthmacher
Anwendungsentwicklung Technische Architektur +49 (0) Klaus Huthmacher +49 (0)

48 Ihr IT-Partner Vielen Dank