Portlets vs. REST und HTML5

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

30. April 2013Alexander Frommelt

Vor einigen Jahren waren Portlets und Portalserver sozusagen der Gral, um komplexe Portale zu realisieren. Es wurden viele Erwartungen in die Standardisierung von Portlets gesetzt: Wiederverwendbare Komponenten sollten entstehen und Portlets als Services bereitstehen. Frontends sollten hoch individualisierbar sein und Kosten durch den Einsatz von Portalservern, die bereits eine große Zahl von fertigen Anwendungskomponenten (sprich Portlets) mitbringen, gesenkt werden. Schaut man jedoch auf die aktuellen Entwicklungen, so spürt man einen Stillstand. Seit der Verabschiedung des Portlet-2.0-Standards gab es keine wirklichen Tendenzen in der Weiterentwicklung.

In der täglichen Praxis hat sich herausgestellt, dass Portalserver-Projekte, die auf Portlets setzen, Projekte mit hoher Komplexität sind und eine erhebliche Investition bedeuten. Vielfach müssen bestehende Portalanwendungslandschaften von Grund auf neu gestaltet werden. Eine sanfte Migration durch Austausch einiger Komponenten oder Implementierung nur neuer Anforderungen mit Portlets kann selten erfolgen, da sie der Homogenität und den Portalserverparadigmen widersprechen. Will man es trotzdem machen, so sind meistens einige Verrenkungen notwendig, um eine Integration zu erreichen.

Daher bietet es sich an, über Alternativen nachzudenken und die Ansätze, die Portalserver und Portlets bestimmen, unter den heutigen Architekturgesichtspunkten zu betrachten. Der HTML5-Standard ist zwar noch nicht verabschiedet, jedoch hat er einen gewissen Stabilitätsgrad erreicht und die Browser-Hersteller unterstützen HTML5 mit ihren aktuellen Implementierungen immer besser. REST (Representational State Transfer) als Programmierparadigma für Webanwendungen – 2000 von Roy Fielding in seiner Dissertation erstmalig beschrieben –  hat sich nicht zu Letzt dank der offenen Schnittstellen beliebter API’s der Shareconomics-Welt für die Implementierung von Webschnittstellen etabliert.

Portalserver und Portlets

Enterprise-Information-Portale stellen ein Baukastensystem zur Integration von Informationen, Benutzern und Prozessen über Unternehmensgrenzen hinweg bereit. Sie bieten einen sicheren und zentralen Einstiegspunkt in Form einer webbasierten Benutzerschnittstelle. Sie sind vorgesehen für die Aggregation und Personalisierung von Informationen durch applikationsspezifische Komponenten und haben als Markenzeichen die dezentralisierte Inhaltsverteilung und Inhaltsverwaltung, die Informationen stets aktuell halten.

Portalserver als Basissysteme für Enterprise-Information-Portale bringen in ihrem Leistungsumfang eine Reihe von Funktionalitäten wie portalübergreifende Security, Single Sign On, Anwendungsintegration und Prozessunterstützung, Content Management, Personalisierung sowie Collaboration und Groupware mit. Dies hat auf der einen Seite Vorteile, da die Anforderungen eines Enterprise-Information-Portals Out-of-the-box umgesetzt werden können. Auf der anderen Seite aber auch Nachteile; bspw. existiert damit häufig ein zweites Content-Management-System im Unternehmen, da bereits vor dem Einsatz des Portalservers Web Content in einem CMS verwaltet wurde.

Das Grundprinzip von Portalservern entsprechend dem JSR286 ist in der Abbildung 1 dargestellt und basiert auf der Aggregation von Content-Fragmenten, die von Portlets erzeugt werden. Portlets werden von einem Portlet Container gemanaged und erzeugen dynamischen Content in Form von Content-Fragmenten. In der Abbildung sind neben Portlets im lokalen Portlet Container auch Remote Portlets entsprechend der WSRP 2.0 Spezifikation dargestellt. Diese können durch einen Portalserver von einem entsprechenden Portlet Producer consumed werden.

Grundprinzip Portalserver

Grundprinzip Portalserver

Portlets haben ein feineres Request Handling mit Action, Event, Render und Resource Requests. Eine detaillierte Darstellung des Sequenceflow einer Request-Verarbeitung entsprechend der JSR286-Spezifikation ist in der folgenden Abbildung dargestellt:

Sequenceflow Request Verarbeitung (entnommen aus der JSR286 Spec)

Sequenceflow Request Verarbeitung (entnommen aus der JSR286 Spec)

Portlets wurden mit dem Ziel konzipiert, komponentenorientierte Benutzerschnittstellen für die Orchestrierung von Services einer Service-orientierten Architektur (SOA) zu ermöglichen. Sie waren einer der ersten Ansätze, um Komponenten als Software-as-a-Service bereitstellen zu können.

Die folgende Abbildung ist ein Beispiel für eine theoretische Anwendungsarchitektur mit Portlets und Remote Portlets, die in den unterschiedlichsten Umgebungen realisiert und betrieben werden. In der Realität führt dies zu erheblichen Schwierigkeiten, da unter anderem die Interpretation der Spezifikationen JSR286 bzw. WSRP2.0 durch die Portalserver im Detail abweichen.

Wenn alles so einfach wäre

Wenn alles so einfach wäre

Betrachtet man weiterhin heutige Benutzeroberflächen, so werden z.B. bei der Eingabe eines Suchparameters in einem Feld bereits beim Tippen mögliche Suchbegriffe zur Auswahl eingeblendet. Hierfür werden AJAX Requests implementiert, die die möglichen Suchbegriffe über einen Server Request selektieren. Die Portlet 2.0 Spezifikation unterstützt zwar AJAX Requests allerdings werden diese als Resource Requests behandelt. Dies schränkt die Möglichkeiten für AJAX Requests ein. Portlets sind also nicht die ideale Umsetzung von AJAX Requests auf dem Server.

Alternativer Ansatz mit HTML5 und REST

Betrachten wir nun einen alternativen Ansatz auf Basis von HTML5 und REST. Für die Content Aggregation können wir ein bereits existierendes CMS einsetzen. Dieses bietet eine mächtige Umgebung zur Verwaltung von Content und stellt Funktionalitäten wie Navigation oder Breadcrumps zur Verfügung, womit ein Großteil der Content-Elemente einer Seite umgesetzt werden kann.

Für die Realisierung einer auf einer Seite integrierten Anwendung bedienen wir uns des Single Page Patterns und beschreiben die entsprechenden Anwendungsseiten mit einem Seiten Template. Hierfür benötigen wir z.B. ein Javascript MVC Framework wie AngularJS. Die Anwendungsdaten werden über einen REST Service im JSON-Format geliefert. Die Realisierung der Seitenbeschreibungen kann so auch durch die Designer der Marketing-Abteilung erfolgen, die den Content und die Templates des CMS betreuen.

Die Eigenschaften von REST Services sind für den Betrieb von Anwendungen sehr vorteilhaft. Zum einen sind REST Services Resourcen-basiert zum anderen stateless. Darüber hinaus werden für den Zugriff auf die Resourcen nur die http-Methoden GET, POST, PUT DELETE benötigt.

Gerade der Stateless-Ansatz verschafft uns eine Reihe von Freiheiten. Zum einen können wir die Anwendungen wesentlich einfacher skalieren, da wir keine Session-Affinität beachten oder Session-Fail-Over-Maßnahmen vorsehen müssen. Außerdem können auch neue Releases unterbrechungsfrei eingespielt werden, da keine User Sessions auslaufen oder terminiert werden müssen. Auch die Umsetzung mit Hilfe von Cloud-Technologien kann auf diese Art und Weise einfach unterstützt werden. Durch die Beschränkung der übertragenen Daten des REST Services mit JSON auf die reinen Anwendungsdaten ohne zusätzliche Strukturelemente oder sonstige Informationsanreicherungen wird die übertragene Datenmenge deutlich reduziert. Darüber hinaus können für die HTML Templates die Caching-Mechnismen des Browsers ausgenutzt werden, da diese nur statische Informationen enthalten.

In der folgenden Abbildung ist eine entsprechende Anwendungsarchitektur dargestellt.

Anwendung mit REST Service und HTML5 Frontend

Anwendung mit REST Service und HTML5 Frontend

HTML 5 = HTML + CSS + Javascript

HTML5 bietet für die Umsetzung von Oberflächen entsprechend dem Responsive-Design-Ansatz eine optimale Basis, um diese umzusetzen. Mit HTML5 können Oberflächen feststellen, welche Darstellung für die aktuelle Display-Größe benötigt wird, um welche Plattform es sich handelt und welche Ausrichtung vorliegt. Damit können Oberflächen umgesetzt werden, die sich an die jeweiligen Endgeräte wie Smartphone, Tablet oder Notebook anpassen.  Hier im Blog können Sie einen ausführlichen Artikel zum Responsive-Design-Ansatz lesen.

Fazit

Portalserver und Portlets sind eine sehr komplexe und im gewissen Sinne monolithische Entwicklungsumgebung für Portale und Portalanwendungen. In vielen Fällen sind Anwendungskomponenten wie ein CMS, die einen Portalserver mitbringen, bereits vorhanden.

Einen Ansatz mithilfe von HTML5- und REST-Anwendungen als Single-Page-Anwendungen mit Responsive Design zu realisieren und mit den Fähigkeiten eines CMS in die bestehenden Content-Seiten zu integrieren, verspricht daher kostengünstiger zu sein und eine geringere Komplexität des Gesamtsystems zu ermöglichen. Darüber hinaus bietet der Ansatz eine einfachere Skalierbarkeit und kann in der heutigen Anwendungswelt auch mit Cloud-Ansätzen sehr gut umgesetzt werden.

Welche Erfahrungen haben Sie mit dem Einsatz von Portalservern und Portlets gemacht? Sehen Sie HTML5 und REST sowie die Responsive-Webdesign-Ansätze als zukunftsfähige Alternativen? Ich freue mich auf Ihre Kommentare.

Literaturverzeichnis

Angular JS. (n.d.). Retrieved from Angular JS: http://angularjs.org/

Fielding, R. (2000). Architectural Styles and the Design of Network-based Software Architectures. Retrieved from http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

JSR286 – Portlet 2.0 Spezifikation. (n.d.). Retrieved from JSR286 – Portlet 2.0 Spezifikation: http://jcp.org/en/jsr/detail?id=286

Responsive Design. (n.d.). Retrieved from Responsive Design: http://blog.adesso.de/responsive-webdesign-die-neue-generation-von-flexiblen-websites/

WSRP 2.0 Specifikation. (n.d.). Retrieved from WSRP 2.0 Specifikation: http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.html

 

Alexander Frommelt Alexander Frommelt ist Competence Center Leiter IT-Consulting Versicherungen bei adesso.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Tim Langer 30. April 2013

Die Idee des austauschbaren, wiederverwendbaren Stücks Software auf einer gemeinsamen Architektur ist hingegen in etwas veränderter Form wiedergeboren worden: Apps. Neben den SmartPhone- und Tabletlösungen gibt es hier ja mittlerweile auch webbasierte Ansätze.

Beispielsweise führen SharePoint 2013 und Office 2013 mit dem Microsoft App-Modell HTML/REST basierte Apps ein, die an das eigentlichen Portal oder die Office-Anwendung nur lose gekoppelt werden und über eine JavaScript API kommunizieren. Die Integration findet also im Browser statt. Auch wenn der Microsoft-Weg proprietär ist, zeigt er doch, dass ein Teil des Portlet-Gedankengutes seine Reinkarnation feiern kann.

Kommentar hinzufügen:

Ihr Kommentar: