Die Portal- und Portlet-Technologie ist kein Hypethema. Vielmehr haben sich diese Technologien langsam, dafür aber sehr kontinuierlich in den letzten Jahren durchgesetzt und Einzug in viele Unternehmen gehalten. Sicherlich, zu den Hochzeiten der dot.com-Ära waren Portale fast so etwas wie ein Garant für hohe Firmenbewertungen und Millioneneinnahmen bei den Investoren. Doch dieses Bild hat sich in den letzten Jahren stark relativiert. Während viele Firmen die damalige Zeit nicht überlebt haben, hat sich die gesamte Portaltechnologie nicht nur gehalten, sondern auch stark weiterentwickelt. Die Portaltechnologie ist eine der wichtigsten Technologien für umfangreiche, komplexe und dynamische Webprojekte.

Die vorliegende Artikelserie führt in die Welt der Portale und Portlets ein. Zunächst wird im ersten Teil auf die Grundlagen von Portalen und Portlets eingegangen und ein kurzer Abriss über die Portlet-Spezifikationen gegeben. In den folgenden Artikeln wird auf die neuen Funktionen der aktuellen Portlet-Spezifikation 2.0 (JSR-286) eingegangen. Im letzten Teil der Artikelserie werden die Vorteile einer Kombination von Portlets und den JavaServer Faces vorgestellt (JSR-301).

Bevor wir uns die Technologie von der technischen Seite anschauen, sollen zunächst die Begriffe „Portal“ und „Portaltechnologie“ geklärt werden. Der Portalbegriff ist an sich nirgendwo spezifiziert oder definiert. Selbst Wikipedia liefert lediglich eine eher allgemeine Einführung dazu. Oftmals wird der Begriff des Portals (fälschlicherweise) für Webseiten eingesetzt, die ein etwas größeres Angebot aufweisen können, sich einem speziellen Thema widmen oder auch redaktionell betreut sind. Schnell ist die Rede von einem „Portal für IT-Berater“ oder dem zentralen „Ferrari-Portal für Europa“. Doch sind diese Webseiten tatsächlich Portale? Nach der Meinung des Autors eher nicht. Vielmehr ist ein Portal ein System, das folgende Charakteristika vorweisen kann:

• Aggregation von Inhalten und Services
• Personalisierung
• Content-Management
• Single Sign-on
• Zentrale Security-Aspekte

Diese Liste ist natürlich nicht vollständig, zeigt jedoch eine Anforderung an heutige Portallösungen. Somit versteht sich von selbst, dass nicht jede Website als Portal bezeichnet werden kann. Dagegen kann der Portalauftritt von Google – iGoogle – zu Recht als Portal verstanden werden (Abb.1).

Es ist möglich, sich in iGoogle zu registrieren und anzumelden. Dabei genügt eine Anmeldung in iGoogle für sämtliche darin enthaltenen Funktionen (Kriterium: Single Sign-on). Einmal im Portal angemeldet, können eigene Einstellungen der Portlets (Welche Portlets möchte ich sehen? Welche Informationen sollen sie liefern etc.?) abgespeichert werden. (Kriterium: Personalisierung). In iGoogle sind verschiedenste Dienste zusammengefasst. So können aktuelle Nachrichten von Financial Times Deutschland oder von JAXenter.de angesehen werden, Börsenticker, eine Wettervorhersage oder auch den Witz des Tages (Kriterium: Aggregation von Diensten und Inhalten).

Um solche Portale aufzubauen, muss man natürlich nicht in jedem Projekt auf der grünen Wiese beginnen. Auf dem Markt gibt es mittlerweile zahlreiche Lösungen von kommerziellen Anbietern (IBM WebSphere Portal, Oracle Portal, BEA Web Portal etc.) sowie von Open-Source-Initiativen (JBoss Portal, Liferay Portal, Apache Jetspeed etc). Zwar weisen alle Portalsysteme oftmals ähnliche Funktionalitäten auf, im Detail existieren grundlegende Unterschiede. Es existiert leider (noch) kein Standard für Portale!

Über Portale zu Portlets

Ein typisches Merkmal von Portalen ist, wie bereits beschrieben, die Aggregation von Inhalten und Diensten. In der Regel besteht eine Portalseite aus mehreren Bausteinen. Diese einzelnen Bausteine sind die Portlets, in denen eine Anwendung ablaufen kann. Portlets sind somit (Web-) Anwendungen, die innerhalb eines so genannten Portlet-Containers ablaufen können. Dabei ist ein Portlet-Container der Lebensraum für Portlets, ähnlich wie ein Servlet-Container ein Lebensraum für Servlets ist. Portlets sind im Gegensatz zu Portalen standardisiert. Bereits 2003 wurde der erste Portlet-Standard, der JSR-168, im Rahmen des Java Community Process verabschiedet. Dieser definiert, wie ein Portlet funktioniert, welche Interfaces notwendig sind und wie Funktionalität mit Portlets umgesetzt werden kann. Der JSR-168 behandelt die grundlegenden Fragestellungen für eine Portlet-Entwicklung. Da dieser Standard schon einige Jahre alt ist und auch viele Fragen nicht beantwortet wurden, wurde im Sommer dieses Jahres eine neue Version dieses Standards veröffentlicht: der JSR-286 (wird auch als Portlet 2.0 bezeichnet). Da heutzutage moderne UI-Frameworks wie JavaServer Faces fast unabkömmlich sind, wird aktuell innerhalb des JSR-301 eine Brückenlösung zwischen JSF und Portlets erarbeitet.

Der Portlet-Lebenszyklus

Portlets leben in einem Portlet-Container. Innerhalb dieses Containers durchlaufen Portlets einen fest definierten Lebenszyklus (Abb. 2). Dieser erinnert stark an Servlets, weist jedoch einige Besonderheiten auf.

Werden Portlets in einem Container verfügbar gemacht, wird zunächst die Init-Phase durchlaufen. Hierin können entsprechende Initialisierungsfunktionalitäten aufgenommen werden. Ebenso steht eine Destroy-Phase zur Verfügung, wenn das Portlet außer Betrieb genommen wird. Sowohl die Init- wie auch die Destroy-Phase werden nur einmal durchlaufen, es sei denn, ein Portlet wird nach dem Destroy wieder erneut in Betrieb genommen. Am wichtigsten bzw. auch charakteristisch für Portlets sind die Phasen Render und Action, die beliebig häufig aufgerufen werden können. Hintergrund ist folgender: Portlets sind in der Regel nicht alleine auf einer Portalseite angeordnet, sondern teilen sich den Platz mit anderen Portlets. Jetzt kann auf einer Seite in einem speziellen Portlet eine Aktion angestoßen werden, z.B. ein Submit-Button gedrückt werden. Als Folge muss eine Aktion speziell für dieses eine Portlet ausgelöst werden. Da danach jedoch die komplette Seite neu dargestellt (also gerendert) werden muss (Ajax lassen wir hier bewusst außer Acht), muss dazu jedes Portlet seinen Output neu erzeugen. Aus diesem Grund sind die beiden Phasen als getrennt realisiert. Es muss nicht jedes Mal zunächst eine Aktion und dann ein Rendering angestoßen werden, es kann durchaus nur ein Rendering in einem Portlet aufgerufen werden (ohne Aktion). Per Definition wird eine Aktion in der Action-Phase ausgeführt, die Render-Phase erzeugt lediglich Markup. Die Portlet-API spiegelt genau diesen Lebenszyklus wider.

Ein erstes Portlet

Ein erstes einfaches Portlet erhält man, wenn eine Klasse das Interfaces javax.portlet.Portlet implementiert. Dieses Interface definiert Methoden für die oben erwähnten Lebenszyklusphasen. Die erwähnten Action- und Render-Phasen werden durch die Methoden render und processAction abgebildet. Ebenso stellt das Interface die Methoden init und destroy bereit. In der Praxis wird jedoch äußerst selten das Portlet-Interface direkt implementiert. Vielmehr wird die Convenience-Klasse javax.portlet.GenericPortlet verwendet, die ebenfalls durch die Spezifikation festgelegt ist. Darin sind bereits alle notwendigen Methoden implementiert und mit nützlichen Basisfunktionen ausgestattet. Üblicherweise leitet ein eigenes Portlet von GenericPortlet ab und überschreibt die relevanten Methoden. So existieren z.B. schon Methoden für die einzelnen Window States und Portlet Modes, sodass sehr komfortabel eine Methode doView, doEdit oder doHelp verwendet werden kann, anstatt in der selbst implementierten render-Methode dies extra auswerten zu müssen. In Listing 1 ist ein einfaches Portlet abgebildet, das lediglich einen Willkommenstext ausgibt.

Listing 1: Ein einfaches erstes Portlet

1. public class HelloWorld extends GenericPortlet{
3. @Override
4. protected void doView(RenderRequest request, RenderResponse response)
5. throws PortletException, IOException {
6. response.setContentType("text/html");
7. PrintWriter writer = response.getWriter();
8. writer.println( "Hallo neue Portlet Welt" );
9. writer.println( "<br><br>" );
10. writer.println( "Herzlichen Glückwunsch zum ersten Portlet !!!" );
11. writer.println( "<br><br>" );
12. }
13. }

Neben der Portlet-Klasse ist für ein Deployment in einem Portlet-Container zudem ein entsprechender Deployment-Deskriptor notwendig. Der Deskriptor wird durch eine Datei portlet.xml realisiert, die parallel zur web.xml im WEB-INF-Verzeichnis der Anwendung abgelegt ist. Dieser gibt an, mit welchem Namen das Portlet angesprochen werden kann, wie die Portlet-Klasse lautet, welche Portlet Modes unterstützt werden und vieles mehr. Abbildung 2 zeigt den Ausschnitt aus einem Deployment-Deskriptor. Ansonsten ist ein Portlet-Projekt analog zu einem Webprojekt aufgebaut.

Listing 2: portlet.xml für das Demo-Portlet

1. <?xml version="1.0" encoding="UTF-8"?>
2. <portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4. xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd
5. http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0">
6. <portlet>
7. <description>HalloWelt Beispiel</description>
8. <portlet-name>HalloWeltPortlet</portlet-name>
9. <portlet-class>de.jsfportlets.sample.portlet.HelloWorld</portlet-class>
10. <expiration-cache>0</expiration-cache>
11. <supports>
12. <mime-type>text/html</mime-type>
13. <portlet-mode>VIEW</portlet-mode>
14. </supports>
15. <supported-locale>en</supported-locale>
16. <portlet-info>
17. <title>Hallo Portlet Welt</title>
18. </portlet-info>
19. </portlet>
20. </portlet-app>