Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?

Post on 28-Nov-2014

1,689 views 2 download

description

Präsentation von der JAX 2013 zu Portalen, Portlets, REST und HTML5.

transcript

Alexander Frommelt | adesso AG

Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale

Alexander Frommelt [frommelt@adesso.de] Competence Center Leiter IT Consulting Versicherungen, adesso AG Tätigkeitsschwerpunkte: Ø  Konzeption und Implementierung von Kunden- und

Vertriebsportalen, Moderne Portaltechniken Ø  Serviceorientierte Architekturen Ø  Beratung von Versicherungen und Finanzdienstleistern

Ø  adesso gehört zu den führenden IT-Dienstleister im deutschsprachigen Raum

Ø  Beratung und individuelle Softwareentwicklung

Ø  Mehr als 1000 Mitarbeiter

Ø  Zu den wichtigsten Kunden zählen die Allianz, Hannover Rück,

Ø  Union Investment, Westdeutsche Lotterie, Zurich Versicherung, DEVK und DAK

Portale Anforderungen und Beispiele

Enterprise Information Portal

•  Baukastensystem zur Integration von Informationen, Benutzern und Prozessen über Unternehmensgrenzen hinweg.

•  Sicherer und zentraler Einstiegspunkt meist in Form einer webbasierten Benutzerschnittstelle.

•  Vorgesehen für die Aggregation und Personalisierung von Informationen durch applikationsspezifische Komponenten.

•  Dezentralisierte Inhaltsverteilung und Inhaltsverwaltung, die Informationen stets aktuell halten.

Beispiele für aktuelle Portale

Häufig gestellte Anforderungen an Portale

•  24 x 7 Hochverfügbarkeit •  Stabilität •  Skalierbarkeit •  Elastizität •  Release Update im laufenden Betrieb •  Service Orientierung •  Single Sign On •  Individualität (White Label, Wiedererkennung, …) •  Multi – Kanalanbindung •  Time to Market

Herausforderungen (1) •  Application Integration

– Oberflächen – Geschäftslogik – Datenbank

•  Berechtigung (Authentifikation, Authorisation)

•  CMS Integration •  Application Security

(Schutz der Anwendung vor Angriffen) •  Wiederverwendung

JSR 286: Portlet 2.0 Spec

JSR 127: Java Server Faces

JSR 301: Portlet Bridge Spec.

Login User commandLogin Portlet

Login URL

Teilnehmernummer und Passwort

PreLogin

Authentificate

PostLogin

Redirect

WAS Login

Suchen und Validieren TNR und PasswortGruppen ermitteln

Portal Login

WAS Security Subject

Portal Startseite

JAAS Login Portal_LTPA

WAS Security

BenutzerregistrierungFederated Repository

Teilnehmerverwaltung

LDAP

·∙·∙·∙ JAAS login·∙ Session anlegen·∙ Laden Portalbenutzer

XML Zugriff

PUMA/VMM

Login Einstiegspunkte

Benutzerdefinierter Repository Adapter

Scripting

Legende

WebSphere Komponente Implementierung

Herausforderungen (2) •  Betrieb / Freigabeprozesse •  Qualitätsmanagement

–  Prozesse – Quality Gates

•  Business Analyse •  Styleguide •  Releasemanagement

Portalserver und Portlets

Typische Funktionen von Portal-Servern

•  Anwendungsintegration / Prozessunterstützung

•  Content-Management-System / Information Retrieval

•  Individuelle Anpassung der Arbeitsumgebung

•  Collaboration / Groupware

•  Security / Single-Sign-On / Benutzerverwaltung

Eigenschaften Portlets •  Von einem Portlet Container gemanaged •  Erzeugen dynamischen Content •  Generieren nur Markup Fragmente

Das Portal aggregiert die Markup Fragmente in komplette Portal Seiten

•  Können nur über von Portlet API erzeugte Urls aufgerufen werden

•  Feineres Request Handling: Action, Event, Render und Resource Request

•  Können vielfach auf einer Portal Seite existieren

Eigenschaften Portlets •  Können Konfigurations und Benutzerspezifische Informationen

speichern •  Portlet Session (zwei Scopes): speichert Transient Data

Portalserver: Grundprinzip

SequenceFlow Portlet

Ziele von Portlets •  Service Orientierte Architektur widerspricht

monolithischen Applikationen •  Einzelne Services werden zu Applikation orchestriert •  Orchestrierung benötigt komponentenorientierte

Benutzerschnittstellen für die Services •  Portlets bieten entsprechendes UI Modell •  Portlet UI Komponenten können in größere UI‘s mit

konsistentem Look and Feel aggregiert werden

Wenn alles so einfach wäre

Alternative HTML5 und Rest

Unterteilung in Komponenten

Unterteilung einer Portalseite in mögliche Content Komponenten

•  Großteil der Komponenten wird durch marktgängige kommerzielle und OpenSource CMS Systeme bereits abgedeckt.

•  Verwaltung der Content-Seiten erfolgt innerhalb des CMS-Systems.

•  Content Aggregation bzw. Layouting erfolgt über die Mechanismen des CMS-Systems

•  CMS Systeme sind meisst schon vorhanden, selten werden Webseiten noch direkt erstellt.

Beispiel Suche (mit Portlet)

•  Search Engine stellt Rest Schnittstelle zur Verfügung

•  Skalierung wird durch Portalserver bestimmt

•  Portal-State wird im Portalserver gehalten

•  Portalserver bringt CMS mit

Portal Server

Search Engine

Browser

CMS

FW

CSS JS HTML

Portlet

•  HTTP ist Stateless per Definition •  Für einen geführten Weg durch eine Anwendung

benötigen wir einen Server State oder eine Kopie auf der Client-Seite in Form einer eindeutigen Session

•  Die Verteilung von Sessions ist komplex und schränkt die Skalierbarkeit ein

•  AJAX wird für Usability und Resource Optimierung gebraucht

Beispiel Suche (Rest + JS)

•  Rest Schnittstelle Search Engine wird direkt angesprochen

•  JS, CSS, Templates können im Browser gecached werden

•  Search Engine kann unabhängig von CMS skaliert werden

•  Datenübertragung minimal (JSON Daten)

•  Bestehendes CMS kann wiederverwendet werden

Search Engine

Browser

CMS

HTTP/ REST / JSON

FW

CSS JS HTML

Session Handling und Client Control

Prinzip

Business Service

Model

Controller

View View View

Prinzip Controller Model: Rest View

Load Entries

Populate Entries

Update

function SearchResultListCtrl($scope, $http) { $http.get('search/result.json').success(function(data) { $scope.searchResults = data; }); }

[ { “titel": “RestServices”, “beschreibung": “Beschreibung von RestServices", ... }, ... ]

<ul class=„searchResults"> <li ng-repeat=„entry in searchResults | filter:query "> {{entry.titel}} <p>{{entry.beschreibung}}</p> </li> </ul>

View

Model

Controller

Beispiel AngularJS

RESTful Roy Fielding Dissertation 2000: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Grundprinzipien: •  Resource Based •  Uniform Interface •  Stateless •  Cacheable •  Client-Server •  Layered System •  Code on Demand

REST und JSON ein gutes Team •  HATEOS (Hypertext As The Engine Of Application

State) –  Response enthält Links auf Actions die auf der aktuellen

Resource ausgeführt werden können

{ "members": [ { "href": "http://example.org/coll/1" }, { "href": "http://example.org/coll/2" }, { "href": "http://example.org/coll/3" }, .... { "href": "http://example.org/coll/N" }, ], "next": "http://example/coll?page=2" }

Was brauchen wir fürs Frontend

•  HTML 5 •  CSS 3 •  JavaScript •  Javascript Template Engine

z.B. Dust JS, mustache, … •  JS Framework

z.B.: AngularJS, Jquery, Javascript MVC, Bootstrap, …

HTML 5 – Featurecluster

Semantics

Offline & Storage

Device Access

Connectivity

Multimedia

Graphics & Effects

Performance & Integration

CSS 3

= HTML + CSS + Javascript

Responsive Design •  Anpassungsfähiges Layout an

–  Displaygröße –  Plattform –  Ausrichtung

•  Bestandteile von Responsive Design –  flexible Layout-Raster –  anpassungsfähige Grafiken –  dynamische Skalierung

•  Ein Website deckt mit verschiedenen Layouts alle Endgeräte ab

Single Sign On •  Bspw. Single Sign On mit Oauth 2.0 •  Verbreitetes, Token Basiertes Authentifikations

Protokoll •  Facebook, Google, Cloud Foundry stellen z.B. OAuth

Authentification bereit •  Jboss Resteasy unterstützt Oauth

BrowserCache Put it together

App Server

App Server

Browser Browser Storage

JS JS

JS

HTML

...

HTML

Web Server … Web

Server

HTTP/ REST / JSON

HTML

FW

FW

Skalierbarkeit und Performance •  Stateless Ansatz erleichtert die Skalierbarkeit •  Updates können einfach produktiv gehen. •  Keine spezielle Session Datenbank oder sonstige

Vorkehrungen für Fail Over im Cluster Betrieb notwendig

•  Übertragene Datenmenge ist deutlich geringer •  Vorsicht: Latenzzeiten haben erheblichen Einfluss

auf Performance

Fazit

Fazit •  Frontends für Service Orientierte Architekturen können rein auf

Web Technologie basieren •  Bestehende CMS Systeme können wieder verwendet werden. •  Single Sign On kann z.B. mit Oauth realisiert werden •  Skalierbarkeit des Gesamtsystems ist leichter gewährleistet •  Die niedrigere Komplexität des Gesamtsystems erhöht die

Verfügbarkeit. •  Bestehende Caching Mechanismen werden ausgenutzt. •  Rest Services können auch als PHP, Python, … bereitgestellt

werden. •  Der Anwendungs-State wird auf dem Client gehalten.

Ausblick •  NodeJS

–  Content Aggregation auf dem Server –  Wiederverwendung des JSCodes

•  NoSQL Datenbanken Bieten häufig REST/JSON Interfaces für Datenzugriff

•  Nutzung von Public und Private Clouds

Keep It Simple and Stupid

Vielen Dank für Ihre Aufmerksamkeit.

Alexander Frommelt adesso AG T +49 89 189316-22 Line of Business Insurance F +49 89 189316-99 Leiter Competence Center IT Consulting M +49 178 2808023 Landsberger Str. 110 E frommelt@adesso.de 80339 München www.adesso.de

Security OAuth