- JSR 168
-
Portlets sind beliebig kombinierbare Komponenten einer Benutzeroberfläche, die von einem Portalserver angezeigt und verwaltet werden. Sie erzeugen Fragmente von HTML-Code und fügen sich in einer Portalseite ein. Typischerweise besteht eine Portalseite aus vielen, nicht-überlappenden Portlet-Fenstern („Kacheln“), in denen jeweils ein Portlet ausgeführt wird. Beispiele für Portlets sind E-Mail, Wetterbericht, Diskussionsforen oder Nachrichten.
Inhaltsverzeichnis
Konzept
Ein Portlet ist dabei eine Erweiterung des Servlets, so wie der PortletContainer (bspw. Pluto) eine Erweiterung des Servletcontainers darstellt (bspw. Tomcat). Portlets bilden auf der Clientseite eine einfach zu benutzende Oberfläche innerhalb des Browsers (Fenster mit Schaltflächen zum Maximieren, Minimieren, Editieren, Hilfe). Intern, also auf Serverseite, kann nun eine beliebige Anwendung liegen, die ihre Darstellung auf das Portlet weiterleitet. Sie entsprechen somit einer Sicht im Rahmen des Model View Controller-Konzeptes (MVC).
Standards
Portlets werden in der Regel für einen spezifischen Portalserver geschrieben und sind dann ohne Code-Änderung nur auf diesem lauffähig. Es gibt jedoch Bestrebungen, einen Standard zu schaffen; der wichtigste ist die Java Portlet Specification JSR 168. Portlets nach JSR 168 sind auf allen Portalservern ausführbar, die diesen Standard unterstützen.
Portlet Specification (JSR 168)
Am 29. Januar 2002 wurde der JSR 168 eingereicht, welcher die Aggregation mehrerer Inhalte in eine Portalseite standardisieren soll. Der Prozess wurde von Sun und IBM geführt. Accenture, Apache Software Foundation, BEA, Boeing, Borland, Bowstreet, Cap Gemini Ernst & Young, Citrix, DaimlerChrysler (jetzt Daimler AG), Documentum (jetzt EMC Corporation), Ever-Team, Enformia Ltd, Epicentric, Hewlett-Packard, Interwoven, Macromedia, McDonald Bradley, Oracle, Plumtree, SAP, Silverstream, Sybase, Tarantella, Inc. und Vignette unterstützten den Prozess und wurden nachträglich von Novell unterstützt. Der Community Review fand nach fast eineinhalb Jahren vom 16. April bis zum 23. Juni 2003 statt. Am 17. Juli 2003 begann der Public Review, der am 16. August beendet wurde und zur Veröffentlichung am 27. Oktober 2003 führte. Der JSR 168 stellt einen der wichtigsten Meilensteine in der Geschichte der Portale dar. Er ebnete den Weg für unabhängig vom verwendeten Portal entwickelte Portlets. Dies bietet den Kunden die Möglichkeit, Anwendungen zu schreiben, ohne sich an einen Anbieter binden zu müssen. Wenn auch dieser Gedanke nicht von allen Portalherstellern konsequent durchgesetzt wird, führte der JSR 168 dazu, dass es unterdessen viele Standardportlets gibt, die eine standardisierte Funktionalität unabhängig vom eingesetzten Portal anbieten und von vielen Drittanbietern auf den Markt kommen.
Die in der JSR 168 dokumentierten Portlet API 1.0 enthält 12 Klassen und 14 Interfaces. Von den 12 Klassen sind acht Exceptions. Die Spezifikation standardisiert das Zusammenspiel zwischen Portlet-Container und Portlets.
Geschichte
Portlet API (JSR 162)
IBM hat mit dem Java Specification Request 162 den Grundstein für eine Standardisierung einer Portal-API gelegt. Der JSR 162 wurde am 8. Januar 2002 dem Java Community Process übergeben. In der Anfrageformulierung wurde ein Standard gefordert, der auf dem existierenden Java Servlet Standard aufsetzen sollte. Dieser sollte so erweitert werden, dass die Portlets nicht mehr wie Servlets als einzelne Seiten gesehen werden, sondern dass sich Seiten aus mehreren Portlets zusammensetzen, die ein einheitliches Erscheinungsbild teilen, und gewisse Grundfunktionalitäten gemeinsam haben.
Am 20. Januar 2002 wurde dieser JSR zurückgezogen.
Java Portlet Specification (JSR 167)
Nur eine Woche nachdem IBM mit dem JSR 162 einen Vorschlag für eine Portlet API eingereicht hatte, zog Sun selbst nach, und brachte eine eigene Anfrage für eine Portletspezifikation in den Prozess ein. Diese wurde von den größten Konkurrenten IBMs unterstützt. Dazu gehörten unter anderem BEA, Plumtree, Vignette und Sybase. Interessanterweise wurden die Teile eines Portals auch hier als Portlets bezeichnet.
Auch diese Anfrage wurde am 20. Januar 2002 zurückgezogen.
Ausblick
Portlet API 2.0 (JSR 286)
Im Juli 2006 wurde das Early Draft 1 zur geplanten Portlet API 2.0 veröffentlicht. Die Ergänzungen konzentrieren sich vor allem auf die Kommunikation zwischen Portlets, der sogenannten Inter-Portlet Kommunikation (IPC). Ein Portlet soll einen Event zu beliebigen Portlets der Portal-Seite schicken können. Die Verarbeitung von Events geschieht in einer zusätzlichen Phase des Portlet-Lebenszyklus: der processEvent-Phase. Sie erfolgt vor der render-Phase und nach der processAction-Phase. Ein Event kann über Aufruf der Methode setEvent des EventResponse Interface versendet werden. Sie kann aus den Methoden processAction und processEvent heraus aufgerufen werden. Events können im Deployment-Descriptor definiert sein und in der processAction-Methode des EventPortlet Interface verarbeitet werden. Alternativ kann die Implementierung des GenericPortlet dazu verwendet werden, Events zu verarbeiten. Dazu muss die Methode, die einen Event empfangen soll, mit einer speziellen Annotation gekennzeichnet sein.
Ein Beispiel zur Verarbeitung eines Events mittels einer mit Annotation gekennzeichneten Methode.
@ProcessEvent(Retention=RUNTIME, name="com.acme.foo") public void processFoo(EventRequest request, EventResponse response) throws PortletException, java.io.IOException { //process event foo }Ein Beispiel zur Verarbeitung eines Events, der im Deployment-Descriptor definiert wurde.
<event-definition> <name>com.acme.foo</name> <java-type>java.lang.String</java-type> </event-definition> .... <portlet> ... <supported-processing-event> <name>com.acme.foo</name> </supported-processing-event> ... </portlet>void processEvent(EventRequest req, EventResponse resp) { ... Event event = req.getEvent(); if ( "com.acme.foo".equals(event.getName() ) ) { String payload = (String) event.getValue(); .... }Weblinks
Wikimedia Foundation.
