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 [email protected]


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












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


WebSphere Portal 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



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



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



CUR

Portlet Container

Member

Repository

Login

Command

Logout

Command

Portlet

Service

Filt

er


Überblick Gesamtarchitektur

Client

Banken Kernsystem (IBM zSeries Mainframe)


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


Überblick












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

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


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

Technology

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