Um neue Inhalte und Applikationen in ein Portal zu integrieren, war bisher erheblicher Programmieraufwand erforderlich. Portalanbieter und -betreiber müssen hierzu spezifische Portlets entwickeln. Portlets sind aggregierbare, interaktive Anwendungskomponenten zur Integration in Portale. Oft enthalten die Portalseiten eines Anwenders mehrere Portlets. Das Portalsystem agiert bei der Interaktion zwischen dem Portlet und dem Endbenutzer als Intermediär. Ein typisches Beispiel ist das "Market Report"-Portlet. In der Normalansicht zeigt es Aktienkurse verschiedener Unternehmen in Form einer Tabelle an. Die Edit-Ansicht in der Titelzeile des Fensters erlaubt es dem Nutzer, die Aktienliste zu modifizieren. Über das Fragezeichen ruft er die Hilfeansicht des Portlets auf. Weitere Schaltflächen erlauben es, die Größe des Fensters zu variieren.

Die Spezifikation "Web Services for Remote Portlets (WSRP)", die von dem Standardisierungsgremium Organization for the Advancement of Structured Information Standards (Oasis) entwickelt wurde, erleichtert es, entfernte Anwendungen und Informationen in Portale auf der Präsentationsebene einzubinden. Administratoren sollen in die Lage versetzt werden, remoten Content und Applikationen mit wenigen Mausklicks in ein Portal einzufügen, und zwar ohne Programmieraufwand. WSRP standardisiert Web-Services auf der Darstellungsebene und nutzt dabei existierende Standards. Remote-Portlets verfügen über einheitliche Schnittstellen, über die sie die Benutzerinteraktionen verarbeiten und im Portal darstellbare Informationen zurückliefern. Dadurch kann jeder WSRP-Web-Service dynamisch in alle dem Standard entsprechenden Portale eingefügt werden, ohne dass der Anwender die spezifische Implementierung der remoten Datenquellen berücksichtigen muss.

Nehmen wir folgendes Beispiel: Ein Administrator möchte Dienste für Gehalts- und Wetterinfos in ein Firmenportal einbinden. Ein Personal- und ein Wetter-Portlet laufen lokal auf dem Portalserver und greifen auf die entfernten Dienste zu, um die Informationen zu erhalten. Die Dienste liefern Rohdaten, während die Darstellung in speziellen Portlets realisiert ist.

Das Personal-Portlet verwendet einen Service, der Gehaltsinformationen liefert, und stellt das Ergebnis als Markup-Fragment dar. Das Wetter-Portlet präsentiert den lokalen Wetterbericht. Um Gehalts- oder Wetterinfos über lokale Portlets zu integrieren, müsste ein Portalentwickler nun die Portlets speziell gemäß der Schnittstellen des Personal-Web-Services implementieren.

Anwendungs- und Darstellungslogik

Wesentlich einfacher wäre es für den Portalbetreiber, wenn der Personal- sowie der Wetter-Web-Service neben der Anwendungslogik auch die Darstellung umfassen würden, indem sie selbst die Markup-Fragmente erzeugen, die dann vom aufrufenden Portalsystem nur noch zu aggregieren wären. Genau hier setzen die WSRP-Web-Services an: Sie stellen die Darstellung von Informationen zur Verfügung und sind somit leichter integrierbar. Der Portaladministrator bindet die gewünschten WSRP-Dienste ein und benötigt dazu nicht die Hilfe von Entwicklern.

Portlets können lokal in einem Portal zur Verfügung stehen oder entfernt eingebunden werden. Lokale Portlets sind stark mit dem Portal gekoppelt und laufen auf dem Portal-Server selbst. Entfernte Portlets sind auf einem anderen Server im Intranet oder Internet installiert und können als Web-Service aufgerufen werden. Die lokalen Portlets lassen sich durch einen entsprechenden Wrapper als Web-Services anderen Portalen zur Verfügung stellen. Umgekehrt kann der Administrator remote Portlets über lokale Portlet-Proxies in sein Portal einbinden.

Präsentationsorientierte Web-Services

Man unterscheidet zwischen datenorientierten Web-Services und interaktiven, präsentationsorientierten Web-Services. Datenorientierte Services empfangen Anfragen und liefern XML-Nachrichten zurück. Der Servicenutzer muss die empfangenen Nachrichten individuell verarbeiten und selbst eine adäquate Darstellung dieser Daten erzeugen. Während sich dieser Ansatz für statische Anwendungen eignet, müssen Portale in der Lage sein, Inhalte und Anwendungen unterschiedlicher Quellen schnell und einfach zu integrieren. Genau dies erlauben präsentationsorientierte Web-Services; sie beinhalten sowohl die Darstellung als auch die Interaktionsmechanismen, indem sie nicht einfach Daten zurückgeben, sondern fertige Markup-Fragmente erzeugen, die auf einfache Art und Weise von Portalen aggregiert werden können.

Dienste- oder Inhalteanbieter können ihre WSRPs in ein globales Verzeichnis eintragen, aus denen sich Portalanwender dann die gewünschten Komponenten heraussuchen.

Gerade große Unternehmen sind darauf angewiesen, dass die verschiedenen Portalinstallationen zusammenarbeiten; in naher Zukunft werden ihre Portale auch mit Kunden- oder Zuliefererportalen kommunizieren müssen.

Hilfreich wäre es dann, wenn ein Administrator Portlets als WSRP-Dienste publizieren könnte, denn das würde die Portalverwalter bei Partnerfirmen oder Klienten in die Lage versetzen, diese ohne großen Aufwand in ihre eigenen Web-Oberflächen einzubinden (fn).

*Thomas Schaeck ist Architect Websphere Portal, Carsten Leue ist Chief Programmer, Richard Jacob ist Experte für Web-Services-Standards und Peter Fischer ist Web-Services-Spezialist bei IBM Deutschland Entwicklung in Stuttgart.

Angeklickt

Die Spezifikation "Web Services for Remote Portlets (WSRP)" ermöglicht es, interaktive, präsentationsorientierte Web Services ohne Programmieraufwand in Portale zu integrieren. Damit entfällt für Anwender beziehungsweise Softwarehersteller das bisher erforderliche Entwickeln dienstespezifischer Portlets. Darüber hinaus ermöglicht es WSRP, Portale zu verbinden, die auf Software von verschiedenen Herstellern aufsetzen.

Standard im Herbst

Das Oasis WSRP Technical Committee (TC) hat die "WSRP 1.0 TC Specification" im April 2003 verabschiedet und zur öffentlichen Begutachtung freigegeben. Diese endete im Mai. Die Einreichung als offiziellen Oasis-Standard ist für Juli geplant. Mit einem anerkannten Standard rechnet die Branche für das dritte Quartal dieses Jahres. Folgende Firmen haben angekündigt, die Spezifikation in ihre Produkte zu implementieren: Bea, IBM, Oracle, Plumtree, SAP und Vignette.