Portalkomponenten in Java

Das Portlet-Ökosystem

Wer sind nun die Produzenten und Konsumenten von Portalkomponenten? Verschiedene
Szenarien sind denkbar, aus deren Motivation heraus Portlets entwickelt
und eingesetzt werden. Ich beschreibe hier drei von ihnen:

  • Integration von (bestehenden) Applikationen
  • Portlets als Bestandteil von Standard-Softwarelösungen
  • Neue Anwendungen auf Basis von Portaltechnologie

Integration von Applikationen: Portale werden innerhalb von Unternehmen und
Organisationen vorrangig als Integrationsplattform eingesetzt. Das klassische
Beispiel sind Mitarbeiterportale, aber auch andere Zielgruppen werden bedacht
(Kunden, Partner, …). Eine Gemeinsamkeit bei all diesen Vorhaben ist, dass
Applikationen innerhalb einer neu zu schaffenden Plattform integriert werden
müssen. Meist geschieht dies in einer Mischung aus bestehenden und neu zu
implementierenden Anwendungen.

Da in diesem Zusammenhang häufig individuell entwickelte Backendsysteme
des Unternehmens („Legacy“) anzubinden sind, werden die entsprechenden
Portalkomponenten in der Regel unter der Federführung des Unternehmens
selbst realisiert. Denn nur das Unternehmen kennt die konkreten Anforderungen
und Schnittstellen.

Portlets als Bestandteil von Standard-Softwarelösungen: Verschiedene Softwarehersteller
haben Portalkomponenten als eine interessante Möglichkeit entdeckt,
um eine Bedienoberfläche zu ihren Produkten anzubieten, meist optional
zur althergebrachten Oberfläche. Dieser Ansatz ist beispielsweise für ERP (Enterprise Resource Planning) oder
CMS (Content Management Systeme)-Produkte sinnvoll, ein weiteres prominentes Beispiel sind E-Mail-Lösungen. Portlets kommen hier als Alternative zu Rich Clients zum Einsatz,
teilweise bereits als exklusiver webbasierter Zugriffsmechanismus auf die Systeme.
Attraktiv ist dies vor allem, da die Hersteller Kunden die Integration in Ihre bestehenden Portalumgebungen „out-of-the-box“ anbieten können. Eine
Integration durch Individualentwicklung von Seiten des Kunden (s.o.) kann
dann entfallen.

Als Entwickler derartiger Portalkomponenten kommen in erster Linie die Hersteller
der anzubindenden Standardsoftwareprodukte selbst in Frage. Diese kennen
die Systeme am besten und haben auch bereits den Kontakt zu Unternehmen,
die diese einsetzen. In diesem Fall werden die Portalkomponenten einfach
mit dem Produkt mitgeliefert. Es haben sich allerdings auch Unternehmen darauf
spezialisiert, Portalintegration für Standardsoftwaresysteme anderer Hersteller
anzubieten. Diese oft hochspezialisierten Unternehmen treten gerne als
Business Partner großer Softwarehersteller auf.

Anwendungen auf Basis von Portaltechnologie: Die beiden zuvor beschriebenen
Szenarien sahen Portale in ihrer klassischen Rolle als Integrationsplattform
für Applikationen und Inhalte. Portalkomponenten lassen sich jedoch auch als
Frontendtechnologie für neue Software verwenden, ohne diesen Integrationsaspekt
im Fokus zu haben. In einer klassischen Mehrschichtarchitektur dienen
sie dann als Präsentationsschicht, um von bestimmten Eigenschaften der verwendeten
Portalplattform zu profitieren. Anforderungen wie Mehrmandantenfähigkeit,
die Unterstützung unterschiedlicher Endgeräte oder die Realisierung
rollenbasierter Anwendungen lassen sich so unter Umständen leichter umsetzen.
Wenn als Alternative eine „normale“ Webapplikation realisiert werden
muss, sind auch beim Rückgriff auf Frameworks bestimmte Aspekte individuell
zu entwickeln, die im Portalprodukt bereits „out-of-the-box“ verfügbar wären.
Auch die Modularität, die mit separaten Portlet-Anwendungen für Entwicklung,
Deployment und Betrieb erreicht werden kann, ist bei großen Applikationen
unter Umständen attraktiv.

Früher sind derartige Ansätze häufig an den Lizenzkosten für die Portalprodukte
und/oder an deren Komplexität gescheitert. Mit der Verfügbarkeit schlanker
und freier Lösungen, deren Lizenz sogar die Einbettung in eigene Produkte
erlaubt, wird sich dies in Zukunft ändern. Ein praktisches Anwendungsbeispiel
stellt die webbasierte Managementkonsole von Apache Geronimo dar, die
auf dem Portlet Container Pluto basiert (siehe Abbildung 4).

Abb. 4: Die Web-Console von Apache Geronimo basiert auf Pluto

Grundbegriffe der Portlet-Spezifikation
Formal ist ein Portlet eine Java-Webkomponente. Oft wird damit jedoch auch
das Vorkommen dieser Komponente auf einer Portalseite eines bestimmten
Benutzers als Portlet bezeichnet. Das ist bequem und wird in diesem Artikel auch
so gehandhabt. Portlets werden zu Portlet-Applikationen zusammengefasst.
Technisch ist eine Portlet-Applikation eine Web-Applikation gemäß der Servletspezifikation,
mit Deployment Deskriptor (web.xml) und allem Drum und
Dran. Sie enthält außerdem eine zusätzliche XML-Datei, die Portlet-Spezifika
beschreibt (portlet.xml).

Der Portlet-Container ist die Laufzeitumgebung für Portlet-Applikationen. Er
steuert den Lebenszyklus der Komponenten und stellt bestimmte Dienste bereit
(z.B. das Persistieren benutzerspezifischer Konfigurationen). Interessanterweise
ist er eine Erweiterung des Servlet Containers und muss dessen gesamte
Funktionalität implementieren. Sinnvollerweise nutzen konkrete Portlet-Container
daher bestehende Servlet-Container, anstatt diese Funktionalität selbst
bereitzustellen.

Das Portal steht zwischen dem Portlet-Container und den Benutzern. Insbesondere
verwaltet es die Portalseiten der Benutzer und aggregiert das Markup der
beteiligten Portlets. Die Portlet-Spezifikation beschreibt die Funktionen eines
Portals nicht konkret. Wie beispielsweise die Platzierung von Portlets auf Seiten
realisiert wird, steht dem Softwarehersteller frei. Sie finden in der API auch
keine Klasse oder Schnittstelle, die eine Portalseite oder das Portal selbst
beschreibt. Es ist daher nicht möglich, allgemeine Administrationswerkzeuge
für diese Aufgabe zu entwickeln. Die meisten Portallösungen erlauben es übrigens,
ein Portlet auch mehrmals auf einer Seite zu platzieren. In der Regel werden
die Exemplare dann durch Administrator oder Anwender unterschiedlich
konfiguriert.

Das Portal nimmt innerhalb der Spezifikation die Rolle eines Platzhalters für
eine Webapplikation ein, die mehr oder weniger eng mit dem Portlet Container
verbunden ist. Es hält die für den Benutzer wahrnehmbare(n) Oberfläche(n)
bereit, reagiert auf Ereignisse und löst über den Portlet-Container Lebenszyklusmethoden
der Portlets aus. Zum Beispiel ermöglicht das Portal dem Benutzer,
Einfluss auf den Portletzustand zu nehmen.

Stefan Zörner arbeitet als Anwendungsarchitekt, Berater, Trainer und Coach in der Softwareentwicklung. Er ist Buchautor, veröffentlicht regelmäßig Artikel (u.a. für das Java Magazin und bei developerWorks) und ist Sprecher auf Konferenzen. Fachliche Schwerpunkte seine Tätigkeit sind Portallösungen und Verzeichnisdienste.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.