OOP 2006: Einsatz von Portaltechnologie in Bankanwendungen für Internet-Endkunden

19.01.2006 © 2006 Sparda-Datenverarbeitung eG 1
Einsatz von Portaltechnologie in
Bankanwendungen für Internet-Endkunden
Ralph Henze
Sparda-Datenverarbeitung eG
ralph.henze@spb.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,3 Millionen freigeschaltete Internet-Kunden
– ca. 6,5 Millionen 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
– Challenge Produktionsumgebung
– Anwendungssicherheit
 Portal Basisarchitektur
– Authentifizierung und Benutzerprofile
– Login- und Logout-Vorgang
– Überblick Gesamtarchitektur
 Portalisierung bestehender Anwendungen
– Struts-basierte Anwendungen im Portalumfeld
– Struts Portlet Framework

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?

Warum ein Portal Server?
 Alternative 1: Eigenes Framework entwickeln
+ zielgerichtete, spezialisierte Implementierung
- hoher Entwicklungsaufwand
- Resultat ähnelt einem Portal Server Produkt!
 Alternative 2: Portal Server Produkt einsetzen
+ bringt viele, aber nicht alle der benötigten Funktionalitäten mit
+ Portlet Features wirken sich positiv auf Anwendungen aus
- besitzt Funktionalität, die hier nicht benötigt/verwendet wird
- Content Management
- Personalisierung
- ...

Benefits eines Portal Servers
 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

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

Challenge 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 (K-Fallfähigkeit)
– 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)

Anwendungssicherheit
 Prüfung der Anwendungssicherheit hat einige kritische
Punkte offenbart
– Standard-Installation hinterlässt Default Content
– Cross Site Scripting anfällige JSPs
– Detaillierte Versionsinformationen zugänglich
 Maßnahmen zur Erhöhung der Anwendungssicherheit
wurden erforderlich
– Löschen von WebSphere Portal Server Default Content
– Einschränkung von zulässigen URLs
– 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
 Portalprojekt

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 waren eine Reihe von Schnittstellen und
Komponenten zu implementieren:
– Authentifizierung
– Bereitstellen von Informationen 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) zur Anbindung an Bankensystem
WebSphere Application Server
WebSphere Portal Server
Client
CUR
Portlet Container

Bereitstellung 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 möglich
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
– Hinzufügen von P3P Compact Policy HTTP Headern
– Beseitigen einer Schwäche des LTPA-Protokolls
Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filter

Ü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
Anwendungen Verbundpartner

Überblick
 Portalprojekt

Portalisierung bestehender Anwendungen
 Die bestehenden Anwendungen lagen in Form von
Struts-basierten Web Applications vor
– Internetbanking
– Postbox
 Die fachlichen Funktionalitäten der bestehenden
Anwendungen müssen 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
– Defacto-Standard: haufenweise Literatur, exzellente Tool-
Unterstützung

Struts Web Application
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

Struts Portlet Applications
J2EE Web Container Portlet Container
Web
Browser
Struts Portlet Application
Controller
config
Action
ModelView
HTTP
Request
HTTP
Response
Portal Server
Web Application
Struts Portlet Application
Controller
config
Action
ModelView
Portal Controller
Servlet
Page
Aggregation
Portlet
Invoker
Any Portlet Application
Any Portlet
1. Action
2. Render
Render
Render

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 Portalisierung bestehender Struts-basierter Webanwendungen
– die Neuentwicklung von Struts-basierten Portlets
 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 ist die Verwendung von Struts in Portlet-
Projekten eingeschränkt
– Verarbeitung in zwei Phasen (Request- und Render-Phase)
– URL-Generierung erzwingt Austausch der <html/> Taglib
– Redirects und Forwards nicht möglich
– ServletResponse in Actions unsinnig

Struts & Portlets
 Aber ist Struts wirklich das beste Framework für
Portlet-Anwendungen?
 NEIN, denn:
– Struts basiert zu stark auf der Servlet API
(z. B. ServletRequest / ServletResponse in Actions)
– Struts Request Flow passt nicht zu zwei Phasen Verarbeitung der
Portlet API
– Limitierung der Möglichkeiten in der Portlet-Umgebung
 Weitere bekannte Nachteile von Struts:
– intrusives Framework (erzwungene Ableitungshierarchie)
– starres Design (Actions und Forms)
 Evtl. bessere Alternativen:
– JavaServer Faces (MyFaces: org.apache.myfaces.portlet)
– Spring MVC (“Spring Portlet MVC”)

Auswirkungen 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.
 Der Einbau eines Portal Servers in eine
Systemlandschaft mit nichtstandardisierten Schnittstellen
ist ein 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

Ende
 Vielen Dank für Ihre Aufmerksamkeit!
 Ihre Fragen und Kommentare bitte!

OOP 2006: Einsatz von Portaltechnologie in Bankanwendungen für Internet-Endkunden

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie OOP 2006: Einsatz von Portaltechnologie in Bankanwendungen für Internet-Endkunden

Ähnlich wie OOP 2006: Einsatz von Portaltechnologie in Bankanwendungen für Internet-Endkunden (20)

OOP 2006: Einsatz von Portaltechnologie in Bankanwendungen für Internet-Endkunden