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

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

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

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

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: 4.3.2008 Verabschiedet von Architektur-Board lt. Frau Eß/Mail vom 4.3.2008 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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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>

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

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

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

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

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

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

Fragen? – Diskussion? Markus Haseneder Klaus Huthmacher Anwendungsentwicklung Technische Architektur markus.haseneder@fiducia.de +49 (0) 89 9943 3923 Klaus Huthmacher klaus.huthmacher@fiducia.de +49 (0) 89 9943 3134

Ihr IT-Partner Vielen Dank