Date post: | 11-Apr-2017 |
Category: |
Technology |
Upload: | joeynbg |
View: | 65 times |
Download: | 1 times |
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 1
Einsatz von Portaltechnologie in
Bankanwendungen für Internet-Endkunden
Ralph Henze
Sparda-Datenverarbeitung eG [email protected]
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 2
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 3
Ü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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 4
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.
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 5
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 6
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?
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 7
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
- ...
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 8
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)
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 9
Portalstrategie
Integrations- bzw. Transaktionsportal
Kein Personalisierungsportal
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 10
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 11
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)
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 12
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 13
Ü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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 14
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 15
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 16
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
WebSphere Application Server
WebSphere Portal Server Client
CUR
Portlet Container Member
Repository
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 17
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 18
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 19
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
WebSphere Application Server
WebSphere Portal Server Client
CUR
Portlet Container
Member
Repository
Login
Command
Logout
Command
Portlet
Service
Filt
er
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 20
Ü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
Anwendungen Verbundpartner
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 21
Ü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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 22
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 23
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 24
Struts Portlet Applications
J2EE Web Container Portlet Container
Web
Browser
Struts Portlet Application
Controller
config
Action
Model View
HTTP
Request
HTTP
Response
Portal Server
Web Application
Struts Portlet Application
Controller
config
Action
Model View
Portal Controller
Servlet
Page
Aggregation
Portlet
Invoker
Any Portlet Application
Any Portlet
1. Action
2. Render
Render
Render
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 25
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 26
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 27
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”)
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 28
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
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 29
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.
19.01.2006 © 2006 Sparda-Datenverarbeitung eG 30
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