Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Machet die Tore weit! Portaltechnologie in Bankanwendungen
Ralph Henze Sparda-Datenverarbeitung eG
www.sparda.de
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Ü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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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.
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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?
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Ausgangssituation
Die Anforderungen aus Kundensicht waren:
Bedienung so einfach wie möglich
Nur ein Login nötig
Einheitliches Look & Feel über alle Anwendungen
Performance
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Warum ein Portal Server?
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)
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Warum ein Portal Server?
Portalstrategie:
Integrations- bzw. Transaktionsportal
Kein Personalisierungsportal
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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)
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
…
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Ü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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
WebSphere Portal Server Client
CUR
Portlet Container Member
Repository
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
WebSphere Application Server
WebSphere Portal Server Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
WebSphere Application Server
WebSphere Portal Server Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
WebSphere Application Server
WebSphere Portal Server Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filt
er
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Überblick Portal Basisarchitektur
WebSphere Application Server
WebSphere Portal Server
Client CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filt
er
Banken Kernsystem
(IBM zSeries Mainframe)
Backend
Adapter
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Überblick Gesamtarchitektur
Client
Banken Kernsystem
(IBM zSeries Mainframe)
WebSphere Application Server
WebSphere Portal Server
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filt
er
Backend
Adapter
Web Service Bus
Service Adapter
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Ü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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
…
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
J2EE Web Container
Situation Struts Portlet Anwendungen
Portlet Container
Web
Browser
Struts Portlet Application
Controller
xml
Action
Model View
HTTP
Request
HTTP
Response
Portal Server
Web Application
Struts Portlet Application
Controller
xml
Action
Model View
Portal Controller
Servlet
Page
Aggregation
Portlet
Invoker
Any Portlet Application
Any Portlet
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Model JSP
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
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
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
The End
Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG
Vielen Dank!
www.sparda.de