Einführung in die Portlet-Spezifikation, Teil 1

Mit dem Aufkommen einer zunehmenden Anzahl von Unternehmensportalen haben verschiedene Anbieter unterschiedliche APIs für Portalkomponenten erstellt, die als Portlets bezeichnet werden. Diese Vielzahl inkompatibler Schnittstellen führt zu Problemen für Anwendungsanbieter, Portalkunden und Portalserveranbieter. Um diese Probleme zu lösen, wurde JSR (Java Specification Request) 168, die Portlet-Spezifikation, gestartet, um die Interoperabilität zwischen Portlets und Portalen bereitzustellen.

JSR 168 definiert Portlets als Java-basierte Webkomponenten, die von einem Portlet-Container verwaltet werden und Anforderungen verarbeiten und dynamischen Inhalt generieren. Portale verwenden Portlets als steckbare Komponenten der Benutzeroberfläche, die Informationssystemen eine Präsentationsschicht bieten.

Die Ziele von JSR 168 sind folgende:

  • Definieren Sie die Laufzeitumgebung oder den Portlet-Container für Portlets
  • Definieren Sie die API zwischen Portlet-Container und Portlets
  • Bereitstellung von Mechanismen zum Speichern vorübergehender und persistenter Daten für Portlets
  • Stellen Sie einen Mechanismus bereit, mit dem Portlets Servlets und JSP (JavaServer Pages) enthalten können.
  • Definieren Sie eine Portlet-Verpackung, um eine einfache Bereitstellung zu ermöglichen
  • Ermöglichen Sie die Portabilität von binären Portlets zwischen JSR 168-Portalen
  • Führen Sie JSR 168-Portlets als Remote-Portlets mit dem WSRP-Protokoll (Web Services for Remote Portlets) aus

Die IT-Branche hat JSR 168 weitgehend akzeptiert. Alle großen Unternehmen im Portalbereich sind Teil der Expertengruppe JSR 168: Apache, ATG, BEA, Boeing, Borland, Broadvision, Citrix, EDS, Fujitsu, Hitachi, IBM, Novell, Oracle , SAP, SAS Institute, Sun Microsystems, Sybase, TIBCO und Vignette. Die Liste der offiziellen Unterstützer ist noch länger.

Derzeit befindet sich JSR 168 in der öffentlichen Überprüfung und die endgültige Version ist für September 2003 geplant.

In diesem Artikel definieren wir zuerst Portale und Portlets und erläutern dann die Konzepte, die JSR 168 einführt, einschließlich der Basisobjekte der API. Als Nächstes gehen wir auf die erweiterten Funktionen des JSR ein, z. B. Benutzerinformationen, Lokalisierung und Caching. Anschließend werden die Erweiterungspunkte behandelt, mit denen Portalanbieter die derzeit in der Portlet-Spezifikation definierten Funktionen erweitern können. Der Artikel schließt mit der Beschreibung der Verpackung und Bereitstellung von Portlet-Anwendungen.

Lesen Sie die gesamte Serie in der Portlet-Spezifikation:

  • Teil 1: Machen Sie Ihre Füße mit den zugrunde liegenden Begriffen und Konzepten der Spezifikation nass
  • Teil 2: Die Referenzimplementierung der Portlet-API enthüllt ihre Geheimnisse

Grundlegende Definitionen

In diesem Abschnitt werden die in der Portlet-Spezifikation verwendeten grundlegenden Definitionen erläutert, einschließlich der grundlegenden Architektur eines Portals, des Portlet-Containers und einer Portalseite.

Portal

Ein Portal ist eine webbasierte Anwendung, die Personalisierung, Single Sign-On und Inhaltsaggregation aus verschiedenen Quellen bietet und die Präsentationsschicht von Informationssystemen hostet. Bei der Aggregation werden Inhalte aus verschiedenen Quellen in eine Webseite integriert. Ein Portal verfügt möglicherweise über ausgefeilte Personalisierungsfunktionen, um Benutzern angepasste Inhalte bereitzustellen. Portalseiten können unterschiedliche Portlets enthalten, die Inhalte für unterschiedliche Benutzer erstellen.

Abbildung 1 zeigt die grundlegende Architektur eines Portals. Die Portal-Webanwendung verarbeitet die Clientanforderung, ruft die Portlets auf der aktuellen Seite des Benutzers ab und ruft dann den Portlet-Container auf, um den Inhalt jedes Portlets abzurufen. Der Portlet-Container stellt die Laufzeitumgebung für die Portlets bereit und ruft die Portlets über die Portlet-API auf. Der Portlet-Container wird vom Portal über die Portlet-Invoker-API aufgerufen. Der Container ruft Informationen über das Portal über das Portlet Provider SPI (Service Provider Interface) ab.

Seite

Abbildung 2 zeigt die grundlegenden Komponenten der Portalseite. Die Portalseite selbst stellt ein vollständiges Markup-Dokument dar und fasst mehrere Portlet-Fenster zusammen. Zusätzlich zu den Portlets kann die Seite auch aus Navigationsbereichen und Bannern bestehen. Ein Portlet-Fenster besteht aus einer Titelleiste mit dem Titel des Portlets, den Dekorationen und dem vom Portlet erzeugten Inhalt. Die Dekorationen können Schaltflächen enthalten, mit denen Sie den Fensterstatus und den Modus des Portlets ändern können (diese Konzepte werden später erläutert).

Portlet

Wie oben erwähnt, ist ein Portlet eine Java-basierte Webkomponente, die Anforderungen verarbeitet und dynamischen Inhalt generiert. Der von einem Portlet generierte Inhalt wird als Fragment bezeichnet, ein Stück Markup (z. B. HTML, XHTML oder WML (Wireless Markup Language)), das bestimmten Regeln entspricht. Ein Fragment kann mit anderen Fragmenten zu einem vollständigen Dokument zusammengefasst werden (siehe Abbildung 3). Der Inhalt eines Portlets wird normalerweise mit dem Inhalt anderer Portlets aggregiert, um die Portalseite zu bilden. Ein Portlet-Container verwaltet den Lebenszyklus eines Portlets.

Webclients interagieren mit Portlets über ein vom Portal implementiertes Anforderungs- / Antwortparadigma. Normalerweise interagieren Benutzer mit Inhalten, die von Portlets erstellt wurden, indem sie beispielsweise Links folgen oder Formulare senden. Dies führt dazu, dass Portlet-Aktionen vom Portal empfangen werden, die dann an die Portlets weitergeleitet werden, auf die die Interaktionen des Benutzers abzielen.

Der von einem Portlet generierte Inhalt kann je nach Benutzerkonfiguration des Portlets von Benutzer zu Benutzer unterschiedlich sein.

Portlet-Container

Ein Portlet-Container führt Portlets aus und stellt ihnen die erforderliche Laufzeitumgebung zur Verfügung. Ein Portlet-Container enthält Portlets und verwaltet deren Lebenszyklen. Es bietet auch dauerhafte Speichermechanismen für die Portlet-Einstellungen. Ein Portlet-Container empfängt Anforderungen vom Portal, um Anforderungen an die von ihm gehosteten Portlets auszuführen. Ein Portlet-Container ist nicht für die Zusammenfassung des von den Portlets erzeugten Inhalts verantwortlich. Das Portal selbst übernimmt die Aggregation.

Ein Portal und ein Portlet-Container können zusammen als eine einzelne Komponente einer Anwendungssuite oder als zwei separate Komponenten einer Portalanwendung erstellt werden.

Konzepte

In diesem Abschnitt werden die grundlegenden Programmierkonzepte in JSR 168 erläutert, z. B. der Lebenszyklus, die Schnittstelle sowie die Modi und Fensterzustände eines Portlets sowie der Sitzungszugriff, der permanente Speicherzugriff und das Einschließen von Servlets und JSP-Seiten.

Portlet-Lebenszyklus

Der grundlegende Portlet-Lebenszyklus eines JSR 168-Portlets lautet:

  • Init: Initialisieren Sie das Portlet und nehmen Sie es in Betrieb
  • Anforderungen bearbeiten: Verarbeiten Sie verschiedene Arten von Aktions- und Renderanforderungen
  • Zerstören: Portlet außer Betrieb setzen

Der Portlet-Container verwaltet den Portlet-Lebenszyklus und ruft die entsprechenden Methoden auf der Portlet-Schnittstelle auf.

Portlet-Schnittstelle

Jedes Portlet muss die Portlet-Schnittstelle implementieren oder eine Klasse erweitern, die die Portlet-Schnittstelle implementiert. Die Portlet-Schnittstelle besteht aus folgenden Methoden:

  • init(PortletConfig config):um das Portlet zu initialisieren. Diese Methode wird nach dem Instanziieren des Portlets nur einmal aufgerufen. Mit dieser Methode können teure Objekte / Ressourcen erstellt werden, die vom Portlet verwendet werden.
  • processAction(ActionRequest request, ActionResponse response):um das Portlet zu benachrichtigen, dass der Benutzer eine Aktion für dieses Portlet ausgelöst hat. Pro Clientanforderung wird nur eine Aktion ausgelöst. In einer Aktion kann ein Portlet eine Umleitung ausgeben, seinen Portlet-Modus oder Fensterstatus ändern, seinen dauerhaften Status ändern oder Renderparameter festlegen.
  • render(RenderRequest request, RenderResponse response):um das Markup zu generieren. Für jedes Portlet auf der aktuellen Seite wird die Rendermethode aufgerufen, und das Portlet kann Markups erstellen, die vom Portlet-Modus oder Fensterstatus, den Renderparametern, den Anforderungsattributen, dem persistenten Status, den Sitzungsdaten oder den Backend-Daten abhängen können.
  • destroy():um dem Portlet das Ende des Lebenszyklus anzuzeigen. Mit dieser Methode kann das Portlet Ressourcen freigeben und alle persistenten Daten aktualisieren, die zu diesem Portlet gehören.

Portlet-Modi

Ein Portlet-Modus gibt die Funktion an, die ein Portlet ausführt. Normalerweise führen Portlets unterschiedliche Aufgaben aus und erstellen unterschiedliche Inhalte, abhängig von den Funktionen, die sie derzeit ausführen. Ein Portlet-Modus gibt dem Portlet an, welche Aufgabe es ausführen und welchen Inhalt es generieren soll. Beim Aufrufen eines Portlets stellt der Portlet-Container dem Portlet den aktuellen Portlet-Modus zur Verfügung. Portlets können ihren Modus bei der Verarbeitung einer Aktionsanforderung programmgesteuert ändern.

JSR 168 unterteilt Portlet-Modi in drei Kategorien:

  1. Erforderliche Modi: Jedes Portal muss die Modi Bearbeiten, Hilfe und Anzeigen unterstützen. Ein Portlet muss mindestens den Ansichtsmodus unterstützen, der zum Rendern von Markups für eine Seite verwendet wird. Im Bearbeitungsmodus werden die Einstellungen pro Benutzer geändert, um das Portlet-Markup anzupassen, und im Hilfemodus wird ein Hilfebildschirm angezeigt.
  2. Optionale benutzerdefinierte Modi: Dies sind Modi, die ein Portal möglicherweise unterstützt. In einem optionalen Modus wird ein Portlet möglicherweise nicht aufgerufen. Zu den optionalen Modi gehört der Info-Modus zum Anzeigen einer Info-Nachricht. den Konfigurationsmodus, in dem Administratoren das Portlet konfigurieren können; Edit_defaults-Modus, in dem ein Administrator die Werte des Edit-Modus voreinstellen kann; den Vorschaumodus, um die Vorschau des Portlets anzuzeigen; und den Druckmodus, um eine Ansicht zu rendern, die leicht gedruckt werden kann.
  3. Portal herstellerspezifische Modi: Diese Modi sind in der Spezifikation nicht definiert und daher herstellerspezifisch.

Fensterzustände

Ein Fensterstatus gibt an, wie viel Portalseitenbereich dem von einem Portlet generierten Inhalt zugewiesen wird. Beim Aufrufen eines Portlets stellt der Portlet-Container dem Portlet den aktuellen Fensterstatus zur Verfügung. Das Portlet kann den Fensterstatus verwenden, um zu entscheiden, wie viele Informationen es rendern soll. Portlets können ihren Fensterstatus programmgesteuert ändern, wenn eine Aktionsanforderung verarbeitet wird.

JSR 168 definiert die folgenden Fensterzustände:

  • Normal: Gibt an, dass ein Portlet die Seite für andere Portlets freigeben kann. Dies ist der Standardfensterstatus.
  • Maximiert: Gibt an, dass ein Portlet möglicherweise das einzige Portlet auf der Portalseite ist oder dass das Portlet im Vergleich zu anderen Portlets auf der Portalseite mehr Speicherplatz hat und daher umfangreicheren Inhalt als in einem normalen Fensterstatus erzeugen kann.
  • Minimiert: Gibt an, dass das Portlet nur minimale oder gar keine Ausgabe rendern soll.

Zusätzlich zu diesen Fensterzuständen ermöglicht JSR 168 dem Portal, herstellerspezifische Fensterzustände zu definieren.

Ein Portlet kann in jedem dieser drei Fensterzustände aufgerufen werden, kann jedoch für alle drei Zustände das gleiche Markup erzeugen.

Dauerhafter Speicher

Das Portlet kann mithilfe des PortletPreferencesObjekts persistente Daten für einen bestimmten Benutzer speichern . Einstellungen können in der Aktionsphase gelesen und geschrieben sowie in der Renderphase gelesen werden. Der bevorzugte Modus zum Schreiben von Einstellungen ist der Bearbeitungsmodus, der dem Benutzer einen Anpassungsbildschirm bietet. Die Einstellungen können entweder Zeichenfolgen oder Zeichenfolgenarraywerte sein, die einem Schlüssel vom Typ Zeichenfolge zugeordnet sind. Einstellungen können mit Standardwerten im Bereitstellungsdeskriptor voreingestellt werden.

Die Einstellungen und die Definition des Portlets im Bereitstellungsdeskriptor definieren zusammen ein Portlet, das manchmal als Portlet-Entität bezeichnet wird.

Sitzungen

Das Sitzungskonzept von JSR 168 basiert auf dem HttpSessionfür Webanwendungen definierten. Da Portlet-Anwendungen Webanwendungen sind, verwenden sie dieselbe Sitzung wie Servlets. Damit Portlets temporäre Daten privat in einem Portlet speichern können, ist der Standard-Sitzungsbereich der Portlet- Bereich. In diesem Bereich kann das Portlet Informationen speichern, die für Benutzeranforderungen erforderlich und für eine Portlet-Entität spezifisch sind. Mit diesem Bereich gespeicherte Attribute werden in der Sitzung vom Portlet-Container vorangestellt, um zu vermeiden, dass zwei Portlets (oder zwei Entitäten derselben Portlet-Definition) die Einstellungen des anderen überschreiben.

Zusätzlich zum Portlet-Sitzungsbereich unterstützt JSR 168 den Sitzungsbereich der Webanwendung . In diesem Bereich kann jede Komponente der Webanwendung auf die Informationen zugreifen. Die Informationen können verwendet werden, um den Übergangsstatus zwischen verschiedenen Komponenten derselben Webanwendung zu teilen (z. B. zwischen Portlets oder zwischen einem Portlet und einem Servlet).

Einschließlich Servlets / JSP-Seiten

Um das Model-View-Controller-Muster zu unterstützen, muss das Portlet Inhalte enthalten können, die aus Servlets und JSP-Seiten generiert wurden. Auf diese Weise kann das Portlet als Controller fungieren, eine Bean mit Daten füllen und eine JSP-Seite zum Rendern der Ausgabe einschließen.

In JSR 168 ist der Einschlussmechanismus für Servlets und JSP-Seiten für die Servlet-API identisch. Über den Portlet-Kontext wird ein Anforderungs-Dispatcher für einen bestimmten Pfad abgerufen. Die include()Methode wird dann für dieses Request-Dispatcher-Objekt aufgerufen:

PortletRequestDispatcher rd = getPortletContext (). GetRequestDispatcher (editJSP); rd.include (portletRequest, portletResponse);

Ausrichtung mit WSRP

WSRP aggregiert Inhalte, die von Portlets erstellt werden, die auf Remotecomputern ausgeführt werden, die unterschiedliche Programmierumgebungen verwenden, z. B. J2EE (Java 2 Platform, Enterprise Edition) und .Net. WSRP-Dienste sind präsentationsorientierte, benutzerbezogene Webdienste, die mit Portalen oder anderen Anwendungen Plug-and-Play-fähig sind. Sie ermöglichen es Unternehmen, Inhalte oder Anwendungen bereitzustellen, ohne dass manuelle inhalts- oder anwendungsspezifische Anpassungen erforderlich sind, indem sie Portale nutzen. Portale können WSRP-Dienste ohne Programmieraufwand problemlos zusammenfassen.

Die JSR 168-Expertengruppe hat die Konzepte zwischen JSR 168 und WSRP sorgfältig aufeinander abgestimmt. Die folgende Liste gibt einen Überblick darüber, inwieweit die wichtigsten Konzepte zwischen beiden Standards ausgerichtet wurden: