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