40
Portaltechnologie in Bankanwendungen für Internet-Endkunden Copyright © 2005 Sparda-Datenverarbeitung eG Machet die Tore weit! Portaltechnologie in Bankanwendungen Ralph Henze Sparda-Datenverarbeitung eG [email protected] www.sparda.de

Banking portal

  • Upload
    joeynbg

  • View
    42

  • Download
    0

Embed Size (px)

Citation preview

Page 1: 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

[email protected]

www.sparda.de

Page 2: Banking portal

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

Page 3: Banking portal

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

Page 4: Banking portal

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.

Page 5: Banking portal

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

Page 6: Banking portal

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?

Page 7: Banking portal

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

Page 8: Banking portal

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

Page 9: Banking portal

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

Page 10: Banking portal

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

Page 11: Banking portal

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)

Page 12: Banking portal

Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG

Warum ein Portal Server?

Portalstrategie:

Integrations- bzw. Transaktionsportal

Kein Personalisierungsportal

Page 13: Banking portal

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

Page 14: Banking portal

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

Page 15: Banking portal

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)

Page 16: Banking portal

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

Page 17: Banking portal

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

Page 18: Banking portal

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

Page 19: Banking portal

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

Page 20: Banking portal

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

Page 21: Banking portal

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

Page 22: Banking portal

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

Page 23: Banking portal

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

Page 24: Banking portal

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

Page 25: Banking portal

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

Page 26: Banking portal

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

Page 27: Banking portal

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

Page 28: Banking portal

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

Page 29: Banking portal

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

Page 30: Banking portal

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

Page 31: Banking portal

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

Page 32: Banking portal

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

Page 33: Banking portal

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

Page 34: Banking portal

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

Page 35: Banking portal

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

Page 36: Banking portal

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

Page 37: Banking portal

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

Page 38: Banking portal

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

Page 39: Banking portal

Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG

The End

Page 40: Banking portal

Portaltechnologie in Bankanwendungen für Internet-Endkunden – Copyright © 2005 Sparda-Datenverarbeitung eG

Vielen Dank!

[email protected]

www.sparda.de