Portlet Specification (JSR-168)

Am 29. Januar 2002 wurde der JSR-168 eingereicht, der eine API für Portalanwendungen standardisieren soll. Der Prozess wurde von Alejandro Abdelnur (Sun) und Stefan Hepper (IBM) geführt. Die initiale Expert Group bestand aus der Apache Software Foundation, BEA, IBM und Sun Microsystems. Unterstützer des JSRs waren ursprünglich Accenture, die Apache Software Foundation, BEA, Boeing, Borland, Bowstreet, Capgemini, Citrix, DaimlerChrysler, Documentum, Enformia Ltd, Epicentric, Hewlett-Packard, Interwoven, Macromedia, McDonald Bradley, Oracle, Plumtree, SAP, Silverstream, Sybase, Tarantella, Inc. und Vignette. Hewlett-Packard schied später aus, dafür kam Novell hinzu und Martin Scott Nicklous übernahm die Leitung der Wartung (Maintenance Lead).

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 dokumentierte 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 Specification 2.0 (JSR 286)

Im Juli 2006 wurde das Early Draft 1 zur Portlet Specification 2.0 veröffentlicht, am 12. Juni 2008 dann die finale Version verabschiedet. 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();
               ...
          }
     }

Portlet Specification 3.0 (JSR 362)

Im März 2013 wurde mit der Arbeit an der dritten Portlet-Spezifikation begonnen. Die Fertigstellung war für Ende 2014 geplant, tatsächlich wurde die Spezifikation April 2017 fertiggestellt. Folgende Änderungen wurden umgesetzt:

• Spezifizierung, wie Ressourcen zwischen Portlets geteilt werden können
• Optimierte Unterstützung für JavaServer Faces via JSR 378
• Ausrichtung an JEE-7-Spezifikationen, Servlet 3.1
• Expliziter Render State
• CDI 1.2 Integration
• Portlet Hub & XHR IPC