Banking portal

Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Machet die Tore weit!
Portaltechnologie in Bankanwendungen
Ralph Henze
Sparda-Datenverarbeitung eG
ralph.henze@spb.de
www.sparda.de

Kurze Vorstellung
 Sparda-Datenverarbeitung eG
 IT-Dienstleister für
 Sparda-Banken
 PSD Banken
 NetBank AG
 ca. 350 Mitarbeiter
 Zwei Rechenzentrumsstandorte in Nürnberg
 ca. 1,2 Mio. Kunden sind für Internet freigeschalten
 ca. 6,5 Mio. Internet-Sitzungen pro Monat
 Ralph Henze
 Software-Architekt und Entwickler
 Technischer Projektleiter Internet Endkundenportal
12 Sparda-Banken
15 PSD Banken
NetBank AG

Überblick
 Portalprojekt
 Ausgangssituation
 Warum ein Portal Server?
 Projekt Arbeitspakete
 Herausforderung Produktionsumgebung
 Portal Basisarchitektur
 Authentifizierung und Benutzerprofile
 Login- und Logout-Vorgang
 Portalisierung der bestehenden Anwendungen
 Struts-basierte Anwendungen im Portalumfeld
 Separation und Zentralisierung von Funktionalität

Ausgangssituation
 2001 haben wir eine J2EE-basierte Lösung für Internetbanking
eingeführt
 Die Applet-basierte Lösung eines Drittherstellers wurde damit
abgelöst.

Ausgangssituation
 Mit dem Erfolg der Internetbanking Anwendung wuchsen die
Anforderungen und Wünsche der Banken
 Weitere Features müssen in die Anwendung eingebaut werden
 Neue Anwendungen sind zu entwickeln
 Postbox (juristisch gültige Kontoauszüge, Mitteilungen, etc.)
 Zielgruppenorientierte Produktangebote auf Basis DWH
 Direkter Verkauf von Bankprodukten
 Integration der Anwendungen von Kooperationspartnern
 Man soll sich nur ein einziges Mal anmelden müssen
 Single Sign On Integration

Ausgangssituation
 Es entstand die Gefahr, die Anwendungen zu überfrachten
 Verringerte Wartbarkeit
 Redundanzen in den Anwendungen
 Mehrfache Logins sind für den Kunden unzumutbar
 Single Sign On?

Ausgangssituation
 Die Anforderungen aus Kundensicht waren:
 Bedienung so einfach wie möglich
 Nur ein Login nötig
 Einheitliches Look & Feel über alle Anwendungen
 Performance

Ausgangssituation
 Die Anforderungen aus Sicht der Entwicklung waren:
 Unabhängige Entwicklung der Anwendungen
 Wiederverwendung/Migration eines großen Teils der bestehenden
Anwendungen muss möglich sein
 Investitionsschutz
 Login soll nicht Bestandteil [je]der einzelnen Anwendung sein
 Konzentration auf die Fachlichkeit der Anwendung
 Gemeinsam benötigte Funktionalität soll ausgelagert sein
 Gemeinsame benötigte Informationen sollen zentral zugängig sein

Ausgangssituation
 Die Anforderungen aus Sicht des Betriebs waren:
 Unabhängiges, revisionssicheres Übergabeverfahren für die
Anwendungen
 Unabhängiges Deployment für einzelne Anwendungen
 Stabilität
 Skalierbarkeit / Clusterfähigkeit

Warum ein Portal Server?
 Alternative 1: Eigenes Framework entwickeln
+ Hoher Entwicklungsaufwand
+ zielgerichtete, spezialisierte Implementierung
- Resultat ähnelt einem Portal Server Produkt!
 Alternative 2: Portal Server Produkt einsetzen
+ Bringt viele, aber nicht alle der benötigten Funktionalitäten mit
- Besitzt Funktionalität, die nicht benötigt/verwendet wird
- Content Management
- Personalisierung

 Separation
 Portlet-Anwendungen sind unabhängige Applikationen
 Getrennter, unabhängiger Entwicklungsprozess
 Unabhängige Deployments
 Übersichtliche, wartbare Anwendungen
 Integration
 Gemeinsam benötigte Bestandteile werden zentralisiert
z. B. gemeinsame Backend-Schnittstellen
 Single Sign On: Gemeinsame Authentifikation
 Präsentation: Gemeinsames Style / Theme / Layout
 Kommunikation
 Portlets können Informationen austauschen
Gemeinsame Session, Benutzerprofil, Messaging (Event Mechanismus)

Portalstrategie:
 Integrations- bzw. Transaktionsportal
 Kein Personalisierungsportal

Welches Portal Server Produkt?
 Kommerzielles Produkt
 IBM WebSphere Portal Server
 BEA Portal Server
 Open Source Produkt
 Apache Jetspeed 1.x
 Zum Zeitpunkt der Evaluation Ende 2002 war kein anderes Open
Source Produkt verfügbar
 Jetspeed war nicht für große, kritische
Unternehmensanwendungen geeignet
 Entscheidung fiel zugunsten IBM WebSphere Portal Server
aus

Projekt Arbeitspakete
 Architektur
 Portal Struktur
 Mandantenfähigkeit
 Anbindung Backend-Systeme (Banken-Mainframe)
 Implementierung
 Portal Basis / Fundament
 Authentifizierung & Single Sign On
 Themes und User Interface
 Erweiterung um nicht vorhandene Funktionalitäten
 Portalisierung bestehender Anwendungen
 Betrieb
 Planung Infrastruktur
 Rollout Prozedur

Herausforderung Produktionsumgebung
 Die Produktionsumgebung für eine Bankenplattform im Internet ist mit
höchster Sorgfalt zu planen
 Im Mittelpunkt stehen dabei die Themen
 Security
 Verfügbarkeit
 Performance
 Wartbarkeit
 Notwendige Maßnahmen
 System zur permanenten Überwachung und Alarmierung
 Lasttests mit unterschiedlichsten Konfigurationen
 Entscheidung für mehrere unabhängige Portal Instanzen
(kein WebSphere Cluster)

Security Hardening WebSphere Portal Server
 Bugs von WebSphere Application Server / Portal Server beheben bzw. umgehen
(LTPA Bug)
 Löschen von Default Content
 Cross Site Scripting anfällige JSPs
 Detaillierte Versionsinformationen
 Einschränkung von zulässigen URLs
 Nicht alle URLs sollten vom Portal Server bedient werden
 Configuration Servlet unzugängig machen
 Administrativen Zugriff auf Admin Subnetz beschränken
 Standard Fehlerseiten definieren (in Portal Server web.xml)
 Deinstallation von Sample Applications / Portlets
 …

Überblick
 Generelles
 Ausgangssituation
 Warum ein Portal Server?
 Projekt Arbeitspakete
 Herausforderung Produktionsumgebung
 Portal Basisarchitektur
 Authentifizierung und Benutzerprofile
 Login- und Logout-Vorgang
 Portalisierung der bestehenden Anwendungen
 Struts-basierte Anwendungen im Portalumfeld
 Separation und Zentralisierung von Funktionalität

Portal Basisarchitektur
 Portal Basis ==
Alles im Portal-Umfeld, was keine fachliche Portlet-Anwendung ist
 Der Portal Server muss in die bestehende Systemlandschaft integriert
werden
 Ein LDAP-Server steht für die Internet-Kunden nicht zur Verfügung
 Dazu sind eine Reihe von Schnittstellen und Komponenten zu
implementieren:
 Authentifizierung
 Bereitstellen von Daten des Benutzerprofils
 Eingriffe in den Login- und Logout-Vorgang des Portals
 Zentralisierter Zugriff auf das Backend (Banken Mainframe)
 Ergänzen des HTTP Datenstroms durch Servlet Filter

Authentifizierung
 Der Portal Server läuft als gesicherte Web Application im
WebSphere Application Server (J2EE Security)
 WebSphere stellt mit UserRegistry eine Schnittstelle zur
Verfügung, eigene Authentifizierungskomponenten an das
System anzudocken  Custom User Registry (CUR)
WebSphere Application Server
WebSphere Portal Server
Client
CUR
Portlet Container

Bereitstellen von Daten des Benutzerprofils
 Die Portlet API bietet Portlets die Möglichkeit, Informationen über den
angemeldeten Benutzer (“Profil”) zu erhalten
 Das Benutzerprofil wird nach der Authentifizierung vom Portal Server über
eine definierte Schnittstelle angefordert
 Die Schnittstelle MemberRepository ist nicht veröffentlicht
 Änderung der Schnittstelle zwischen verschiedenen Portal Server
Releases sind wahrscheinlich
L WebSphere Application Server
Client
CUR
Portlet Container
Member
Repository

Eingriffe in den Login- und Logout-Vorgang
 Aus einer Reihe von Gründen ist es erforderlich, in den Login- und Logout-
Vorgang des Portals einzugreifen
 Beschränkung des administrativen Zugriffs auf dediziertes Subnetz
 An- und Abmeldung an Backend System
 Freigabe von Resourcen
 Dazu können Default Command-Klassen überschrieben werden
Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command

Zentralisierter Zugriff auf das Backend
 Mehrere Portlets benötigen Zugriff auf das gleiche Backend
 Daher sollte eine gemeinsame Anbindung innerhalb des
Portals vorliegen, auf das die Portlets Zugriff haben
 Dies ist mittels eines Portlet Service realisiert
Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service

Ergänzen des HTTP Datenstroms
 Servlet Filter (nach Servlet API 2.3) werden verwendet, um
den HTTP Datenstrom zu verändern/ergänzen
 Hinzufügen von HTTP Headern für den Load Balancer
 Beseitigen einer Schwäche des LTPA-Protokolls
 Hinzufügen von P3P Compact Policy HTTP Headern
Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filter

Überblick Portal Basisarchitektur
Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filter
Banken Kernsystem
(IBM zSeries Mainframe)
Backend
Adapter

Überblick Gesamtarchitektur
Client
Banken Kernsystem
(IBM zSeries Mainframe)
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filter
Backend
Adapter
Web Service Bus
Service Adapter

Portalisierung der bestehenden Anwendungen
 Die bestehenden Anwendungen lagen in Form von Struts-basierten Web
Applications vor
 Internetbanking
 Postbox
 Die fachlichen Funktionalitäten der bestehenden Anwendungen mussten
erhalten bleiben (Investitionsschutz)
 Generell ist es wünschenswert, die Vorteile des Struts-Frameworks auch in
der Portlet-Welt zu haben
 Saubere MVC-Trennung
 Performance, Stabilität, Praxiserprobung
 haufenweise Literatur, exzellente Tool-Unterstützung
 …

IBM Struts Portlet Framework
 IBM liefert mit dem Portal Server (ab Version 5.x) das Struts Portlet
Framework mit (ist auch als separater Download erhältlich)
 Das Struts Portlet Framework ermöglicht
 die Neuentwicklung von Struts-basierten Portlets
 die Portalisierung bestehender Struts-basierter Webanwendungen
 Die entstehenden Portlets folgen wahlweise IBM Portlet API
(org.apache.jetspeed.*) oder JSR 168 (javax.portlet.*)
 Das Struts Portlet Framework besteht aus
 Struts Controller Portlet und Portlet Request Processor
 Taglib als Ersatz für die Struts <html:/> Taglib
 einer Reihe von Utility Klassen

Portalisierung einer Struts-basierten Anwendung
 Es gibt eine definierte Prozedur zur Portalisierung einer
bestehenden Struts-basierten Anwendung:
 Anpassung der JSPs der Anwendung
 Ersetzen des Action Servlets durch das Action Portlet
 Ersetzen des Standard Request Processor
 Ersetzen der <html:/> Taglib in web.xml
 Hinzufügen eines portlet.xml Deskriptors
 Jar-Dateien nach WEB-INF/lib kopieren
 Jedoch sind eine Reihe von Besonderheiten zu beachten,
welche die Verwendung von Struts in Portlet-Projekten
einschränken

Situation Struts Webanwendung
Web
Browser
J2EE Web Container
Web Application
Action Servlet
(Controller)
struts-config.xml
Struts Action
(Logik)
Anwendungszustand
(Model)
JSP
(View)
dispatch
forward
get
(tag)
provide
HTTP
Request
HTTP
Response

J2EE Web Container
Situation Struts Portlet Anwendungen
Portlet Container
Web
Browser
Struts Portlet Application
Controller
xml
Action
ModelView
HTTP
Request
HTTP
Response
Portal Server
Web Application
Struts Portlet Application
Controller
xml
Action
ModelView
Portal Controller
Servlet
Page
Aggregation
Portlet
Invoker
Any Portlet Application
Any Portlet

Besonderheiten
 Servlet- und Portlet-APIs haben eine Reihe von
Gemeinsamkeiten, jedoch Servlet ≠ Portlet
 Die Portlet-Request-Verarbeitung läuft in zwei Phasen ab
 Action Processing Phase
 Rendering Phase
 Portal URIs haben ein spezielles Format
 Forwards und HTTP Redirects werden nicht unterstützt

Problembereich Verarbeitung in zwei Phasen
 Die Verarbeitung von Requests in Portalanwendungen ist in
zwei Phasen aufgeteilt
 Action Processing zur Reaktion auf Benutzerinteraktionen
 Rendering erzeugt das Markup-Fragment des Portlets
 Ein typischer Struts Request Flow umfasst jedoch Action
Processing und Rendering vermischt in einem Schritt
Web
Browser
J2EE Web Container
Struts based Web Application
Controller
config
Action
ModelJSP

Problembereich Verarbeitung in zwei Phasen
 Während der Action Processing Phase kann kein Output
erzeugt werden
 in einer Struts Action kann das HttpResponse Objekt nicht verwendet werden!
 Das Rendering kann mehrfach hintereinander auch ohne
Action Processing aufgerufen werden
 Situation: Auf einer Page sind mehrere Portlets, der Benutzer arbeitet
nur in einem.
 Problem, falls die JSPs auf Beans im Page- oder Request Scope
zugreifen
 die zur Darstellung des View erforderlichen Beans müssen evtl.
zwischengespeichert werden
 Das Struts Portlet Framework erreicht dies durch View Commands, die
Beans speichern und mehrfach ausgeführt werden können
 Erfordert Eingriff in die Applikation

Problembereich URI Generierung
 Mehrfache Controller müssen koordiniert werden
 Die generierten URIs müssen immer auf den Controller des
Portal Servers zeigen
 Wird von den Tags der mitgelieferten <html:/> Taglib erledigt
<html:form />, <html:link />, <html:rewrite />, <html:image />
 Die Bestandteile für den Struts Controller müssen trotzdem in
der URI codiert sein und vor der Verarbeitung decodiert
werden
 Wird vom mitgelieferten RequestProcessor erledigt
 Pfade in der Anwendung, die nicht durch <html:/>-Tags
generiert werden, funktionieren nicht mehr

Folgen der Portalisierung
 Login-/Logout-Funktionen sind aus der Anwendung
herausgenommen worden
 Der Zugriff auf das gemeinsame Backend wird in Form von
Portlet Services ermöglicht und ist ebenfalls nicht mehr
Bestandteil der Anwendungen
 Die Anwendungen haben sich insofern verändert:
 Geringere Größe (weniger Actions, Forms, JSPs, …)
 verbesserte Wartbarkeit
 Konzentration auf fachliche Funktionalität

Fazit
 Der strategische Einsatz von Portaltechnologie im
Endkundengeschäft für Banken ist aus unserer Sicht sinnvoll
und richtig
 Das Einbringen eines Portal Servers in eine Systemlandschaft
mit nichtstandardisierten Schnittstellen ist ein sehr komplexes
und aufwändiges Unterfangen
 Mit Hilfe des Struts Portlet Framework ist es möglich,
bestehende Struts-basierte Anwendung mit vertretbarem
Aufwand zu portalisieren

Links
 Gruppe der Sparda-Banken
http://www.sparda.de/
 IBM developerWorks WebSphere Portal Zone
http://www-128.ibm.com/developerworks/websphere/zones/portal/
 Struts Portlet Framework
http://catalog.lotus.com/wps/portal/portal dort nach “1WP10003N“ suchen
 Java Specification Request 168
http://www.jcp.org/en/jsr/detail?id=168

The End

Vielen Dank!
ralph.henze@spb.de
www.sparda.de

Banking portal

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Banking portal

Similar to Banking portal (20)

Banking portal