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

1. Alexander Frommelt | adesso AG
Wozu Portlets – reichen HTML5
und Rest nicht aus für moderne
Portale

2. 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

3. Portale
Anforderungen und Beispiele

4. 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.

5. Beispiele für aktuelle Portale

6. 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

7. 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 Passwort
Gruppen ermitteln
Portal Login
WAS Security
Subject
Portal Startseite
JAAS Login
Portal_LTPA
WAS
Security
Benutzerregistrierung
Federated
Repository
Teilnehmerverwaltung
LDAP
·∙
·∙
·∙ JAAS login
·∙ Session anlegen
·∙ Laden Portalbenutzer
XML Zugriff
PUMA/VMM
Login
Einstiegspunkte
Benutzerdefinierter
Repository Adapter
Scripting
Legende
WebSphere
Komponente
Implementierung

8. Herausforderungen (2)
• Betrieb / Freigabeprozesse
• Qualitätsmanagement
– Prozesse
– Quality Gates
• Business Analyse
• Styleguide
• Releasemanagement

9. Portalserver und Portlets

10. Typische Funktionen von
Portal-Servern
• Anwendungsintegration /
Prozessunterstützung
• Content-Management-
System / Information Retrieval
• Individuelle Anpassung der
Arbeitsumgebung
• Collaboration / Groupware
• Security / Single-Sign-On /
Benutzerverwaltung

11. 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

12. Eigenschaften Portlets
• Können Konfigurations und Benutzerspezifische Informationen
speichern
• Portlet Session (zwei Scopes): speichert Transient Data

13. Portalserver: Grundprinzip

14. SequenceFlow Portlet

15. 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

16. Wenn alles so einfach wäre

17. Alternative
HTML5 und Rest

18. 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.

19. 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

20. • 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

21. 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

22. Session Handling und Client Control
Prinzip
Business Service
Model
Controller
View View View

23. Prinzip
Controller Model: Rest View
Load Entries
Populate Entries
Update

24. 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

25. 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

26. 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"
}

27. 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, …

28. HTML 5 – Featurecluster
Semantics
Offline & Storage
Device Access
Connectivity
Multimedia
Graphics & Effects
Performance & Integration
CSS 3
= HTML + CSS + Javascript

29. 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

30. 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

31. 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

32. 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

33. Fazit

34. 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.

35. 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

36. Keep It
Simple and Stupid

37. 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

38. Security OAuth